ABS clonen

Nachdem wir ja nun wissen wie man ein BCM cloned wäre mein nächstes Wunschziel das ABS. Auch das ist Teil des PATS-Systems und daher nicht ohne weiteres austauschbar. Ähnlich wie beim BCM vermute ich auch im ABS einen Speicherbereich in dem die Schlüssel/PATS-Codes hinterlegt sind. Und ähnlich wie beim BCM glaube ich auch hier das wenn man diese Daten identifizieren und separat umkopieren kann, ein Wechsel auch zwischen verschiedenen ABS-Modellen möglich sein sollte.

Im Ford FDRS (ehem. IDS) gibt es ja auch genügend Prozeduren die ähnliches tun. Ein Module-Replacement wird da immer so begleitet das zunächst der Inhalt des Moduls runtergeladen wird, dann soll das Modul mechanisch gewechselt werden und anschließend wird es wieder mit den gleichen Daten beladen/programmiert. Dadurch wird sichergestellt das nur die defekte Hardware gewechselt wird, nicht aber die Programmierung oder Anlerndaten. Und so verwundet es auch nicht das dies mit Original-Mitteln erstmal nur für gleiche Bauteile möglich ist, also ein Upgrade nicht vorgesehen ist bei diesem Vorgang.

Lange Rede... los gehts. Schauen wir uns mal an was da so drin steckt!

Dummerweise hat Ford das ABS derart in der Karosserie versteckt das man an nichts wertvolles rankommt ohne es komplett auszubauen. Auch der eigentlich "abziehbare" Elektronik-Block ist dadurch das er zur Spritzwand zeigt unmöglich im eingebauten Zustand zu entnehmen. Hier mal ein Bild nachdem das Batteriefach komplett ausgebaut wurde, vorher bekommt man das Teil nichtmal zu Gesicht:

Die Schrauben die den Kopf auf dem Block befestigen sind recht lang. Es besteht keine Chance die im eingebauten Zustand rauszudrehen, bzw. den Kopf vom Block abzuziehen. Hier mal ein Foto von einem "geteilten" ABS:

Es konnte bis heute auch nicht zweifelsfrei geklärt werden ob ein ABS mit erweiterter Kontrolle (wie man ihn für den Hill-Assist oder das ACC benötigt) den gleichen mechanischen Block und nur einen anderen Steuerkopf besitzt oder nicht. Das bedeutet als im Endeffekt das man das alte ABS ausbauen und ein neues einbauen muss.

Glücklicherweise kommt man bei ausgebautem Batteriefach wenigstens an den ABS-Stecker ran, man kann also seinen Clone daran wenigstens testen bevor man die Bremsflüssigkeit ablässt und später alles neu befüllen und entlüften muss (eine nicht zu unterschätzende Arbeit, sowohl zeitlich als auch fachlich!). Das habe ich einfach mal getan und wie erwartet den Fehler "Wegfahrsperre aktiv" erhalten.

Reverse Engineering, Teil 1 - Informationsbeschaffung

Wie immer muss es Opfer für die Wissenschaft geben, also habe ich mir ein "Schlacht"-ABS besorgt. Hier handelt es sich um ein Standard-ABS (IVD):

Der Deckel vom Elektronik-Modul ist aufgeklebt und scheinbar nicht durch erwärmen weich zu bekommen. Ich musste das Gehäuse knacken (aufsägen), eine Methode die für einen späteren Tausch eher nicht in Frage kommen wird.

Danach gibt sich folgendes Bild:

Der Modulstecker sowie die Magnetventile sind mit Pressfit-Kontaktstiften in die Platine gedrückt. In der hohen Konzentration hält das unglaublich gut, ist also nicht mal eben so abzuziehen. Ich habe es aber trotzdem gemacht weil ich wissen wollte was sich ggf. auf der Unterseite befindet. Zum glück ist da nichts:

Also konzentriere ich mich rein auf die Oberseite:

Mein besonderes Interesse gilt erstmal dem Zentralprozessor (1), einem TMS470R1VF478 von Texas Instruments. Sowie dem darüber liegenden EEPROM (3) vom Typ ST 9504W. Es würde mich nicht wundern wenn genau darin die gesuchten Daten liegen würden... Wenn sowas in einem externen EEPROM gespeichert wird, dann könnte der Inhalt durchaus verschlüsselt, in der Regel nur mit etwas "Bitgefummel" obfuskiert sein. Das kennen wir ja schon vom Tacho.

