"Once upon a time, there was a young boy, and this young boy was
having his 10th birthday. His father thinking that it was an
important day for his young lad, said to him, 'You can have
anything that you want for your birthday'. The boy thought and
thought. Finally, he said to his pop, "Dad, I want a green golf
ball." The man was surprised a bit, but decided to humour his
son. And so, the boy recieved 1 green golf ball for his 10th
On this boy's 13th birthday, when he hit his teens, the father
once again walked up to the boy, and told him what he had before.
The boy thought. And thought. Finally, he said, "Dad, I want 10
green golf balls." Now, the father was slightly curious about
this, and he almost asked his son why. But then he decided that
it was just youthfulness, and left it at that.
Upon graduating from High School, the boy was once again given
that same offer by his father. He thought and thought and
thought. Finally, he went up to his old man and said, "Dad, I
want 100 green golf balls." Now, the father was very curious
about this, and asked his son, finally, why he wanted the balls.
The boy just said, "Dad! It's a secret!" The father backed down,
and got the boy his balls.
When the boy graduated from college, his father once again
offered him anything he wanted. Once again, the boy thought. Once
again, the boy walked up to his father. He said, "Dad, I want
1000 green golf balls." The father decided that the boy knew how
to live his life. But still he asked, "Why, son? Why do you want
these green golf balls?" And once again, the boy said, "It's a
And then came the war. And the boy volunteered himself for his
country. And when he came back in one piece, his father said,
"Son, I will get you anything that you want!" And the boy
thought. And thought. And he said, "Dad, I want 10,000 green
golfballs." And the father could not hold back his question any
longer. "Why? Why, son? Why do you need these green golf balls?"
And the son looked at thim, and he said,"Dad, now, I told you
that it was a secret. Please don't make me tell you." And the
father backed off.
The boy got married. His father walked up to him, and offered
him anything he would want on this joyous occasion. The boy
thought and thought and thought. And thought. And, finally, he
said,"Dad... I want 100,000 green golf balls..." And the father,
keeping calm, asked why. Why the boy wanted so many green golf
balls. And all the boy could do was look at his father, and
say,"It's a secret." And the father kept silent.
Then, tragedy struck. There was a car accident. The boy was
mortally injured. And the father went to see the son in his final
hour. And he asked his son if there was anything he could get
him. And the son whispered,"Father... Please get me 1,000,000
green golf balls..." And the father almost wept. He said, "Son,
please tell me why you want these green golf balls..." And the
son looked at his father, and he said, "Alright, dad..."
And then he died."
The Mysterious Green Gables (courtesy of UNT)
UNPACKING PACKED PROGRAM FILES
- or -
A FUNNY WAY TO CRASH YOUR COMPUTER
by Marinos Yannikos
I've always liked program packers, such as "Pack-Ice" or the
"Jek Packers", because they save a lot of disk space. However,
for most packers a suitable decompression program doesn't exist.
This is often very annoying, because if you have packed programs
on your harddisk, the few K's you saved just don't compensate for
the time you have to wait each time while they're being unpacked.
If you don't have a harddisk, loading a packed program from disk
may take less time than the original program would, but sometimes
you'll want to have a look at the program don't you? Anyway, I
wanted to write a program which can unpack as many packed program
files as possible.
If you have ever tried to decompress a program, you might have
tried loading it from a debugger like "MonST", then setting a
breakpoint just before the part of the unpacking routine where
the program is being relocated (after it has been decompressed).
Then, if you're lucky, you could run the program, it would be
unpacked, and then you'd be able to save it as it was before.
This was the way I used to uncompress programs. But why do the
same thing over and over again, if your computer can do it too?
Thus, I started wrote a program called The Universal Unpacker,
which did just that. It checked whether the file you wanted to
unpack had been packed with a known packer, and then it inserted
a jmp- instruction where it knew the relocation code would start.
I also added the possibility to unpack certain types of
compressed data files - those I had the decompression source code
T.U.U. was not a very flexible approach to this problem though.
I had to write a new version for every new packer I found,
because it had to know exactly which packer the program file was
packed with - otherwise the jmp- instruction might have been
inserted in the wrong place, which could easily cause the
computer to crash. Also, soon TUU became bigger and bigger,
because I had to keep enough bytes of every unpacking routine I
knew just to make sure it could distinguish between very similar
unpacking routines - there are quite a few, believe me! Just look
at the "Jek-Packers". And still I would never be sure if a packer
would be written which produced files so similar to some other
packer's that TUU wouldn't notice the difference.
I soon realized this was the wrong way to go. I decided that a
much more efficient and flexible way would be to search for
certain instructions in the packed file, which were typical for
relocation routines. When I inspected packed programs, I noticed
that the most common way to check whether relocation information
is available or not was to calculate the first address after the
TEXT- and DATA- Segment and then do either a
TST.L (An) (usually TST.L (A0))
These look like very common pieces of code, but if I could make
sure that I only checked files which were really packed, and if
restricted the BEQ.S somewhere_near by allowing somewhere_near to
be only a few bytes and positive, then I could be quite sure that
I had found the right position.
So I was able to spot the location where the jmp- could be put.
There was still something else I had to cope with though: I
needed to find the exact location of the unpacked program data.
I knew that all unpacking routines (all I knew of!) had this
information in one of their registers at the time they reached
the above piece of code. TUU just got it from a certain register
which it knew, since it recognized the packer. So I had to search
all data and address registers for an address which pointed to
what should be a BRA.S $1A (hex: $601A) - because this was the
only thing I knew about what the beginning of the unpacked
program data looked like. I had to be careful though, because
some unpacking routines do not only keep the address of the
unpacked data in a register, but also the address of the packed
data. So what could happen was that my program would save the
packed file again instead of the unpacked. The solution to this
was to compare the sizes of the programs which started at these
memory locations - the bigger one should be the unpacked program.
So I wrote my first version of The Naughty Unpacker, without any
test whether the file one tried it on was packed or not. This
would often crash the computer though if the file wasn't packed.
Thus, I decided not to allow programs which conained relocation
information to be tried. That way, most non-packed programs could
be recognized, because they usually contain relocation infor-
mation. I had assumed that no-one would write a decompression
routine that wasn't position-independant, because it's much
trouble for nothing. At least I knew Pack-Ice and the Jek Packers
were. However, I noticed that the Happy Packer, as well as some
others did save relocation information! So what I did was to
treat these as special cases and hoped that no-one would write
such packers again!
Now this seemed to be working! Most packed programs could now be
unpacked and saved, without any information about the specific
packer that was used.
One other reason why I wanted to unpack some programs was that
some unpacking routines copied themselves to some memory location
which they just assumed to be free, such as the small area above
the screen memory - some even assumed the screen memory would
certainly be at address $78000, which was only the case on 512K
computers though! These assumptions could be hazardous,
especially on newer machines, or even multitasking OSs like MiNT.
So I tried to cope with these too, and I managed to unpack with
The Naughty Unpacker even some files which wouldn't even run from
the desktop before.
So much for the program's history. One last thing you should
know before you use it is that in will certainly crash if you try
to unpack a protected program that uses horrible things like
TRACE- decoding to protect itself agains hackers. Also, the
program is very "naughty" in general - but I think the way I did
it was the only way it could be done.
You can find a copy of the program and its doc file in the
PROGRAMS folder on this ST NEWS disk.
Below you will find a list of all known packers...
Please help me maintain this list and report any errors, missing
information and new versions as soon as possible! Thanks!
---> Last update: 19 Feb 1992 (NAUGHTY version 1.3)
R = creates relocatable files
(x=yes, blank=no, ?=don't know)
M = unpacking routine accesses dangerous memory areas, such as
just below $78000 - usually to copy the unpacking routine
7 = uses area below $78000 (very dangerous! avoid!)
s = uses area below screen memory (a little risky)
g = uses gemdos buffer area (dangerous!)
blank = no
Most unpacking routines however DO access memory that
doesn't belong to them, which is after the data segment and
is needed for the decompression (as a buffer). This is not
very dangerous though.
S = Packer is not programmed safely i.e. has problems with new
TOS or harddisks, ACC's etc.
(x=yes, blank=no, ?=don't know)
Other = more comments at the end of the list
Packer: date: supported: |R|M|S|Other
ATOMIC 3.1 ??? yes |?| |?|(atomic)
Automation 2.31 ??? yes | |s|x|(auto)
Automation 2.4 ??? ??? |?|?|x|(auto)
Automation 2.51 ??? ??? |?|?|x|(auto)
Automation 5.01 ??? ??? |?|?|x|(auto)
ByteKiller 1.4 1989 no |?|?|?|
Bytekiller 2.0 no |?|7|?|
Bytekiller 3.0 no |?|g|?|(bk3)
DC Squish 1.4 no!? |?| |?|(DCSq)
Happy Packer yes |x|?|?|
I-Tech No Quick Cruncher no |x|?|?|(pack20)
JAM Packer 1.1 (.TTP version) yes | |s| |(jam)
JAM Packer 3.0 pre-release yes(LZH) | |s|x|(jam)
JAM Packer 3.0 release 1.1 yes | |s|x|(jam)
JAM Packer 4.0 yes | |s| |(jam)
JEK Packer 1.2 ??? yes | |s| |(jek1)
JEK Packer 1.3 ??? yes | |s| |
JEK Packer 1.4 13.06.89 yes | |s| |
L.S.D. Packer 1.2 18.01.89 yes | |s| |
MCA-Crunch ??? |x|?|?|(mcacr)
Pack 2.0 no |x| | |(pack20)
Pack-Fire 1.01 03.08.90 yes | | | |
Pack-Fire 2.01 19.02.91 yes | | | |
Pack-Ice 1.13 20.05.90 yes | | | |
Pack-Ice 2.12 22.06.90 yes | | | |
Pack-Ice 2.20 21.11.90 yes | | | |
Pack-Ice 2.31 19.02.91 yes | | | |
Pack-Ice 2.40 14.08.91 yes | | | |
PFX Packer 1.5 yes | | | |
PFX Packer 1.7 yes | | | |
Pompey Packer 1.9a yes |x| |x|(pp19)
Thunder Packer 1.0 yes |x| |x|
(atomic): I only have one packed file, please, if you have this
packer send it to me!!
(auto): All these packers crash (when packing), so I can't
test if the files created can be uncompressed. Please
try that for me if you can...
Automation 2.31 almost the same as LSD packer and JEK
Automation 2.4 (actually Crown Of Creation Compacter
v2.4) packed programs crash on TOS 2.05 when unpacked.
(bk3): The Bytekiller v3.0 by M.Coates does not use a correct
unpacking routine, it can't unpack non-relocatable
programs. This is the main reason it is not supported.
(DCSq): I WILL NOT SUPPORT THAT ONE!!! (Spaghetti-code!! looks
like a compiled-C unpacking routine!) Strangely, some
programs packed with DC Squish DO unpack!
(mcacr): This one crashes all the time (TOS 2.05), if you can
use it, please tell me if it works...
Actually, not even programs packed with MCA Crunch
will unpack and run on TOS 2.05!!!
(pack20): Contains very stupid code, which would have to be
checked for separately, use the unpack.tos supplied
with it instead!! Also, this one doesn't like the
fastload/TT bits... You must remove those before
packing with removsym.prg.
(pp19): Crashes all the time too. Should be able to unpack
Special message to the Pompey Pirates: GEM may have
some bugs, but it's not GEM's fault if you don't know
how to use it...
Try to write a serious TOS-version-independant
(jek1): The JEK Packers 1.1 - 1.4 and the LSD Packer are very
(jam): The JAM Packers v3.0 are now supported too. However,
with TOS 2.05 the compressed files can not be loaded
from the desktop, only if uncompressed first with
Also, the JAM-packer 3.0 pre-release V2-compressed
programs cannot be unpacked with Naughty (at least the
ones I tested) as it seems because of a bug in the
End of additional information.
If you include the Naughty Depacker on a Public Domain disk, or
spread it through a BBS or whatever, please take the trouble to
dump this file as ASCII with it as well and spread the whole
ST NEWS rules!
The text of the articles is identical to the originals like they appeared in old ST NEWS issues. Please take into consideration that the author(s) was (were) a lot younger and less responsible back then. So bad jokes, bad English, youthful arrogance, insults, bravura, over-crediting and tastelessness should be taken with at least a grain of salt. Any contact and/or payment information, as well as deadlines/release dates of any kind should be regarded as outdated. Due to the fact that these pages are not actually contained in an Atari executable here, references to scroll texts, featured demo screens and hidden articles may also be irrelevant.