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.
The crackers are going to love breaking this in 1, 2, 3 ...
I keep my code undeadable with a liberal use of goto statements.
Have gnu, will travel.
Just another step along the road of "We own your computer, not you."
Does anyone in the industry who actually works with computers believe these kinds of claims? Such technologies are great for getting buy in from marketing, the legal dept, underwriters, and content owners, but outside making the life of developers more difficult I have not heard of them actually stopping reverse engineering.
The only time these kinds of tools seem to 'work' is when you are producing something which lacks the popularity to be worth the effort, which is not a good sign.
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.
SJW's don't eliminate discrimination. They just expropriate it for themselves.
... somebody exploits this to write malware that's truly a bitch to reverse-engineer.
Are the TLB registers not accessible via JTAG?
Another way to crack HARESâ(TM) encryption, says Torrey, would be to take advantage of a debugging feature in some chips... But taking advantage of that feature requires a five-figure-priced JTAG debugger, not a device most reverse engineers tend to have lying around."
Or running the code in a VM.
Really? This sounds just the same as someone saying that DEP would stop this kind of reverse engineering (the concept seems incredibly similar to me, maybe I'm wrong). If someone wants to reverse engineer software, they will have the tools to do so and, in this modern world, any software thats run on physical hardware but not in a VM must have a limited lifespan.
If all else fails, emulate the machine. Slow, yes, but reverse-engineering and debugging tools need to be incredibly slow anyway.
Sorry, but this is a slashvertisement for something with precisely zero deployments in real-life software that people might want to reverse-engineer.
And, as said, all you've done is make it easier to create malware that's difficult to remove. So, in effect, such facilities in processors will end up being beefed up to take account of this and rendering the technique obsolete.
In all of recorded computing history, every technique for preventing reverse-engineering or debugging has turned out not to work, or to be so onerous on users that nobody ever actually enables it.
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.
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.
C. Sagan : A demon haunted world:
http://www.amazon.com/gp/product/0345409469/
visit randi.org
L2 cache has mechanisms to be read from outside, but L1 does not. L1 is internal to the CPU, and unless they add back doors, it'll be extremely hard to dissect a CPU and use an electron scanning microscope to read the data from the L1 cache. The other issue is cache uses SRAM, which does not use capacitance capacitance to store data like DRAM. Once power is lost, the data goes with it nearly instantly instead of slowly draining.
How will this hinder current fuzzing techniques to search for vulnerabilities?
I am Bennett Haselton! I am Bennett Haselton!
As this, by definition, requires that the encryption key is present in the clear on the machine where the decryption is happening in order to make it possible to decrypt the instructions (CPU cannot execute encrypted code), then it can be trivially circumvented. Finding where the key is stashed is going to be only a matter of time and then the encrypted code can be conveniently decrypted off-line, repackaged without the stupid performance-impeding encryption (caching will suffer badly with it) and released on a torrent somewhere, as always ...
Fundamentally this is not different from doing ROT13 on your code - code obfuscation.
In the article, they mention a JTAG hardware debugger as a possible tool to defeat HARES. Suppose, however, that your reverse engineering environment is a virtual machine, possibly with CPU emulation as well. Couldn't you then do the equivalent debugging in software? What if you write the the VM software specifically to help you out, possibly even just give you the key which the authentic CPU would keep secret?
Can't you just emulate the processor with QEMU and run the app in a sandboxed environment ?
https://github.com/hackndev/qe...
------
https://stackoverflow.com/ques...
JTAG debuggers are a major problem when you really need to protect your IP. It's enough of a hole that I got NetLogic to add an e-fuse to their XLP network processors (+ later generations) that could disable EJTAG.
Blow the e-fuse during ICT on production hardware and you can cut down on RE capabilities a fair bit.
Doesn't really help for general purpose computers, but a very nice for hardening embedded systems.
I honestly don't see how this is anything innovative, this is a known artifact of x86 microarchitecture (it isn't an architectural thing though - and it will not work on all x86 processors*). That it could be used for a copy protection scheme is also obvious to anyone with that level of knowledge.
This, together with things like disabling primed data caches (x86 processors will still allow accesses to caches even when disabled under some circumstances) is a trick that is relatively fragile. And it really doesn't buy much extra security given the existence of a good low level emulator.
(* there are x86 processors with a shared I/D TLB, not commonly in use nowadays though, exercise for the reader ;P)
Venkat!!! Why on God's good name are you passing the reference to a pointer to a function as a construction argument?!?!?! aarggghhhh!
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
To me it looks like this trick has a similar, very simple trick to defeat it:
Assuming you can run some code at kernel (or even SMM) mode, you should be able to scan through all code segments that are marked execute only, and which have a data segment which aliases it? I.e. same virtual address - different physical addresses.
When you find such blocks, you just create new readonly or readwrite mappings which points to the same physical addresses as the decrypted/execute-only memory.
At that point you can dump/debug to your heart's content.
Terje
"almost all programming can be viewed as an exercise in caching"