Slashdot Mirror
New Encryption Method Fights Reverse Engineering
New submitter Dharkfiber sends an article about the Hardened Anti-Reverse Engineering System (HARES), which is an encryption tool for software that doesn't allow the code to be decrypted until the last possible moment before it's executed. The purpose is to make applications as opaque as possible to malicious hackers trying to find vulnerabilities to exploit. It's likely to find work as an anti-piracy tool as well.
To keep reverse engineering tools in the dark, HARES uses a hardware trick that’s possible with Intel and AMD chips called a Translation Lookaside Buffer (or TLB) Split. That TLB Split segregates the portion of a computer’s memory where a program stores its data from the portion where it stores its own code’s instructions. HARES keeps everything in that “instructions” portion of memory encrypted such that it can only be decrypted with a key that resides in the computer’s processor. (That means even sophisticated tricks like a “cold boot attack,” which literally freezes the data in a computer’s RAM, can’t pull the key out of memory.) When a common reverse engineering tool like IDA Pro reads the computer’s memory to find the program’s instructions, that TLB split redirects the reverse engineering tool to the section of memory that’s filled with encrypted, unreadable commands.
Just another step along the road of "We own your computer, not you."
Are the TLB registers not accessible via JTAG?
I did a technological solution similar to this where the TLB split was done in ring -1 (VMX/SMM). Ridiculously easy to decrypt and execute on the fly only as a given page is executed. Really fast. Key exchange happens in ring -1 with an external licensing server. The only way to defeat my mechanism is to get into ring -1 before I did which of course is possible to do. No DRM system is perfectly secure. But this was orders of magnitude more difficult than your average system. If you attached a debugger to the protected process, you literally would see the encrypted opcodes. You could single step and execute as normal but the executable code was always encrypted from the user's perspective because data reads would always return the encrypted code whereas instruction reads would always be decrypted.
The biggest problem I had with this technology actually happened to be the compiler. Some compilers like to mix read-only data into code segments. It wasn't an impossible solution to fix, but it was the biggest headache.
Its possible, but entirely unlikely. There is going to be a massive performance hit. What they can do is encrypt RAM with the key directly in the CPU, something modern computer support.(See unmerged TRESSOR patches). They can then decrypt the data with hardware instructions(AES-NI), as they move main memory to the cache, either on die, on the motherboard which cannot be easily removed.(not within the timespan for coldboot attacks). harder to break does not mean unbreakable as well. If the operating system is rooted, it migh be very well easy enough to get the key from the CPU(AES is symetric, and no CPUs have HW implementations of asymetric ciphers.). If the key is burned when the CPU is made, it would be an industry-wide key. All it would take is one leak, one time, and everyone can now decrypt memory.
Sounds like all you need to analyze this, is a "fake" processor.
EG, running this inside something like BOCHS, which has a built in x86 debugger, and runs a lot like a hypervisor. This encryption would need to be able to detect living inside a fully emulated system and simply refuse to operate in order to be safe from this kind of analysis. BOCHs will let you step through exactly what instructions the emulated CPU is actually doing, regardless of the data that is stored in the memory allocated to the emulator's process.
Don't get me wrong-- this makes a nasty bump in the road for career data thieves, but forensic analysis of the encryption is not completely thwarted.
Well that depends a bit. It would be moderately difficult with VMware since there aren't good facilities to get after what you are looking for. It would be easier on Bochs which has integrated VM debugging. Although with good obfuscation it is still difficult. But as I mentioned above in my post, this kind of a system isn't impossible to break, just more difficult.
Back before DVD drm was generally broken with DeCSS, I had my own mechanism for breaking DVDs It was cumbersome but it worked. I would use a software DVD player to unlock the DVD drive. I had hardware acceleration for the DVD decoding itself. This meant that 90% of the CPU time that was in use was mostly spent doing decryption. So I would attach a debugger, and randomly break in and statistically speaking it wouldn't take me long to catch the decryption function in action. From there it was trivial to find the key and once I had the key I could externally decrypt the DVD.
You could do a similar thing for this kind of a problem. If you are in ring -1, statistically speaking there is a good chance you are running the decryption algorithm. Once you find that, it isn't too hard to trace back to the decrypt init function and extract the key.
This is part of the reason I gave up on (making) DRM stuff. No matter how hard you make it, it's always easy to crack with the right know how and tools. ANYTHING drm and be cracked. Wanna play with my netflix downloader?
Back before DVD drm was generally broken with DeCSS, I had my own mechanism for breaking DVDs It was cumbersome but it worked.
Me too. I electrically emulated a LVDS flat panel and reconstructed the high resolution image from the LVDS.
Works great for BluRay encryption, and for projectionist monitor screens in movie theaters, too, since the flat panels themselves are *after* the content decryption.
I am the author of Loop-Amnesia, a system similar to TRESOR, but more sophisticated in that it supports multiple encrypted volumes. After looking over the article, it does not appear that this is at all similar. It also does not appear to protect against the cold boot attack as claimed.
The authors claim a 2% performance reduction. Such a reduction implies that the instructions are not being decrypted literally on-the-fly; the reduction would be much more severe then. They're using a tactic called a "TLB split", which corrupts the cached page table so that reading memory gets you different results from executing it. A page of executable code is likely decrypted with a key stored in the CPU, put in a different physical page, and then the TLB split is performed so that executes go to the other page while reads still go to the encrypted page.
The cold boot attack dumps physical memory. This tactic corrupts virtual memory to frustrate analysis. The executable code is still stored in RAM somewhere, just not somewhere where you can get to it by reading from a virtual memory address. The cold boot attack would still work fine.
Finally, TRESOR and Loop-Amnesia are not broken. TRESOR-HUNT only works if you enable DMA on your FireWire bus. You shouldn't be doing that anyway.
vi ~/.emacs # I'm probably going to Hell for this.