1 little known secret of advpack.dll, LaunchINFSection

Yes, yet another oldie with a secret…

The .inf files are as old as Windows itself, and their internal structure has been covered by many, and over at least last two decades.

So, what’s new?

Well…

Ever heard of LoadAdvpackExtension ?

This simple .inf file demonstrates how to use it to load a DLL of your choice:

[version]
signature=”$CHICAGO$”
AdvancedINF=2.5,”test”

[DefaultInstall]
Patching=1
LoadAdvpackExtension=test64.dll

To launch it, you need to do the following:

Place the above .inf file in c:\test\test.inf
Place test64.dll in c:\test
Go to terminal: cmd.exe
Run: set path=.
Run: c:\windows\system32\rundll32.exe advpack.dll,LaunchINFSection c:\test\test.inf,,1,

We change the PATH to make sure our test64.dll is found in a current directory, and then loaded:

Beyond good ol’ Run key, Part 149

This post is a nothing burger. I didn’t make it work, but I still want to document it.

When I came across a ‘GPExtensionDLL’ entry expected under

HKLM\SYSTEM\CurrentControlSet\Services\MPSSVC\Parameters

I got excited, because it looked like a typical undocumented registry entry that can be abused for persistence.

After setting it up, as usual, to point to my test DLL I restarted the system only to discover the system … crashing.

After a few back and forth, it downed on me that the code that loads that DLL is surrounded by other code that relies on code pointers expected to be hard coded to point to proper function addresses, which is not always the case, hence system BSODs after calls to a null pointer-based function.

So, does this entry deserve to be even mentioned in this series?

I think so.

We cannot exclude the possibility someone will figure it out better than me, there is always an opportunity to stop the execution after the main DLL module is loaded, and in general, one of the goals of this series is to document ALL possible persistence mechanisms out there, no matter how difficult it is to actually take advantage of them…