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.
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?