3

My question is regarding driver development for Windows 7.

I need to intercept system calls to a driver. Theoretically in such cases it's recommended to create a filter driver, however in my case the driver doesn't expose a filter-compatible interface. It's a Vista/7 display miniport driver to be exact.

Display driver is loaded as a standard WDM driver. In its DriverEntry it's expected to call a DxgkInitialize system routine (exported by win32k.sys I guess). My goal is to intercept this call.

Can anyone suggest me any useful source I can find information about how to achieve this?

The key to the victory is probably replacing the DxgkInitialize within the driver executable import section with the address of my function. The problem is that this should be done after the executable is loaded (mapped + relocated if necessary + all the import table entries are prepared), but before the driver's entry point is invoked.

I thought about the following options:

  • Map the executable into the system memory and "prepare" it manually (i.e. do the work of the loader). Then patch the needed function(s) and run the entry point.
  • With some effort ZwSetSystemInformation can be used for module loading (?)
  • Maybe patch the export section of the module that exports DxgkInitialize. So that the loader automatically will redirect every loaded module into my hands.

Thanks in advance.

valdo
  • 12,632
  • 2
  • 37
  • 67
  • 1
    Even if you do everything perfectly, 64-bit systems WILL blue-screen. Windows Vista and 7 specifically go looking for code that's been modified after it was loaded. A alternative, safer approach would be to replace the driver's import table on disk and change the module name from which imports are taken, but 64-bit Windows also won't load a driver without a valid signature, and it won't be valid if you edit the import table. – Ben Voigt Apr 11 '11 at 16:28
  • @Ben Voigt: Thanks, I see your point. I wonder however how the "code-modification-detection" works exactly. When the executable is loaded it **is** changed by the loader. In particular its import section. What if I change it once more, and then - immediately restore to the original state (after the driver will call that function) – valdo Apr 11 '11 at 18:35
  • @Ben Voigt: Plus, do you know if there's a legal way to achieve what I want: spying for the "display" activity. That is, I want to know when something is displayed on the screen. As a minimum - where. Nice to have - what exactly (drawing command sequence). Thanks a lot. – valdo Apr 11 '11 at 18:39
  • 1
    @valdo: I may have overestimated the degree to which KPP would interfere. ["It does not offer any protection against one device driver patching another"](http://en.wikipedia.org/wiki/Kernel_Patch_Protection) Especially look at the referenced [work by Skywing](http://uninformed.org/index.cgi?v=6&a=1), it's excellent. Based on your goals, I think you should be writing a ["mirror display driver"](http://msdn.microsoft.com/en-us/library/ff568315.aspx), which is much better supported and doesn't require meddling with internals of other kernel modules, so should be much more stable and composable – Ben Voigt Apr 11 '11 at 19:43
  • @Ben Voigt: Indeed mirror display driver is a standard way to go. And, as you pointed out, it's much simpler, plus there're already dozens of open-source mirror drivers available. **However**, from my experience, this approach has some limitations. Especially when it comes to DD (DirectDraw) and D3D. In particular I've read that enabling the mirror display driver automatically disables the "aero"-stuff in Vista/7. In the past I've managed to achieve what I described under Windows 2k/XP. Now I need to do something similar for Vista/7. But maybe I'll go the "mirror driver" way anyway. – valdo Apr 11 '11 at 20:39
  • 1
    @valdo: [This](http://www.datronic.de/cms/Windows-Display-Driver-Develop.15.0.html) seems to be a good summary. Probably nothing there you don't already know. If losing Aero isn't acceptable, I would suggest hooking `dwm.exe` instead, since all WDDM drawing goes through there anyway, and you're much less likely to destabilize the system with user-mode hooking. – Ben Voigt Apr 11 '11 at 20:50
  • @Ben Voigt - PatchGuard is disabled when your machine is booted with the /DEBUG flag (which also disables the need for driver signing), so if this project is just for his own machine then patching out bits of his kernel is dangerous but entirely achievable. He won't be able to sell his new awesome driver to normal users though - as they'll all have PatchGuard getting angry at his driver. – SecurityMatt Mar 07 '12 at 23:10
  • PatchGuard doesn't check drivers memory. It works only for a kernel. – Sergey Podobry Jun 14 '13 at 15:22

1 Answers1

0

You don't provide a business reason for this, so I'd hesitate to say something harsh. But you should reconsider your technological approach if it involves hooking calls.

The steps I'd take would probably include:

  1. Who exports DxgkInitialize? Don't guess win32k, look it up. (I won't give you the answer). Maybe you can easily hook the callee and not the caller.

  2. Do I have any callbacks of when a driver module is loaded but before it's inited? Lookup PsSetLoadImageNotifyRoutine. Maybe it will provide you an appropiate timeslot to patch the drivers IAT (if you don't know what an Import Address table is, reconsider hooking).

I see from the comments that you're primarily interested on "spying on display activities". I'm not sure that's precisely allowed on computers you don't fully control. But lets assume for the sake of the question that this is legal.

Depending on the resolution you want to get, you don't need a driver. Heck, you barely need a DLL. Look up Window hooks for partial solutions and accessibility callbacks.

Daniel Goldberg
  • 19,908
  • 4
  • 21
  • 29