IE5 *was* pre-patched to VML vulnerability

As I was researching for ZERT to patch the VML vulnerability back in september, I found an interesting issue.
All ZERT members tried to get as many as possible VGX.DLL file versions (the affected DLL) from different Windows versions, so eventually I could write a generic binary signature (which will find the vulnerability point and later on patch it).

My signature worked for all DLLs I had, approximately 20 files. It didn’t work on 2 different DLLs for IE 7, which were pre-patched from June already (according to the compilation time, that is we assume the build machine is accurate).
You can read about it at:, a blog post “Zero Daze” written by Joe Stewart, also a member of ZERT.

There was only one DLL from IE5, that my signature didn’t “catch”. Back then, when I was writing the patcher, I didn’t have all DLLs in existence (this is the reason why I made it a generic signature). Some of them I got later, and my generic signature still worked well. Eventually, I realized that this DLL was already pre-patched.

Speaking technically: It had a size test in the beginning of the function. It checked whether the input buffer (fill method) isn’t longer than 0x100 bytes, if so it returned null. So in contrast with IE7 pre-patched DLLs, MS lets the fill method buffer be copied to the destination buffer (on stack), but stopped at 0xfe WCHARs. Same was done for the patched DLLs, which as you can see, is more permissive than that IE5 pre-patch.
Examining the compilation date of that IE5 file (specifically version:5.0.3014.1003) results in timestamp of Nov 30, 1999. Which makes sense, since IE5 came out when Win2000 came out too, take or give.

After all, it is clear that some source code was thrown out from the repository. The reasons behind I can’t tell, but it’s a solid proof that we were secure for a short period 7 years ago!
More than that, can researchers find vulnerabilities by going over on older versions of Windows’ DLLs to track bugs? (ala bindiff) you bet.
So what do you think really happened?

Enjoy the weekend,
Gil Dabah

Tiny PE – Rel0ad3d (304 bytes!)

Another long night, :sigh:

Creativeness is the name of the game,
in the end if you shave another byte or two, it’s not a big deal, (as much fun as it is, don’t get me wrong) you have to come up with better ideas. Sometimes, you are sure that what you got something good, but then you have to push your limits, and come up with something better.

I wish to thank Peter Ferrie, Nicolas Brulez and Jamz Yaneza for encouraging me and providing some information, about that downloader virus which is known to be around 330 bytes…

I haven’t got any sample of it, nor I know the real size, but to be sure my Tiny PE is smaller, my latest version stands at 304 bytes. If you read carefully my first blog post about this Tiny PE, I said that I was playing with Optional Header Size. So this time I cut a big part of it, and managed to crunch my code even more and put the Import Module Descriptor inside the header itself 🙂 Though, now I think I broke compatibility with other versions of Windows…

Who is going to get it to below 300 bytes? hehe.

You can find the latest Tiny PE here: tiny3.exe.

If you like Assembly, or you just happen to remember hex code by heart,
even something easy like: EB 02 13 37 33 C0 40 C3 (LOL – sad but true), then you should subscribe to our new code crunchers mailing list at !

Have a beautiful weekend,
Gil Dabah

Tiny PE – The Frenzy Ends! (or not, now at 304 bytes!)

For an update on how I got it smaller, check:

Hi everyone,

As I promised to get the tiny.exe less than 400 bytes, I sat last night and did it. Now with a new record size of 384 bytes and still supposed to run on all Windows versions. 🙂

You can find my original blog post with further technical details on this challenge here:

Here’s a snippet of the conversation between me and a good friend.
This is one of the ways to develop new tricks for code crunching:

Arkon: The problem with that URLDownloadToFileA is that it creates another thread,
Arkon: and that thread never terminates for some unknown reason to me.
Arkon: So I HAD to call ExitProcess and finish it, otherwise my process will hang. 🙁
Arkon: But now what I’m going to do is raising a silent exception 😡
Matthew: Just blow away the SEH chain and trigger an INT3.
Arkon: It will eliminate the string “ExitProcess” and the GetProcAddress code for it as well.
Matthew: BAM! 🙂 Instant process death…
Arkon: This is too long.
POP FS:[0]
Arkon: Nah
Matthew: XOR ESP, ESP might also do the trick 🙂
Arkon: LOL!!!
Arkon: Wait I’m stupid, push 0 is 2 bytes long.
Arkon: 2 bytes ExitProcess OMFG
Matthew: You’re a maniac

Thanks to my idea and to Matthew Murphy, I got the new .EXE size to merely 384 bytes.
It seems to be 99% usage of all spared room in the file…
If you even dare looking at this .EXE, you are crazier than me,
well – I wrote it, but you will have to understand it. 🙂
This is only one trick, there are way more undocumented tricks to explore and to learn from!

Check it out here:

Gil Dabah

Code Crunching – Tiny PE (challenge) [update #2: now with 304 bytes!]

[ Update: tiny PE is now at 384 bytes. The follow-up post and one of the techniques used to achieve this can be found here.
Update #2: tiny PE is now at 304 bytes: ]

Or shall I dare saying the Tiniest?

It all began a few days ago, a few friends challenged me to write a smaller PE executable than theirs.

Ground rules

It might sound fairly easy at first, but it’s not, and there is merely one simple goal:
Grab a file from the Internet and execute it.

With the following rules:
1) Only Imports section is allowed for kernel32.dll to get LoadLibraryA and GetProcAddress.
2) All strings must not be viewable (except rule 1), so we xor… 🙂

After working dozens of hours I came up with something extremely crazy, 411 bytes.

Most of the debuggers will hate this file and it has anti-disassemblers effect. I couldn’t check it on many systems, just my WinXP and it works nicely.

Here’s the hex:

Hex of Tiny PE
Continue reading Code Crunching – Tiny PE (challenge) [update #2: now with 304 bytes!]