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 32-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?

Thew result will be a never-ending chain 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 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!