I am trying to use ObRegisterCallbacks to prevent my app being terminated.
in windows 7 x64 system, it works well as my plan.
but in windows 7 x86 system, there are some problems.
I have to link my driver with /INTEGRITYCHECK linker option, or I couldn't use ObRegisterCallbacks function. It returned ACCESS_DENIED.
but if I build it with /INTEGRITYCHECK linker option, I couldn't load my driver.
when I call StartService(), it returned ERROR_INVALID_IMAGE_HASH.
Of course, I had signed my driver after build. so my driver file had a digital signature on binary.
However it still returned ERROR_INVALID_IMAGE_HASH.
and if I built with same sources for x64 platform, it works fine.
furthermore, if I boot my PC(x86) with Test Boot Mode , it works well too.
I am wondering that is possible to use ObRegisterCallbacks on x86 system ( not test boot mode ).
Any reply will be appreciated.
It works for x86 system you need to sign your driver using certificate , Testsigning does not work so make sure you have certificate using makecert tool.
use signtool to sign your driver withthe certificate you created
Related
Before I ask my question, here's some background information so that you might have a better understanding of what I am trying to accomplish. I have searched around and found similar questions but none that are specifically what I am asking.
I am trying to port over a modified 32-bit PLX Pci9056 device driver to 64-bit. I also have a few User apps that utilize the driver. PLX provides a complete SDK, including the PLX API in a dll, driver source code, and tools to create and debug user apps. It uses the Windows DDK build environment to build the drivers. The following is how they all interact:
User app --> PLX API --> PLX Pci 9056 driver --> PLX chip
The 32-bit driver has been tested on Windows 7 32-bit and works properly. I believe I should be able to simply rebuild the driver in the 64-bit Windows DDK build environment (Of course after handling any pointer casting. Please correct me if I am wrong.) At this point the driver should run properly on a 64-bit Windows 7 machine.
I understand that usually 32-bit apps will run fine on a 64 bit machine, but in this case the User app is using the PLX API which was initially built only to support 32-bit. Will my User app still work in a 64-bit OS without updating it, or will I run into issues?
The PLX PCI SDK (now Broadcom PCI/PCIe SDK) has supported both 32b/64b drivers with the same source code for many years now. Special macros are used when required, etc. In Windows, your 32-bit app will work fine due to WOW layer. The PLX IOCTL structures always store pointers in 64-bit fields to ensure the structure does not vary if you build a 32-bit app. The SDK also provides 64-bit build of the API library, so you can also build your app as native 64-bit. The same app level source code, for the most part, should work in both Windows & Linux. The samples provided in the SDK are all identical source for both Win/Linux.
I am developing a driver based on ddk sample "passthru" and I have trouble loading this driver in win7(x86 or x64). I have tested my driver in winxp (x86 and x64), and it works pretty well, but when I tried to load this driver into win7 (F8->Disable Driver Signature Enforcement), it seemed failed. Then, I tried the native passthru code, it also failed. I thought it failed because
I can not see any outputs using KdPrint fron windbg.
I can not see any useful information from system event.
I set a breakpoint on passthru!DriverEntry, it seems that DriverEntry has not been called.
My WDK is 7600.16385.1, and passthru is supposed to be compatible with win7. I compile passthru using command "build -cZ".
Could you help me understanding this problem, or any clue about why passthru not loaded in win7?
I have built this driver in win7 x86 checked build environment， and tested in win7 x86.
Solved: Actually, the driver has been loaded, but the output of KdPrint not shown in win7 by default, you should use KdPrintEx to specify message level, or modify registry to make debug message shown. Now I have no idea why bp failed either.
Normally you can't use a driver that was built for WinXP target on a Win7 machine. Rebuild for Win7 target.
Well your question is rather unspecific, but I see one particular problem here: Enabling test-signing and disabling kernel mode signing policy still requires you to sign the binary ... (after WHQL-tests MS would cross-sign the .cat file for the driver). Refer to this.
See:
For 64-bit versions of Windows Vista and later versions of Windows,
the kernel-mode code signing policy requires that all kernel-mode code
have a digital signature.
and:
The operating system loader and the kernel load drivers that are
signed by any certificate. The certificate validation is not required
to chain up to a trusted root certification authority. However, each
driver image file must have a digital signature.
These commands should allow to load a driver signed with anything
bcdedit.exe -set loadoptions DDISABLE_INTEGRITY_CHECKS
bcdedit.exe -set TESTSIGNING ON
You don't mention what target OS you chose when building. Icepack mentioned it. You need to actually build for Windows 7 to make it work with the new NDIS 6.0. Simply loading a driver built for XP (and older NDIS version) may not work at all.
My suggestion, use DDKBUILD.CMD and build one driver with (free build, W7):
ddkbuild.cmd -W7 fre . -cZ
and one with (free build, WXP)
ddkbuild.cmd -W7XP fre . -cZ
the above command line already takes into account the WDK you have. Note that if DDKBUILD.CMD fails to detect your installed WDK you'll have to set the environment variable W7BASE to point to the folder in which the WDK is installed (the one with install.htm, usually something like C:\WINDDK\7600.16385.1).
I have done a great deal of looking around, and I can't seem to get a straightforward answer to this issue.
I am hobbyist programmer, I have done a great deal of work with windows drivers, and wrote my own personal 'antivirus' driver for windows XP. So don't get me wrong here, I don't work for any software development firm or anything of the like.
My question is: as far as windows 7 x64 is concerned, is there any possible legit and legal method I can use to release sign my driver that would only be for my own personal use?
Yes I am well aware I can test sign my driver and run it in a virtual machine under windows test mode, which I do quite frequently. However if you have used windows in test mode you know there are some major drawbacks.
So to to sum this all up, is it possible for me ( a hobbyist ) to release sign a driver for my own personal use and not have to deal with windows test mode?
Thanks.
If it's a boot time required driver, I don't think there is a way you can get it to use it without signing it with a certificate from a Microsoft sanctioned provider (Verisign only I think for drivers?).
If this is a normal device driver that isn't required at boot you can create your own certificates and use those instead. I did it myself for Vista x64 to get an HP ScanJet driver to work from XP x64 by signing the .sys and the .inf files.
I used Active Directory Certificate Services on my domain to issue a Code Signing certificate for my use and had my machine trust the ADCS CA certificate. These two actions will cause Windows to trust your signed driver.
I believe you could use OpenSSL to create a CA certificate and issue code signing certificates with that, but I've had no practice with it.
Again, to reiterate, if this driver is required at boot then this method will not work, if it's used for a device which can be attached at anytime, it should work.
You can have the ReactOS Foundation do it for you.
Please refer to my answer to this post: Windows 7 kernel driver signing.
So to to sum this all up, is it possible for me ( a hobbyist ) to release sign a driver for my own personal use and not have to deal with windows test mode?
Yes.
For boot time drivers: Go to VeriSign, buy the (only?) code signing certificate ($500), and sign your driver.
For non-boot drivers: You can self-sign, with appropriate warnings.
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 need to install the libusb-win32 driver on Windows 7 64 bit machines. This driver is open source so it is not digitally signed so I want to do this myself, but I wonder if this can be done WITHOUT paying lot of money. Is it possible to use a certificate which is NOT signed by Verisign or GlobalSign? Maybe self-signed or by using StartSSL instead?
And if yes, how do I do it? According to a how-to, The Practical Truth About x64 Kernel Driver Signing, I have to use a "cross-certificate" (and there are only six available on the Microsoft list and most of them are for CAs which are no longer active).
I don't care if the user is confronted with a warning message. I can even accept if the user has to install a special CA certificate first. I only require that the driver runs without manually disabling the signature check on each Windows startup.
No, the driver has to be cross signed by one of those specific certificates and thus the driver has to be signed by one of those CAs. You can disable driver signing on the machine for testing purposes, but obviously you don't want to do this on production machines. Sorry, that's just the way it is.
LibUSB_win32 is now already signed, according to http://sourceforge.net/apps/trac/libusb-win32/wiki
It says: "Vista/7/2008/2008R2 64 bit are supported from version 1.2.0.0 since a Microsoft KMCS accepted digital signature is embedded in the kernel driver libusb0.sys."
So the only thing you have to do is update your libusb_win32 driver.
To allow loading into kernel, you have to sign with those CA and have WHDL checked.
The only alternative would be using the user mode driver framework. (but libusb does not support it -- it was discussed, but never implemented)