Depacking in a Naughty Way

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

 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 
secret, Dad!"

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

 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))
     BEQ.S somwhere_near

     or a

     MOVE.L (An)+,Dm
     BEQ.S somewhere_near

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

     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

                                                information: 
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| 
-----------------------------------------------------------------

 More information:

 (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
           Packers...
           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
           though...
           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
           program!

   (jek1): The JEK Packers 1.1 - 1.4 and the LSD Packer are  very
           much alike...

    (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
           Naughty!!
           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
           packer.

 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 
thing together.
 ST NEWS rules!