Annoying adventures in disassembly: SNATCHIT
Posted by Trixter on February 5, 2015
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,'
…and later:
; 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.
Oldskooler Ramblings 
Joe Emenaker said
Wow… what a trip down memory lane. I was waiting for you to mention “Sourcer”, the best disassembler I could get my hands on at the time.
Trixter said
I used to use that too :-) but IDA is so, so much better that I’ve never looked back.
bleuge said
hi Trixter,
it seems wordpress eat my comment :/
in the disk copiers pack i made and uploaded to some sites, i got 3 different snatch it versions, last one is 1.11, in the doc we can read:
“1.10 – Added support for COPY II-PC 4.X series.
1.11 – Added support for COPY II-PC 5.X series.”
so it supports 5.x series, in the pack there are 29 copy2pc versions :), last one is 6.20 (but fake version)
also i’ve read that copy2pc 6.0 version is worst than the last in the 5.xx series (5.20), because game producers press Central Point for this, but i don’t know if this is true or not, maybe you know more about this?
curiousity made me debug snatchit 1.11 last night, for this i’ve used a dos debugger that works great in modern OS (my machine is running windows 8.1), Liu Taotao’s TR 2.52 is a emulating debugger for the old times (there are others, as cup386, etc…) specialized debuggers for exe/com unpacking
i’ve also made a huge pack of dos exe/com utils (packers, cyphers, unpackers, debuggers,etc) to preserve all this knowledge (and being serious, for huge nostalgy, as i was part of this scene ;) 20 years ago) (if you want this pack tell me and i’ll upload as i did with the disk copiers)
debugging it, the value you forced is because the author used one old antidebug trick, the prefetch queue, you wrote in the prefetch queue, the value is written in memory but not executed, look for this in at last 2 locations, 2C3C and 21EA
i’ve disassembled and extensive commented this dumped version, if you want to have a look just ask for it, there is not too much magic just a lot of error checking, interrupt trapping, and a strange parity checking all the time (it seems in 1991 memory was bad, i don’t remember this ;))
Trixter said
I’ve never heard of TR but after grabbing it, it seems very interesting; the author essentially created a 386 emulator that you can trace through the program in. DOSBox’s debugger performs that function for me now, but I sure wish I had TR back in the 90s!!
If you upload your pack to http://ftp.oldskool.org in /incoming, I can move it to the /pub portion so that others can pick it up. If you want to upload your commented version of snatchit, I’d definitely like to read it.
As for getting snatchit to run, Peter Ferrie beat you to it :-) and wrote me this: “change 75 cf 80 to b0 d5 80”.
bleuge said
ok, i’ll try to upload this weekend the packers pack
there are more antidebug checks in snatchit, as i said, 2 use prefetch queue trick, check 2c3c and 21ea
but later in the program other checks are made for some bytes, for example at int 9 there is a check for 21ef to be 0xd5
also 2c41 must be 0x18 all the time (checked in int 10 for example)
also the interrupt trap is horrible, int 9 checks for int 8 validity, int 10 check for int 9, also int 8 and int 9 overwrite ints 1,2 and 3, all the time
and these 3 performs parity checking in a way i cannot understand…
Peter Ferrie is a wizard!, i wrote him some years ago about some virtual cpu used for protection and anti-disassembling in Copywrite disk copiers (used since 1984!!) and he confirmed this
this is the only old DOS program i’ve been unable to “open”, and i’ve tried many times these years…
anyways, thanks for this little trip to my lovely DOS!
Tommi Lempinen said
Today a device called Kryoflux allows one to connect 5.25″ and 3.5″ (also 8″ with suitable adapter) drives via USB on modern computers and transfer the “raw” data (analog magnetic polarity changes converted to digital pulses) for further processing. So far it’s the closest, simplest way for accessing what’s really on that old spinning magnetic media, including all the tricks used for various protections.
Digging deep into that old media (in my case it’s the C64) is very, very much interesting!