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.