Binärdateiformate mit AI reverse engineeren

Das Problem

Immer wieder wird man mit proprietären Dateiformaten konfrontiert. Bei Textformaten ist das Lesen meist noch relativ einfach, bei Binärdateiformaten ist das jedoch oft viel schwieriger. Aufhänger war diesmal das .TC Format, wie es von einigen OBDII Diagnosegeräten für Autos verwendet wird. Originalhersteller ist ThinkCar, die Geräte werden jedoch unter diversen anderen Marken verkauft - meins ist z.B. als "KINGBOLEN EDIAG Elite OBD2" verkauft worden. Während man für die Fehlercodes noch Reports als PDF oder als Webshare exportieren kann, wird ein Mitschnitt von Fahrzeugparametern in besagtem .TC Format auf dem gekoppelten Android Handy gespeichert. Dies war bei mir nötig, weil ich ein merkwürdiges Regelverhalten des stufenlosen CVT Getriebes (Lineartronic) meines Subaru Outback analysieren wollte. Eine Exportmöglichkeit bietet die App nicht an. Selbst die Datei muss mühsam aus dem Dateisystem geangelt werden. Ich habe sie unter

/Internal shared storage/Android/data/com.kingbolen.ediag/files/ThinkCar/ThinkDiag/images/SUBARU_9T8P20524415_20260117154318.TC

gefunden. Das konkrete Dateiformat soll hier aber nur als Aufhänger für die Fähigkeit von Coding Agents / LLMs zum reverse engineering von Binärdateiformaten verwendet werden.

Vorgehensweise

Recherche

Zuerst habe ich versucht, per ChatGPT deep research alle öffentlich bekannten Informationen über das .TC Format zu finden. Konkretes zu dem Format konnte ChatGPT zwar nicht zu Tage fördern, jedoch ist der erzeugte Report dennoch nützlich, weil er Vergleiche mit anderen Dateiformaten von solchen Diagnosewerkzeugen zieht und somit beschreibt, welche Datenstrukturen prinzipiell zu erwarten sind. Den rohen Chatverlauf habe ich hier geshared: ChatGPT Deep Research - .TC Format (keine Garantie wie lange das online bleibt)

Reverse Engineering

Lokal habe ich einen groben Rahmen für ein Python Projekt angelegt und den Report von ChatGPT als Markdown lokal gespeichert. Zusätzlich habe ich eine .TC Datei bereitgestellt. Ziel der Software war in der README.md beschrieben, grobe Architekturvorstellungen und Hinweise auf bestehende Infos über das Dateiformat direkt in der AGENTS.md. Als Agent habe ich den nativen von Zed mit Claude Opus 4.5 als Modell verwendet. Der Prompt war einfach:

wir haben hier im Ordner eine Beispiel .TC datei.
Bevor wir mit der eigentlichen Software loslegen versuchen wir das Dateiformat zu verstehen. Du darfst alle tools verwenden die unter Debian Linux per APT verfügbar sind, aber wenn du ein tool brauchst das noch nicht installiert ist STOP und sag mir bescheid, ICH installiere das dann auf dem system.
Versuche das Dateiformat zu verstehen und entsprechend so gut es irgendwie geht zu dokumentieren.
Die beispieldatei ist von einem Subaru Outback BR, Baujahr 2014, VIN JF1BRDLY5E******, ein recording vom Getriebesteuergerät (TCM) von einer ca. 15minütigen testfahrt.

Die eigentliche Kernarbeit hat Claude dann beeindruckend autonom erledigt und sich mit "strings", od (octal dump) und jeder Menge in Python geschriebenem Testcode, um Structs in den Binärdaten zu finden, dem Problem genähert. Eine Viertelstunde und zigtausend Tokens später war die wesentliche Struktur erfolgreich beschrieben. Geschwindigkeit hatte er doppelt gefunden (Index 13 und 14), einmal plausibel, einmal völlig daneben mit "900 km/h". Ursache war eine falsche Annahme über die Einheit, weil ein Raddrehzahlsensor, der RPM liefert, als km/h betrachtet wurde. Mit einer kurzen Diskussion über die extrahierten Werte und Plausibilisierung durch mein Weltwissen (Fahrprofil der Probefahrt, aktuelles Wetter, bekannter Zustand des Autos) konnten ruck-zuck alle Einheiten identifiziert werden und sogar beschriebene Fahrmanöver wie eine Wende im Waldweg konnte man in den Daten sauber wiederfinden.

Ergebnis und Learning

Im Ergebnis konnte ich in ca. 2 Stunden und knapp 6$ in Tokens ein proprietäres Binärformat reverse engineeren und einen funktionsfähigen Converter zu CSV bauen. Wie lange ich dafür ohne Coding Agent gebraucht hätte? Keine Ahnung, vermutlich wäre ich das Projekt gar nicht angegangen. Aber wenn, dann sicher mehrere volle Nachmittage! Gleichzeitig ist Claude hier nicht "magisch" und stellenweise etwas "dumm": 900 km/h als Geschwindigkeit wäre einem menschlichen Reverse Engineer sofort als unplausibel ins Auge gestochen. Die gesamte Methode ist denke ich auf andere Dateiformate übertragbar. Kern ist, dass der Mensch sagen kann, was er überhaupt in den Daten erwartet - und zwar über die rein technischen Infos wie "da muss eine Geschwindigkeit drin stecken" hinaus auch, was im konkreten Datensatz erwartbare Wertebereiche sind etc.

Den kompletten Reader gibts unter Apache 2 Lizenz auf GitHub: thinkcar-tc-reader