OSDev.org

Just a few minutes ago, I got an email from someone saying "Important details!" with a zip attachment. I looked at a hex dump of the zip and saw in clear text (not compressed...), "This program cannot be run in DOS mode". Haha, right! I wonder what that is.

The import table says that it imports LoadLibraryA, GetProcAddress, VirtualAlloc and VirtualFree from the Windows kernel. Clearly it loads more code at run-time from DLLs that they don't want anyone to know about from the import table. They also stripped the relocations (obviously), so I can't find out where those imports are referenced.

At any rate, I disassembled the executable, but the assembly doesn't make sense. At the entry point (0x403e5f), there's the following code:
  403e5f:       b8 6e 3e 40 00          mov    $0x403e6e,%eax
  403e64:       80 00 28                addb   $0x28,(%eax)
  403e67:       40                      inc    %eax
  403e68:       81 00 67 45 23 01       addl   $0x1234567,(%eax)
  403e6e:       90                      nop    
  403e6f:       cb                      lret  
  403e70:       76 39                   jbe    0x403eab
  403e72:       ff 50 64                call   *0x64(%eax)
  403e75:       ff 35 00 00 00 00       pushl  0x0
  403e7b:       64 89 25 00 00 00 00    mov    %esp,%fs:0x0
  403e82:       33 c0                   xor    %eax,%eax

Look at that code right there: it modifies itself. Right now it looks like it's dead code (where the hell is it returning to with the lret instruction?), but in reality it changes itself. Sneaky... Unfortunately, I don't know what exactly it's doing. I assume it is is jumping somewhere else in the code. Can anyone else make any sense of it?

Here's the executable: http://flyswatter.dyndns.org/~michael/Details.exe

If you're running Windows, be careful not to run it. It is a virus after all. I' m running Linux, so I don't have to worry (as long as I don't invoke Wine)

there's nothing special about it. this is a special form of SMC (selfmodifying code) and is used quite often. *every* exe-packer or exe-encryptor uses that way. they usually attatch a section to the exe which decompresses (or decrypts) the code (maybe loading modules too) and jumping to the original entry-point of the program.
ah, ya, what it does, you ask? despite i'm hating AT&T-syntax, i took a closer look. so, eax is loaded with the value 0x403e6e, obviously the address of the 5th line. the value of that address (0x90) is added 0x28.
so, 0x90 + 0x28 = 0xb8 - the first byte of an instruction? - let's move on thinking...
the value of eax gets increased (pointing to the next code-byte).
then the instruction add [eax],0x01234567. it does excactly the same as before, but with a dword.
so, 0xff3976cb (you have to read the next 4 bytes in reverse - big endian you know) + 0x01234567 = 0x005CBC32.
so, what's the result? the instructions
>nop
>iret
>jbe 0x403eab
>call (i can't read that line..., maybe it's [eax+64h]? i don't know. as i said - i hate that syntax)
become
>mov eax,0x005CBC32
and the next instruction is at address 0x00403e73
50    push eax
64 ff 35 00 00 00 00  push fs:[00000000]
64 89 25 00 00 00 00  mov fs:[00000000],esp

then the code seems to be like normal, like in the disassembly.
so, it makes the disassembly not readable, but acutally there's just harmless and useless code written over it.

greets, hartyl