
A Crypto Trick That Makes Software Harder to Reverse-Engineer - pron
http://www.wired.com/2015/02/crypto-trick-makes-software-nearly-impossible-reverse-engineer/
======
userbinator
_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...](http://reversinglabs.com/newsroom/blog/lockpicking-telock.html)

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.

~~~
erglkjahlkh
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.

------
groby_b
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/](http://opencfp.immunityinc.com/talks/64/)
[2]
[https://www.usenix.org/legacy/event/sec11/tech/full_papers/M...](https://www.usenix.org/legacy/event/sec11/tech/full_papers/Muller.pdf)

~~~
belorn
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?

~~~
MichaelGG
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.

------
MrZipf
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...](https://software.intel.com/en-
us/blogs/2013/09/26/protecting-application-secrets-with-intel-sgx)
[http://theinvisiblethings.blogspot.co.uk/2013/08/thoughts-
on...](http://theinvisiblethings.blogspot.co.uk/2013/08/thoughts-on-intels-
upcoming-software.html)

------
bjornsing
> 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/](http://scanlime.org/2009/09/dsi-ram-tracing/)

2\.
[https://twitter.com/scanlime/status/562925122106191873](https://twitter.com/scanlime/status/562925122106191873)

3\. [http://hackmii.com/2009/09/dsi-ram-tracing-
camera/](http://hackmii.com/2009/09/dsi-ram-tracing-camera/)

4\. [https://github.com/scanlime/ram-tracer](https://github.com/scanlime/ram-
tracer)

~~~
SixSigma
Or use Firewire

[http://www.hermann-uwe.de/blog/physical-memory-attacks-
via-f...](http://www.hermann-uwe.de/blog/physical-memory-attacks-via-firewire-
dma-part-1-overview-and-mitigation)

------
ziles88
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)

~~~
m8rl
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.

------
zik
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.

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

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

------
wmt
-"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!"

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

------
falcolas
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.

~~~
pstrateman
There's a number of techniques.

Mostly they have to do with abusing the debug registers.

[http://en.wikipedia.org/wiki/TRESOR](http://en.wikipedia.org/wiki/TRESOR)

I cant find any specifics for this implementation though.

[https://www.syscan.org/index.php/sg/speakerlist](https://www.syscan.org/index.php/sg/speakerlist)

~~~
falcolas
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.

~~~
pstrateman
It's certainly DRM and thus broken.

The question is how broken relative to other DRM.

------
ars
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.

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

~~~
Tegran
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).

------
Ar-Curunir
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.

------
moe
_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?

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

~~~
MichaelGG
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...](http://www.networkworld.com/article/2243700/security/black-
hat--researcher-claims-hack-of-processor-used-to-secure-xbox-360--other-
products.html)

But I don't see any actual details.

------
kordless
> “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.

------
kabdib
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.

------
conductor
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-...](http://www.woodmann.com/forum/showthread.php?4027-Armadillo-
and-CopyMem-II-decryption)

------
jwildeboer
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.

------
solomatov
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.

------
pikachu_is_cool
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

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

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

------
testabc1234
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.

------
frozenport
Does it run on Windows?

~~~
kordless
Only from the scroll bars.

~~~
vmulas
Best reply ever.

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

~~~
lucb1e
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 ;)

~~~
glaberficken
Ah! thank you =)

