A Crypto Trick That Makes Software Harder to Reverse-Engineer | Hacker News Reader

A Crypto Trick That Makes Software Harder to Reverse-Engineer

wired.com

93 pointspron56 comments

encrypts software code such that it’s only decrypted by the computer’s processor at the last possible moment before the code is executed.

I have heard this phrase repeated so many times in the advertisements for protectors/packers that it's become almost cliche. Such techniques have been around for over 20 years. Using the debug registers to store the decryption key is relatively well-known - and defeatable (this is 5+ years ago):

http://reversinglabs.com/newsroom/blog/lockpicking-telock.ht...

On the other hand, I like how the article presents the negative aspect too - that security features can be used to make systems secure against their owners is a point that I definitely believe needs to be more prominent among the public.

Also, does the scheme unencrypt the code to be run into what memory segment? What does this technique mean for current memory protection methods?

We do have nowadays non-executable stack, and heap by default. In fact, only the marked read only segments can contain runnable code, unless if you use specific workarounds. What happens if the code you are protecting and running is more complex, requiring calls where you would usually use position independence and stuff like ASLR to full extend? Do you lose these the benefits or those features, or is there necessary information leak (take a look at plt for instance)?

To add to this that in the end of the day if you can access both the data and the key it is just highly complex obfuscation, I am hardly impressed.

Yes, they are making systems secure against their owners. Decrypting binaries just before executing means writable memory pages that becomes executable. For my security, I would like that only a couple of "blessed JIT VM" (io.js, jre) were allowed to perform this kind of change to memory pages.

Ah. Reading the actual abstract[1] makes clear this relies on TRESOR. TRESOR, in turn, relies on storing the key in _debug registers_[2]. I suppose the Hypervisor part of HARES is mostly to protect those registers.

Of course, reporting that would require actual research, as opposed to the breathless rehashing of wired. About 30 seconds of it, but clearly too much.

[1] http://opencfp.immunityinc.com/talks/64/ [2] https://www.usenix.org/legacy/event/sec11/tech/full_papers/M...

Sorry. Couldn't find the actual paper. Can you explain that TLB-split technique?

EDIT: Nevermind. Got it:

The idea is probably to make sure D-TLB is pointed at the encrypted code so that the decrypted code (switched to I-TLB after decryption) can't be read, only executed.

* https://www.blackhat.com/docs/us-14/materials/us-14-Torrey-M...

* http://www.cse.iitd.ernet.in/~sbansal/csl865/readings/self-c...

I knew from the headline that this was clickbait and nearly fell for it before reading your comment. Thanks for linking to the underlying research and summarizing it.

Debug registers require ring 0, so tresor would be restricted to (most generously) applications with kernel help, right?

Yes.

Causing a TLB-Split requires ring 0, too.

By occupying the x86 debug register with key data, what impact does it have on a computer? Are they completely optional to the normal everyday operation?

You should read the TRESOR paper. It's amazingly well done and explains everything. They go on to try to attack it many ways and check its security. They then patched a hypervisor with TRESOR, so that you can run any OS but still benefit from it. Really neat work. GP, thanks for posting that link.

Debug registers are used for debugging, to set hardware breakpoints. They aren't really needed, as most debuggers use software breakpoints anyways.

If you're not doing debugging with hardware breakpoints, they're not used.

Intel's SGX is just a hardware generation away. This allows for encrypted code to run inside hardware protected regions called enclaves - the memory regions are encrypted and decrypted as they are pulled into the core.

In a curious design decision, SGX allows the code in the enclave to access all the memory of the process it's associated with so it can do whatever ugly stuff it wants.

Can we have proof carrying encrypted code? Or perhaps a trusted code verifier that's not encrypted that runs in an enclave too?

https://software.intel.com/en-us/blogs/2013/09/26/protecting... http://theinvisiblethings.blogspot.co.uk/2013/08/thoughts-on...

> But taking advantage of that feature requires a five-figure-priced JTAG debugger

Reading RAM in a running system (even a "hardened" one) is easier than most think. Micah Elizabeth Scott's work on the Nintendo DSi [1] is an excellent example: with a budget of just $500 and a month or two of work [2] she could read a video stream out of RAM as it was being DMAed to/from the camera [3].

I can't even begin to describe how impressed I am with Micah's work, but cloning her FPGA tool from GitHub [4] and repeating the feat for a relatively static segment of executable code on a system that's less physically hardened against tampering, that seems trivial to me in comparison. Certainly doable with $500 and a couple of weeks time.

1. http://scanlime.org/2009/09/dsi-ram-tracing/