Also mal schauen was der Mikrocontroller so zu bieten hat.

• 16/32 Bit RISC Architektur
• 24 MHz Systemtakt
• Build-In Debug Module (Interessant!)
• Big-Endian Format
• 288 KB Programmspeicher (Program-Flash)
• 16 KB SRA
• Betriebsspannung 1,8 - 2,0 V
• IO-Spannung 3,0 - 3,6 V
• Analoger Watchdog Timer
• Digitaler Watchdog Timer
• 2 SPI Interfaces
• 2 SCI Interfaces
• High-End CAN 2.0B Controller (32 Mailboxen)
• Standard CAN 2.0B Controller (16 Mailboxen)
• Serial Interface (128 Word Puffer)
• Timer und AD-Wandler und jede Menge GPIOs
• JTAG Interface (Interessant!)
• Code Composer Studio Entwicklungsumgebung
• HET Assember/Simulator

Auch immer interessant ist die Bedeutung der einzelnen Ziffern der Typenbezeichnung zu kennen, die sog. "Device Numbering Conventions".

TMS 470 R1 V F 47 8 BGJZ Q

Daraus geht hervor das dieser Chip zur "TMS470" RISC-Familie gehört. "R1" spezifiziert die CPU auf den Typ ARM7TDMI. ARM7 ist eine weit verbreitete RISC-CPU. Der Zusatz TDMI (Thumb) spielt hier jetzt erstmal keine Rolle.

Das V steht nur für die Betriebsspannung von 1,8V.

"F" zeigt an das sich im Mikrocontroller ein Flash-Speicher befindet von dem das Programm ausgeführt wird.

Die "47" weißt die internen Peripheribausteine aus wie ich sie oben schon angerissen habe.

Die "8B" zeigt an das die Größe des Flash-Speichers zwischen 128kb und 1MB liegt.

"GJZ" ist das BGA-Gehäuse des Chips (176 Pins, Ball Grid Array)

Zuletzt gibt "Q" die Temperaturfestigkeit an. Hier wurde die höchste Güte für Automotive gewählt, -40 bis +125 °C

Der JTAG-Port interessiert mich ganz besonders, denn hierüber lässt sich in der Regel die komplette Firmware auslesen und beschreiben. Natürlich werde ich auch hier einen Weg finden müssen die Watchdogs zu deaktivieren damit diese mir schön Zeit für mein Vorhaben lassen. JTAG bietet aber auch noch die Möglichkeit des Single-Step Debuggings, so kann man auch hinter das ein oder andere Geheimnis der Firmware gelangen.

Laut Datenblatt befinden sich die JTAG-Ports an diesen Balls des BGA:

Leider ist ein BGA nicht so einfach durchzumessen wie ein Chip mit Beinchen. Um von der Ball-Position zu einem Test-Punkt oder JTAG-Header zu finden müsste man diesen eigentlich entlöten. Den danach aber wieder funktionsfähig aufzulöten ist leider alles andere als trivial und daher lasse ich das erstmal.

Die Pads (5) sehen ja stark nach einem Debug-Header aus, haben jedoch nicht die für JTAG übliche Pin-Zahl sondern deutlich mehr:

Einfach mal probieren ist eher aussichtslos. Es gilt also herauszufinden welcher diese Pads mit den JTAG-Pins vom BGA verbunden ist.

Im Reference Manual der TMS470 Familie ist zu lesen das TI ein Tool namens "nowFlash Tool" für das lesen, löschen und beschreiben des internen Flash-Speichers via JTAG bereitstellt. Das werde ich mir auch mal ansehen.

Wenn ich jetzt so drüber nachdenke... der Chip hat ja kein eigenes EEPROM und das er zum speichern von Daten das interne Program-Flash nimmt ist mehr als unwahrscheinlich, denn genau dafür wurde das externe EEPROM platziert. Dieses konnte ich nach dem öffnen einfach auslöten und auslesen (Datei im Anhang). Ich denke die Suche nach dem JTAG kann ich mir sparen, der Chip wird in seinem Flash nur die Firmware drin haben und die kennen wir ja bzw. lässt sich leichter geschaffen.

