
Anti-Debugging Tricks (1993) - antigizmo
http://textfiles.com/programming/antidbg.txt
======
chris_overseas
I remember hitting a few of these back in my youth when I was trying to
"backup" game floppy disks. Some were easy to work around (eg 1.1.1 could just
be replaced with NOP commands to allow further debugging), others were much
more difficult to deal with (eg 2.2.2 resulted in single stepping through huge
chunks of code, taking notes as I went, and rebooting/restarting the session
each time I made a mistake - very time consuming).

I liked encountering a form of protection I hadn't seen before, it gave me a
new challenge to solve and a chance to learn something new. I came to realise
I didn't even care about the games themselves, bypassing the protection WAS
the game for me.

As an aside, overall I noticed a positive correlation between the quality of
the game and the quality of the protection (if any) it used.

------
tux
Here is a bit easier to read version:

[http://readtext.org/programming/anti-debugging-
tricks/](http://readtext.org/programming/anti-debugging-tricks/)

------
jkot
Most extreme trick was destruction code, which would only be executed while
debugging, due to timing. Back than it was possible to destroy CRT display
(set refresh frequency too high), motherboard (overwrite BIOS) or harddrive.

~~~
jacquesm
One particular nasty trick was a very tight loop with interrupts disabled
writing 0 to a location that was 0xff in the ROM. The ROM and the CPU would
end up fighting over this, it effectively shorts 5V through the databus
drivers to ground. The goal here is not to damage some peripheral but to
directly damage the CPU.

On more modern CPUs this trick should not longer work but on quite a few 8 bit
micros it definitely did (let's not go into how I know this and how I know the
ca. 1987 list price of a 6809).

~~~
beagle3
So, you're saying that the mythical HCF instruction[0] was somewhat real?

[0]
[https://en.wikipedia.org/wiki/Halt_and_Catch_Fire](https://en.wikipedia.org/wiki/Halt_and_Catch_Fire)

~~~
jacquesm
Yes, but it was more like 'loop and burn out a transistor'. No fire and no
visible damage, just a cpu that wouldn't work any more. I didn't try it again
to see if it was reproducible, it was a lot of money for me at the time and I
considered myself pretty dumb for trying. A sample of '1' was enough to prove
the point for me. I wished I recalled what drove me to try it, I'm fairly sure
it was some outside influence, not something I came up with by myself and
wondering 'what if'. More like: that's never going to work, here, let me show
you. (Famous last words...)

------
beagle3
The author lists his fido addresses... I'm feeling nostalgic even though
nostalgia isn't what it used to be.

A quick google shows that he headed Checkpoint's vulnerability research until
recently. Another name on this article, Eden Shochat, is now running Aleph[0]
- a VC with a blog worth reading.

[0] [http://aleph.vc/](http://aleph.vc/)

------
bnjf
Serge Pachkovksy's EDB can still be found at
ftp://ftp.oldskool.org/pub/ANORMAL%20executable%20tools/DOSEXE%20Executable%20Tools%20Pack/tools/edb.015-Serge%20Pachkovsky/

------
krylon
I remember reading a paper about how Skype attempts to foil attempts to run it
under a debugger/tracer/whatever, and when Skype "thinks" it's being debugged,
it will write random garbage to all registers and then branch to a random
address. It had whole arsenal of tests to check if somebody was sneaking up on
it, and it ran a couple of these, chosen randomly, at more-or-less regular
intervals. Some programs really value their privacy.

~~~
kuschku
Or, in other words, some programs try to take their customers computers
hostage.

Seriously, who would be willing to run software if they knew it would try to
do everything to destroy your system (read the comments above about actual
physical damage) when you try to understand it?

If you run the software on your system, it is yours. Debugging is, per ECJ
decision, a human right. Your software, your right to take it apart and try to
understand it.

I don’t get how people can accept to run such hostile software.

------
mattlutze
A course I took this last semester spent quite a bit of time in assmebly,
something I'd previously not done. I'd honestly like to see exploration of
some of these tricks in those sorts of courses -- it's a really fascinating
way to think about the light-side of the ASM force...