2. https://twitter.com/scanlime/status/562925122106191873

3. http://hackmii.com/2009/09/dsi-ram-tracing-camera/

4. https://github.com/scanlime/ram-tracer

Or use Firewire

http://www.hermann-uwe.de/blog/physical-memory-attacks-via-f...

I developed exactly this type of software, like 5 years ago. This is just click bait.

There are numerous ways to pack, and unpack code. It's really going nowhere tbh. It is mostly a meta-game between you and the person you'd expect to be RE your code. You think he's going to use a vm to RE? Then you prevent your code from running in that vm. You leave red herrings - like obscuring control flow, disabling ability to set breakpoints, delay unpacking, and phantom unpacking (where it only truly unpacks a certain percentage of the time)

There will NEVER be a way to prevent RE, and there will never be true polymorphic code. The world is still flock with people fluent in ASM and low level debugging, and all code will revel itself. Commercial protection suites aren't even where the real tricks come into play, malware and 'anti anti-virus' packers, are at the forefront of ingenuity. Even when the hardware is a part of the protection (a la Xbox) it still means nothing. I've seen some nasty stuff done to electronic payment devices by rather unsophisticated people, and those are some of the most hardened systems available (think self destruct if the casings are opened, or if JTAG is conntected)

Hopefully you're right. For me this kind of endeavor sounds like a nightmare, being the absolute opposite of openess, open source, free standards and customer rights. All those "security" argumentations seem only a means to implement further undemocrative deployments.

Even the title reads like spam...

"Reverse engineers hate him!"

"One weird crypto trick to burn reverse engineers"

Wouldn't this scheme be entirely susceptible to an emulation-based attack? You'd need an emulator which could do the split TLB trick but it doesn't sound particularly hard.

They say in the article that an attack that has the foresight to mess with the software from the beginning can win. The use case seems to be, load the key in while the system is uncompromised (just booted off fresh media), and then you don't have to worry about it being compromised later, after it's processed untrusted data from the internet.

My thoughts exactly, unless they're using undocumented features of the CPU.

Wouldn't using said undocumented features make it easier to emulator devs to reverse engineer and implement those features in the emulator?

-"Should we ask from some known reverse engineer if this is true?"

-"Of course not, why would a DRM vendor lie about whether the DRM can be cracked of not?"

-"A good point!"

This article is right up there with 'one simple trick to whiten your teeth, dentists hate it!'

How, precisely, does one store a decryption key on the CPU for longer than the duration of the programming running (and never have it swapped out to RAM when making syscalls and handling interrupts, to boot)? Plus, where is the decrypted instruction stored? IP typically points at some place in memory. Not to mention the many different VMs which would let you pull the values of registers right from the virtual CPUs. HARE brained scheme indeed.

There's a number of techniques.

Mostly they have to do with abusing the debug registers.

http://en.wikipedia.org/wiki/TRESOR

I cant find any specifics for this implementation though.

https://www.syscan.org/index.php/sg/speakerlist

It's indeed TRESOR-based. See http://opencfp.immunityinc.com/talks/64/

TRESOR would rely on the user applying a kernel patch (I don't believe it's broadly disseminated yet), and if you wanted to run more than one HARES based program, well, you couldn't (unless they rely on a single key for all HARES applications, which opens them up to having their private key posted on pastebin). Plus, the decryption key would have to be stored in the binary somewhere, unless they want to provide custom dongles which would provide the key to the hardware directly.

As for blocking GDB and its ilk, the knowledge of how to disable ptrace blocking in executables is already fairly broadly disseminated on the internet.

I also don't see it working around the VM problem (short of saying "I don't run in VMs, period", which would severely limit the reach of such binaries).

Interesting idea in theory, but without significant changes to the underlying hardware or kernels, I don't see it functioning in practice (yet). It has the capability of blocking your casual user from accessing the application, but the folks they seem to really want to defend against would have few problems working around these limitations.

It's certainly DRM and thus broken.

The question is how broken relative to other DRM.

Couldn't they just store keys and decrypt instructions using something like a Trusted Platform Module?

There are a couple of problems with that. The first is that many devices don't have a TPM and there is no point in bothering if using it is optional.

The second, and this is the one that kills half the stuff people think a TPM would be good for, is that it assumes every TPM implementation everywhere is secure. Reverse engineer finds one device with one vulnerability and you lose. Someone who finds a vulnerability doesn't even need to disclose what it is so you can fix it, they just start selling TPM keys for Bitcoin that anyone can use to emulate a device with a TPM.

