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."
I remember hearing about it being used in Malware back in 2004, when I worked on a research project that used the split-TLB trick for data execution prevention, at Microsoft Research.
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?
Instead of reading it from RAM addresses they'll read it from the cpu cache memory.
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.
That just mean you need better hardware, that gives you debug access to the buffer, or emulates the code step by step in its own little blue pill VM. Anyone trying this for antipiracy is just an idiot, but most of those guys are, so we probably will see it.
Meanwhile, it WILL have merit as encryption- defeating cold boot is a big deal.
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.
Nope, never heard of a VM. There is no way to emulate the CPU, no siree! If it's inside a CPU, it can't get out.
What is this? Zoolander? The files are *inside* the computer?
https://www.youtube.com/watch?...
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?
Vertical markets have severe problems with unauthorized software use (ie: piracy). This will make cracking that software much more difficult.
It's lucky that only the good guys have access to this technology and that malware authors are strictly prohibited from ever using techniques like these, or there would be trouble!
which literally freezes the data in a computer’s RAM
VM's processor has no idea whats up
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?
> “cold boot attack,” which literally
> freezes the data in a computer’s RAM
By "literally" you mean "figuratively", yes?
> 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?
It is through transparency of code that security is achieved, not further obscurity. Someone will figure out how to reverse engineer the code, and people obfuscating code for "greater security" will be lulled into a false sense of security, and write less secure code.
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!
"doesn't allow the code to be decrypted until the last possible moment" AND THEN IT'S DECRYPTING... which means it's accessible, which means it's crackable... There is no way to make anti RE tool that is uncrackable on current computer architecture. I'ts just impossible. Because you can't run any instructions in assembler without decrypting/decoding them to machine languge which can be interpreted by cpu. The only thing that change with systems like denuvo or hermes is the time needed for cracking the protection, they are adding more steps that's all...
That mentioned-in-passing "key" that resides in the CPU. The article is actually honest enough to mention that getting that key into the CPU in the first place is the weak spot in the approach. Anyone who wanted to hack a program would simply pick up that key from whatever artifact is used to deliver the software in the first place and voila, you can now decrypt the software.
The only thing that this approach prevents is someone getting onto a system *after* it has started running some piece of software and accessing the software. There are some scenarios where that might be useful, but it is not the typical scenario for someone looking to reverse engineer a piece of software (said person almost certainly has acquired the to-be-hacked software themselves, in which case they now have the key).
The only way to make an application that runs on a system that is fully under someone else's control secure is to remove critical and hard-to-reverse-engineer pieces of the app's logic and keep them on some piece of inaccessible hardware. For example, I saw a dongle years ago that claimed to be hardened which could run small amounts of Java code. If one could push pieces of one's app into the dongle and have the main app hand data to the dongle when it needed that functionality, that would be secure because the code in question never leaves the secure computing platform. If the operating environment of the app can reach out to the internet, then one can do the same thing via network RPC calls back to some secure server for the critical pieces of logic.
While this is secure, it is has two obvious challenges - which pieces of the app can be extracted that are critical to the app and not easily reverse engineered -and- performance. If the logic is critical and has to be accessed via an Internet RPC call, performance will be limited.
I like how the /. story right below this one contains the line "It is well known at this point that nothing is unhackable...". Just something I noticed.
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.
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.
check out www.trulyprotect.com for more complete industrial solution!
For some fun, read the comments on TFA, and compare them to the comments here.
Demographic estimations, anyone?
Sent from my ENIAC
The proposal is to have the key built into the physical processor, and it does not appear to be something which can be changed.
- this ties the software to a single physical processor.
- to prevent hackers from being able to snag the key, it must not be readable, even by VMs.
This feels like some of the old dongle-based-license-locking.
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.
"Torrey notes that it may someday be possible to encrypt a program’s code in a way that its instructions can run without ever being decrypted—making software that’s truly unhackable. But such a system, known as 'fully homomorphic encryption,' is still largely theoretical."
First, he probably means garbled circuits, not homomorphic encryption. Second, FHE (and other homomorphic schemes) have been implemented. It's the applications and performance tradeoffs that everyone is working on.
If these are merely misquotes, then I feel comfortable continuing to read the paper(s).
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...
Thanks to Windows Japanese OEM's were able to make lots of money by reverse engineering and inventing nothing. China then did the same.
Now guess what, China has all the money and America is going to get locked out of the very technology that itself created... joke
The joke that never ends....
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
any money on how long it will take malware writers to start using HARES to make their code harder to grok?
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.
big deal.. just open the processor chip, stick probes in the right places, run the correct decyption code. done.
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
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"
Before the key is in the CPU internal memory, it needs to be somewhere.
Right...
Had a hell of a time vs. 5 antiviruses (Norton, McAfee, ClamAV, Comodo, Dr.Web, & ) in a SIMILAR situation!
I used mpress by MATCODE (good FREE 64-bit + 32-bit .exe compressor) & it signalled my program -> APK Hosts File Engine 9.0++ SR-1 32/64-Bit http://start64.com/index.php?o... was a "virus"!
Wrong:
In the end? Each RESCINDED their findings as 'false positives'
(Since using such an exe compressor IS NOT A VIRUS @ all whatsoever)
---
I compress executables for 4 reasons:
1.) Compressed exe's load FASTER over a LAN/WAN by far, very noticeably so (& faster from local HDD's too, since the compression/decompression process is offset by the speed of today's CPU's, & since the file is SMALLER on disk & tinier files load up from disks, faster!)
2.) Compressed exe's are HARDER TO "resource hack"
3.) Compressed exe's are HARDER to 'disassemble' (not in memory though - more on that below, which this tech *MAY* help against!)
4.) I test my program @ startup, & IF IT IS NOT THE COMPRESSED SIZE? It will self-terminate (assuming it is infested/infected OR being hacked into in some way (noted above))... since std./classic viruses add size & alter jump tables + tack on code @ the tail of exe's typically? This method works as "built-in" virus protection (I am surprised EVERY coder's not using this technique in fact).
---
* The latter point #4 above, & how I use compression ANOTHER WAY (sizetest vs. alterations) was one I did well/was modded up on here during "Coding for DEFCON" a few years ago here, since it makes sense for the reasons above -> http://it.slashdot.org/comment...
APK
P.S.=> That stuff's all "fine & good" UNTIL you peeked into RAM to look @ the code (ProcessExplorer by SysInternals can do this)
Doesn't HELP then!
Yes - it's great on disk vs. disassembly, but NOT once it's loaded into RAM: This SOUNDS good, let's see them pull it off though, MINUS what you brought up (which in a way, did happen to myself already, hence why I "second your motion")... apk
There is an alternative value than for DRM purposes: Exploit prevention
The value is not in obfuscating the code from reverse engineering, but about protecting the integrity of the code being executed by using the encryption as a way to prevent something as simple as 'jmp ESP' or any other instruction from being meaningful if injected externally, since 'jmp ESP' would be the one-time encrypted version for that block of memory (lets assume some sane mode of AES encryption).
Consider this scenario:
Every instance of the software downloaded was separately encrypted with different keys
or
maybe even better if the the operating system could be modified to leverage this technique to dynamically encrypt the instruction pages of every application that ran dynamically, and managed the keys dynamically in the CPU for every process. In memory, there is never a single representation of any instruction and every instance is different even in memory.
Assuming DEP is enforced also, any kind of buffer overflow would need to know the dynamic encryption key(s) in order to inject the buffer overflow code.
This really sounds like marketing hype to me.
At some point the encryption key has to pass from RAM storage to the CPU. All you need to do is run the code in simulator/virtual machine, and wait for the instructions which loads the key.
In my college days I relished such challenges, the harder the better. I didn't care about the decrypted data or code, the sheer challenge of outsmarting a protection scheme was what drove me. I would spend days, sometimes weeks studying disassembled code. Although I don't bother about those things today, I'm pretty sure you can find a lot of people out there with similar interests.
Once the code and data, DRM based or not has left the manufacturer it vulnerable. At some point the code/data needs to be converted into clear text in order to be usable.
When data is encrypted, e.g. sound or video, it must be converted into clear text, prior to touching the render/playback hardware. All you need to do is to replace the drivers. If the OS requires signed drivers, all you need to do is to patch the sign checking part of the OS.
When code is encrypted, in must be converted into clear text, prior to touching the instruction decoder of the CPU. All you need to do is to replace the CPU with a simulated CPU.
DRM based on cryptography is build on a flawed premise. Cryptography assumes that sender and receiver have a shared goal maintaining a shared secret. In DRM based on cryptography only the sender can be relied on having a goal of maintaining that shared secret. In order for the data/code to be usable the recipient needs to have the ability to decrypt the data/code. Since the recipient controls the execution environment, the recipient will always be able to access the decryption key, it is merely a question of how much effort is required to gain access. No matter of wishful thinking can make that problem go away.
While Intel processors have fully coherent caches, even catching writes to the instruction stream only a few bytes ahead of the IP, the TLB must be explicitly flushed.
Sp it's possible for the DTLB and ITLB to have different mappings.
So the trick is to have the processor executing in an area of invalid virtual pages. Whenever there's an instructon access fault, the code does:
- Allocate a new page, with two virtual addresses: one for execution, and the other for data access.
- Put a single return (0xc3) instruction in the page and call it. This faults in the ITLB mapping.
- Remove the ITLB mapping from the page tables.
- Decrypt the code and put it in the page via the data access alias.
- Return from the fault and resume executing code.
As long as there are no interrupts, debugger traps, or other ITLB-polluting code executed, this will have the processor executing "unmapped" virtual memory due to the "stale" TLB entry.
There are a bunch of variants on that (e.g. you could have in-line code to handle page boundary crossings rather than use the page fault handler), but that's the basic idea.
I was wondering about SMM, but I think it doesn't use the page tables, so they might survive that.
FFS if you really must you can crack it with a box of pencils, pads of paper, an assembly language reference, and a room full of idiot savants.
Only encrypted code for an undocumented CPU can be protected, then you really are just dumping noise into a black box and getting rainbows to come out.
d@3-e.net
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. ;)
Only one winner here, and it's NOT the user.
Sigh.
If the person writing this literally thinks that's the way it literally works, then I literally cannot take this seriously.
If it can be ran on a crackers computer it can be cracked end of story. We've seen everything from online only activation, virtualization, all the way to online only servers when it comes to games and they've all been destroyed completely with ease. Diablo 3 is online only play yet it was cracked with a server emulator created before the game was even fucking out of beta. When are software developers going to learn hardcore DRM is pointless and it only hurts legitimate users. Just take a look at Skybound Stylizer and the issues their VM wrapper causes for legit users.. Did I mention it was still was cracked easily?
Cracking is a game, it's about reputation, showing off ones skill, and the harder the better because people love a challenge.
Harder game = more players fighting to be the first to win.
This will end up being another super ironic torrent.
And how does it defeat being ran on a custom vm that stores the instructions as their executed?
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.