Windows Treiber und Kerneldebugging

[Hans-Georg L. (h-g-l)]

Weil ich Hilfe von Spezialiste bräuchte habe ich mal einen neuen Thread 
eröffnet. Konkret geht es darum für ein Firewire Gerät eine Software zu 
schreiben siehe hier:Beitrag "R&S TSMU Radio Network Analyzer"
Da die Original Software nicht erhältlich bzw. verdongelt ist versuche 
ich das Protoll zu dem Gerät zu analysieren. Betriebsystem ist Windows 
7.
Der Treiber Stack sieht so aus:

--- user mode
W1394.exe    R&s TsmuX Test tool
k1394api.dll  R&S api 
--- kernel mode
k1394.sys    R&S (legacy)Device driver
1394bus.sys     Microsoft 1394 (legacy)Bus driver
1394ohci.sys    Microsoft OHCI driver

Für den UserMode gibt es Programme die DLLs umlenken und 
Funktionsaufrufe Tracen können.
Gibt es das auch für Kernel Driver ?

Es gibt für Firewire die kd1394.dll damit kann man mit 2 Rechnern und 
dem kernel Debugger den Bus Firewire Bus Traffic tracen. Aber soviel ich 
weiss nicht die Kommunikation mit einem Firewire Device.
Alle spezifischen R&S Erweiterungen müssten ja auf das nackte Protokoll 
mit der 1394ohci.sys (Firewire Controller im PC) abgebildet werden und 
die möchte ich tracen.

Kennt jemand Programme, Tricks oder hat sonst noch irgendwelche Ideen ?.

[Jim M. (turboj)]

Andere Idee: .sys Datei durch einen Disassembler jagen, Ergebnis 
amalysieren.

[Hans-Georg L. (h-g-l)]

Jim M. schrieb:
> Andere Idee: .sys Datei durch einen Disassembler jagen, Ergebnis
> amalysieren.

Habe ich auch schon probiert .. aber mich interessiert nicht der code 
sondern das Protokoll das von höheren Ebenen kommt. Und Datenstrukturen 
und Klassen kann ein Disassembler nicht rekonstruieren.

[Peter M. (r2d3)]

Hallo Hans-Georg L.,

Hans-Georg L. schrieb:
> Kennt jemand Programme, Tricks oder hat sonst noch irgendwelche Ideen ?.

ich habe da nur ganz grob eine Idee.

Du müsstest einen Kernel-Treiber schreiben, der bestimmte 
Kernel-Funktionen "hookt". Über die gesetzten Hooks protokollierst Du, 
was Dir wichtig scheint.

Die eigentliche Funktion routest Du nur durch.

[Hans-Georg L. (h-g-l)]

Peter M. schrieb:
> Hallo Hans-Georg L.,
>
> Hans-Georg L. schrieb:
>> Kennt jemand Programme, Tricks oder hat sonst noch irgendwelche Ideen ?.
>
> ich habe da nur ganz grob eine Idee.
>
> Du müsstest einen Kernel-Treiber schreiben, der bestimmte
> Kernel-Funktionen "hookt". Über die gesetzten Hooks protokollierst Du,
> was Dir wichtig scheint.
>
> Die eigentliche Funktion routest Du nur durch.

Ich habe jetzt viel gelesen und auch interessante bücher gefunden ...

Ich müsste ein kernel-filter-driver schreiben und den im 1394 driver 
stack, zwischen den Treibern deren Kommunikation ich abhören will, 
einfügen.
Der könnte dann alle IO Request Pakete abfangen und Protokollieren.
Im Normalfall wäre das oberhalb der 1394ohci.sys aber da es sich um 
einen legacy Treiber handelt is es die 1394bus.sys. Nun müssten die 
gewonnen Informationen nur noch auf den Bildschirm .... So die Theorie 
;-)

Genaueres werde ich nicht mehr darüber schreiben um keine script kiddies 
anzulocken

[Peter M. (r2d3)]

Hans-Georg L. schrieb:
> Ich müsste ein kernel-filter-driver schreiben und den im 1394 driver
> stack, zwischen den Treibern deren Kommunikation ich abhören will,
> einfügen.

