

An Anti-Reverse Engineering Guide - AndreyKarpov
http://www.codeproject.com/Articles/30815/An-Anti-Reverse-Engineering-Guide

======
mrcharles
As someone who has decided to do all (or most of) his personal coding in
public, I must say the idea of spending time and effort making sure no one
reverse engineers your stuff is kind of funny.

~~~
marshray
I agree. It seems like a big waste of time and energy.

I suspect most of these techniques are defeated in one fell swoop by debugging
the process from kernel mode and/or under virtualization.

At best, you're only going to delay reversers who aren't as experienced as
this high school senior (and can't find articles on codeproject.com).

~~~
DanBC
To be fair he does say clearly that all of these would be reasonably easy to
bypass.

Perhaps he needed a better, but less catchy, title. "Some tricks that will
slightly delay reverse-engineering" or "What I know about making reverse
engineering a little bit harder than it needs to be".

~~~
jonl
If you read past the title and into the article content, you'll see that he
says "In this article, I plan to travel a bit deeper into the interesting
world of reverse engineering and explore some more intermediate level
techniques for annoying reverse engineers."

He's right - these techniques basically just annoy any mildly competent
reverse engineer.

~~~
ChuckMcM
Of course there is the 'knowing you're being reverse engineered and doing
something else'. I don't doubt for a minute people who write sensitive code,
be it malware or DVD decoders, might simply act differently if they thought a
debugger was involved, not so much as not act at all. Some of these techniques
could be used there.

That being said, the more interesting thing is poking around in the inner bits
of the machine and seeing how it comes together. Highly recommended for anyone
serious about wanting to know how the machine does what it does.

If you want to practice on code that is easily obtained I suggest you poke
around the World of Warcraft rootkit code that it uses to prevent people from
cheating at WoW.

~~~
tptacek
Detecting debuggers and altering behavior is so much the oldest trick in the
book that it is actually covered in depth in this Codeproject article
(Codeproject is often unusually well written, and so is this article, but be
clear that this is really basic stuff he's talking about).

------
conductor
Well, nothing new. If it runs, it can be cracked. I say it as a reverser
(legal) with more than 10 years of exp. So, instead of investing money/time
into the protection mechanisms, it's better to use the resources to improve
your software. Yet well-thought custom protection (i.e. not ASProtect,
Armadillo, etc..) can be harder, but it's all the same crackable.

~~~
timsally
It is true the techniques in the article are nothing new. However, this
comment is a knee jerk reaction and largely misleading. The notion that
something being crackable is a failure is incorrect. The time a protection
scheme needs to hold up varies depending on the industry, but the economics of
DRM to not require it to last forever. For video games it's a month or two
(Starcraft 2 sold 75% of total copies told to date within the first month).
Also, there are several DRM schemes deployed in production today that are
acknowledged by those in the field as quite effective, namely BD+ and
DirecTV's scheme. Indeed, as far as I know there hasn't been a break in
DirecTV for over half a decade.

As far as malware goes, virtualization obfuscators are the current state of
the art. They are a fundemental advancement in packing. Up until
virtualization obfuscators, all other packers had the weakness where at some
point the unprotected program would end up in memory. This weakness is easily
exploitable (ala VxClass, see Recon 2010 for an easily digestible talk).
Virtualization obfuscators are still beatable with manual reverse engineering
(see Rolles WOOT 2009) and some effort has been made to automate the process
(see Wenke Lee's group at Oakland 2009). But when a packing scheme forces you
to hire reverse engineers who know what symbolic execution is, you know that
you've substantially raised the bar.

~~~
bri3d
I'm not sure DirecTV's scheme is entirely relevant, because it revolves around
protected hardware rather than protected software.

The idea behind DirecTV is that the crypto code runs entirely in hardware the
user can never see, heavily protected physically - a protection method which
isn't possible for software on most modern x86 machines. Plus, satellite
providers have a distinct advantage in that their content needs to be
protected only in real time.

I do give kudos to DirecTV for managing to create a technology that's less of
a sieve than Nagravision (although that might also have to do with DirecTV
suing everyone who dared go near their smartcards into oblivion in the early
2000s), but they play a totally different (and, IMO, much easier) game than
software protectors do.

As for BD+, with HDCP broken so widely I don't really see a point to breaking
it. Scene groups can source movies of equal or greater quality from many other
sources, even using decrypted HDMI as a last resort, before needing to care
about actually exploiting the BD+ VM.

~~~
joezydeco
_"Plus, satellite providers have a distinct advantage in that their content
needs to be protected only in real time."_

I could be wrong here, and it's been a while since I missed with Echostar/Dish
hardware, but DVR recordings are stored on the hard drive in raw, encrypted
form and then played back through the decryption hardware.

~~~
bri3d
Yet another mistake Dish made - IMO, every iteration of Nagravision is end-to-
end pretty poorly implemented.

At any rate, I was speaking more to the practical aspects than the technical
ones. In the eyes of a DRM writer, a game needs to be protected for at least a
few weeks (launch purchase window), and once it's cracked once, it's pretty
much the end - the game is in the wild, and the damage is done, because what's
being pirated is _the game itself_.

On the flip side, what satellite providers are protecting isn't really the
_content_ \- it's the ability to display the content in at a certain point of
presence as a stream. Public exhibition (bars, clubs) and live PPV fights are
the big game for satellite encryption, not Joe Public (or Joe Pirate) watching
his shows. They'll be available to pirates immediately after they're aired
through other means (stations, screeners, stripping HDCP off of HDMI) anyway.

That's why I think the satellite game is easier - not technically, but
practically. As a satellite TV provider, even if your DRM can be removed post
facto, the benefit to the pirate is greatly diminished (and the downside to
you, as well).

------
mwexler
Impressive article by a current high school senior; I wish I wrote at this
level in high school!

Note that it is from 2008.

~~~
tptacek
There is something about high school seniors and low-level code like this.
From numerous observations over the last 15 years or so. I think it might be
because your first 5 years in the profession serves in part to teach you what
technical issues to be "scared" of, and high school kids haven't learned that
yet.

~~~
marshray
I certainly did my lowest level stuff (building PC ISA hardware from scratch)
in high school. Mainly it was out of necessity as I didn't have the money for
the real hardware. Other folks I've known who have gotten into ASM in high
school did so for game cracking/cheating/modding, also a form of necessity.

Any* sane professional development organization is going to try to minimize
the amount of time their developers spend writing ASM by hand. There's almost
always a higher level tool that's more productive.

* Actually, I worked at a place where the main DOS product had been hand written entirely in x86 ASM. The sanity of continuing such a practice into the 90's is an open question. Rumor had it that even the Windows versions of Wordperfect were written in ASM.

------
DrJokepu
This is probably a very naive question but can't any of these measures be
easily bypassed by running the observed software in a VM like KVM and just
attaching a debugger like GDB directly to the VM?

~~~
bri3d
They absolutely can be. At the time this article was written (2008), VMs
weren't as in vogue as they are today, VM-attached debugging wasn't as mature,
and the leading "ring-0" / above-the-kernel debugger (SoftICE) had just been
discontinued.

Today, there are a host of new measures designed to thwart in-VM debugging,
but the playing field differs substantially from the one present when this
article was written, and your observation is a good one.

------
jtchang
And my all time favorite technique...an army of lawsuit happy lawyers!

