Last Version Hopefully

of Tiny PE that is. 216 bytes – over here.

 Some juicy details of the new tricks:

1. I had a gap of 4 bytes between two code chunks. 4 bytes is an immediate of 32 bits. Instead of jumping over this 4 bytes (which is a pointer to import data directory), I just skip over them using something stupid like MOV EDX, <DWORD>. Where <DWORD> is a place holder for the pointer. This way I destroy the value in EDX, but I chose EDX because I don’t use it anyway. I end up sparing a byte this way because jmp is 2 bytes long, and opcode for the mov is 1 byte.

2. Another problem was that the opcode of the mov was the same data as part of the export data directory size which poses a limitation on the values I could put there. Make long story short – I changed the base address of my image and adding size field of the directory size (the byte code for the mov is the high byte in the size DWORD field)  with the new base address there is no overflow and the exports continue to work well…

3. Immediately following the ‘Number Of Sections’ field I had the decryption loop code. In the beginning I used XOR for simplicity but now it’s changed to ADD R/M8, REG8. This is because this field is two bytes (a WORD) with the value of 1, means the image contains only one section and the second high byte is 0. The ADD byte code is 0. Do you make the math? So now I reuse this 0 byte to be a code for my decryption loop. Cool as it is, I had to change the code which encrypts the data in the image. XORing is really easy to do, but now my instruction looks something like this: add byte [ebx+ecx+off], bl. Mind you I know the value in BL in static time. Therefore I had to change the algorithm. Let plain-text-byte be P and value-of-BL be B, we got the following: Cipher = (P+256-B) & 255 for each byte we want to encrypt. The trick here is the modulo base, since we work with byte units (and it seems they are eventually truncated to 8 bits), we have to consider the add with the modulo. Decryption is actually: P = (Cipher + B) % 256. Anyway this way I saved one byte and it was a good practice on modulo stuff… ;)

4. Another byte was shaved by changing the URL of the image I download and execute by changing the URL from:

http ://ragestorm.net/f.DLL
to
http ://ragestorm.net/kernel32.DLL

Naughty? I need the kernel32.DLL anyway. So this way I can remove the ‘f’ and put the “kernel32” instead. So yes, now you’re downloading a file called ‘kernel32.DLL’ from my site. Though it’s being saved as something else locally… Ahh BTW-this way the image should be Win2000 compliant, but I can’t check it out. Any volunteers?

I wanted to release the code a month ago, but since then I have changed the code so many times. I think this is my final version for now :grins:. So I will pretty the code a bit and document some stuff and release it.

2 Responses to “Last Version Hopefully”

  1. This version does not work in Vista32. The program terminates with the following message displayed in the console window: “Error in EXE file”

  2. arkon says:

    I know :) Thanks.

Leave a Reply