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