Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

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.

Device objects and DACL

AvalonAvalon Member Posts: 35
edited June 3 in NTDEV

Hello. So there are 2 ways to create software based drivers right, the legacy way using sc and a PNP device using devcon.
 
For the legacy way, using sc create, sc start, etc, works fine and you can start and then sc stop to fully unload the driver. My driver's Unload is called, and all resources are cleaned up, and driver verifier is happy. However you cannot apply a INF SDDL to restrict opening of the symbolic handle for IOCTLs, as the sc way doesn't load the INF.
So how could I apply an admin/system level SDDL on this method?
 
Alternatively we can use devcon install aaa.inf root\aaa to create a root enumerated device without needing hardware. However when I go to unload my driver via devcon remove I get a Windows popup saying the device requires a restart to unload this driver. All I've done is change the INF to be devcon compatible, I haven't added all the minor PNP IRPs yet, but is that required to just remove the driver without needing to restart the driver. My Unload() doesn't get called (unlike sc stop) hence why I guess the restart is asked for?
 
The sc way is obviously the simplest if I can just get the DACL applied. Otherwise I can use the devcon way if I can unload without the reboot, any simple software based wdksamples for this concept?

Comments

  • AvalonAvalon Member Posts: 35
    edited June 3

    Oh stupid DriverStore. For the past day, every build I've done has been instead loading a cached driver from the DriverStore from devcon and only just realized all my attempted tests never even ran. Even devcon dp_delete wouldn't delete the driver package, had to manually psexec as system to remove my driver packages.
     
    Simply setting IoCreateDeviceSecure() with the SDDL secured the DACL on the device object, preventing standard users from opening handles to the device. Simple.
     
    Since I am essentially the PDO, with no PCI root device below me, I am legitimately allowed to call IoCreateDeviceSecure right.

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,600
    KMDF supports the legacy and pnp scenario. Why aren’t you using it? Your life will be much simpler. To stop a pnp driver you need to fully support pnp. KMDF gives this to you from the start, wdm requires you start from scratch.

    > Since I am essentially the PDO, with no PCI root device below me, I am legitimately allowed to call IoCreateDeviceSecure right.

    It is not clear which scenario you are asking about here. In the legacy driver case, yes it is safe to assign the dacl directly to the device object. In the pnp case, even for a root enumerated device, it is not safe and you should be using the INF to assign it.
    d
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,493

    every build I've done has been instead loading a cached driver from the DriverStore

    Let me guess: You're trying to do a new install each time? Instead of "disable", then copy new version of driver to whatever installed location is, then "enable"??

    Or are you saying that you WERE copying the driver... to \windows\system32\drivers... but the driver was being loaded from the driver store instead? That should have been evident from the INF... no?

    I'm trying to see if there's a lesson for us all to learn here... or if this is just a case of a problem between keyboard and chair.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Pavel_APavel_A Member Posts: 2,781

    @Peter_Viscarola_(OSR) said:
    Let me guess: You're trying to do a new install each time? Instead of "disable", then copy new version of driver to whatever installed location is, then "enable"??

    But now drivers loaded into memory cannot be overwritten, their disk files become locked, like UM applications?
    Also, there's some protection by the PnpLockDown directive ...

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,493

    But now drivers loaded into memory cannot be overwritten

    Maybe. But that’s not where I was going with that. Rather, the most common error is doing a reinstall each time but having the same DriverVer in the INF. In this case, the old binary is used. The installer says, “Ah! Same version I have already! I know how to deal with this!”

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Developing Minifilters 24 May 2021 Live, Online
Writing WDF Drivers 14 June 2021 Live, Online
Internals & Software Drivers 27 September 2021 Live, Online
Kernel Debugging 15 November 2021 Live, Online