IDs (Guids) for Madshi drivers?

[n3evl]

It appears that a user needs to have admin privileges to load/unload Madshi drivers (there is a specific priv that can be granted to a user/group via Local Security Policy). At least this is the behavior I have seen in my application - can anyone confirm this?

In any event, there appears to be a better solution (if this is indeed needed). Microsoft supports configuring computer policy to allow Non-Administrators to install specific devices. So this means I could avoid elevating the privs of users and modify the policy for the Madshi drivers (32 & 64 bit) instead. In order to use this alternative approach, I need to know the GUID for the Device Setup Class for each driver but I have been unable to find this information. MS indicates it is typically obtained via the .inf file but I don't see any .inf file - just the .sys files.

The MS policy config is documented here: https://technet.microsoft.com/en-us/lib ... 25772.aspx

Any advice appreciated.

[madshi]

There is no such thing for a driver like the one used by madCodeHook. I think such GUIDs are for hardware drivers.

What you can do is write a little service which would then load the driver. Services usually have all the needed privileges. You'd just need admin privileges once to install the service. The HookProcessTermination demo shows how to do this:

http://madshi.net/HookProcessTermination.zip

[n3evl]

OK thanks for the information. Actually, we already have a service but maybe we aren't taking advantage of its capability to load/unload. I'll take a look and see what we're doing.

[n3evl]

I've compared the sample service to what we currently have. Our service is implemented as a subclass of some ATL class but essentially implements the same things.

The problem I'm seeing is as follows"

Normal (non-admin) user logs in to windows
Same user now logs into a client app
Client app send IPC msg to injection service
Injection service invokes InjectLibraryA() for 32 and 64-bit drivers; no errors reported, all seems well
Windows user now chooses to run another application as administrator (e.g. Excel)
Excel hangs; windows becomes unstable; reboot required.

The above bad outcome can be prevented by either of the following:
- User logs in initially as admin, does everything as admin or
- Otherwise 'normal' user is given load/unload driver permission, logs in as self, does all other steps as described above

So my question are:
- Why does logging in as admin or logging in as user with the specific permission make a difference since the driver load is occurring in the context of the service which is running as System?
- Is there some step I may have missed in configuring the service so that the driver load does not depend on the logged-in user's permissions and the windows hang does not occur

BTW, I have no idea what triggers the odd behavior of the second app run as admin other than it does not occur unless the driver load occurs; in the absence of the driver load operation, windows behavior is normal. Running the secondary app as normal user also does not trigger the bad behavior.

[madshi]

Does the Excel hang problem also occur with the demo? Or does it only occur with your own project? If the demo shows the same problem on your PC, have you tried a different PC (e.g. a VM)? I see no such stability issues on my PC, at least, and I haven't received any similar complaints from other madCodeHook users.

[n3evl]

I have not tried the demo - I'll look into doing that and see what happens.
The problem originally occurred on a customer machine. I was able to reproduce the behavior on a VM and subsequently determine the workaround via running as admin or config the user with the specific load driver permission. I suspect it is something specific to our project. Will report back if I learn anything further.
Thanks for the response.

[madshi]

If the demo works, but your project does not, then I'd suggest to first double check if you've followed the "hooking rules":

http://help.madshi.net/HookingRules.htm

If you find anything obvious, I'd suggest to first try to comment out all your HookAPI() calls. If that doesn't change anything, let me know and we'll go from there. If it does help, you can put the HookAPI() calls back in one by one to find out which one is causing the issue.

[n3evl]

OK, the character of the problem has change quite a bit since I last posted. It turns out some of my previous observations were in error. So here is what I think is happening:

Our 'normal' windows user logs in to windows and runs an application that requests our injection service to begin injecting our dll.
Our injection service is working normally - we inject our dll into the list of processes including system processes when we invoke InjectLibraryA for both 32 and 64-bit processes
We specify an exclusion list for processes into which we do not want to inject our dll.
Later, another process (Excel) is run as administrator by our 'normal' user.
The run-as-admin attempt causes a new process (that runs ..\windows\system32\consent.exe) to be created
Somewhere behind the scenes, Madshi code attempts to inject into the new consent.exe process and from this point, Windows becomes unstable.
Consent.exe IS listed in the process exclusion list supplied to the initial InjectLibraryA calls.

I think the Windows instability is actually due to some things we do in the injected dll such as some of our hooked functions get invoked and in these we are accessing shared memory. However, this only appears to be a problem when done in the context of the 'Consent' process. So, I guess I'd prefer not to inject into that process at all.

Assuming the above makes any kind of sense, should the behind-the-scenes injection into this process occur even though we specified the name in the exclusion list earlier? Since we do not appear to be in control of injections performed after InjectLibraryA has been called, I can't see any way to prevent the injection into this specific process .

[madshi]

I've seen "run as" operations being notified to the driver with one process name, which then later suddenly changes to something else. Maybe it's something like this. The madCodeHook driver is supposed to not touch any processes in your exclusion lists at all (no memory allocations or patches). So my best guess is that at the moment when the OS notifies my driver about the "Consent.exe" process, the file name/path might be reported different somehow. Do you have the full path in the exclusion list, or just the file name? Some system32 processes are created without a path, or with some %system% variable or stuff.

One additional option (just to be safe) is that you could check in DllMain of your hook dll in which process you're loaded (GetModuleFileName(NULL)), and if you then find you're loaded in Consent.exe, simply skip all the madCodeHook initialization/finalization stuff, so the hook dll is nothing but an empty shell in that process. Not nice, but better than to hook APIs which cause problems.

[n3evl]

OK, that gives me someting to think about & look into. In the exclusion list, I do supply the full pathname which is "C:\Windows\system32\consent.exe".

Thanks, will post again when I finally get to the bottom of this

[madshi]

Try only the exe name. Not necessarily as a final solution, but as a test to see if that helps. If it helps, the path obviously is different somehow.