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.
Recent Intel processors have the ability to use encrypted RAM and only decrypt it in the CPU's caches. They do it with the SGX instructions.
We have had many, many technologies that were supposed to stop reverse engineering.
I remember back in the Apple ][ days, a program called "Lock it Up" by Double Gold Software had anti-reverse-engineering things in it, and was advertised as sending the bad guys packing (one of which was doing "poke 214, 128" which would disable the BASIC prompt). Then we had obfuscators for C++, BASIC, Java, and other languages, same thing.
This technology looks like it will be broken by running it in a VM, so I'm sure the next generation will have anti-VM stuff in it, and someone will just run a Bochs emulator (dog slow, but emulates everything 100%) to bypass that.
My take: How about companies spend money on improving their software instead of playing with DRM which will get broken anyway? In the enterprise, the fear of an audit is good enough to keep people in compliance with Oracle licenses. For games, using CD keys is good enough. They can play locally, but can't go multiplayer without a proper key.
If the code is so sensitive it -has- to be protected, put it in a tamper-resistant appliance, like a HSM.