Permanent Injections problem

c++ / delphi package - dll injection and api hooking
Post Reply
ngidalov
Posts: 5
Joined: Mon Mar 07, 2011 8:22 pm

Permanent Injections problem

Post by ngidalov »

Hi,

We are using madCodeHook 4.0.3 with EV signed driver and Cross Signed by Microsoft.
The System is Windows 10 64bit.
In the installed we do permanent driver installation and also permanent loading of the libraries.
Example code:
////////////////////
res = InstallInjectionDriver(driverName, driver32Path, driver64Path, driverName);
res = InjectLibraryW(driverName, dll32Path, ALL_SESSIONS, TRUE, TRUE);
if (Is64bitOS())
res = InjectLibraryW(driverName, dll64Path, ALL_SESSIONS, TRUE, TRUE);
////////////////////

Libraries are also EV certificate signed and cross signed by MS.

Just after those calls, the driver is installed and started and both 32bit and 64bit libraries are injected properly.
However, after restarting the system , the driver is properly started , but the libraries are not injected any more.
It looks like the bPermanent = TRUE, does not have any effect.

I looked into the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WSupportDriver to find if there is "driver private data" that contains the names of the dlls that the driver needs to inject automatically, but could not find any.

What I'm doing wrong?
How can I make sure that after restart the installed driver will automatically inject the libraries?

Thanks in advance.
Nikola
madshi
Site Admin
Posts: 10749
Joined: Sun Mar 21, 2004 5:25 pm

Re: Permanent Injections problem

Post by madshi »

Hi Nikola,

the user mode part of madCodeHook is supposed to store the DLL information into the registry, in the moment when you call InjectLibrary() with the permanent flag set to TRUE. It seems that this doesn't work for you? I'm wondering if it could maybe be an access right problem? You can find the code in "DriverInject.cpp" in the function "JectDll()". Maybe you can debug what happens there?

Of course in the moment when you call UninjectLibrary(), the registry is cleaned up, but you don't call UninjectLibrary(), do you?
ngidalov
Posts: 5
Joined: Mon Mar 07, 2011 8:22 pm

Re: Permanent Injections problem

Post by ngidalov »

Hi Mathias,

Thank you for your answer.

After a lot of try and error tests, I would like to give you some feedback and request some more help.
--------------------------------------------------------------
After some code debugging and tracing, I can now confirm that both calls
if (Is64bitOS())
res = InjectLibraryW(driverName, dll64Path, ALL_SESSIONS, TRUE, TRUE);

res = InjectLibraryW(driverName, dll32Path, ALL_SESSIONS, TRUE, TRUE);

successfully inject both 32bit and 64bit dlls in all running processes and also add entries in the Driver Registry location as the permanent injection dlls.
The Registry looks like image Capture.jpg.
The "DLL 001" key contains the dll64Path (path to the 64bit dll) and the "DLL 002" key contains the path to the dll32Path.
So far so good.

BUT, When the system is restarted, and the drivers is auto started, only the 32bit dll is automatically injected into the 32bit processes, but no 64bit dll is not injected in any 64bit (native) process.
As a test, I used the IOCTL_ENUM_INJECT IO CONTROL and the drivers reports that both 32bit and 64bit libraries exists into the DllList into the driver.
So, the drivers loaded correctly the data from the Registry, but for some reason the 64bit dll is never loaded into existing and newly started 64bit processes?
Any help is much appreciated.

Regards,
Nikola
Attachments
Capture.JPG
Capture.JPG (38.63 KiB) Viewed 8648 times
madshi
Site Admin
Posts: 10749
Joined: Sun Mar 21, 2004 5:25 pm

Re: Permanent Injections problem

Post by madshi »

When calling InjectLibrary(), you say injection succeeds for all running 64bit process. This injection is performed by the user mode part of madCodeHook.

Does injection (before the reboot!) also succeed for newly created process? This part is performed by the driver.
ngidalov
Posts: 5
Joined: Mon Mar 07, 2011 8:22 pm

Re: Permanent Injections problem

Post by ngidalov »

Mathias,

Thank you for the quick replay.

Yes, after the res = InjectLibraryW(driverName, dll64Path, ALL_SESSIONS, TRUE, TRUE) call (before re-starting the PC), the 64bit dll is injected in every new 64bit process. Whenever I start notepad.exe (which is 64bit app) or any other 64bit app, I can see the 64bit dll injected. After each injection, I create a log file for each process, and also I can confirm the dll is injected using ProcessExplorer from SysInternals.

Is there any way to enable more diagnostics from the kernel driver without the need to re-compile the driver with more debug messages and re-sign the driver?

Regards,
Nikola
madshi
Site Admin
Posts: 10749
Joined: Sun Mar 21, 2004 5:25 pm

Re: Permanent Injections problem

Post by madshi »

The driver by default doesn't log, but I suppose I could create a special driver build with some logging to get to the bottom of this. But before I do this, do you have the chance to double check this on another PC? Would be good to know if this problem is specific to one PC, or whether it occurs on all your PCs.
Bevan Collins
Posts: 42
Joined: Fri Jul 07, 2006 2:50 am

Re: Permanent Injections problem

Post by Bevan Collins »

I am also facing this problem with madCodeHook 4.0.4.
I inject permanently a 32bit and a 64bit dll. Before reboot, the dlls are injected into running and new processes. But after reboot only the 32bit dll is injected.
I have been able to replicate it on Windows 10 (16299) and Windows 8.1 (9600) but not Windows 7 (7601).
Bevan Collins
Posts: 42
Joined: Fri Jul 07, 2006 2:50 am

Re: Permanent Injections problem

Post by Bevan Collins »

The work-around I used was to install a windows service that called InjectLibrary with permanent = FALSE and then exited. It would be much nicer if the permanent flag worked though.
madshi
Site Admin
Posts: 10749
Joined: Sun Mar 21, 2004 5:25 pm

Re: Permanent Injections problem

Post by madshi »

Hi Bevan,

I'm sorry for the extremely late reply. There will finally be a fix in the next build (planned for later this week or early next week).

The (initial version of) the fix was actually provided by Nikola - thanks for that!
Post Reply