Category Archives: LOLBins

1 little known secret of regsvr32.exe, take three

Posted on by

In the past I wrote a few times about the side-effect of having 2 binaries named the same way and residing in respective System32 and SysWOW64 directories.

Regsvr32.exe is not different. If you run a 32-bit Regsvr32.exe with a command line argument being a path to a 64-bit DLL or OCX, it will spawn its 64-bit twin Regsvr32.exe to handle the request:

I am happy to report that regsvr32.exe is using GetSystemDirectoryW and GetSystemWow64Directory2W APIs instead of relying on environmental variables to build the paths for respective binaries, so there is definitely less chances for lolbinish abuse.

Now, this is not the little known secret yet.

The secret is this:

When you force the regsvr32.exe for one architecture to spawn the other regsvr32.exe with the other architecture, the command line argument that you started with will be passed to children regsvr32.exe process, in full.

Do you see where it is going?

Based on the idea from the post number one in this series, we now know we can pass a list of library names (limit is 256) to regsvr32.exe and it will load them all one by one. What if we passed a command line argument that interleaves 32-bit and 64-bit libraries?

The result will be a never-ending, chain reaction-like tree of interleaving regsvr32.exe processes executed one bye one!

Do you want to test it at home?

Warning: do not try this at home!

regsvr32.exe c:\WINDOWS\system32\hhctrl.ocx c:\WINDOWS\syswow64\hhctrl.ocx c:\WINDOWS\sysnative\hhctrl.ocx

As far as I can tell this is the first documented case where c:\WINDOWS\system32\, c:\WINDOWS\syswow64\, and c:\WINDOWS\sysnative\ have ever been used together in a command line of any program.

And yes, you can add /s parameter to it too, that is – if you don’t want any control over it (/s stands for silent and is disabling any GUI feedback from regsvr32.exe)! 

regsvr32.exe /s c:\WINDOWS\system32\hhctrl.ocx c:\WINDOWS\syswow64\hhctrl.ocx c:\WINDOWS\sysnative\hhctrl.ocx

Be warned tough! This is a regsvr32.exe bomb! And it’s a possible DOLBIN!

1 little known secret of regsvr32.exe, take two

Posted on by

There is an archaic feature that regsvr32.exe leverages to autoregister libraries associated with file extensions.

For this to work, it expects an AutoRegister key to be present under the file extension handler with a default value pointing to the library f.ex:

file extension entry: txt -> txtfile
file handler: txtfile
autoregister entry: txtfile\AutoRegister\{Default}=<Library>

As such, one can use regsvr32.exe to load library of their choice without passing it as a command line argument to the program!

Let’s see an example for the txtfile:

reg add HKEY_CLASSES_ROOT\txtfile\AutoRegister /ve /d c:\test\bar.dll

echo > foo.txt

regsvr32 foo.txt

The AutoRegister feature requires the library supporting this feature to export a function called DllRegisterServerEx, but in my example I didn’t even bother as I just wanted to demo the DllMain Load…