Add support for binaries without static user32 linking

[TomSie]

Attaching to services/processes with dynamorio only works if the target process loads the user32.dll.

We should write a little tool/script that modifies Windows executables to add a dependency for user32.dll.

[joyride9999]

Hi, would like to give this enhancement a shot. To be on the same page:

• i guess this targets especially window console apps ?
• i see 2 ways:
  • either patching the file, by using some kind of resource editor ... ofc the file signature will be broken so windows UAC might not like this
  • installing a hook that loads does a LoadLibrary(user32.dll) in the process space

Integration with fluffi might come a bit later once i have POC :)

[TomSie]

Hey, thank you for your help!

A little information about the background of this task: What we basically need this for is running Windows service binaries in dynamorio. There are two ways to do so: 1) Start the target with drrun 2) use the AppInit_DLLs method.

In certain scenarios we need to use AppInit_DLLs. This method, however only works if the target process loads the user32.dll at its very startup.

And here comes the problem: Some Windows binaries (mostly Windows services, but also others) do not do so. They are not using any of user32.dll's functionaliry and therefore do not load it.

To overcome this, we need to change the binaries in a way that they statically load the user32.dll. Breaking the binaries signature is fine at this point, as our test systems don't check it anyways.

Injecting the user32.dll into the process once it is loaded won't work in our scenario, as it would be too late in the process (dynamorio wont work).

So my idea was to write a little program / script that parses the Import Directory Table (IDT), and the Import Address Table (IAT), and adds an entry for the user32.dll (preferably at the beginning, so it is loaded first).

If you are going to write this script please:

• Use python 3 or c/c++ (I would prefer the latter, as the Windows API comes with all the code to parse PE headers)
• Try coding it without adding a dependency to a third party library (if possible) - we already have tons of dependencies
• Support x64 and x86

Alternatively, you could also look for a freeware / opensource tool that does the job for us, and write a tutorial about it ;)

[joyride9999]

Thanks for the overview, i prefer also c++ :), also i've done something similar before (processing the PE file and changing some stuff there) so i have a bit of experience in this area !

[joyride9999]

Should i try to import all exported functions from user32.dll? ¯_(ツ)_/¯ ... there are quite a lot !

[TomSie]

As I understand the AppInit_DLL technique, one (any) should be enough.

[joyride9999]

It looks like InitializeLpkHooks needs to be exported. However LoadappInitDll is in other dll

However it looks like before calling this user32.dll (ClientThreadSetup) set ups some stuff, and those function calls might not work from the context of a windows service, as a service normally does not have a "desktop" so this means further code is necessary in order to aquire those handles when running from a service. Will try to do a test to see if this work !

[joyride9999]

Ok, so this is the solution i ended up with. All in all it has a dependency on PE Bliss lib (https://github.com/BackupGGCode/portable-executable-library) I decided to use it because it can be linked statically, there should not be any license problems, it can be included easily in any project as static project (so it shouldn't be needed to be downloaded on build like the other dependencies')

IDll.zip

If needed i can continue also on my little tool to inject the dll, basically its needed to copy the import directory section to a new section and there also add the injected dll ... but i don't see any advantage having it over PE Bliss (basically this is how i found Pe Bliss as i was thinking on making a nice PE image class with all the objects and then stumble upon this lib 🥇 )

[TomSie]

does this work for both x86 an x64?

[joyride9999]

yes it should ... i tested only on 32 with my service, but i can make a quick test also on 64 just need to rebuild my service again :))

[TomSie]

yes that, would be great :) Your solution looks quite neat btw. Correct me if I'm wrong: What you do is

• Read the Import Section
• Add a new import to it
• Create a new section
• Write the modified Import Section to the new section
• Overwrite the PE's pointer for Import Section to point to the new section

Is that correct?

[joyride9999]

y, that kind of sums it up ...

[joyride9999]

Y its ok 👍

[TomSie]

great work! I will integrate this into FLUFFI master as soon as I can spare some time :)