eipl

[EddyHawk <quarsicon@...>]

Dear EXEList members,

"Executable protector is dead"
Since the beginning, executable protection relies on
undependable condition:
 trap door (Softice worm), bug (TR), security hole
(int1), etc
Executable protection is based on the never-ending
desire of software authors
 to protect his work from third-party interfere:
patching, modifying,
 cracking, hacking. But how it's possible? Computer is
never designed to
 be secure. Hardware even restrict the privilige of
software (breakpoint)
 in order to trace & filt error. Executable is
designed to be executed.
 Original code must be revealed, however complicated &
complex the protection
 is. Ultra-strong encryption doesn't help much to
improve protection because
 the key must be stored in the executable. A cracker
only need one copy of
 executable to crack it, even if each copy of the
executable is variably
 protected. Hardware identification protector only
works on certain hardware.
 Password protection is very annoying
The awareness of this thing inspires some protector
name, like Final Fantasy
 Security Envelope & iLUssion CRYPT
The amount of efforts to achieve secure protection is
equal with the amount
 of efforts to break it. EDUMP & GTR is written to end
this scheme, and it
 looks like that they are successful
But the need of protection is not just vanished. Even
for impossible
 environment like Win32, a bunch of protectors still
exist
Then how can we achieve the desired protection level
nowadays?
 Only one thing crossed on my mind: generic thing.
Make everything generic
That's why I proposed Executable Instant Protector
Laboratory (EIPL):
-collects all elements of executable protector
  user/author can add/modify/update the elements
(stored in separate file)
  each elements is sub-classified into:
  -minimal processor to run it (8086, 386, 386pm)
  -compatibility
(Win31/Win9x/Win2000/WinNT/LinuxDOSEMU/ OS/2)
  -placement (begin/middle/end/on certain sequences of
code/need certain
   arrangement)
 .all anti (debug/unpack/dump/trace/load/disassemble)
tricks ever invented
  -generic
   not restricted to specific unpacker (ex: CodeView),
but for certain type
   of unpacker (RM debugger)
  -specific
   kicker for fearsome unpacker that can't be
generalized
 .all exec packer
  -UCL
  -aPLib
  -LZSS
  -PKWARE
  -etc
 .all integrity check
  -MD5
  -CRC32
  -SHA
  -Snefru
  -checksum
  -etc
 .all mte & polymorphic engine
  -ZVCE2
  -SHAME
  -VICE05
  -BMWE
  -SMEG
  -$UPD21
  -TME
  -TPE
  -etc
 .all encryption algorithm (BlowFish, TEA, IDEA, etc)
 .all decryptor generator (RSS)
 .all relocation handler (RELOC100, Gabler's
RELOCHANDLER, RelPack)
 .all anti-virus-shield
-randomly selects (use one/some (P)RNG) one/some of
these elements to be
 applied to target executable,
 .more than 1 mte (like Gabler's TME & MMtE)
 .more than 1 encryption (algorithm)
 .more than 1 key
 .more than 1 decryptor
 or user-customized selection (pick only
 the fastest/most secure/most compatible/generic/dirty
protections)
 .user defined round(s)
-generates random/user decryptor & key if encryption
is selected
-each element has a rule of placements/condition in
order to be functional
 ex: ADTs should be integrated with decryptor; ADTs
should be put in certain
  instruction sequences, registers must be restored
after certain ADTs,
  these ADTs can be put anywhere, etc
 ex1: sp corruption value to kick RM debugger is
variable. EIPL are free
  to give random value
-each rule from selected elements is examined &
arranged properly inside
 protected executable to avoid disabling/corrupt one
another
-apply (pre-select/user/random) string to confuse
protector identifier :)
 'Darken-X (c) DarkLight [2K]. Get A Life!'
 'Registered To: EveryBody Who Can Read'
 'HackStop V4.5 Max build 330 (c) ROSE SWE 12-31-2001.
All rights reserved'
 'FirstFSE V8.11 by Zenix Yang 19995. Special
Non-Public Beta Version'
 'MESK 2.6i by StoneHead & Jose M. L. Lopez.
Regeneration Version'
 'PKLITE V3.37 by PKWARE. Never enough memory'
 'Debug Razor V9.87f (c)opyright 1919 Automata Inc.'
 'Code Blind (c) Blind_Nose / Bleeding_Eye [Blind
Corporation]'
 'Dedebug V666.999.omega by AlphaBet. This is Public
Last Release'
-very compherensive options for user:
 'EIPL, just give me the most secure & compatible 8086
protection for this 
  executable. I don't care about other elements
(choose it randomly)'
 'I don't care about other elements, except that you
must add 7 layer of
  TEA encryption & twice PSP_Shifter for this
executable'
 'Give all ADTs only (appending protector)!'
 'Give all Soft/WinICE tricks to my prog!'
The purpose of EIPL is the generation of completely
generic/random protector
 on each execution. No structure/signature can be
recognized/detected, thus 
 forces new unpacker to be (re)written for each
generated protected 
 executable (hopefully :)
EIPL may still not stand against EDUMP & GTR, but it
may? stands against
 UG2000 :)
Disadv:
-hard to collect/write
-slow protecting
-protector is dead, dead, dead
-nobody? interested to write it
-why bother with EIPL?
 it's much easier to fix security holes on FFSE V0.76
& UPStop V0.97,
 improve their ADTs size/speed/compatibility, add
anti-XFSE or anti-DEUPS &
 forcing EDUMP memory detection & GTR dirty trick as
the last defense

regards,
eddyhawk

__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/