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.

Comments

Bring it on, folks!

[aaaaaaargh!]

The crackers are going to love breaking this in 1, 2, 3 ...

Re:Bring it on, folks!

[Anonymous Coward]

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.

Re: Bring it on, folks!

[Anonymous Coward]

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?

More of the same:

[Hartree]

Just another step along the road of "We own your computer, not you."

Re:More of the same:

[DocSavage64109]

Assuming this encryption actually works, it probably wreaks major havoc with processor caching and branch prediction algorithms. I'd be interested in seeing benchmarks of this encryption in action vs the non-encrypted version.

Well, that's it...better pack up hackers...

[NotDrWho]

That's it. They've finally come up with uncrackable software. I guess all the hackers will just have to pack their bags and find another hobby now. It was a good many decades while it lasted. But now it's clearly over. Congrats to Jacob Torrey on doing what no one else has ever been able to do! No way this will ever be cracked. He's beaten us all.

No JTAG access?

[Migraineman]

Are the TLB registers not accessible via JTAG?

Does it matter?

[aepervius]

As long as you can hide to the software you are debugging it, you can step by step through it until it is decrypted. So for all the money, all the added complexity, all you won is only a slight bit more time. The only real copy protection is when part of the code is not run locally but on a different remote machine. For example if you have something on a server which needs to be queried and allow you to continue with the software, like some of the online authorization.

Re:Already sloved

[BronsCon]

Is that your goto solution for preventing reverse engineering?

Re:Already sloved

[mr_mischief]

Hardware by Intel, code by Escher.