Category Archives: Random ideas

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.

The art of overDLLoading

Posted on by

Some time ago I came up with a silly idea: i’d like to build an executable that statically links to most of the c:\windows\system32 libraries. It’s a non-sensical programming exercise, but it’s also an interesting challenge.

Forcing a static import of so many libraries into a single executable is actually a non-trivial task, and there are many approaches we can take to do it. Most of the high-level language-based avenues one can pursue here are kinda problematic though, because they are full of custom library building aka lots of troubleshooting. After looking at various programming languages I have eventually found myself looking at the assembly language compilers available out there. The incredible simplicity of generating your own, customized import tables offered by fasm immediately caught my attention.

With a bit of python foo and fasm compilation magic, I was able to build this monster (79K APIs):

I am not 100% sure it is a correct PE file (in terms of all structures filled in properly), but it seems to run on windows 11 (with a caveat that it reports a critical error).

If you are wondering what is the purpose of this exercise, I’d like to throw a few ideas:

  • linking to many OS-dependent libraries could be an interesting guardrail technique
  • it may break tools (it would seem it breaks python’s pefile module and it causes problems to decompilers)
  • it is a great learning exercise about a PE file format; after so many years of dealing with it I am still surprised how much I don’t know about it

And here’s the import table as seen by Ida:

An attempt to copy these function names to clipboard pretty much freezes the program.