Hacker News Reader

Comment by mrcharles | Hacker News Reader

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.

View on HN

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

This has a lot to do with the time the article was written. 2008 was a time where ring0 had gone out of fashion (SoftIce dead, nothing usable to replace it), and virtual machines weren't quite that common yet for debugging.

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.

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

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.

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.

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

I think its a better deterrent to just release software updates often. Of course you need to give the user a compelling reason to want to update.

In the old days (80's and early/mid 90's) where people would distribute small and simple patches to disable protections (i.e. "crack" executable files), a fast release cycle for the software thwarted the simple cracks. This situation did not last long. The crackers started using more sophisticated patching techniques, like search-string-patching and key generators.

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.

In the 80s/90s where software companies able to develop, test and distribute updates as efficiently as the warez community?

I think it's an unfair question. The creators are always at a disadvantage since the replicators always leverage and reuse the efforts of the creators.

I'm sorry I did not mean to be unfair. I was curious if the companies were able to distribute updates pre-broadband. I can remember downloading the twenty something floppies for os2 over a dialup.

At one point in time, software companies sent updates on magnetic tape through the postal mail. One of the most clever hacks I've read about was when a group doing penetration testing mailed a fake (back doored) update tape to the target.

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.

Reply on news.ycombinator.com