rash - dummy EXE packer

[encode]

OK, just for fun, check out my dummy EXE packer:
rash.zip (46 KB)

This package contains:
rash.dat - a decompression stub, written using Delphi 2007
tc.exe - TC v3.4 - an old compressor which uses LZW
make.bat - a brief script for packed EXE creation

Note that this is a kind of a non public release made for testing purposes only.

Also note that:
The EXE size may not be larger than 16 MB
The size of a packed file may not be larger than 8 MB

So, do not pack a large executables!

Have fun!

[LovePimple]

Thanks Ilia!

[nimdamsk]

Now compare with !352 bytes of !LZMA decoder in upack Got this number making simple computations with numbers from readme.txt, can't check it anyway Full PE header is 496 bytes long Mew also has tiny LZMA depacker, it's bigger but fuster. Not to say about UPX FSG has (imo) smallest LZ decompressor, second is mew's LZ. Crinkler has something like CM in it's tiny decompression engine.

[encode]

This new UNWHAP-like LZW decoder should be faster and smaller than LZMA of course.

Current draft source code:

 
PROCEDURE INSERTNODE(L: INTEGER); INLINE; 
BEGIN 
  TAB[N].POS := P; 
  TAB[N].LEN := L; 
  INC(N); 
  IF N = $10000 THEN 
    N := 256; 
END; 
 
PROCEDURE COPYBLOCK(I, L: INTEGER); INLINE; 
BEGIN 
  REPEAT 
    BUF[P] := BUF[I]; 
    INC(P); 
    INC(I); 
    DEC(L); 
  UNTIL L = 0; 
END; 
 
PROCEDURE DECODE; INLINE; 
VAR 
  I: INTEGER; 
BEGIN 
  N := 256; 
  P := 1; 
  FOR I := 1 TO M DO 
  BEGIN 
    IF BIN[I] >= 256 THEN 
    BEGIN 
      INSERTNODE(TAB[BIN[I]].LEN + 1); 
      COPYBLOCK(TAB[BIN[I]].POS, TAB[BIN[I]].LEN); 
    END 
    ELSE 
    BEGIN 
      INSERTNODE(2); 
      BUF[P] := BIN[I]; 
      INC(P); 
    END; 
  END; 
  DEC(P); 
END;

By the way, does anyone know hot to execute a program in memory. For example, RASH decompresses data to BUF[].

Briefly tried simply JMP to BUF[ENTRYPOINT OF ACTUAL EXE] - not works program crashes.

Note that currently RASH dumps unpacked code to a tmp file...

[osmanturan]

Do you use FastMM in your packer? I like it very much. My old game engine based on it. FastMM gives about 20% additional speed to my engine without changing my code

Another thing, your stub's size can be decreased. There is a unnecessary block in delphi generated executables which called relocation section. When I've tried StripReloc for removing it, I've noticed that this section was already removed.

And last thing, you can remove any resource from your stub (like icon, pictures etc.)

I have tested it with our commercial software executable (The biggest executable that I have got - written in delphi). This software is a leather dressing catalog for leather shops in Russia . Here is the test result:

mymt.exe
Original Size: 5.619.712 bytes
Packed Size: 3.059.236 bytes

[osmanturan]

Executables can not be run by using direct jump actual entry point. There must be lots of preparation for executing at operation system level. Because, needs some rearranging codes i.e. making DLL links. So, there must be a set of API calls like that purpose. You may decompile a virus Else you must use TEMP folder But, this makes some error due to working folder. Our software didn't run properly

[osmanturan]

Another thing, Kaspersky Internet Security 7 detected packed executables as infected by a virus

[Black_Fox]

Thanks encode! Are you going to use QUAD 1.12 or LZPM 0.06 (perhaps with added exefilter)? Those have relatively small executables, compress better, so the resulting file could be even smaller (in worst case, you can always pack the stub ).

Full PE header is 496 bytes long

Reminds me of this

[nimdamsk]

Reminds me of this

http://www.phreedom.org/solar/code/tinype/
May be this?