So funktioniert z.B. die Einbindung von Truecrypt und Veracrypt auf 
Windows-Systemen.

Hans-Georg L. schrieb:
> Genaueres werde ich nicht mehr darüber schreiben um keine script kiddies
> anzulocken

Eben noch stelltest Du Fragen zum Debugging/Hacking auf Kernelebene.
Jetzt auf einmal fürchtest Du, dass Du geheimes Wissen ausplaudern 
könntest.
Das ist doch mal ein Erkenntnisfortschritt in nur zwei Beiträgen! :)
Alle Achtung. :)

Script Kiddies benutzen fertige Software und können nicht selbst 
programmieren. Da hilft auch keine funktionsfähige Beschreibung weiter.

Ein Filtertreiber für Firewire reißt keinen Hacker vom Hocker, zumal es 
da doch einen einfachen DMA-basierten Angriff von außen auf die 
Schnittstelle zu geben scheint.

[Hans-Georg L. (h-g-l)]

Peter M. schrieb:
> Hans-Georg L. schrieb:
>> Ich müsste ein kernel-filter-driver schreiben und den im 1394 driver
>> stack, zwischen den Treibern deren Kommunikation ich abhören will,
>> einfügen.
>
> So funktioniert z.B. die Einbindung von Truecrypt und Veracrypt auf
> Windows-Systemen.
>
> Hans-Georg L. schrieb:
>> Genaueres werde ich nicht mehr darüber schreiben um keine script kiddies
>> anzulocken
>
> Eben noch stelltest Du Fragen zum Debugging/Hacking auf Kernelebene.
> Jetzt auf einmal fürchtest Du, dass Du geheimes Wissen ausplaudern
> könntest.
> Das ist doch mal ein Erkenntnisfortschritt in nur zwei Beiträgen! :)
> Alle Achtung. :)
>
> Script Kiddies benutzen fertige Software und können nicht selbst
> programmieren. Da hilft auch keine funktionsfähige Beschreibung weiter.
>
> Ein Filtertreiber für Firewire reißt keinen Hacker vom Hocker, zumal es
> da doch einen einfachen DMA-basierten Angriff von außen auf die
> Schnittstelle zu geben scheint.

Ich wollte nur vorsichtig sein .... kenne mich in der Hackerszene nicht 
aus und will ja nur meinen eigenen Rechner hacken. Und ein Filterdriver 
funktioniert in anderen Device Stacks genau so. AFAIK machen das die USB 
Log Programme auch so

Der DMA Angriff funktioniert nicht mehr in den neueren OHCI Treibern die 
virtualisieren die DMA. Allerdings lässt sich dieses Feature über ein 
Registry Eintrag abschalten.

[Hans-Georg L. (h-g-l)]

Peter M. schrieb:
> Ein Filtertreiber für Firewire reißt keinen Hacker vom Hocker ...

Da hatte ich wohl zuviel über Rootkits gelesen ;-)

Es ist alles kein Geheimnis und im DDK dokumentiert ... man muss es nur 
finden.
Im Toaster sample gibt es ein "pass through" Filter driver, der Requests 
einfach weiterreicht den werde ich als Einstieg nehmen.

[Hans-Georg L. (h-g-l)]

Es ist nicht mehr so heiss und ich würde gerne meinen selbst 
geschriebenen KMDF Treiber (k1394dbg.sys) testen. Für den Treiber selbst 
gab es keine direkte Vorlage im DDK und ich musste ihn aus verschiedenen 
Samples selbst zurecht stricken.

Jetzt habe ich das Problem, das sich das inf File für die Installation 
nicht so einfach wie den Quellcode zusammen stricken lässt.
Der Treiber hat einen Filenamen und eine eigene GUID und ich will ihn 
als LowerFilter Treiber für 1394 Geräte installieren.

Die Registry könnte ich bei dem TSMU Treiber noch per Hand um
"LowerFilters   REG_MULTI_SZ   k1394dbg" ergänzen.

Aber der Treiber selbst muss ja auch mit seinem Namen und GUID in die 
Registry und da fehlt mir im Moment die Info wie das geht.