TPMs have already been broken, Christopher Tarnovsky showed that for some Infineon TPM. I find it suspect that Lenovo, for instance, is making sure they have truly hardened TPMs. Even dedicated HSMs like the Chrysalis Luna CA3 (I own one) have been broken: http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-592.pdf

Isn't this trivially (for some definitions of trivially) defeated by running it inside a virtual machine?

You don't need an expensive JTAG device when the virtual machine gives you that ability for free.

We have a winner! Yes.

People have been hiding crypter variables in debug registers since… the early 90s was the first I saw it? Sure it might have tripped up those who thought SoftICE was the bee's knees, but those of us who had access to (or wrote) emulating debuggers - which had "debug registers" and a functioning "MMU" just fine - sailed right through this sort of thing and could just read the obfuscation code and adapt it to dump the unencrypted code right out.

Hell, with this, we wouldn't even have to translate/recompile bytecode, the MMU did all the work.

Yes, however I'm not aware of any virtual machine (including emulators) for x86 that isn't trivially detected.

But the VM detection has to occur BEFORE you setup the clever encrypted CPU stuff so that code is then vulnerable to the usual debugger cracking techniques (without worrying about the encryption stuff).

Deadlisting. :)

Competitive advantage from tool exclusivity.

The article, and possibly the author of the code, incorrectly define Fully Homomorphic Encryption. FHE doesn't have much to do with obfuscation. Formally, its the task of making the ciphertext malleable so that you can perform addition and multiplication on it such that these operations are translated over to the plaintext as well, thus allowing servers to operate on encrypted data without knowing what they're operating on.

The techniques used in FHE have been applied to obtain Indistinguishability Obfuscation, but that's not the intuitive notion of obfuscation, and the intuitive black box obfuscation for general functions was proven to be impossible over a decade ago.

Any program that wants to use its crypto trick needs to somehow place a decryption key in a computer’s CPU __when the application is installed__.

Huh?

Do CPUs come with persistent storage now?

XBox360 stored a unique crypto key in ROM inside the CPU. No one cracked it. Though the DVD drive firmware was insecure.

I see news articles that say Christopher Tarnovsky says he has compromised the key storage on the 360, in 2010:

http://www.networkworld.com/article/2243700/security/black-h...

But I don't see any actual details.

> “This is something you can stick on your existing computer to protect your existing software.”

Let me adjust your expectations accordingly. I will not be sticking your software on my computer, at least willingly.

The Xbox 360 had encrypted code (decrypted on cache-line fill) years ago. Also vanilla R/W RAM (for the hypervisor state, and other sensitive things). Done in hardware, very fast.

If it runs it will be defeated (if reversers get enough motivation). This technique of decrypting the code only when it is needed is more than decade old. For example, Armadillo's CopyMem II [1] used that technique in 2002. Current state of the art in software protection is the combination of all available methods like code obfuscations, embedded virtual machines, "code splicing", "imports elimination", "stolen bytes", anti-debug tricks, etc. But again, if it runs it can be defeated.

[1] - http://www.woodmann.com/forum/showthread.php?4027-Armadillo-...

Because Security By Obscurity is so totally THE solution.

Note that reverse engineering is also used for very legitimate reasons. For example for interoperability. In a lot of jurisdictions it is absolutely legal to reverse engineer for such purposes.

It's just security by obscurity and I'm sure as soon as hackers can profit from reverse engineering such code, they will reverse engineer it.

If you want to look and see how to make your code less exploitable just look at the security layers of iOS.... the jailbreakers seemed to have documented it quite well. It has this, ASLR and a bunch of other stuff

Also this article sucks

Is it the one strange trick that will make my soft ware harder?

Skype version 2.x.x through to version 5.x.x.x utilized this technique - it's nothing new.

lol; this is how tools that "protect" PHP code work, one such tool is IonCube. And, best part, you can decrypt that code by doing an strace of the code running through PHP; the result being the encryption key.

Does it run on Windows?

Only from the scroll bars.

Best reply ever.

can you explain the joke please! =) it flew right over my head

Recently (yesterday I think) an exploit was released for Windows which works from Windows 10 all the way back to Windows XP. The title of the article was something about "One bit to rule them all" because it only took one bit to trigger the exploit. It had something to do with running a program with scroll bars, and giving Windows invalid parameters for that scroll bar.

This way, when you are a normal user on a computer, you could get system permissions (higher than admin!) by running their exploit. It wasn't quite changing a single bit as they claimed, you had to develop (or run) a program that exploited the bug, but scroll bars were the key. That's the joke here I think ;)

Ah! thank you =)

got it.

Reply on news.ycombinator.com