More Info on Driver Writing and Debugging

The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.

Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

Best Of

Re: IQueueCallbackCreate OnCreateFile callback question

Hi Donald,

The UMDF driver callback to be called in your case when you have CreateFile() from an app is IQueueCallbackCreate::OnCreateFile(). When you call CloseFile() the callback IFileCallbackCleanup::OnCleanupFile() is called first and next if you don't have a pending i/o - the IFileCallbackClose::OnCloseFile() callback is called.

Hope this information helps,
Tanya

Tanya_Radeva

Re: Monitor New Creation File on pre&post call back

Create a secondary FAT32 volume and only attach your filter to this volume
Have your filter print out information for every Pre/PostCreate operation
Use FileTest to create some files/perform file operations
Look at logs and try to understand what's happening
Repeat steps 3-4

Scott_Noone_(OSR)

Re: Using CreateFileW to get a handle to a display adapter device for DeviceIoControl

If my process exits without calling CloseHandle on the returned handle, is this cleaned up like a file handle would be?

It IS a file handle. No more, no less. The same semantics apply.

Tim_Roberts

Re: Using CreateFileW to get a handle to a display adapter device for DeviceIoControl

Requested access -- since I'm just making DeviceIoControl calls with the returned handle, can I just pass zero here?

Your ioctl code indicates whether it needs FILE_READ_ACCESS or FILE_WRITE_ACCESS. You need to have the corresponding permission in your CreateFile call.

Requested sharing mode -- If RequestedAccess param is zero, does this matter?

Exactly like a file. If you specify 0, then no one else can open the handle for read or write.

Tim_Roberts

Re: Can we add a new internal root CA to our internal certificate store for driver loading?

From your excellent blog post:

“Right. Like people are going to move their shit from Windows to Linux just because we won’t let them update their Win 7 drivers. Right. Sure. You’re nuts.”

I'm amazed they don't acknowledge this. Two of my clients (both in the defense world) have had me switch their telemetry systems from Windows to Linux precisely because of these short-sighted policies from Redmond. The simple fact is, the operating system Just Doesn't Matter any more. It is totally irrelevant. I'm now quite adept at writing user interfaces and processing systems that work identically on Windows, Mac and Linux.

I have previously told my personal story. After a lifetime of being a Windows "fan boy", about 7 years ago I bought a MacBook Air 13 for my primary home laptop, just because the package is so sexy. I was AMAZED how quickly I made that transition. After transferring files, I never started my Windows laptop again. (And, by the way, the MacBook Air 13 is by far the best laptop I've ever owned). However, because Apple is now making what I consider to be short-sighted decisions, this month I bought an LG Gram 17 from Costco, wiped Windows, and put Ubuntu 20.04 on it. Again, I am AMAZED at the ease of the transition. Since firing up the LG, I have not turned on my MacBook, and I don't miss it.

People don't buy computers because they run Windows. People buy computers to solve problems. They'll run whatever solves the problems with the least hassle.

Tim_Roberts

Re: Can we add a new internal root CA to our internal certificate store for driver loading?

Read the blog post, where I describe all this: https://www.osr.com/blog/2021/04/08/lost-cause-no-driver-updates-allowed-except-for-win-10/

Peter

Peter_Viscarola_(OSR)

Re: Can we add a new internal root CA to our internal certificate store for driver loading?

Doesn't Attestation signing the driver mean that it will load only in Windows 10?

Here, once again, we run up against the significant and often overlooked difference between INSTALLING a driver and LOADING a driver. An attestation-signed driver package can only be installed on Windows 10, because they have scent-marked the CAT file to do that. If you are a PnP device, this means you.

HOWVER, if you have a non-PnP driver that does not need an INF file (and that's a significant fraction of the driver market), then you don't care about the package or the CAT file. And in that case, an attestation signed DRIVER will happily load all the way back to Windows XP.

Tim_Roberts

Re: Another code sign question

IMHO with this one you can give the new Microsoft Q&A system a try.
Post with tags windows-10-security, windows-10-application-compatibility, maybe windows-10-general. Share your file via Google - oops, OneDrive.

https://docs.microsoft.com/en-us/answers/topics/windows-10-security.html

--pa

Pavel_A

Re: Another code sign question

INTEGRITYCHECK linker switch is quite special and only rarely required, e.g. for AMSI provider DLLs, processes talking to WSC, Antimalware protected process light, etc. Code signing verification in that case is similar to legacy driver verification and as such requires cross signing with Globalsigns cross cert toward the Microsoft Code Verification Root CA. Manual verification via signtool requires /kp the kernel mode policy switch, which unfortunately only works with secure boot disabled.
The bad news is that the Globalsign cross cert expires 2021-04-15, which is next week, and will not be reissued by Microsoft. This basically means you can not use Globalsign any longer with Integritycheck binaries. As I am in the AV industry and a member of the Microsoft Virus Initiative I do know quite a bit more of how to continue after that date, but all that stuff is still under NDA...hope that clarified a bit.

AndreG

Re: question about async io on sync IRP_MJ_READ/WRITE implementation

Thank you Peter, you mean overlapped ReadFile/WriteFile won't return until I/O completes, right?

Yes. The driver dispatch routines always run on the user mode process' thread. It's just a series of function calls, one of which happens to shift into kernel mode. Nothing can continue until the dispatch routine returns and the call stack unwinds back to you.

This is even true with drivers that do asynchronous properly. The dispatch routines still run on the user thread until they queue up the IRP and return STATUS_PENDING, at which point the stack unwinds back to the original caller. The difference with overlapped is that, without overlapped, the unwind gets blocked in the I/O manager until the IRP shows "complete". With overlapped, it unwinds back to the caller right away.

Tim_Roberts