Anti-Debugging Tricks (1993) | Hacker News Reader

Anti-Debugging Tricks (1993)

textfiles.com

74 pointsantigizmo18 comments

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.

Here is a bit easier to read version:

http://readtext.org/programming/anti-debugging-tricks/

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.

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

Time for a lawsuit, I guess?

Debugging is your right, and destroying your hardware is not something the software may do.

I think you replied to the wrong person.

Well, you wrote about software you used trying "to directly damage the CPU."

That definitely sounds like malicious intent from the devs.

I was the dev, checking if this was actually possible. And - much to my surprise I might add - it was.

oh, interesting. Still, it’s not really a great idea to damage your users’ systems. Liability and everything.

    ----------------

EDIT: Due to HN blocking me from posting new comments, I’ll answer here:

Yes, I’m sorry, I had originally thought you were talking about the same as the parent you replied to: Software that tries to physically hurt your system when you try to debug it.

We can only be lucky that that isn’t possible today anymore, considering the fact that malware is widespread by now, it’d surely have used a "pay 20$ or your PC is dead" scheme otherwise.

The system was my own.

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

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

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

I remeber the CIH virus used to break motherboards by corrupting the BIOS.

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/

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/

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.

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.

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

Reply on news.ycombinator.com