SoylentNews is people
SoylentNews
from the cracker-jack-anti-crack-hack dept.
Software reverse engineering, the art of pulling programs apart to figure out how they work, is what makes it possible for sophisticated hackers to scour code for exploitable bugs. It’s also what allows those same hackers’ dangerous malware to be deconstructed and neutered. Now a new encryption trick could make both those tasks much, much harder.
At the SyScan conference next month in Singapore, security researcher Jacob Torrey plans to present a new scheme he calls Hardened Anti-Reverse Engineering System, or HARES. Torrey’s method encrypts software code such that it’s only decrypted by the computer’s processor at the last possible moment before the code is executed. This prevents reverse engineering tools from reading the decrypted code as it’s being run. The result is tough-to-crack protection from any hacker who would pirate the software, suss out security flaws that could compromise users, and even in some cases understand its basic functions.
http://www.wired.com/2015/02/crypto-trick-makes-software-nearly-impossible-reverse-engineer/
(Score: 5, Interesting) by frojack on Wednesday February 18 2015, @05:23AM
I've heard that a lot of the vulnerabilities are found by fuzzing techniques, shooting random data through the software till it misbehaves, or takes a different branch, and then looking at what caused the instruction pointer to jump to the unexpected address.
Most of this can be done with modern instruction level debuggers. At that level, you are running machine assembly level code, and you can get there with test harnesses that freeze things when ever instruction pointer gets to the offset you are interested in. By that time, it would already be decrypted in memory for you.
Removing the encryption would also seem to be not that hard, because the instructions have to be in clear text when passed to the processor, and you could record each instruction as it goes by. To have any kind of performance, you would have to decrypt blocks of code, put them in a non-execute-protect memory segment and begin execution. Those blocks would have to be size-able chunks of code or you would spend more time decrypting and loading than executing the code. So you could grab huge chunks of code at once.
Seems like a short term gain if you ask me.
No, you are mistaken. I've always had this sig.