SNATCHIT is a program written in the 1980s that loads COPYIIPC (a protected-disk copying program) and then interacts with it runtime to provide disk image saving and loading (features it did not ship with because such features expressly encouraged software piracy). We used this in the 80s to transfer protected disk images around BBSes until someone could figure out how to crack the game and release it properly.
I recently had a need to run SNATCHIT on a 1GHz system. I recycled an old system to become a box for dumping all my media, from floppy disks to memory cards to hard drives, something that can do it in the background without tying up my main machine. Because it’s a 1GHz system, SNATCHIT won’t run, even with hardware and software slowdowns. I wanted to run it there because I have some 3.5″ protected disks I want to preserve, so I investigated patching it to work around whatever is tripping it up. It’s a .COM file, the very easiest type of executable program for old PCs to reverse-engineer, debug, and patch — should be easy, right?
When I try to debug SNATCHIT.COM, I see it’s encrypted. Okay, not totally unexpected; simple encryption schemes were common at that time. Let’s try patching it to decrypt and continue… Okay, now it exploits a HLT bug to, I guess, fool debuggers (I didn’t see any PIC code disabling hardware interrupts, but whatever, maybe it was only partially implemented). Loading in the DOSBOX debugger bypassed that.
Protip: As soon as you see anti-debugger tricks in something you’re debugging, bypass all of them by loading the program into an emulator debugger (such as the DOSBOX debugger). This is an advantage that 25 years has given our hobby; in the 80s and 90s, the best we had was something like SoftICE, which wasn’t foolproof. Running in an emulator debugger view is fantastic because the target program has no idea it is being inspected.
Work continued. In a neat trick that I don’t fully understand yet, I found that on real hardware it puts a certain value in a register, but in the DOSBOX debugger it puts the wrong value and locks up. I don’t quite understand why, but DOSBox debugger lets me force a value, so I forced the correct value and kept going…
An hour later, I was tearing my hair out. SNATCHIT, in that fine software pirate impress-your-friends-and-bury-your-enemies tradition, has multiple sections that decrypt, but not all at once, argh! (In a pirate voice: “aarrrrrgh!”) I had some of it decrypted in non-contiguous chunks, enough to see this:
db '(C) Copyright 1991, Software Pirates, INC.' db ' Software Pirates will try to fool you' db 'and hide code that you cannot find' db 'and then decode it and then execute' db 'this is to fake out the opposi$$$n,'
; anything in (parenthesis) is not in the text, but implied db '(they think) that they are smarter than us but no one can ever b' db 'the infamous programmers that bring you the new and' db 'fangled code thatknocks your socksoff and stinks up' db 'the room and probbly your computeralso. Sometimes t(he)' db 'best way to beat them is to look t(hem)' db 'straight in the eye and ask them w!' (why)
Great. Later, the somewhat ominous:
seg000:01D4 db 'PARITY ERROR, Continuing processing.',0Ah
Not only should that wording strike fear into your heart (parity errors are a BAD THING that should NOT CONTINUE PROCESSING), but this message proves they’re redirecting the NMI at some point. Gee, thanks. I can’t wait to get to THAT chunk of joy.
In the end, I decided it was faster to pull a vintage system out of storage and put a 3.5″ drive in it. I’m a Generation X guy going through multiple mid-life crises — I haven’t got time for this shit.
I would love to see the actual source code someday, if the programmer would ever come forward (statute of limitations is way over, so I’m crossing my fingers). Hooking and patching copyiipc runtime was, and still is, incredibly impressive; the source would make a great read. The last version of this tool was 1991, and I remember seeing Software Pirates, INC. stuff as early as 1984. That’s a pretty good run.