Ich habe ein Geräts mit Microcontroller drin und USB-A-Anschluss für USB-Sticks. Ich würde gerne zwecks reverse-engineerings einen Fake-USB-Stick, bestehend aus einem Raspberry Pi Zero, zusammenbasteln, der mir Zugriffe auf die Fake-Inhalte protokolliert (ich will wissen, was der Controller liest).
Für den Anfang hab ich eine Anleitung für g_mass_storage gefunden, womit ich ein mit dd erstelltes block device exponieren und auf der anderen Seite mounten kann. Ein Ansatz, da loggedfs draufzuwerfen, war nicht erfolgreich - der loggt nur, was ich auf dem "Zielsystem" tue (auf das ich eigentlich keinen Zugriff habe). Ich hatte gehofft, g_mass_storage mit einem virtuellen Dateisystem oder sowas füttern zu können. Es könnte auch sein, dass der µC roh auf dem fat32 rumstochert... ich weiß aber nicht, wie ich das herausfinde.
Das Modul selbst gibt da nichts her: https://www.kernel.org/doc/Documentatio ... torage.txt
Zugriff auf USB-Stick "client"seitig debuggen
- TRex
- Moderator
- Beiträge: 8038
- Registriert: 23.11.2006 12:23:54
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: KA
Zugriff auf USB-Stick "client"seitig debuggen
Jesus saves. Buddha does incremental backups.
Windows ist doof, Linux funktioniert nicht • Don't break debian! • Wie man widerspricht
Windows ist doof, Linux funktioniert nicht • Don't break debian! • Wie man widerspricht
Re: Zugriff auf USB-Stick "client"seitig debuggen
Gut möglich, dass ich nicht alles richtig verstanden habe. Was mir jedoch dazu einfiel: Man kann USB-Geräte vom Host an eine VM „weiterleiten“. Mit qemu hatte ich eine Zeit lang ständig mit solchen Weiterleitungen zu tun. Evtl. gibt es ja auf diesem Weg eine Möglichkeit, die Kommunikation mitzulesen. Dann bräuchtest Du nicht mit Hardware basteln.TRex hat geschrieben:19.07.2022 23:07:01... Ich würde gerne zwecks reverse-engineerings einen Fake-USB-Stick, bestehend aus einem Raspberry Pi Zero, zusammenbasteln, der mir Zugriffe auf die Fake-Inhalte protokolliert (ich will wissen, was der Controller liest). ...
HTH
Gregor
Wenn man keine Probleme hat, kann man sich welche machen. ("Großes Lötauge", Medizinmann der M3-Hopi [und sog. Maker])
- TRex
- Moderator
- Beiträge: 8038
- Registriert: 23.11.2006 12:23:54
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: KA
Re: Zugriff auf USB-Stick "client"seitig debuggen
Das kann ich nicht mit dem zusammenbringen, was ich erreichen will, aber wenn ich die Situation in ein VM-Szenario übertrage, dann wäre mein Problem, dass ich in der VM nichts tun kann (Blackbox) und daran auch nichts ändern kann. Und die VM liest meinen USB-Stick. Und ich möchte vom Host aus protokollieren, was die VM tut.
Nochmal in anderen Worten, was bei mir passiert: ich stecke einen USB-Stick in ein Gerät, das ich nicht debuggen kann (kein Zugriff). Das Gerät liest Dinge vom Stick und ich will wissen, was und wie es das tut.
Nochmal in anderen Worten, was bei mir passiert: ich stecke einen USB-Stick in ein Gerät, das ich nicht debuggen kann (kein Zugriff). Das Gerät liest Dinge vom Stick und ich will wissen, was und wie es das tut.
Jesus saves. Buddha does incremental backups.
Windows ist doof, Linux funktioniert nicht • Don't break debian! • Wie man widerspricht
Windows ist doof, Linux funktioniert nicht • Don't break debian! • Wie man widerspricht
Re: Zugriff auf USB-Stick "client"seitig debuggen
g_mass_storage liefert rohes Block-Device. Der µC greift auf das Dateisystem also blockmässig zu und muß das Dateisystem seblst verwalten.TRex hat geschrieben:19.07.2022 23:07:01Für den Anfang hab ich eine Anleitung für g_mass_storage gefunden... Es könnte auch sein, dass der µC roh auf dem fat32 rumstochert...
Die Frage ist nur, wie man da was protokollieren kann. Da das alles im Kernel passiert, müßte man wohl das g_mass_storage-Modul entsprechend modifizieren, um die Zugriffe mitzuschneiden. Ob es einen Schalter für das Modul gibt, der Logging anschaltet, ist mir unbekannt.
- TRex
- Moderator
- Beiträge: 8038
- Registriert: 23.11.2006 12:23:54
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: KA
Re: Zugriff auf USB-Stick "client"seitig debuggen
Das hab ich verstanden - ich dachte mir, dass es vielleicht was gibt, das die rohen Zugriffe wieder umrechnet in Dateisystemzugriffe. blktrace und blkreplay stehen auf meiner Agenda. Das Modul g_mass_storage hat das nicht, darum hab ich die Doku dazu verlinkt.MSfree hat geschrieben:20.07.2022 08:27:04Der µC greift auf das Dateisystem also blockmässig zu und muß das Dateisystem seblst verwalten.
Jesus saves. Buddha does incremental backups.
Windows ist doof, Linux funktioniert nicht • Don't break debian! • Wie man widerspricht
Windows ist doof, Linux funktioniert nicht • Don't break debian! • Wie man widerspricht
Re: Zugriff auf USB-Stick "client"seitig debuggen
Hilft dir das vielleicht ein Stückchen weiter?
https://www.kernel.org/doc/Documentation/usb/usbmon.txt
Ob das auch für den "Gadget"-Modus funktioniert, weiß ich aber nciht.
https://www.kernel.org/doc/Documentation/usb/usbmon.txt
Ob das auch für den "Gadget"-Modus funktioniert, weiß ich aber nciht.
- TRex
- Moderator
- Beiträge: 8038
- Registriert: 23.11.2006 12:23:54
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: KA
Re: Zugriff auf USB-Stick "client"seitig debuggen
joa, und es ist noch ne Schicht unterhalb von blktrace (noch offen), also noch aufwendiger auszuwerten.
Jesus saves. Buddha does incremental backups.
Windows ist doof, Linux funktioniert nicht • Don't break debian! • Wie man widerspricht
Windows ist doof, Linux funktioniert nicht • Don't break debian! • Wie man widerspricht
- TRex
- Moderator
- Beiträge: 8038
- Registriert: 23.11.2006 12:23:54
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: KA
Re: Zugriff auf USB-Stick "client"seitig debuggen
Kurzes Update: ich kann mit blktrace und blkparse mitschneiden, was passiert. Ich denke, ich werde noch ein bisschen Zeit brauchen, um das auch wirklich zu verstehen, aber es sollte hoffentlich ausreichen. Sieht dann so aus:
Auf dem Pi:
- Datei mit dd oder ähnlich erstellen
- loopback-device mit losetup erstellen
- g_mass_storage mit file=/dev/loop1 (oder was auch immer losetup angelegt hat) laden
- sudo blktrace -a fs -d /dev/loop1 -o - | blkparse -i - | tee -a blkparse.log
sieht dann etwa so aus, wenn ich eine kleine Datei auf dem Blockdevice auf der anderen Kabelseite ausgebe (beim "Einstecken" kommen bereits ein paar Dutzend Zeiten):
Das kann ich dann vermutlich mit dd nachstellen. Vielleicht finde ich noch etwas, was mir daraus Dateisystemzugriffe macht.
edit: und crossposted: https://unix.stackexchange.com/question ... ock-device
Auf dem Pi:
- Datei mit dd oder ähnlich erstellen
- loopback-device mit losetup erstellen
- g_mass_storage mit file=/dev/loop1 (oder was auch immer losetup angelegt hat) laden
- sudo blktrace -a fs -d /dev/loop1 -o - | blkparse -i - | tee -a blkparse.log
sieht dann etwa so aus, wenn ich eine kleine Datei auf dem Blockdevice auf der anderen Kabelseite ausgebe (beim "Einstecken" kommen bereits ein paar Dutzend Zeiten):
Code: Alles auswählen
7,1 0 99 37.186916362 18775 D RA 16392 + 32 [file-storage]
7,1 0 100 37.187196360 9 C RA 16392 + 32 [0]
7,1 0 101 37.187496358 18775 D RA 16424 + 64 [file-storage]
7,1 0 102 37.187964354 9 C RA 16424 + 64 [0]
edit: und crossposted: https://unix.stackexchange.com/question ... ock-device
Jesus saves. Buddha does incremental backups.
Windows ist doof, Linux funktioniert nicht • Don't break debian! • Wie man widerspricht
Windows ist doof, Linux funktioniert nicht • Don't break debian! • Wie man widerspricht