Wer kann mir dabei helfen ?
Wie muss das inf File dafür aussehen ?
Muss ich auch noch ein inx File erstellen um den Treiber zu signieren ?

ps. Der Treiber soll zwischen dem MS 1394 Bus Treiber und dem R&S TSMU 
Geräte Treiber sitzen und das 1394 Bus-Protokoll auf dem Kernel Debugger 
sichtbar machen.

[georg (Gast)]

Hans-Georg L. schrieb:
> Wer kann mir dabei helfen ?

Aber wir wollen doch keine Script Kiddies anlocken...

Georg

[Hans-Georg L. (h-g-l)]

georg schrieb:
> Hans-Georg L. schrieb:
>> Wer kann mir dabei helfen ?
>
> Aber wir wollen doch keine Script Kiddies anlocken...
>
> Georg

Scherzbold .. aber du kannst ja so oder nichts anderes dazu beitragen.

[Peter M. (r2d3)]

Hans-Georg L. schrieb:
> Wer kann mir dabei helfen ?
> Wie muss das inf File dafür aussehen ?
> Muss ich auch noch ein inx File erstellen um den Treiber zu signieren ?

Ich kenne die Lösung nicht!
Ich würde in Deiner Situation eine Frage in einer passenden Newsgroup 
stellen.
Alternativ würde ich mich mal physisch zum nächsten ERFA-Kreis bemühen.
Du machst da ja interessante Low-Level-Debug-Geschichten.
Vielleicht kennen die jemanden, der gerade an ähnlichen Projekten 
schraubt.

Am besten nimmst Du Laptop mit Umgebung und Code gleich mit.

[Sempfdazugeber (Gast)]

Zu XP-Zeiten gab es den "Driver Installer" von www.beyondlogic.com.

Der brauchte glaub ich, nichtmal ein Inf-File.

[Hans-Georg L. (h-g-l)]

Sempfdazugeber schrieb:
> Zu XP-Zeiten gab es den "Driver Installer" von www.beyondlogic.com.
>
> Der brauchte glaub ich, nichtmal ein Inf-File.

Und woher will das Programm wissen wo ich eden Filter driver 
installieren will ?

Egal ich hab jetzt ein inf geschrieben und es hat funktioniert und 
meinen Treiber als LowerFilter Driver für alle 1394 devices installiert.

Der Trick war diese Zeile mit der GUID der 1394 class.

HKLM, 
System\CurrentControlSet\Control\Class\{48721b56-6795-11d2-b1a8-0080c72e 
74a2},  LowerFilters, 0x00010008, k1394dbg

Da ich sonst keine Firewire Geräte habe stört das nicht.

[Hans-Georg L. (h-g-l)]

So richtig weiter gekommen bin ich noch nicht ... Die Einträge in der 
Registy scheinen grundsätzlich zu stimmen aber der Treiber startet immer 
noch nicht

Weil Windows7 64bit Kernel-Treiber eine Signatur benötigen habe ich in 
der Zwischenzeit den Filter nochmal neu mit dem wdk 8.1 und Visual 
Studio 2013 geschrieben und das Paket (*.cat) als "Test" signiert. 
Verwendet habe ich das Projekt Template "Kernel mode driver (kmdf)" vom 
Visual Studio.

Boot log sagt immer noch: Treiber nicht geladen und beim Treiber Service 
gibt es einen Eintrag INITSTARTFAILED in der Registry.

Wenn der Treiber geladen wird, müsste ich auf jeden Fall den log vom 
DriverEntry im debugView sehen.

Den Treiber von Hand starten funktioniert auch nicht, da kommt die 
fehlermeldung "nicht signiert"

Kennt jemand einen Trick wie man direkt für private Zwecke die sys Datei 
selbst signieren kann ?

[Roger S. (edge)]

Hans-Georg L. schrieb:
> Kennt jemand einen Trick wie man direkt für private Zwecke die sys Datei
> selbst signieren kann ?

Die Datei signieren.. nein, aber du kannst dein Windows in den Test-Mode 
versetzen, dann startet es unsignierte x64 Treiber.
In einem elevated promtpt folgendes eingeben und neustarten:

bcdedit /set testsigning on

Cheers, Roger

