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:
1
--- user mode
2
W1394.exe R&s TsmuX Test tool
3
k1394api.dll R&S api
4
--- kernel mode
5
k1394.sys R&S (legacy)Device driver
6
1394bus.sys Microsoft 1394 (legacy)Bus driver
7
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. 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.
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.
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
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.
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.
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.
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 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.
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 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.
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 ?
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:
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.
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.
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 :-)
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.
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.