[nimdamsk]

Another thing, Kaspersky Internet Security 7 detected packed executables as infected by a virus

To be more precise it detects unusual way to execute programs

[encode]

To be more precise it detects unusual way to execute programs

Yep, since my packer first unpacks and dumps it to a temporary file, after executes it. Kaspersky dont like such behavior - it marks it like Hidden Install... Anyway, when RASH will run a program from memory - all will be fine.
But first of all, Ill improve the compression untouching the decoder:
1. Eliminate dictionary resetting
2. Add an optimal parsing

QUAD 1.12 or LZPM 0.06

By itself, the decompression speed of the new codec is really faster. I think its even faster than LZOP and others. So, firstly Ill write a small program to test an optimized LZW.

[encode]

To be more precise it detects unusual way to execute programs

Furthermore, looks like the file was added to a Kaspersky database as a malicious program! Since the files packed by this software may not be unpacked freely...

[nimdamsk]

LOL!
They are blazing fast! May be Dr.Golova is reading this forum?

[encode]

May be Dr.Golova is reading this forum?

During these days I sent lots of files packed by RASH to various online scanners, including scanner at kaspersky.com...
Its sad, each time I compile my project - exe file automatically deleted by KAV. KAV screams WORM! Damn, its simple exe packer...
From now on Ill freeze the RASH development, due to LZW compression improvement. Later versions of RASH will not be such freely available.

Yes, instead of writing correct unpacker its easier to mark files as a Trojan in their database... FUCKERS!

[nimdamsk]

Send unpacker source to Dr.Golova (can take his contacts on Kaspersky forum) - and you won't have problems If you'll imagine how many young "hackers" develop their packers every day, may be you won't be so strict to AV developers. They write unpackers only to wide-spread packers. And i think Dr.Golova is the man who made Kaspersky's upacker stuff best in the market. It's funny that days before he joined K.Labs he wrote articles (see uinc.ru for example) how to full AVP engine
P.S. Do you really want to make competitor to UPX or FSG? Yet Another?

[Black_Fox]

P.S. Do you really want to make competitor to UPX or FSG? Yet Another?

95% packers use either LZMA or aPlib, its hard to say there is something unique... If some comparately effective compressor using other (home-brewn) coder emerged, it would be great

[nimdamsk]

May be it would be better to add new compression engine to mature and almost open source UPX.

[encode]

May be it would be better to add new compression engine to mature and almost open source UPX.

Actually the main purpose of this packer is to test a new compression. Like you see, the compressed stream consists from 16-bit words only. Thus we can keep a simple array of words, organizing an efficient buffering.
Furthermore, I further improved this variant of LZW, keeping decoder untouched.
One of the main questions of LZW - what to do if dictionary became full?
1. Reset
2. Freeze
3. Rebuild
My answer is to keep the entire dictionary as is, each time replacing an oldest entry. Its impossible with UNIX COMPRESS-like implementations but with UNWHAP-like its OK.

To do this trick possible, I rewrote the LZW encoder in LZ77 manner.

Some experimental results (a generic LZW versus RASH, lets call an improved LZW - RASH )

world95.txt
LZW: 1,304,146 bytes
RASH: 1,059,928 bytes
Original: 2,988,578 bytes

english.dic
LZW: 1,600,476 bytes
RASH: 1,543,228 bytes
Original: 4,067,439 bytes

acrord32.exe
LZW: 2,527,954 bytes
RASH: 2,395,558 bytes
Original: 3,870,784 bytes

A10.jpg
LZW: 1,187,912 bytes
RASH: 1,098,894 bytes
Original: 842,468 bytes

The disadvantage of any LZW is an extreme inflating, if data already compressed. However new trick gives some improvements in this case also.

Overall, nice improvements, keeping in mind that decoder stays the same and its LZW! Many papers described an improved versions of LZW, but with changed decoder - which makes decompression slower... But here the decompression is even far more faster than with a generic LZW.

At next step, I will try to improve a parsing.