Ob eine Treiber-Schwachstelle für BYOVD taugt, hängt laut der Analyse von zwei Kriterien ab: Die Ausnutzung muss eine eigentlich manipulationsresistente Sicherheitskomponente spürbar stören können – etwa durch beliebiges Lesen und Schreiben im Kernelspeicher, beliebige Codeausführung oder beliebigen Ressourcenmissbrauch –, und sie darf nicht von seltenen Systembedingungen wie spezieller Hardware abhängen. Genau dieses Hardware-Gating, das in bisherigen BYOVD-Veröffentlichungen kaum betrachtet wurde, steht im Mittelpunkt.
Zwei Hindernisse treten typischerweise auf, wenn ein Treiber ohne die zugehörige Hardware angegriffen werden soll: Das Geräteobjekt wird gar nicht erst erzeugt, oder der interne Zustand des Treibers lässt das verwundbare Verhalten trotz erreichbarem Geräteobjekt nicht zu. Einfache, oft Nicht-PnP-Treiber legen ihr Geräteobjekt direkt in der DriverEntry-Routine an und lassen sich schon nach simplem Deployment per sc.exe ansprechen. Die meisten Treiber gehören aber nicht in diese Kategorie.
Bei PnP-fähigen Treibern – der Mehrheit – reicht die Initialisierungslogik über DriverEntry hinaus in die Routinen AddDevice (bei WDF/KMDF EvtDriverDeviceAdd genannt) und den IRP_MJ_PNP-Handler. AddDevice erzeugt die funktionalen Geräteobjekte (FDO) und Filter-Geräteobjekte und initialisiert interne Variablen, die für das Erreichen des verwundbaren Codes nötig sind. Entscheidend: AddDevice wird nicht beim Laden des Treibers aufgerufen, sondern erst, wenn der PnP-Manager einen neuen Geräteknoten entdeckt und diesem Treiber zuordnet. Ohne diesen Aufruf entstehen weder die IRP-Einsprungpunkte noch die in den Geräteerweiterungen abgelegten Werte, hinter deren Bedingungen verwundbarer Code häufig sitzt.
Der Kern des vorgestellten Verfahrens: Über die test device-Funktion von devcon.exe lassen sich Geräteknoten mit beliebigen, gefälschten Hardware-IDs anlegen. Die passende Hardware-ID stammt aus der INF-Datei des Treibers (Models-Abschnitt). Mit pnputil wird das Treiberpaket in den Windows Driver Store eingespielt, anschließend erzeugt devcon einen softwareemulierten Geräteknoten mit passender ID – der PnP-Manager erkennt den Treiber als beste Übereinstimmung und ruft dessen AddDevice-Routine auf. In Vortests entstanden so fast doppelt so viele neue Geräteobjekte wie beim einfachen sc.exe-Deployment; Horoszkiewicz konnte auf diesem Weg zahlreiche Treiber-Schwachstellen bestätigen, darunter brauchbare BYOVD-Kandidaten.
Warum viele Versuche scheiterten, klärt die Analyse ebenfalls: Bare PDOs, die der PnP-Manager bzw. \Driver\SoftwareDevice anlegen, unterstützen IRP_MJ_CREATE nicht (die Dispatch-Einträge zeigen auf nt!IopInvalidDeviceRequest), sodass sich kein Handle öffnen lässt. Ein Handle zu einem Gerätestapel gelingt nur, wenn mindestens ein Treiber darin IRP_MJ_CREATE annimmt. Für Filtertreiber, die IRPs lediglich durchreichen, baut der Autor deshalb über die Disk-Drive-Klasse einen Stapel mit darunterliegendem FDO – damit ließen sich Filtertreiber für Klassen wie Disk, Bluetooth, Maus, Tastatur und Audio betreiben und teils ausnutzen.
Darüber hinaus zeigt die Analyse, dass sich die Bindung eines Treibers an ein Gerät auch ohne INF-Datei allein über Registry-Strukturen unter SYSTEM\CurrentControlSet\Enum und …\Control\Class herstellen lässt. Daraus folgert Horoszkiewicz, dass INF-Dateien und ihre Signaturen keine Sicherheitsgrenze sind, sondern dem Schutz vor INF-Missbrauch dienen – die .sys-Datei selbst blieb signiert. Hardware-Probing-Prüfungen ohne echte Hardware zu bestehen, sei dagegen nach seiner vorläufigen Einschätzung rein aus dem User-Mode generisch nicht zu umgehen; dafür brauche es zusätzliche Kernel-Komponenten oder Hypervisor-Zugriff.