Category Archives: Archaeology

Rundll32.exe bomb

Posted on by

Update

Turns out @sixtyvividtails has already discovered the very same issue via a minimalist PE file back in June. Touche!

Old Post

This is a silly example of a basic mistake leading to a funny discovery…

When I was experimenting with the imported phantom DLLs I accidentally placed a dummy 64-bit DLL in a place of a 32-bit phantom DLL called WDSUTIL.dll that was imported by the 32-bit uxlib.dll. I then attempted to enforce loading of uxlib.dll with a 32-bit version of rundll32.exe by referencing its full path c:\WINDOWS\SysWOW64\rundll32.exe:

c:\windows\syswow64\rundll32 uxlib.dll bar

Turns out that loading of the 32-bit library with an import that points to DLL that is actually 64-bit creates a chain of never-ending executions of the very same command line!

What happens is that when the 32-bit DLL (uxlib.dll) is loaded, the importing fails on the 64-bit phantomDLL (WDSUTIL.dll) which leads rundll32.exe to receive the ERROR_BAD_EXE_FORMAT error from the loading attempt, which in turn leads it to follow the internal _TryWow64Scenario path in its code, which… literally means creating a new SysWow64’s rundll32.exe process with the very same command line passed to it – aka repeating the cycle that we have started this test with!

This leads to a cascade of new rundll32.exe processes being spawn, and it’s similar in nature to regsvr32.exe bomb:

Yes, it is a dolbin!

The art of underDLLoading

Posted on by

In my previous post I created a posh artisan .exe file ornamented with a large number of intricate system32 DLL imports. The process of building that file was painful – before I even managed to run the final executable I had to troubleshoot a number issues – many of which I didn’t even expect (missing DLLs, missing manifest, random crashes, etc.).

In the process of sculpting it I decided to kick off a parallel mini project that would look at the problem from a different angle — instead of a single file, I decided to generate a lot of test executable files, where each of these files would import just ONE single DLL from the system32 directory + the kernel32 as I needed it for its ExitProcess API. I then ran all these compiled files one by one. The original idea was to isolate and troubleshoot problematic DLLs, but to my surprise, I got some other interesting results.

First of all, with the real-time detection on, Windows Defender started picking up on some of these executables one by one:

Linking to dpnaddr.dll, dpnathlp.dll, dpnet.dll, dpnhpast.dll, dpnhupnp.dll, dpnlobby.dll causes an interesting side-effect. When you run an .exe that links to any of these libraries, you get a DirectPlay Windows Features install dialog box:

This is a result of svchost.exe hosting Program Compatibility Assistant Service (C:\Windows\system32\svchost.exe -k LocalSystemNetworkRestricted -p -s PcaSvc) launching this dialog via fondue.exe:

Fondue.exe /enable-feature:DirectPlay /show-caller /top-most /caller-name:"test_<dllname>.exe"

This looks like a shim at work, but I have not verified it. And no, we cannot launch our own fondue.exe here as far as I can tell 🙁

Many other test files fail too, for many different reasons:

We can extract crash details from the Windows Event Logs/Applications:

When you start experimenting with a PE file format itself, there are no limits. By playing around with its frivolous structure we can create a lot of interesting and unexpected results.