madshi.net

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

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...

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!!!

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?

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?

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.

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!

I'm pretty sure the injected dll is initialized in any case. Disabling protected mode just makes it easier to see/check.

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.

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.