An Anti-Reverse Engineering Guide
codeproject.com
codeproject.com
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).
Today you'll find lots of anti-VM tricks, and if you go a few more years back, lots of ring0/SoftIce tricks.
That said, they are what they are, tricks. Good protections can't simply rely on tricks, which simply temporarily inconvenience whoever is not aware of them.
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".
He's right - these techniques basically just annoy any mildly competent reverse engineer.
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.
The task of maintaining on-going disassembly across multiple release versions of some software is actually straight forward. The "dumb" (but useful) way to do it is by finger-printing all of the subroutines in the old disassembly, and then using the fingerprints to identify the similar routines in the new disassembly (IDB2PAT). The "smart" way to do it is the graph theoretic approach of Halvar Flake.
Anyone in the Anti-Virus or compatibility industries can confirm both the capacity and the need to maintain disassemblies across multiple versions of software.
Pumping out a relentless stream of new versions of your software is no longer a deterrent, and hasn't been for over a decade.
When it comes to the efficiency of distribution, it's best to think of it in terms of the constraints and requirements.
Without a way to duplicate and distribute their products to customers, software companies could not exist, so the capacity to duplicate and the ability to distribute are both requirements.
Those very same duplication and distribution methods used by the company can also be used by others to further (re)distribute additional copies.
The difference is, the software companies are operating under the constraint of needing to make a living by selling copies of their products, so there's really no way to make a fair comparison on the efficiency of the methods used by the companies versus those people making additional copies. You're essentially comparing farmers to chefs; one produces food, while the other prepares the food.
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.
http://static.usenix.org/event/woot09/tech/full_papers/rolle...
In fairness, symbolic execution and theorem proving was a future direction for him; this paper is mostly compiler theoretic.
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.
BD+ has produced multiple titles which, during their new release window, had no high-quality HD rips torrented. But that's besides the point: if antidebugging and antireversing is such a lost cause, it stands to reason that BD+ should be completely broken by now. But, of course, it is not.
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.
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).
I beleive 99.99% of those who pirate will never buy a game just because they don't want to wait several days (or weeks, very rare). DRM only harasses those who don't pirate.
>> Starcraft 2 sold 75% of total copies told to date within the first month.
And who says that without the DRM it would be lower? Maybe it would be even higher! Many techy people just don't buy those new games with draconian DRMs/Spyware which require internet connection. Or they buy the game and then download NODVD/cracked.exe
> ...as far as I know there hasn't been a break in DirecTV
> for over half a decade.
http://drm-removal.com/features/DirecTV-Save-Download-Captur...
I believe your comment's parent was referring to their over-the-air stream DRM (i.e. the stream to the dish receiver), which hasn't been publicly broken.
This is a case of deadbolted door, window left open.
There's still some incentive to crack video DRM, since ripping through HDMI requires a re-encode and degrades quality, but the approach is good enough that the payoff is reduced substantially.
I do not know a lot about reversing but I was always under the impression that nothing was impenetrable and most schemes were easily defeated. In light of this I am always puzzled by the relative efficacy of punkbuster and related daemons.
What you can do? I would start from tuts4you.com, teach x86 assembly language, download a degugger and/or disassembler and dig something or follow tutorials.
Note that it is from 2008.
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.
The irony is that the applied pressure probably doesn't produce a superior result to being left to your own devices.
It's helped me a lot professionally, actually - I'm much faster at debugging compiled languages than my coworkers are, and the mental patterns I developed while peeling away the layers of control flow in disassembly map very well to understanding large code bases even when I do have the source.
I think it's mostly a function of time rather than being scared, though - learning how to reverse takes quite a while, and once you've got a professional job where reversing seems entirely irrelevant (and even potentially dangerous), it's hard to justify taking the time to learn how.
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.