[Hans-Georg L. (h-g-l)]

Vielen Dank Roger, der Treiber wird im Bootlog jetzt als gestartet 
gemeldet. Die Reihenfolge stimmt auch es wird erst mein LowerFilter 
Treiber geladen dann das Original darüber. Die Registry und die 
Ereignissanzeige bringen auch keine Fehler mehr also sollte der Treiber 
laufen.
Aber DrirverEntry sollte beim Start des Treibers doch aufgerufen werden.

NTSTATUS DriverEntry(
    _In_ PDRIVER_OBJECT  DriverObject,
    _In_ PUNICODE_STRING RegistryPath
    )
{
    WDF_DRIVER_CONFIG config;
    NTSTATUS status;
    WDF_OBJECT_ATTRIBUTES attributes;

    //
    // Initialize WPP Tracing
    //
    WPP_INIT_TRACING( DriverObject, RegistryPath );

    TraceEvents(TRACE_LEVEL_INFORMATION, TRACE_DRIVER, "%!FUNC! Entry");

....
}

Aber ich bekomme nicht einmal die Trace Info vom DriverEntry. Weder mit 
DebugView noch mit WinDbg zu sehen. Wahrscheinlich ist der Trace nicht 
aktiviert. Mein Treiber soll erstmal nur die 1394 Aufrufe protokollieren 
und alle Nachrichten an den darunterliegenden Treiber weiter geben. Das 
Forwarding scheint aber auch noch nicht zu funktionieren weil der 
Original Treiber das Gerät nicht mehr findet. jetzt muss ich aber erst 
mal das Tracing aktivieren. Im Trace.h sind auskommentierte Zeilen die 
durch einen Trace Preprozessor behandelt werden sollen. Mal schauen wie 
dieser Preprozessor sich nennt und ob er vom build überhaupt gestartet 
wird.

ps. Ich habe den Treiber mit einem Test Zerfikat versehen und auch die 
Zertifikate für das cat File und den Treiber als vertrauenwürdig 
registriert. Hat aber auch nicht funktioniert.

[Hans-Georg L. (h-g-l)]

WPP Traces brauchen ihr eigenes Tool - TraceView damit muss man eine 
Trace Session erzeugen. Das geht mit einem Wizzard aus dem pdb File vom 
Treiber.
Dort kann man dann den gewünschter Level einstellen und sie da es kommen 
Nachrichten vom Treiber. Es wird die richtige Funktion aufgerufen 
(k1394dbgInternalEvtIoDeviceControl in Queue.c) und dort wird die 
Fehlermeldung geworfen: "WdfRequestRetrieveInputBuffer failed 
0xc0000023(STATUS_BUFFER_TOO_SMALL)". Ein Lichtblick ... endlich :-)

[Hans-Georg L. (h-g-l)]

So jetzt bekomme ich auch die richtigen Nachrichten vom Treiber.

Ich habe mich von den Codebeispielen des DDK in die Irre führen lassen
und die IOCTL_XXXX Nachrichten erwartet. Die stammen aber vom 
k1395diag.sys Treiber den es bei mir nicht gibt. Die richtigen 
Nachrichten stecken in der IRP struktur als FunctionCode und sind in 
1394.h als REQUEST_XXX definiert.

Falls sich jemand dafür interessiert habe ich den geänderten Code 
hochgeladen.

[Hans-Georg L. (h-g-l)]

Nachtrag ...

Windows7 64bit Treiber müssen immer signiert sein.

Mit dem Befehl "bcdedit /set testsigning on" lädt Windows zusätzlich 
Treiber die mit einem registrierten Testzertifikat versehen sind.

Mit dem WDK8.1 werden im Visual Studio2013 Erweiterungen installiert mit 
denen man (WDF) Kernel Treiber Projekte erzeugen kann. Das ist 
wesentlich komfortabler wie mit den Kommandozeilen Tools herum zu 
spielen.
Damit kann man sich auch ein Testzertifikat (.cer) erstellen und das 
Zertifikat bei Windows registrieren. Der Treiber selbst wird mit einem 
Package signiert, das die Signaturen des sys und inf Files in einem cat 
File zusammenfasst.