home *** CD-ROM | disk | FTP | other *** search
-
-
- THE NAUGHTY UNPACKER
- ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙
-
- VERSION 1.3
-
- 16 Feb 1992
-
-
-
- WHAT DOES THIS PROGRAM DO?
- ~~~~~~~~~~~~~~~~~~~~~~~~~~
-
- This tiny little program will unpack almost all packed
- executable programs. If you try it on a program which isn't
- packed, in most cases it will tell you, even though it does
- not really check for specific unpacking routines.
- The things it checks for (on the supposedly packed program!) are:
-
- 1. Is the file executable?
-
- Some guys always try everything to crash their computer...
-
- 2. Does the program contain a symbol table?
-
- Usually packers do NOT add symbol tables, and the ones
- that the unpacked program may contain would be packed
- too anyway...
-
- 3. Is the program relocatable?
-
- Someday a packer might be written by someone, which adds
- relocation information, but since this would be very stupid,
- I don't expect this too happen. In fact, this is a very good
- method to check for packed programs, since most unpacked
- programs of a certain length are relocatable anyway...
-
- 4. Now this is the only check made that's a bit tricky:
-
- The Unpacker looks for certain instruction sequences in the
- program, which are usually used by the unpacking routine
- after having unpacked the original program to check if this
- is relocatable (and then relocate it).
- These are: (assembler of course...)
-
- a) tst.l (An)
- beq.s xxx
-
- This is used by the Ice-Packers and some others. An is an
- address register which usually contains the address of the
- offset of the first address to relocate. If it is 0, the
- program is not executable, and the relocation routine can
- be skipped (beq.s xxx). I also check whether the address
- xxx if more than $30 bytes from this sequence, since this
- is about the maximum size for a relocation routine...
-
- b) move.l (An)+,Dn or move.l (An),Dn or move.l -(An),Dn
- beq.s xxx
-
- Some other unpacking routines use these sequences to check
- for relocation information. An contains the same as in the
- above case, xxx is checked again as above.
-
- If none of these sequences exist, the program is assumed to be
- not packed! I know this might fail some packers, but I haven't
- found one... Please send me any packers that don't work...
-
- ##########################################################################
-
- HOW DOES IT UNPACK THE PROGRAMS?
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
- What the Unpacker does, is in fact load the packed program, look for
- the instruction sequences shown in (4) above, and replace them with
- a JMP yyy instruction pointing inside the Unpacker. Then, a (dummy)
- basepage is constructed, and the unpacking routine is executed.
- This is the critical point. If the program was not packed, despite
- all checks made being positive, it is very likely that you'll get
- bombs (and other nasty things...). Some old unpacking routines also
- assume that the space below address $78000 is free, and copy
- themselves there before executing. This will crash the computer if
- it wasn't free because you had many Accessories loaded, or TSR's.
- This however is the packer's fault not mine! The only packers I
- know of with this "bug" are the bytekiller packers (also known as
- COMPAK_x.TTP). Then again, some unpacking routines make some
- assumptions about the registers' contents when the program is
- started. The Pompey Packer v2.6 for example assumes that A4 points
- to the first address after data segment. I fixed the Unpacker so
- that this will be correct, but in some other cases other assumptions
- may be made that I didn't foresee... This might be changed though
- in a later version of the program.
- You should also bear in mind that some unpacking routines do other
- things before starting the decompression, such as check for the
- correct resolution, if the program was run from the auto folder etc.
- In this case, the unpacking routine will terminate the program,
- because it doesn't know of course that we only want to save the
- unpacked program, and not execute it!
- There are many other reasons that your computer might crash when
- using this program, so be careful. I don't think this will destroy
- your data, except if you use it on a program with a protection that
- wants to destroy your data when it sees that it's being modified etc.
- Anyway,
-
- ##########################################################################
-
- DISCLAIMER:
- ~~~~~~~~~~~
-
- I AM NOT RESPONSIBLE FOR ANY LOSS OF DATA OR OTHER DAMAGE THAT
- YOU SUFFER FROM USING THIS PROGRAM EITHER BY NOT USING IT CORRECTLY
- OR DUE TO AN ERROR IN THE PROGRAM!
-
- USE THIS PROGRAM ENTIRELY AT YOUR OWN RISK!
-
- ##########################################################################
-
- KNOWN BUGS:
- ~~~~~~~~~~~
-
- - Programs packed with DC-Squish will go in an infinite loop.
-
- HISTORY:
- ~~~~~~~~
-
- Version 1.0, 2 Feb 1992:
- ------------------------
- The first version, tested with Pack-Ice, Pack-Fire, and many other
- packers. No checks being made at all.
-
- Version 1.1, 3 Feb 1992:
- ------------------------
- - Fixed incompatibility with Pompey Packer v2.6
- - Added some Alert-boxes for easier use.
- - Added checks for executability, relocation, symbol table.
- - Wrote a documentation (fingers still hurting :)
- - Fixed a bug which caused the program to crash after trying
- 3 files...
-
- Version 1.2, 12 Feb 1992:
- -------------------------
- - Relocatable programs can now be unpacked, if they have been
- packed with the Happy Packer or Pompey Packers (I hope!)
- - First version of Packers list (PACKERS.LST). Thanks Richard
- Clarkson for the idea!
-
- Version 1.3, 16 Feb 1992:
- -------------------------
- - I finally managed to test the program with PP v1.9a packed files,
- and fixed it so that they are recognized (they are relocated too).
- - (Potential) unpacking routines which used the following sequence:
- move #2/#3,-(sp)
- trap #14
- addq.w/.l #2,sp
- to find out the screen address and copy the unpacking routine below
- that address are now forced to use a safer address...
- - The JAM Packer versions 3.0 pre-release and release 1.1 are now
- supported (pre-release only LZH compression), due to the above
- change!
-
- ##########################################################################
-
- WHAT IS THE PROGRAMMER ASKING FOR?
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
- 1. Do not try to hold me responsible for anything that goes wrong
- with this program. I tried to make it fool-proof as much as
- possible, but the way it works requires some risky and tricky
- code...
-
- 2. Please always copy this DOC together with the program. You may
- have noticed that it contains a great deal of information on
- how the program works, and when it may fail.
- Also, I don't like typing long texts, so this is particularly
- valuable! :)
-
- 3. Please report to me any bugs or incompatibilities (there must be
- quite a few!!) or any changes you would like me to make.
- Especially, if you see any new packers whose packed files can't
- be uncompressed, please send them to me!! You'll get your disk
- back together with a new version of the program if you send it
- by mail, otherwise you can send it to me to my e-mail address
- (UUEncoded) and I'll upload a new version anyway. I don't know
- how long my account will last, so if your mailer bounces the
- address, please try it by normal mail...
-
- Also, if you would like Naughty to support packer formats which
- are not supported in the current version (look at PACKERS.LST)
- for various reasons, mainly because they use unusual code for
- relocation etc., tell me, and I'll see what I can do!
-
- 4. This is a very small program, the source code however is about 30K
- (which is not very much either) in assembler. It is quite hard to
- maintain (especially with my programming style :), but I don't
- think this is a suitable program to release as Shareware. So this
- is FREEWARE, AS LONG AS YOU COPY ALL FILES TOGETHER!!. If you still
- want to donate money I won't complain, :) but I prefer bug-reports
- and/or useful information and/or new packers! I think this will
- make this program more useful (but the source even bigger ARGH!).
-
- If you like, you can send me some empty disks too!
-
-
- My address is: email:
-
- Marinos Yannikos kdv_521@eiaida.tuwien.ac.at
- Wulfeniaweg 3 kdv_521@eimoni.tuwien.ac.at
- A-9100 Völkermarkt
- AUSTRIA
-
-
- HAPPY UNPACKING!
-
- Marinos Yannikos
-
-