Es würde vermutlich funktionieren dieses zwischen den Steuergeräten zu tauschen. Das Problem hier ist das man um da ran zu kommen beide ABS-Module ausgebaut und geöffnet auf dem Labortisch haben muss und das wird so eher nicht funktionieren. Allein weil das öffnen des Gehäuses ohne Gewalt nicht möglich ist.

Also scheint mir der einzig sinnvolle Weg eine Softwarelösung für das Problem zu finden. EEPROM aus altem ABS über CAN-Bus auslesen und auf die gleiche Weise auf das neue programmieren.

Wie immer liefert uns das Firmware-Update File und das Datenblatt des Microcontrollers gute Hinweise für den Start.

Die Firmware besteht also aus zwei Teilen. Der Update geschieht über den HS-CAN und die ABS UDS-ID ist 0x760.

Jetzt hilft ein Blick auf die Memory-Map:

Der erste Teil geht laut Updater von 0x2000 bis 0x5FFF, das ist quasi mitten im bereich des "Program and Data Area" des µC. Auch der zweite Bereich von 0x4_0000 bis 0x7_FFFF liegt dort drin. Was uns also wie immer fehlt sind die Reset-Vectoren und der primäre Bootloader die wie üblich am Anfang des Adressbereichs liegen. Dieser Bereich wäre durchaus interessant weil er uns die Startadresse der Firmware verraten würde. Aber diese liegt natürlich im Bootloader und nicht direkt in der eigentlichen Software.

Eine Strategie wäre nun sich selbst einen Bootloader zu schreiben, der ähnlich wie beim Modulupdate ins RAM transferiert und dort ausgeführt wird, dann die Kontrolle über den Chip übernimmt und seinerseits den Inhalt des Flash, vor allem aber des externen EEPROMs über die CAN-Bus Schnittstelle auf den Bus überträgt. Als Empfänger würde hier dann ein einfacher CAN-Bus Sniffer dienen, welche die Datenpakete aufschnappt und wieder zusammensetzt.

Um das zu ermöglichen muss man wissen wie man eine solche Software programmieren kann, also in welcher Sprache mit welcher Entwicklungsumgebung (IDE) und Compiler damit am Ende ein ausführbares Programm dabei heraus kommt. Natürlich könnte man das auch direkt in Assembler programmieren, aber das kann sehr aufwändig werden, normal nimmt man Hochsprachen wie "C" für so etwas.

Ich werde mir also als erstes eine Entwicklungsplattform zusammenstellen. Das Datenblatt hat ja schon einige Angaben gemacht. Am Ende ist es ARM-Code, den kann so gut wie jede Embedded-Plattform herstellen, da reicht sogar OpenSource Software völlig aus.

Dann muss ich mir anschauen wie man per Software den Chip initialisieren muss damit einem z.b. der Watchdog nicht in die Quere kommt, aber auch wie man den CAN-Controller initialisiert und darüber Daten sendet, genauso wie man das externe EEPROM anspricht. Hier gilt es noch herauszufinden über welchen Port des Chips das verbunden ist. Gleiches Problem wie beim JTAG ist das man die Pins nicht einfach "durchklingeln" kann. Das das gewählte EEPROM ein Serielles EEPROM mit SPI-Interface ist, bleiben zumindest nur zwei Optionen, SPI1 und SPI2, denn mehr solcher Schnittstellen bietet der Chip nicht. Es wäre also zur Not einfaches ausprobieren beider Varianten.

Danach bleibt dann die Frage zu klären wie man die Software, welche natürlich so klein sein muss das sie ins RAM des Chips passt, auf selbigen drauf bekommt. Grundsätzlich so wie jedes Firmware-Update auch, also eine UDS-Session eröffnen, einen Security-Access erwirken, die Daten in UDS-Pakete zerteilen und an das Modul senden und danach zur Ausführung bringen. Per Prinzip gibt es für das alles UDS-Funktionen. Die Hürde wird der Security Access sein, denn dazu muss man das Schlüssel-Berechnungsverfahren kennen. Einige Module sind hier sehr lax programmiert wie z.B. das PAM und nutzen immer wieder dieselben Codes. Andere haben etwas mehr Hirn reingesteckt. Mal sehen...