View Full Version : 0x20 bytes instead of 0x00 in PE header?

March 27th, 2008, 14:32
Hi all,

Today I came across a very strange problem... there was a new malware I had to analyse, but strangely it was impossible to load it into OllyDbg (cannot laod, no matter what event options I was using), no PE editor got along with it (they all reportes the exe was not legal), and in a VMWare the executable didn't run (not enough space available); but I was told it's running on a standalone system (not virtualized). I couldn't confirm that definitely yet, because I have currently no standalone system available as victim. But the guy who let it run there has the same md5sum, so I guess he used the same binary.

By looking into a hexdump of the file, I found that in the header there are a lot of 0x20 (spaces) where I'd expect 0x00 bytes. Here's the start of the hexdump (done using sfk):


>4D5A9020 03202020 04202020 FFFF2020< MZ. . . .. 00000000
>B8202020 20202020 40202020 20202020< . @ 00000010
>20202020 20202020 20202020 20202020< 00000020
>20202020 20202020 20202020 E0202020< . 00000030
>0E1FBA0E 20B409CD 21B8014C CD215468< .... ...!..L.!Th 00000040
>69732070 726F6772 616D2063 616E6E6F< is program canno 00000050
>74206265 2072756E 20696E20 444F5320< t be run in DOS 00000060
>6D6F6465 2E0D0D0A 24202020 20202020< mode....$ 00000070
>EC855BA1 A8E435F2 A8E435F2 A8E435F2< ..[...5...5...5. 00000080
>6BEB3AF2 A9E435F2 6BEB55F2 A9E435F2< k.:...5.k.U...5. 00000090
>6BEB68F2 BBE435F2 A8E434F2 63E435F2< k.h...5...4.c.5. 000000A0
>6BEB6BF2 A9E435F2 6BEB6AF2 BFE435F2< k.k...5.k.j...5. 000000B0
>6BEB6FF2 A9E435F2 52696368 A8E435F2< k.o...5.Rich..5. 000000C0
>20202020 20202020 20202020 20202020< 000000D0
>50452020 4C010320 C37C1041 20202020< PE L.. .|.A 000000E0

If you look for instance at offset 0x3c, where the PE header offset is expected, you find 0x20e0, and of course there's nothing there. But, at offset 0x00e0 you can see the "PE".

Either this executable is really fucked up, I'm plain stupid, or there is some issue that such "executables" can somehow be started anyway? Maybe some feature I'm not aware of...?

Thanks for any help,

[EDIT] Hmm I think I found a trace, seems to have to do with microsofts "Rich format"... still I can't yet make much sense out of it.

Daniel Pistelli
March 27th, 2008, 17:27
Rich Format? Don't see the link to it. It seems more likely to me that this is a trick to fool pe editors and things like that. If you say that this exe can be loaded by windows, then the windows loader is only considering the first byte of e_lfanew. Just replace the initial 0x20 with 0x00 and you'll have a 100% working exe again. Not that I tried, but I'm assuming so.

Edit: I tried to modify the e_lfanew value the same way and it doesn't work for me on my winxp.

March 27th, 2008, 18:55
Some crappy webservers tend to replace zeroes with spaces for files with "text/plain" mimetype, which might be assigned to .exe files if the server is not configured properly.

March 28th, 2008, 11:42
Thanks, I'm not yet 100% sure but I think I found the problem. Indeed all zero bytes in the files seem being replaced by spaces - I suspect not by the webserver, but by opening the exe in a notepad and writing it back (stupid hackers).

By asking again the other guy I now know he didn't calculate the md5 on the very file he successfully started, but made a second download. Actually this very malware URL seems to return different binaries (note that the host in the URL is an IP address, so no flux stuff or so). I suspect there's some kind of load balancing that redirects request to different backend servers, and one of the binaries there is just bogus. So finally it was no RCE issue at all ...

April 6th, 2008, 16:50
regarding the server serving different binaries, it may be checking the User-Agent in the GET request as well to decide what binary to serve.

April 6th, 2008, 16:55
Thanks - and yes, meanwhile I'm sure that source IP address as well as user agent are evaluated by the webserver.