home *** CD-ROM | disk | FTP | other *** search
/ The Elite Hackers Toolkit / TheEliteHackersToolkitVolume1_1998.rar / HACKERS.BIN / appcraks / APACK061.ZIP / APACK.DOC next >
Text File  |  1998-01-09  |  7KB  |  162 lines
  1.                                                   ___.__
  2.                       _.____.___   __/\__  __/\__ \    | ____
  3.                 __/\__\.        \ /      \/   ___\|    </    \
  4.                /      \/   /T    \  /\    \  /   _|_   /    /
  5.               /  /\    \   \|     | \|     | \__/   |      /_
  6.              >   \|     <   |    /   |     <        <  T     <
  7.              |    /_.___|  /__._/    /__.__\_  __.__\  l_.___\
  8.              /__.___\ /______|  l___.__\     \/  /_______\AnG
  9.                          .:the:smaller:the:better:.
  10.  
  11.           Copyright (c) 1997-98 by  ─·Jibz·─  All Rights Reserved
  12.  
  13. aBOUT:
  14. ──────
  15.  Humm .. well .. nothing much to say yet .. the whole idea behind this
  16.  packer is to make executable files (especially small ones) as small as
  17.  possible (hence the slogan)..
  18.  
  19.  Exe-packers like LZEXE are ok for small files .. but the unpacker takes
  20.  up 330 bytes... WWPACK is great for medium and large files because its
  21.  compression is great ;) .. but _at_least_ 380 bytes for an unpacker is
  22.  way too much for 4k intros and BBS-intros (IMHO ;)..
  23.  
  24.  The unpacker in aPACK is between 136 and 236 bytes long (depending on the
  25.  input file). I have put a lot of work into making it as small as possible.
  26.  Compression ratio is a little worse than WWPACK (but I'm getting closer ;).
  27.  On small files (below 20k or so) I have not been able to find anything
  28.  better than aPACK).
  29.  
  30.  Furthermore LZEXE can be unpacked by any decent unpacker out .. and WWPACK
  31.  can be unpacked by CUP386. I have not been able to find an unpacker able
  32.  to automatically unpack aPACK files (except files that UPC works on ...
  33.  but then you can just use AntiUPC or something like that). Of course
  34.  anybody who knows anything about packers will be able to unpack files
  35.  packed with aPACK .. but at least most lamers won't be able to ;)
  36.  
  37.  So far aPACK is GREET-WARE for non-profitable use (if nobody charges money
  38.  for programs that are packed with it) which means that if you use it, then
  39.  please greet me (well, ain't that cheap!). If you (or anybody else) plans
  40.  to sell a program packed with aPACK then contact me (email address later..)
  41.  
  42.  You may not distribute aPACK without the rest of the files (aPACK.DOC and
  43.  WHATS.NEW). And you may not edit any of the files or sell aPACK for money
  44.  (except for charging for the media).
  45.  
  46.  Feel free to upload aPACK to any BBS or site, or including it on a CD..
  47.  
  48.  Bla bla bla .. the usual stuff - you know it anyway:
  49.  
  50.    If anything goes even remotely wrong - blame _yourself_, NOT me!
  51.  
  52.  
  53. aPACK "LIMITATIONS":
  54. ────────────────────
  55.  In the following:
  56.  
  57.   1) if your program has a problem with that - use some other packer!!!
  58.  
  59.  aPACK does NOT unpack the code back to where it would have been (why waste
  60.  space on code to do that ?) .. instead the unpacker is at the front of the
  61.  exe, and it unpacks the code further into memory. This, of course, requires
  62.  more memory .. but 1). When the unpacker jumps to the unpacked code, ES and
  63.  DS, as usual, point to the PSP (which has not been moved) .. hence the PSP
  64.  is NOT at CS-10h anymore, 1).
  65.  
  66.  I do NOT zero any registers in the unpacker .. if you need any registers
  67.  to be zero, then zero them in your code (the packed file will be smaller
  68.  that way ;). Again, 1).
  69.  
  70.  The experimental COM-packer only works (so far) on files where both packed
  71.  and unpacked data fit into 64k.
  72.  
  73.  The aPACK unpacker has NO funky little messages or other forms of "wastefull
  74.  bytes" - I have tried to make the unpacker as small and "clean" as possible.
  75.  
  76.  The unpacker depends on the input-file .. Eg. if all unpacked code fits into
  77.  64k then no code to handle segments will be added. And if there are no
  78.  relocations then no relocation-handling-code will be added (why add a full-
  79.  blown super-duper unpacker to a mini-file??)
  80.  
  81.  But if I get the time - and anybody starts using this util - I might add
  82.  switches for adding a "code-mover"...(anybody ?).
  83.  
  84.  
  85. aRGUMENTS:
  86. ──────────
  87.  So far there are only a few switches and arguments for aPACK:
  88.  
  89.     Syntax:   aPACK [options] <input file> [output file]
  90.  
  91.        General options:
  92.           -i    Invert literals
  93.  
  94.        EXE-specific:
  95.           -d    Don't save DS and ES
  96.           -r    Don't pack relocation-table and code together
  97.           -s    Force own stack in unpacker
  98.  
  99.        COM-specific:
  100.           -p    Leave segment of PSP in DS
  101.  
  102.  The switches can be given anywhere in the argument-list, in any case and
  103.  in any order you like. Input- and output file should be pretty self-
  104.  explanatory. The switches work like this:
  105.  
  106.    -i : Invert literals - this inverts all literals that are transmitted.
  107.         This makes it somewhat more difficult to read text-strings using
  108.         an hex-editor or some other viewer (unless of course you invert
  109.         them back :) .. This is NOT meant to be any kind of protection -
  110.         it merely makes the exe-file look more uninviting ;) It costs you
  111.         3 bytes.
  112.  
  113.    -d : Don't save DS and ES - if you do not need anything from the PSP in
  114.         your program, then use this switch. It makes the unpacker 4 bytes
  115.         smaller.
  116.  
  117.    -r : Don't pack relocation-table and code together - by default the
  118.         relocation-table is packed together with the code (unless there
  119.         are LESS than 8 relocations - in which case they are hard-coded
  120.         into the depacker). It is worth experimenting with this switch
  121.         on files with more than 7 relocations, but "not too many". May
  122.         save a few bytes .. on the other hand, may not ;)
  123.  
  124.    -s : Force own stack - forces aPACK to set up its own stack when unpacking
  125.         (usualy it chooses to add it's own stack whenever necessary). Costs
  126.         12 bytes.
  127.  
  128.    -p : Leave segment of PSP in DS - this will give you easy access to the
  129.         PSP from COM-files. And it saves you 2 bytes :)
  130.  
  131.  
  132. aLGORITHM:
  133. ──────────
  134.  aPACK uses (right now) LZSS with 57300 bytes lookback and lazy-matching.
  135.  Tag-bits are inserted in the data to distinguish literal bytes from
  136.  code-pairs. Code-pairs are encoded using my own version of Gamma-encoding.
  137.  
  138.  
  139. aPPRECIATION:
  140. ─────────────
  141.  .. goes out to the following people:
  142.  
  143.   * x-otic for being a great beta-tester and drawing me a logo (thx mate ;)
  144.   * "Jurik" for discussing the mysteries of Gamma-encoding with me
  145.   * The people who made the Epsilon Compression Page
  146.   * Piotr Warezak, for making a truly great exe-packer
  147.   * Michael Tippach (Wuschel) for making WDOSX (all you need now is a
  148.     good exe-packer, and I'll switch to WDOSX for sure ;)
  149.   * All other people who make good software freely available for non-
  150.     commercial use!
  151.  
  152.  
  153. aLWAYS THE NEWEST VERSION:
  154. ──────────────────────────
  155.  You can find it at:  ftp://ftp.elf.stuba.sk/pub/pc/pack/
  156.  
  157.  
  158. aND HOW TO REACH ME:
  159. ────────────────────
  160.  Well, if you have any questions, suggestions or bug-reports about aPACK (or
  161.  you just like chatting), this email-address should work:  jibz@hotmail.com
  162.