home *** CD-ROM | disk | FTP | other *** search
/ GEMini Atari / GEMini_Atari_CD-ROM_Walnut_Creek_December_1993.iso / files / archiver / naughty / naughty.doc next >
Text File  |  1992-02-16  |  9KB  |  216 lines
  1.  
  2.                       
  3.                        THE NAUGHTY UNPACKER
  4.                       ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙
  5.  
  6.                             VERSION 1.3
  7.         
  8.                             16 Feb 1992
  9.  
  10.  
  11.  
  12.   WHAT DOES THIS PROGRAM DO?
  13.   ~~~~~~~~~~~~~~~~~~~~~~~~~~
  14.  
  15.     This tiny little program will unpack almost all packed
  16.   executable programs. If you try it on a program which isn't
  17.   packed, in most cases it will tell you, even though it does
  18.   not really check for specific unpacking routines.
  19.     The things it checks for (on the supposedly packed program!) are:
  20.  
  21.   1. Is the file executable?
  22.  
  23.      Some guys always try everything to crash their computer...
  24.  
  25.   2. Does the program contain a symbol table?
  26.  
  27.      Usually packers do NOT add symbol tables, and the ones
  28.      that the unpacked program may contain would be packed
  29.      too anyway...
  30.  
  31.   3. Is the program relocatable?
  32.         
  33.      Someday a packer might be written by someone, which adds
  34.      relocation information, but since this would be very stupid,
  35.      I don't expect this too happen. In fact, this is a very good
  36.      method to check for packed programs, since most unpacked
  37.      programs of a certain length are relocatable anyway...
  38.  
  39.   4. Now this is the only check made that's a bit tricky:
  40.  
  41.      The Unpacker looks for certain instruction sequences in the
  42.      program, which are usually used by the unpacking routine
  43.      after having unpacked the original program to check if this
  44.      is relocatable (and then relocate it).
  45.        These are: (assembler of course...)
  46.         
  47.      a)   tst.l (An)
  48.           beq.s xxx
  49.  
  50.           This is used by the Ice-Packers and some others. An is an
  51.           address register which usually contains the address of the
  52.           offset of the first address to relocate. If it is 0, the
  53.           program is not executable, and the relocation routine can
  54.           be skipped (beq.s xxx). I also check whether the address 
  55.           xxx if more than $30 bytes from this sequence, since this
  56.           is about the maximum size for a relocation routine...
  57.  
  58.      b)   move.l (An)+,Dn  or  move.l (An),Dn or move.l -(An),Dn
  59.           beq.s xxx     
  60.         
  61.           Some other unpacking routines use these sequences to check
  62.           for relocation information. An contains the same as in the
  63.           above case, xxx is checked again as above.
  64.  
  65.      If none of these sequences exist, the program is assumed to be
  66.      not packed! I know this might fail some packers, but I haven't
  67.      found one... Please send me any packers that don't work...
  68.  
  69. ##########################################################################
  70.  
  71.   HOW DOES IT UNPACK THE PROGRAMS?
  72.   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
  73.  
  74.     What the Unpacker does, is in fact load the packed program, look for
  75.   the instruction sequences shown in (4) above, and replace them with
  76.   a JMP yyy instruction pointing inside the Unpacker. Then, a (dummy)
  77.   basepage is constructed, and the unpacking routine is executed.
  78.   This is the critical point. If the program was not packed, despite
  79.   all checks made being positive, it is very likely that you'll get 
  80.   bombs (and other nasty things...). Some old unpacking routines also
  81.   assume that the space below address $78000 is free, and copy 
  82.   themselves there before executing. This will crash the computer if
  83.   it wasn't free because you had many Accessories loaded, or TSR's.
  84.   This however is the packer's fault not mine! The only packers I 
  85.   know of with this "bug" are the bytekiller packers (also known as
  86.   COMPAK_x.TTP). Then again, some unpacking routines make some 
  87.   assumptions about the registers' contents when the program is 
  88.   started. The Pompey Packer v2.6 for example assumes that A4 points
  89.   to the first address after data segment. I fixed the Unpacker so
  90.   that this will be correct, but in some other cases other assumptions
  91.   may be made that I didn't foresee... This might be changed though
  92.   in a later version of the program.
  93.     You should also bear in mind that some unpacking routines do other
  94.   things before starting the decompression, such as check for the
  95.   correct resolution, if the program was run from the auto folder etc.
  96.   In this case, the unpacking routine will terminate the program, 
  97.   because it doesn't know of course that we only want to save the
  98.   unpacked program, and not execute it!
  99.     There are many other reasons that your computer might crash when
  100.   using this program, so be careful. I don't think this will destroy
  101.   your data, except if you use it on a program with a protection that
  102.   wants to destroy your data when it sees that it's being modified etc.
  103.   Anyway,
  104.  
  105. ##########################################################################
  106.  
  107.   DISCLAIMER:
  108.   ~~~~~~~~~~~
  109.  
  110.     I AM NOT RESPONSIBLE FOR ANY LOSS OF DATA OR OTHER DAMAGE THAT
  111.   YOU SUFFER FROM USING THIS PROGRAM EITHER BY NOT USING IT CORRECTLY
  112.                   OR DUE TO AN ERROR IN THE PROGRAM!
  113.  
  114.               USE THIS PROGRAM ENTIRELY AT YOUR OWN RISK!
  115.   
  116. ##########################################################################
  117.  
  118.   KNOWN BUGS:
  119.   ~~~~~~~~~~~
  120.  
  121.   - Programs packed with DC-Squish will go in an infinite loop.
  122.  
  123.   HISTORY:
  124.   ~~~~~~~~
  125.  
  126.   Version 1.0, 2 Feb 1992:
  127.   ------------------------
  128.       The first version, tested with Pack-Ice, Pack-Fire, and many other
  129.       packers. No checks being made at all.
  130.  
  131.   Version 1.1, 3 Feb 1992:
  132.   ------------------------
  133.       - Fixed incompatibility with Pompey Packer v2.6
  134.       - Added some Alert-boxes for easier use.
  135.       - Added checks for executability, relocation, symbol table.
  136.       - Wrote a documentation (fingers still hurting :)
  137.       - Fixed a bug which caused the program to crash after trying
  138.         3 files...      
  139.   
  140.   Version 1.2, 12 Feb 1992:
  141.   -------------------------
  142.       - Relocatable programs can now be unpacked, if they have been
  143.         packed with the Happy Packer or Pompey Packers (I hope!)
  144.       - First version of Packers list (PACKERS.LST). Thanks Richard
  145.         Clarkson for the idea!
  146.  
  147.   Version 1.3, 16 Feb 1992:
  148.   -------------------------
  149.       - I finally managed to test the program with PP v1.9a packed files,
  150.         and fixed it so that they are recognized (they are relocated too).
  151.       - (Potential) unpacking routines which used the following sequence:
  152.         move #2/#3,-(sp)
  153.         trap #14
  154.         addq.w/.l #2,sp
  155.         to find out the screen address and copy the unpacking routine below
  156.         that address are now forced to use a safer address...
  157.       - The JAM Packer versions 3.0 pre-release and release 1.1 are now
  158.         supported (pre-release only LZH compression), due to the above
  159.         change!
  160.  
  161. ##########################################################################
  162.  
  163.   WHAT IS THE PROGRAMMER ASKING FOR?
  164.   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  165.  
  166.    1. Do not try to hold me responsible for anything that goes wrong
  167.       with this program. I tried to make it fool-proof as much as 
  168.       possible, but the way it works requires some risky and tricky
  169.       code...
  170.  
  171.    2. Please always copy this DOC together with the program. You may 
  172.       have noticed that it contains a great deal of information on
  173.       how the program works, and when it may fail.
  174.       Also, I don't like typing long texts, so this is particularly 
  175.       valuable! :)
  176.  
  177.    3. Please report to me any bugs or incompatibilities (there must be
  178.       quite a few!!) or any changes you would like me to make.
  179.       Especially, if you see any new packers whose packed files can't
  180.       be uncompressed, please send them to me!! You'll get your disk
  181.       back together with a new version of the program if you send it
  182.       by mail, otherwise you can send it to me to my e-mail address
  183.       (UUEncoded) and I'll upload a new version anyway. I don't know
  184.       how long my account will last, so if your mailer bounces the 
  185.       address, please try it by normal mail...
  186.  
  187.       Also, if you would like Naughty to support packer formats which
  188.       are not supported in the current version (look at PACKERS.LST)
  189.       for various reasons, mainly because they use unusual code for
  190.       relocation etc., tell me, and I'll see what I can do!
  191.  
  192.    4. This is a very small program, the source code however is about 30K
  193.       (which is not very much either) in assembler. It is quite hard to
  194.       maintain (especially with my programming style :), but I don't
  195.       think this is a suitable program to release as Shareware. So this
  196.       is FREEWARE, AS LONG AS YOU COPY ALL FILES TOGETHER!!. If you still
  197.       want to donate money I won't complain, :) but I prefer bug-reports
  198.       and/or useful information and/or new packers! I think this will
  199.       make this program more useful (but the source even bigger ARGH!).
  200.  
  201.       If you like, you can send me some empty disks too!
  202.       
  203.  
  204.       My address is:                        email:
  205.  
  206.          Marinos Yannikos               kdv_521@eiaida.tuwien.ac.at
  207.          Wulfeniaweg 3                  kdv_521@eimoni.tuwien.ac.at
  208.          A-9100 Völkermarkt
  209.             AUSTRIA   
  210.   
  211.  
  212.                              HAPPY UNPACKING!
  213.  
  214.                              Marinos Yannikos
  215.  
  216.