Injection problem with processes having the same name

c++ / delphi package - dll injection and api hooking

Injection problem with processes having the same name

Postby michel » Thu Apr 03, 2014 11:30 am

My dll injection works fine for any processes but Acrobat Reader.
Acrobat runs two processes with the same name "AcroRd32.exe:
- the parent one ("...\AcroRd32.exe")
- the child one, the renderer ("...AcroRd32.exe" --channel=1976.1.1033634757 --type=renderer")
Only the parent is injected.
My problem is that I have to manage windows messages like HCBT_XXX or WM_XXX and that they are sent to the child not to the parent.

I don't know if this is a general feature as I don't inject processes having children with the same name like iexplore.exe.

Is this a madCodeHook problem or did I miss a setting in SetMadCHookOption (I set USE_NEW_IPC_LOGIC)?

Michel
michel
 
Posts: 24
Joined: Tue Aug 10, 2010 4:20 pm
Location: Paris France

Re: Injection problem with processes having the same name

Postby madshi » Thu Apr 03, 2014 1:00 pm

I suppose you're using system/wide DLL injection? Are you starting the DLL injection before or after Acrobat Reader is started? Please try both, just to be safe...
madshi
Site Admin
 
Posts: 9774
Joined: Sun Mar 21, 2004 5:25 pm

Re: Injection problem with processes having the same name

Postby michel » Fri Apr 04, 2014 4:14 pm

Sorry. The madCodeHook injection works fine.
I trace the injected dlls actions in files using the Process Identifier as a part of their names.
Sysinternals Process Explorer displays the processes tree with the main processes (with a PID) and eventually the child processes (with different PIDs).
I did not get the 'child' processes traces and I thought that they were not injected. So my stupid post!
It appears that the child processes PIDs found by my code are the parent one! I tried the different windows functions (process ID, process ID from thread ID...) and the madCHook library ones (process or process from thread). Each of these functions returns the same 'parent' process ID (the one displayed in PE) but never the 'child' ones(the ones displayed in PE).
I don't know how PE found the child PIDs!!!
michel
 
Posts: 24
Joined: Tue Aug 10, 2010 4:20 pm
Location: Paris France

Re: Injection problem with processes having the same name

Postby madshi » Fri Apr 04, 2014 4:28 pm

I think one of the process enumeration APIs tells you which process created which other process. Not sure, was it NtQueryInformationProcess? Or NtQuerySystemInformation? Don't remember...

So, no problem with madCodeHook, right?
madshi
Site Admin
 
Posts: 9774
Joined: Sun Mar 21, 2004 5:25 pm

Re: Injection problem with processes having the same name

Postby michel » Sat Apr 05, 2014 8:30 pm

Thanks for the functions.

I made extended tests (having Acrobat running or not before the injection). I added a window message box as the first code of my injected DllMain. It appears that;
- AcroRd32.exe (main process, the Acrobat broker?), 32bit medium integrity:
* is injected
* displays the message with its PID...
* produces a trace
- AcroRd32.exe (child process, the Acrobat renderer? The one interesting me), 32bit low integrity:
* is injected
* doesn't display the message
* doen't produce a trace
- AdobeARM.exe, started by Acrobat Reader (for automatic update):
* is injected
* displays the message with its PID...
* produces a trace

Thsi sound like the child Acrobat Reader (with the properties command line "...\AcroRd32.exe" --channel=6156.1.1479966364 --type=renderer") injected DLL's entry-point function is not called.
The main Acroabt Reader (with the propeties command line "...\Reader\AcroRd32.exe") injected DLL's entry-point is called and for all other injected processes as expected!

Did you have any idea?
Is it possible to 'force' a call to the dll entry point?
michel
 
Posts: 24
Joined: Tue Aug 10, 2010 4:20 pm
Location: Paris France

Re: Injection problem with processes having the same name

Postby madshi » Sat Apr 05, 2014 9:31 pm

I think you're drawing the wrong conclusions. The child processes are running in a very strict sandbox. They probably block the window message box. It's very unlikely that DllMain isn't called. Just the code you're using there is blocked by the sandbox.
madshi
Site Admin
 
Posts: 9774
Joined: Sun Mar 21, 2004 5:25 pm

Re: Injection problem with processes having the same name

Postby michel » Sun Apr 06, 2014 4:58 pm

Right. My Acrobat was in protected mode.
When this mode is disabled the injected dll is initialized (called).
This prove that application Protected Mode (Acrobat, Internet Explorer,...) works and blocks 'malware' programs trying to inject them!
michel
 
Posts: 24
Joined: Tue Aug 10, 2010 4:20 pm
Location: Paris France

Re: Injection problem with processes having the same name

Postby madshi » Sun Apr 06, 2014 5:32 pm

I'm pretty sure the injected dll is initialized in any case. Disabling protected mode just makes it easier to see/check.
madshi
Site Admin
 
Posts: 9774
Joined: Sun Mar 21, 2004 5:25 pm

Re: Injection problem with processes having the same name

Postby michaelgorelik » Mon Mar 02, 2015 9:12 am

Hi Mathias,

In Acrobat 11 under OS 64 bit i noticed an enhanced sandbox technique.

While i can inject the dll using your driver into any renderer process in Acrobat 10.x , i fail doing it on Acrobat 11.

More precisely , i debugged the code using windbg and noticed that Acrobat hooks ntdll earlier than madshi (doing it while creating the child process and writing directly to its memory in suspended state - only the ntdll is loaded). so what actually happens is that Acrobat tries to load my dll , and while loading the dll and before intilizing (calling its dllmain) - in its hook which redirects from ntdll to acrobat executable it unloads the dll (unmaps) even before initlization - so the loading of any dll into renderer fails.
michaelgorelik
 
Posts: 1
Joined: Mon Mar 02, 2015 9:05 am

Re: Injection problem with processes having the same name

Postby madshi » Mon Mar 02, 2015 9:52 am

Hi Michael,

that sounds like the first sandbox which is that agressive. The next madCodeHook version (4.0) will have 2 new injection methods, which (hopefully) both might not be affected by this. For now I don't have a quick solution for this. I don't have an ETA for v4 yet, either, but I plan to have it ready in the first half of this year.
madshi
Site Admin
 
Posts: 9774
Joined: Sun Mar 21, 2004 5:25 pm


Return to madCodeHook

Who is online

Users browsing this forum: No registered users and 3 guests

cron