Code injection fails in combination with fodhelper UAC bypass (?)

[jumpsc4r3]

Hello,

I hope it is fine to write this in English. Please let me know a translation is required.

Im using a modified version of this code for injecting another PE file into the address space of the current executable. The code in this example and my modified version seems to work fine on all Windows version, but when I add the fodhelper.exe UAC bypass to the injector before running the code injection, it fails in a weird way:

After the injection is finished, the console window of the injected application (a C++ console application) shows up, but instead of carrying on with the execution, I receive a bunch of error messages stating "The code execution cannot proceed because [some garbage characters].dll was not found". One time so far the error message did not print garbage characters as file name but "vector constructor iterator'". After searching this specific string on the web, I found out that this has something to do with Visual C++ compiler generated functions.

I dont really understand whats going on here. Is the problem caused by the UAC bypass in some way or is it just coincidence that it only fails when the injector was launched by fodhelper.exe?

Any explanation or assumption is appreciated.

 

[DildoFagins]

Okey. The weird some garbage generated string.dll may come from the loader reading invalid import table of your injected executable. I can use my telepathic powers to try to find the reason for that. Let's see. As I see in the RunPE code it is made for x86 executable file. Maybe after using uacbypass you are staring some x64 process, then replace it's image with your x86 executable and obviously the system loader doesn't check that the executable is in fact x64 and just try to parse import table, but ends up in some weird bytes, due to reading data at invalid offsets in the x86 PE files. How about that?

 

[jumpsc4r3]

Okey. The weird some garbage generated string.dll may come from the loader reading invalid import table of your injected executable. I can use my telepathic powers to try to find the reason for that. Let's see. As I see in the RunPE code it is made for x86 executable file. Maybe after using uacbypass you are staring some x64 process, then replace it's image with your x86 executable and obviously the system loader doesn't check that the executable is in fact x64 and just try to parse import table, but ends up in some weird bytes, due to reading data at invalid offsets in the x86 PE files. How about that?

Thank you for your answer.
The injector, the target process and the application to be injected are x86 (it also works when starting the injector with a double click).
However, I noticed that fodhelper.exe only exists as 64bit application (System32) and not as 32bit version (SysWOW64).

Is it possible that there are some properties being inherited from the parent process (fodhelper.exe) that cause the error?

 

[DildoFagins]

Is it possible that there are some properties being inherited from the parent process (fodhelper.exe) that cause the error?

If a target process exists in both x86 and x64 versions and is stored in System32 and SysWOW64 or in Program Files and Program Files (x86), the fodhelper.exe would start a x64 version.

 

[DildoFagins]

But the process is started by your own code, which is x86 right? So the shouldn't be a problem with starting x64 process from System32. Anyway are you using absolute paths? What target process is it?

 

[DildoFagins]

Current working directory, environment variables may be inherited, I don't know what is fodhelper and how it works, but I think in some circumstances handles and other stuff can be inherited.

 

[jumpsc4r3]

But the process is started by your own code, which is x86 right? So the shouldn't be a problem with starting x64 process from System32. Anyway are you using absolute paths? What target process is it?

The entire launch chain looks like this:
Desktop/Injector.exe (x86) -> System32/fodhelper.exe (x64) -> Desktop/Injector.exe (x86 / Elevated) -> Desktop/Injector.exe (x86 / Elevated / Suspended for injection).

I also tried injecting into applications other than itself but it always fails anyways.

 

[DildoFagins]

What is the point in injecting to yourself? It is kinda hard to tell what is going on, try posting the code you are using for injection here, maybe it will make things clearer.

 

[jumpsc4r3]

What is the point in injecting to yourself? It is kinda hard to tell what is going on, try posting the code you are using for injection here, maybe it will make things clearer.

As I said, my code is only a modified version of the github example (which is also injecting into itself). Once I fixed this UAC bug I will add another injection so that it starts making sense, but for now it simply injects into intself for debugging purposes.

In the meantime I made sure that its really a problem with the UAC bypass. If I start the injector 10 times as user without UAC bypass, no problem, if I try with manual UAC elevation 10 times, no problem, if start 10 times using elevated cmd, no problem. Only if started by fodhelper.exe it fails. I doubt this can be coincidence.

I think the injection itself is not the problem. I guess I have to somehow find out what exactly fodhelper is doing differently...

 

[DildoFagins]

I think the injection itself is not the problem. I guess I have to somehow find out what exactly fodhelper is doing differently...

Probably. I'd suggest you use a debugger, but at least try putting OutputDebugString on each and every line, output all the variables and other stuff to it, try to figure out how the environment differs in both cases.

 

[jumpsc4r3]

Probably. I'd suggest you use a debugger, but at least try putting OutputDebugString on each and every line, output all the variables and other stuff to it, try to figure out how the environment differs in both cases.

Yeah...I started debugging the windows file.
I guess for some reason the loader thinks that the file is x64 and thats why the offsets are wrecked.
There are indeed some things inherited from fodhelper, as the working directory for all child processes is changed to system32... but changing that back didnt seem to help.

 

[jumpsc4r3]

Ok, I solved the issue. There are indeed some undocumented attributes for exploit protection that are automatically applied on some Windows executables (including fodhelper.exe). These attributes are inherited by any child processes and caused the bug. I could fix the issue using the UpdateProcThreadAttribute function.