I need to change the output buffer whenever a call to ZwDeviceIoControlFile is made. Is it possible to hook ZwDeviceIoControlFile from within a kernel mode driver in Windows 10 x64 while Patchguard is enabled? If not, could I maybe use ObRegister callbacks to change its output buffer?
Would like to know if someone ever succeeded with this on Windows x64 while PG is enabled.
I ended up writing a Hypervisor and using EPT to hide the actual hook when PG does a read operation on the region. I am able to fully hook kernel APIs without PG noticing on Win 10 x64.
Related
I'm remote-debugging a Windows kernel-mode driver using WinDbg. The driver has issues in the initialization routine, leading to a bugcheck/crash when installing the device driver. When I detach the debugger, the target PC reboots and runs again into the same bugcheck.
In order to test a new version of the driver, I therefore have to boot into safe mode, uninstall the device using device manager and reboot into normal mode.
Is there any way to simplify this workflow so that the device driver is automatically removed upon rebooting after a bugcheck?
Additional infos:
I'm using dpinst to install the driver on the target PC
use .Kdfiles to pull a replacement driver during boot
Documentation From MS
Write Up in Nt Insider From Osr Online
if you are using windows 10 then you can leverage the -m option to provide a partial name
and forego the dospath C:\ NtPath \.\xx , %SystemRoot%
confusions in the map file formats ,
or as described here
I've got a driver for a custom PCI card, which builds and runs fine on XP. I'm trying to use this custom hardware on W7, and am trying to build and run my driver.
I've got the latest DDK from Microsoft, and build my driver for XP using Windows XP "x86 Free Build Environment". Everything installs & works fine. (Build using a DDK "build" command)
If I use the Windows 7 "x86 Free Build Environment" build environment, everything builds fine. I run it through the PREfast and staticdv code checkers, no errors from either. ( I get a couple of warnings about "The dispatch function 'FooFnc' does not have any __drv_dispatchType annotations" - are these likely to be the issue? )
When I install, the install starts OK (standard error about drivers not being signed), but gets to a certain point and then hangs, then fails with a timeout error. The device then shows up in device manager as installed. At this point the PC won't shutdown or boot, but hangs indefinitely. I'm forced to boot into Safe Mode and uninstall the driver from there.
So my question(s) are:
If there has been a change in the driver model between XP and W7, what's the best way to find it? I can't see anything on MSDN.
How would I go about debugging the driver? The box doesn't start, so it's not like I can run up WinDBG.
Any specific W7 driver gotchas that are hidden away?
I've tried to keep this as generic as possible, but if more detail would be helpful I'll provide more
AFAIK, the biggest changes have been made in video and network drivers. Other drivers retain backward compatibility and can be run on W7 even with no recompiling.
Run your driver under driver verifier and turn on generating crash dumps with a keyboard (very helpful in case of system hangs, you can manually generate crashdump, analyze it and find what was wrong).
Hope this helps!
I'm curious about how, running Windows 7 on x86, you could execute some code in kernel mode. This is for my own personal use; so I'm not bothered about giving Windows a trillion permissions or whatever. Does kernel mode code have to be specially compiled or linked? etc
Only code from the kernel itself, and from certain device drivers, can run in kernel (supervisor, ring 0) mode.
So you will have to write a device driver.
EDIT: the question has already been answered here.
Ring 0 drivers can execute code in kernel mode.
You will need Windows Device Driver Kit for such development.
Also you have to be extremely careful with driver development because unhandled exception occurring in the kernel indicates a serious bug that exists in the operating system or (more likely) in a device driver and not in an application. Once memory in the kernel gets potentially corrupt, it isn't safe for the system to continue running and you see what is typically called "the Blue Screen of Death."
So normally your drivers should be WHQL certified.
Our application requires HASP SRM device driver to be installed in order for ours to install and run.
At this time, only their 5.50 drivers work consistently on all tested platforms (both their 5.75 (official) and 5.86 (beta) drivers crash on about 1 in 3 computers tested).
Hence, their 5.50 drivers are good, anything else currently available is broken, and the 5.50 drivers refuse to load under Vista and Windows 7. However, if I set the exe's properties to "XP compatibility mode" then their 5.50 driver installs and runs successfully.
I dug around in the registry under Windows 7, and I've found that there is at least one entry made when I ask for compatibility mode:
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers\
full-path REG_SZ WINXPSP3
I should be able to add that key from our installer, before attempting to launch the 5.50 driver installer.
Questions:
Where I can find a more complete discussion of compatibility modes?
Are the keys/settings different under Vista vs. Windows 7?
Are the keys/settings different under 32 bit vs. 64 bit?
Is there a way to directly ask for this when I call CreateProcess()?
You can set the __COMPAT_LAYER environment variable (By setting it in your process before calling CreateProcess, or build a new environment block for CreateProcess)
Is there any way to programmatically disable a device? (preferably in .net, win32, or batch).
Most hits on google suggest using devcon but it does not seem to be working on Windows Vista/7 64bit.
How do I disable a system device? has a solution using SetupDiSetClassInstallParams but it also doesn't work for Vista64.
The 32-bit version of devcon doesn't completely work in WoW64 emulation; I've seen it fail to disable devices as well. The Windows Driver Kit includes a 64-bit version of devcon, which works. It also includes the source code to devcon, so you can see that devcon is just a wrapper for the Setup API.
When you tried calling into the Setup API directly, was it from a 32-bit or 64-bit process? Based on experiences using devcon, I suspect that you need to call into the Setup API from a 64-bit process.