Page 1 of 1

Driver survives reboots, but how about injection requests ?

PostPosted: Thu Mar 17, 2016 6:01 pm
by Overnissen
Dear madshi,

Having the injection driver survive reboots is absolutely a great thing, so it automatically starts when the system starts, very convenient for many purposes.

It would appear that it doesn't remember injection requests from the last session, or at least the beta driver doesn't, is that a design choice ?

Respectfully

Re: Driver survives reboots, but how about injection request

PostPosted: Thu Mar 17, 2016 6:37 pm
by madshi
It's a design choice at this point. I was afraid of introducing stability issues when starting injection too soon during the boot process. However, many users asked for this feature, so I'm going to implement it for madCodeHook 4.0.

Re: Driver survives reboots, but how about injection request

PostPosted: Thu Mar 17, 2016 9:00 pm
by Overnissen
I know what you mean..

My challenge was that I need the injection driver to perform the injection, ideally when my application is running, but in order to communicate with the driver through the API the application needs to run with administrative (or elevated) privileges, that is not possible or by me anyway considered particularly responsible, needing to have my application run with elevated privileges.

So I created a small service that starts automatically and starts the injection.

This have quite correctly created some quite peculiar results, as when the service is running (or starting automatically) certain processes behave a bit odd, like run at 100% CPU, but only some, like the shell (explorer.exe) and Firefox, they behave quite odd if the service starts the injection before the user logs on..

If I set the service to "Manual start" and then just run a small application (with elevated privileges) after logging on, initiating the injection with the _exact_ same parameters, everything works brilliant, perfect, I find that to be a bit odd..

So I'm now delaying the injection request until I can see the explorer.exe process and examine it to see if the hooking .dll have already been loaded and if not, initiate a system-wide injection.

Do you have any idea what causes this slightly odd behavior ??

Re: Driver survives reboots, but how about injection request

PostPosted: Thu Mar 17, 2016 9:05 pm
by madshi
Not sure which madCodeHook version you're using. You could try this one, it's a release candidate for the next official build, will probably be released next Monday:

http://madshi.net/madCollectionBeta.exe (installer 2.7.12.15)

If the problem still occurs with that build then there's a good chance that the problem could be something in your code. I think several madCodeHook users are injecting in a service and nobody has complained about any problems to me so far. I'd suggest you empty DllMain as a test, to see if that changes anything. If that solves all problems, try putting Initialize/FinalizeMadCHook back in. If there are still no problems, put the HookAPI calls back in one by one. Maybe one of the API hooks is reponsible. If you do more than just call InitializeMadCHook + HookAPI in DllMain, try commenting that out.

Re: Driver survives reboots, but how about injection request

PostPosted: Thu Mar 17, 2016 9:26 pm
by Overnissen
I'm using madCodeHookBeta 2.7.12.11

I would tend to agree with you, except that if I perform system wide injection after login, everything works without any problems..

Anyway, I'll try the latest build for sure and see where that takes me.

I'm using Delphi XE5 btw, I wasn't to call Initialize/Finalize was I ?

Re: Driver survives reboots, but how about injection request

PostPosted: Thu Mar 17, 2016 9:57 pm
by madshi
No, that's only for MSVC++ users.

Re: Driver survives reboots, but how about injection request

PostPosted: Fri Mar 18, 2016 12:29 am
by iconic
Overnissen,

I do a lot of service work and the most important thing to pay attention to is that depending on your service start type (say auto), especially when you're spawning another process is to ensure that you wait for the correct time to do this. For example, you might wait inside the service control handler for the WTS_SESSION_LOGON event, and then say create a process after creating the proper environment block. Otherwise, processes started too early in the Win32 environment (especially desktop/windowed programs) may have strange side effects. It's easiest to use CreateEnvironmentBlock() in this case as per my example. It's even more problematic when you set a lower-level service load order group, say TDI for example. At this stage most interactive processes such as Explorer aren't even created yet. Loading before WinInit is also possible and will result in potential problems. This is because the user environment isn't completely initialized. Just my experience...

--Iconic

Re: Driver survives reboots, but how about injection request

PostPosted: Fri Mar 18, 2016 7:43 am
by Overnissen
Iconic,

Thanks, but I'm not spawning another process, if you got that impression I apologize.

It's basically just a very simple service that starts and checks if the injection driver is running, if not it attempts to start it and then if successful, submits an injection request for the driver to inject the hooking .dll(s) into all processes system wide, excluding system processes.

The problem that I'm experiencing is a bit annoying, as everything appears to work just fine and then, after "some time" suddenly certain processes like the shell (explorer.exe) and Firefox 32 bit winds up to 100% cpu on the processor core they're running on.

I have noticed that whether I use the service to initiate the injection or do it from an application I launch after login appears to not matter, I know I stated the opposite in an earlier post, but that was what it looked like at the time, I just hadn't waited long enough for the problem to appear, sometimes it shows after 5 minutes maybe, at another occasion it shows after hours, it's really quite unpredictable.

So, to exclude the driver all together I'm now testing on it without even using the driver, just a regular InjectLibrary call to madCodeHook into those two specific processes, to see if it still behaves odd "after a while"..

To be continued.. :)