@talk2me
Der Ansatz mit einer hidapi-Proxy-DLL ist auf jeden Fall interessant.
Ich bin bei der Untersuchung bisher allerdings einen etwas anderen Weg gegangen und inzwischen
lässt sich auch schon deutlich genauer sagen, was Loader und Dongle miteinander machen.
Der VIIPlusLoader ist nicht einfach nur ein Programm, das schaut "Dongle vorhanden = VCDS starten".
Die Kommunikation besteht aus mehreren Ebenen.
Vereinfacht sieht das inzwischen ungefähr so aus:
Code:
VIIPlusLoader
|
| HID / eigenes Protokoll
v
STM32F429 im Dongle
|
| Authentifizierung / Gerätezustand
v
Loader
|
| teilweise FLY-Backend
v
Freigabe / weitere Session
Den USB/HID-Teil habe ich inzwischen ziemlich ausführlich mitgeschnitten und zerlegt.
Der Dongle meldet sich als Vendor-Specific HID-Gerät. Die eigentliche Kommunikation läuft über 64-Byte-Reports
und größere Antworten werden über mehrere Reports fragmentiert.
Dabei gibt es verschiedene Endpoints bzw. Kommunikationskanäle. Einer wird beispielsweise sehr häufig für
kleine Statusmeldungen bzw. Polling verwendet, während über einen anderen Kanal die eigentlichen Antworten des Dongles kommen.
Interessanter sind aber die Kommandos innerhalb dieser HID-Reports.
Dort konnte ich inzwischen verschiedene wiederkehrende Kommandoklassen unterscheiden.
Es gibt beispielsweise eine Abfrage, auf die der Dongle einen relativ großen und bei identischer Anfrage reproduzierbaren Datenblock zurückliefert.
Daneben gibt es weitere Kommandos mit deutlich kleineren, aber sehr hochentropischen Antworten sowie größere Antworten,
die über mehrere HID-Fragmente verteilt werden.
Das sieht inzwischen sehr stark danach aus, dass der Dongle nicht nur eine Seriennummer speichert, sondern aktiv an der Authentifizierung beteiligt ist.
Vereinfacht würde ich den Ablauf momentan ungefähr so beschreiben:
Code:
Status prüfen
|
v
Geräteinformationen / Identität abfragen
|
v
Authentifizierung zwischen Loader und Dongle
|
v
weitere Session-/Freigabedaten
|
v
geschützte Funktionen des Loaders
Ein weiterer interessanter Punkt ist
Code-DRV.dat.
Diese Datei ist ungefähr 2 MB groß und hat eine sehr hohe Entropie. Sie ist also offensichtlich nicht einfach eine normale
unverschlüsselte STM32-Firmware, die man mit einem Hexeditor öffnen und analysieren kann.
Gleichzeitig enthält V2Plus bzw. der Loader einen Crypto-Unterbau mit OpenSSL und lädt entsprechende Funktionen teilweise dynamisch.
Meine derzeitige Arbeitshypothese ist deshalb, dass Loader, Dongle und Code-DRV.dat wesentlich enger zusammenspielen als ursprünglich gedacht.
Der Dongle könnte dabei beispielsweise gerätespezifisches Material bzw. Ergebnisse einer kryptografischen Operation liefern,
die der Loader für die weitere Verarbeitung benötigt.
Ob Code-DRV.dat komplett auf dem PC entschlüsselt wird, ob Teile davon durch den Dongle verarbeitet werden oder ob
das Ganze hybrid funktioniert, ist allerdings noch nicht abschließend geklärt.
Genau an dieser Stelle wird es momentan interessant.
Die reine USB-Kommunikation ist nämlich inzwischen gar nicht mehr das größte Rätsel.
Ich habe vollständige Sessions aufgezeichnet und kann Host → Dongle und Dongle → Host voneinander trennen,
Fragmentierung rekonstruieren und verschiedene wiederkehrende Kommandotypen erkennen.
Wir haben dabei unter anderem gesehen, dass der Dongle auf bestimmte Anfragen reproduzierbar antwortet,
während andere Antworten offensichtlich dynamische bzw. kryptografische Daten enthalten.
Auch ein interessantes Detail:
Wenn man dem Dongle einfach irgendeinen syntaktisch falschen HID-Report schickt, ignoriert er das nicht unbedingt einfach,
sondern kann darauf mit einem Reset reagieren.
Da läuft also definitiv eigene Logik, die das Protokoll relativ streng überprüft.
Deshalb ist Dein Vorschlag mit der
hidapi Proxy-DLL durchaus interessant,
aber für mich momentan eher noch eine zusätzliche Beobachtungsebene.
Ich habe die Kommunikation bisher direkt über USB-Captures und die HID-Reports untersucht und dadurch bereits
einen großen Teil des Transportprotokolls sichtbar gemacht.
Eine Proxy-DLL hätte natürlich den Vorteil, zusätzlich genau zu sehen, welche hidapi-Funktion der Loader
wann aufruft und welche Buffer die Anwendung unmittelbar davor bzw. danach verwendet.
Das könnte später noch hilfreich werden.
Mein größeres Problem liegt momentan aber eine Ebene höher:
Was macht der Loader mit den Daten, nachdem die Authentifizierung erfolgreich war?
V2Plus.exe ist zusätzlich ziemlich stark geschützt. Große Teile der eigentlichen Programmlogik liegen
nicht schön lesbar in normalen PE-Sektionen, sondern in Bereichen, die sehr stark nach VMProtect aussehen.
Unter Linux/Wine verhält sich das Programm außerdem anders und klassische Instrumentierung hat sich ebenfalls als problematisch erwiesen.
Deshalb bringt mir ein weiterer Mitschnitt derselben HID-Pakete momentan weniger als die Frage,
was anschließend im Windows-Prozessspeicher passiert.
Wenn dort irgendwann Code-DRV.dat in entschlüsselter Form auftaucht, wäre das natürlich wesentlich interessanter.
Deinen zweiten Punkt mit den älteren Firmwareständen sehe ich genauso.
Die im Netz vorhandenen extrahierten Firmwarestände und insbesondere bekannte RAM-Inhalte können als Referenz extrem hilfreich sein.
Allerdings muss man dabei genau wissen, was man eigentlich vor sich hat:
- kompletter interner Flash?
- nur Application?
- Bootloader?
- RAM-Abbild?
- Update-Payload?
- bereits entschlüsselte Daten?
- bestimmte Hardware-/Firmwaregeneration?
Genau deshalb habe ich parallel mein STM32F429-Testprojekt aufgebaut.
Ich möchte auf eigener Hardware verstehen, wie die Speicherbereiche tatsächlich aussehen und vor allem feststellen können,
ob ein erzeugtes Abbild vollständig und unverändert ist.
Sonst findet man irgendwann irgendeine BIN-Datei im Internet und vergleicht sie tagelang mit etwas,
das möglicherweise überhaupt nicht denselben Speicherzustand repräsentiert.
Ein weiterer Punkt, den wir inzwischen ziemlich gut bestätigen konnten:
Der BOOT-Dongle ist nicht wirklich "tot".
Der STM32 läuft, USB läuft und es findet weiterhin Kommunikation statt.
Was blockiert ist, ist der normale Debug-Zugriff auf den STM32.
Das passt wiederum ziemlich gut zu den Informationen, dass diese Geräte bewusst gegen das direkte Auslesen geschützt wurden.
Deshalb laufen bei mir momentan eigentlich drei Untersuchungen parallel:
- USB/Protokoll: weitgehend verstanden, weitere Kommandos und Authentifizierung analysieren.
- Loader/Code-DRV.dat: herausfinden, was nach erfolgreicher Dongle-Authentifizierung im Prozessspeicher passiert.
- STM32F429-Testhardware: Speicher-, Boot- und Schutzverhalten auf eigener Hardware nachvollziehen, damit spätere Dumps überhaupt zuverlässig bewertet werden können.
Und irgendwann müssen diese drei Teile zusammenpassen.
Dann lässt sich hoffentlich nicht nur sagen "hier ist eine Firmware", sondern auch:
Wo kommt sie her, was enthält sie, wie wird sie verwendet und was unterscheidet einen funktionierenden Dongle tatsächlich von einem BOOT-Dongle?
Das ist momentan eigentlich die spannende Frage.
Die Proxy-hidapi behalte ich aber definitiv im Hinterkopf. Als zusätzliche Ebene zwischen Loader und echter hidapi.dll könnte das später noch interessante Informationen liefern, insbesondere wenn ich einen Update-/Recovery-Vorgang gezielt untersuche.
Vielleicht noch kurz dazu, warum ich mir den ganzen Aufwand überhaupt antue:
Mein ursprüngliches Ziel war eigentlich ziemlich simpel:
Ich möchte einen günstigen FLY-Dongle wieder zum Leben erwecken.
Ich finde es einfach bescheuert, funktionierende Hardware auszusortieren, nur weil sie plötzlich softwareseitig nicht mehr nutzbar ist.
Vermutlich gibt es einen
Aktivierungszähler. Laut Hersteller ist der Dongle nach
100 Schreibvorgängen nicht mehr nutzbar.
Bei mir war es konkret so:
Ich musste bei meinem relativ aktuellen Auto die Batterie wechseln und wollte vorher prüfen,
ob ich die neue Batterie anschließend mit VCDS entsprechend anlernen bzw. einprogrammieren kann.
Dongle angeschlossen, VCDS gestartet, Zugriff auf die entsprechenden Steuergeräte geprüft, alles funktionierte problemlos.
Danach VCDS sauber beendet, Dongle abgesteckt, Batterie gewechselt,
gemütlich ein Bier getrunken
und anschließend den Laptop wieder gestartet.
Loader geöffnet, und plötzlich stand der Dongle nur noch auf
BOOT.
VCDS war damit ebenfalls nicht mehr nutzbar.
Und genau das finde ich einfach Mist.
Vor allem weil sich bei meiner bisherigen Analyse immer deutlicher gezeigt hat, dass viele dieser Dongles technisch sehr eng miteinander verwandt sind.
Badrax, Kolimer, VII Plus, V2 Plus und weitere Varianten verwenden teilweise dieselbe Hardwarebasis und
einen sehr ähnlichen bzw. teilweise identischen Software-Unterbau.
Aus der ursprünglich simplen Frage:
"Warum funktioniert mein Dongle plötzlich nicht mehr und kann ich ihn reparieren?"
ist dann irgendwann dieses komplette Forschungsprojekt entstanden.
Ich möchte am Ende eigentlich gar keinen neuen "Super-Dongle" entwickeln.
Mir würde es vollkommen reichen zu verstehen, warum funktionierende Hardware plötzlich im BOOT-Zustand landet und
ob man solche Geräte sinnvoll wiederherstellen kann, anstatt sie wegzuwerfen.
Und noch eine Frage zu den erwähnten älteren Dumps bzw. den bereits extrahierten Firmware- und RAM-Inhalten:
Wo genau findet man diese Dateien?
Falls jemand die entsprechenden Dumps noch hat und sie zur Analyse zur Verfügung stellen kann, wäre ich sehr daran interessiert.
Gerade ältere Flash-Dumps, RAM-Dumps oder bereits extrahierte Firmwarestände wären für meine Vergleichsanalyse sehr hilfreich,
auch wenn sie nicht exakt von derselben Firmware-Version stammen.
Bitte nur HEX V2
Falls jemand etwas davon hat, gerne hier im Thread oder per PN melden.
