Introduction
This was a packer from around 1989 and was coded by Zarathrusta. It’s a packer designed for .PRG / .TOS files only. It was released as a competitor (based on the mocking text that appears when depacking) to one of the first exectuable file packers on the Atari ST, the ubquitous Happy Computer Packer.
Why am I writing about a file packer from 1989? Because this was the first year (2020) that I’d ever encountered it. I had no knowledge of it back in the days of writing my Multi Depacker tool. After it was mentioned in a private FB Atari ST group, I did some digging around and worked out there was a quick way to create unpacked versions of the .PRG files it generated. Even when it specifically prevented you from doing this.
My interest in file packers was back again!
Tools used
- A copy of Fast Cruncher II by Zarathrusta
- A target program to pack and depack as a test (I’ve used Antic’s Disk Doctor tool – my favourite hex editor on the Atari ST- and a random .PRG from a game)
- Easy Rider 4 (or whatever is your favourite disassembler)
- A hex editor (to change a few bytes in the code) – I’ve used the Antic Disk Doctor.
- File Compare v2.2 by Alien/Pompey Pirates
Process
First thing we need to do is pack the test file. So load up Fast Cruncher II (FCII from here onwards), select the test program (Antic’s Disk Doctor is my one) and wait for it to finish packing.
Note: All of my screenshots will be of a medium resolution desktop from STEem v4.02. They have the extra border area included.
When FCII has finished examining the repeated patterns within your code and compressed it all down, you will be presented with the statistics of how much space it has saved you.
Don’t forget that back in 1989, disks weren’t cheap, so the more you could store on a single disk the better. Unlike file archiving systems such as ARC and LZH, this would still allow the program to run afterwards once it was unpacked. Archive files were more useful for sending files via the BBSes around the world, as we didn’t have the use of the Internet back then.
Clicking on the Save option presents another menu choice – do you want the option to save off the file when it has been depacked?
I did two runs of this packer and my target: once with the save option switched on, and once without.
Purely for comparison reasons, I also compressed Disk Doctor using v3.91 of UPX.
The DISK_D0C.UPX file is just over half the size of the packed version as compressed by FCII. That’s the progress that file packers have made over the last 31 years.
The packed files
So after packing the target program twice, with the different save options on and off. We’re presented with two files that are exactly the same length. If you run DDNOSAVE.PRG, it depacks whilst displaying the packer’s text message on screen and then Disk Doctor appears.
However, running the DD_SAVE.PRG, a different option appears on screen:
Pressing Y will cause the program to ask where you would like to save it – using the original program’s filename and by default it will be in the same folder that it was launched from.
But what if you forgot to say that you wanted to depack your program and you’ve stupidly deleted the unpacked version? This is where it gets interesting.
Switching on the built-in depack option
Comparing the two versions
Back when I was doing/churninh out saved game editors for the Atari ST, I created my own file comparison tool using GFA BASIC. It was pretty basic as it just compared the different bytes at the same address between two different files. But it did what it said on the tin and it was used a lot.
However, there was a much better tool for more in-depth comparisons and that was File Compare v2.2 by Alien/Pompey Pirates. This had so many more extra options and it is the one I’m using here.
Using the FCOMPARE tool, I loaded up both the DD_SAVE.PRG and DDNOSAVE.PRG files and looked at the differences. The very first difference looked “odd” because it was nowhere near all of the other bytes that had changed in the two programs. A $0000 word value in one program was now $FFFF in the other. A true or a false flag, perhaps?
I also noticed that every byte after this $694 didn’t match up. So that (to me) sounds like there’s some encryption involved too. If so, it’s an additional layer that was added by the coder to to protect the file from being saved off.
Just to make sure, I packed another file into the Yes / No Save options and ran them through the same comparison.
It’s the same byte offset as in the first test. At offset $058E there is that word value. If it’s set to $0000 then the save function is removed, if it’s set to $FFFF then the save function is allowed. So what we need to do is work out where in the packer’s code this flag is checked and what happens to your program afterwards.
It’s disassembly time
Load up Easyrider 4 and open up the DDNOSAVE.PRG file and we’ll scroll through some of the code. We know that the flag offset is $058E bytes into the program, so using EasyRider’s Hex view, I was able to find it and label it accordingly as SAVE_FILE_FLAG.
I’ve also relabelled other obvious parts (text messages, known routines that I could spot) to make it easier to follow the code below. Yes, I am jumping the gun a little, but this was meant to be a short article!
As you can see with my edited label names, there is a test of a word value within the code. If it’s $0000 then the code jumps straight into the depack routine. If it’s $FFFF then it jumps to the saved routine – even if you specifically asked it not to give this function when you packed the original program!
A quick hex edit and ..
So by changing these two bytes to $FFFF you will *always* get the option to save off the program after depacking. This is especially useful as Fast Cruncher II wasn’t a common compression tool – compared to Happy Packer at the time – and Naughty Depacker can’t unpack the files either.
Good job the coder left an easy to find back door in 🙂
Mug UK – August 12th 2020.