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.
I assume by "inside the processor" they mean in the L2 or L3 cache. What is to stop someone from extracting the cached keys and decrypting the entire program? I assume they have some mechanism, but does anyone know what sort of mechanism that would be?
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
Is it emulator safe? Would there be any way to determine which instructions are part to the decryption engine and which are part of the application?
Some translation step would be required for an issued binary (e.g an operating system and/or program) to be transformed into locally encrypted "executable" code. Now if there is a mechanism available to a bios and/or an operating system to do this, then ergo, it could be subverted. So why bother?
> That means even sophisticated tricks like a “cold boot attack,” which literally freezes the data in a computer’s RAM
Does the attacker douse the computer in liquid nitrogen, like the T-1000?
Gee, so hardware ICE [In Circuit Debug] and JTAG can't possibly snoop on the processers internal busses. I'll just put my useless ICE tools and JTAG adapters away, they have solved ALL the hacking problems.
Yep, it's impossible to write privileged code to read the TLB, heck, it must be IMPOSSIBLE to even TEST the TLB.
Hint: If it can be TESTED, it can be read.
So obviously, the solution to hacking is, make nothing testable!
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.
To do the job properly would take a processor with encryption support baked in, like Sega's Kabuki, or the into the memory controller as in the XBox. Software encryption or obfuscation is nearly useless.
I've never heard of anyone trying to tweak or read code on the fly like that. In every case I wanted to look at what code a CPU was executing it has been in a virtual machine or emulator.
Does encryption method prevent the code from being run in an emulator?
If not it's like locking the window while leaving the door wide open.
Sure, it will make it harder to climb in through the window, but no-one has ever considered climbin in through the windows since it is easier to just use the door.
How will this hinder current fuzzing techniques to search for vulnerabilities?
I am Bennett Haselton! I am Bennett Haselton!
You don't even need JTAG access, modify one the many opensource VM and then have it log this awesomely secure key.
I envisage some mechanism now placed between CPU and socket that intercepts instructions sent to and from the CPU to be reviewed or even "replayed" at a later time.
I am Bennett Haselton! I am Bennett Haselton!
For some fun, read the comments on TFA, and compare them to the comments here.
Demographic estimations, anyone?
Sent from my ENIAC
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.
Well, this sounds like the attempt to avoid what has been around for years: Dynamic programs
which modify their own code... Tremendously hard to do correctly, but might solve the problem
of people decrypting the static code, and even in a VM/emulator would require a lot of work to
figure out.
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?
AV products will have to kill this dead, because they won't be able to easily detect malware. If it can't be inspected it can't be known to be safe, so I'm going to bet anything using this that isn't whitelisted e.g. by digital signature is going to be DOA.
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...
These kinds of "feel good" measures only amount to more work for devs, and stuff not working when they should.
I'd rather people spent their time writing better and more secure code.
They missed the boat on that acronym, IMO. Change the last word from 'System' to 'Mechanism' or 'Method', and then they'd have HAREM, which evokes the Arabic word for 'forbidden'. (Not that I approve of this DRM chicanery, of course.)
HSJ$$*&#^!#+++ATH0
NO CARRIER
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)
Seriously. Are there really people out there so naive that they think this will pose anything more than a minor inconvenience?
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
What they really want is white box cryptography, but it seems computationally impractical right now.
Also, http://en.wikipedia.org/wiki/T... did this and was broken!
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
how much more difficult is that? My guess is, not very. They have to supply you with the encrypted package, they have to supply you with the key to decrypt it. They have to supply you with the algorithm to decrypt it. Failure to supply all those things means you can't run it. If the goal is to decrypt it and then start reverse engineering it, the software vendor has to distribute everything needed to reverse engineer it, simply by providing everything needed to run it.
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"
Oh I agree there is a demand for them, but I question how well they actually fill the need. I have used several, both in house and commercial, including ones that required special hardware to run, and they all got cracked. The only time they helped even a little was for low value products that were not worth the pirate's time.
And within that, there is usually some weak link that can be exploited. A pirate does not need full understanding of the code base, they just need to track down that one little 'make it run' signal and duplicate that. At some point the program has to ask something, either itself or an external authority, 'can I run?', and there is always a way to say 'yes' otherwise, well, it would not work in the first place.
These 'tools' usually just harden a stage that a pirate is probably not going to be needing to deal with anyway.
It would be a little work, but by simply observing the changes in the register file step by step, you could make some good guesses at what instruction was executed. That gives you a portion of the decrypted executable code. If you can get a few 16 byte blocks (AES blocksize), then you can reverse the key.
The other issue is that the only modes they could likely use to encrypt the data would be ECB, CTR or XTS. There are many known attacks on those modes when you have leaking cleartext.
I said no... but I missed and it came out yes.
"St. Peter don't you call me, 'cause I can't go. I owe my soul to the company store."
They always did own you. ;)
Yes but 'harem' already means something else in English...
I believe that, conceptually, this is right on target. Practically, today's CPU are very noising across the RF spectrum and my guess is that THEY will be able to determine the actual instructions being executed using spectral theory and signal processing techniques. At the cost of performance, additional layers of instruction execution noise could be used to increase the complexity of RF radiation making the cracking mathematically more... challenging.
Still waiting to see some s/w dev in my neighborhood buy a Tesla and get the plate HCF
Have gnu, will travel.
no text
True, but I figure anyone who's going to be savvy enough to be aware of H.A.R.E.M. is going to be familiar with the word's etymology, and make the connection. ...And if a few neckbeards get a chuckle out of it, what's the harm?
HSJ$$*&#^!#+++ATH0
NO CARRIER
Run it in an emulated CPU
That won't work if it gets the decryption keys from the Trusted Platform Module (TPM).
There is no way to make anti RE tool that is uncrackable on current computer architecture.
Write the software in a managed language to prevent buffer overflows. Instead of distributing it to the public, run it only on a server that you control. This "service as a software substitute" principle is suitable for anything that doesn't need very low latency or very high throughput in a mobile use case.