Technical PE Information
 
---------------------------------------------------------------------------  
  PERULES v1.00  (SOME [INCOMPLETE] RULES FOR PROTECTORS LIKE PELOCKnt)
  
  1. MZ/PE HEADER
     Never erase the EXE/DLL Header itself, Windows NT uses it too often
     to load DLL's or lookup some values for internal/external things.
  
  2. ALIGN RVA's TO DWORD
     All RVA's should be aligned on 4 byte boundary!
     Microsoft document: "Image pages are aligned and zero padded to a
     File Align boundary.  The bases of all other tables and structures
     must be aligned on DWORD (4 byte) boundary.  Thus, all VA's and RVA's
     must be on a 32 bit boundary. All table and structure fields must be
     aligned on their 'natural' boundaries".
  
  3. MODIFIED TABLES OR STRUCTURES SHOULD BE INDICATED BY A ZERO (0) RVA
     
     A. IMPORTTABLE
     The RVA should be dword aligned. If the ImportTable will be erased or
     modified indicate this by a dword ZERO inside the DLL-NAME RVA field
     (DD Relative Virtual Address of the DLL asciiz Name).
     Absolut any value inside the IMPORTTABLE might be destroyed EXCEPT the
     IMPORT ADDRESS TABLE itself. Keep this in mind and don't use pointers
     to ascii names like KERNEL32.DLL (GetModuleHandleA would fail) or
     MessageBoxA which could be overwritten already by another protector.
     
     B. FIXUPTABLE (RELOCATIONS)
     The RVA should be dword aligned and points to Fixup blocks having the
     following format: DD PAGE RVA, DD BLOCK SIZE, DW FIXUP... After erasing
     the fixuptable it should look like PAGE RVA=0 and BLOCK SIZE=0.
     The SIZE of the fixup table itself should be either 0, 8 (PELOCKnt)
     or 0Ah (PEShield) - be careful, a value of 0 don't seem to work.
  
  4. TLS (THREAD LOCAL STORAGE)
     Better don't touch the RVA or the TLS entries itself.
  
  5. FLAGS FOR PETOOLS (DWORD)
     Supportvalues for unpacker, analysing tools etc.
     I searched a long time for a place inside the PE Header to store a
     single bit for any protector. Only a address with a usual dword value
     of ZERO is possible. First I thought about the end of the PE-Header,
     but the PowerBuilder compiler has a wrong value in PE-Header+54h so
     the HEADER-SIZE would be wrong calculated. Finally I checked 1000h
     files and found the value right before the first ObjectName at
     [NT-Header Size + 18h]=PE-Header-Start + 0F4h being always ZERO.
     
     PE-Header+0F4h = DWORD [PETools] Flags
       The flag bits have the following definitions:
        
        o  000000xxh __ByteNumber of PEProtectionLayers, increment it.
        
        o  00000000h __Packing and crypting allowed
        o  00000100h __Do NOT pack or crypt this file at all
        o  00000200h __reserved
        o  00000400h __reserved
        o  00000800h __reserved

        o  10000000h __PELOCKnt          (c) Marquis        
        o  20000000h __PE-Crypt          (c) Random
        o  40000000h __PEShield          (c) Anakin
        o  80000000h __
        o  01000000h __Shrinker          (c)
        o  02000000h __WWPack32          (c)
        o  04000000h __...
        o  08000000h __
        o  00100000h __

        Add your own protector to the PE-Header is easy:
        inc     byte  ptr [PETools]
        or      dword ptr [PETools],10000000h    ;Flag for PELOCKnt
   
     Only those protector/packer get listed here, which are compatible to
     Windows NT4 and Win98.
     COMPATIBLE is defined by:
      a. being able to protect at least MSPAINT.EXE AND MFCxx.DLL.
      b. allow another protector on top of itself.
         Shrinker (although it works) is incompatible because it does not
         allow another packer on top of itself. Calc.exe would be incompa-
         tible too if it don't allow a packer on top of it without crashing.

  6. SOFTICE
     In general: any protected file will/should work 100% normal even with
     Winice in the background as long as no breakpoint is set. But just a
     single enabled breakpoint might cause a total reset.
     Means: Do NOT reset the computer unless you are sure winice is used to
     TRACE your program. Windows should be handled different than plain
     DOS. Why? Once you booted into DOS in seconds, but if someone resets
     your PC today because the softice-check is positive you might loose
     your Internet Connection, unwritten data and maybe more. Windows than
     needs 2 holy minutes to boot up and 2 more minutes to get in Internet
     again. Noone will like this.

    
  Last words: It's easy to code a program, but it's much harder to make
  it compatible to all others. Remember how often you called Win95 a
  simple big bug, but was it really Win95 which caused the error?
  Although we all know "Rules are made to break these rules" PELOCKnt
  will follow the above documented rules wherever possible.
  Feel free to complete the document with your own rules, alter or add
  something if needed, email me or re-release it.