Ich habe hier einen "Basteltacho" aus einem Ford Mondeo Bj. 2011 und versuche gerade dessen Firmware mit IDA zu disassemblieren. Nicht um ein spezielles Ziel zu verfolgen sondern zu lernen wie das Teil funktioniert und mit der Hardware interagiert. Der Tacho hat so div. LEDs und Schrittmotore für Anzeigenadeln, einen Piezo-Lautsprecher und ein monochromes LCD Matrix-Display mit Hintergrundbeleuchtung. Die gesamte Hardware rund um den µC scheint recht überschaubar, meist nur Treiber-Bautsteine, d.H. hier wird das meiste direkt von der CPU selbst gesteuert, inkl. dem LCD-Display. Zuvor habe ich noch ein Firmware-Update aufgespielt, damit ich auch vergleichen kann wo welche Komponenten aus den Update-Dateien hin kommen. Für das Update wird der Bootloader aus "AM2T-14C025-BA" via CAN-Tester auf das KI geladen und ausgeführt. Dieser lädt dann die Daten aus "CS7T-14C026-BF", "CS7T-14C026-DE" und "CS7T-14C088-BE" in den internen Flash des Zentralprozessors, einem MC9S12XHZ512. Rein rechnerisch dürften diese Daten dort garnicht reinpassen, denn die MCU verfügt über keinen externen Flash (nur ein EEPROM für Tachostand und ein paar Konfig-Daten) sondern nur ihren internen mit 512KB. Die Daten zusammengenommen ergeben aber fast 770KB. Mittels BDM habe ich die MCU mal ausgelesen, linear (flat) von 0x0000 bis 0xFFFF. Da fehlen mir natürlich die Pages. Ich habe da noch nicht raus wie ich das mit dem Pages disassemblieren soll. Ich müsste ja immer wieder einen Teil der Firmware in den Speicherbereich 0x8000-0xBFFF legen. Bislang habe ich keinen Weg gefunden IDA das "Paging" selbst beizubringen, auch wenn es mit "Segmenten" ein ähnliches Konzept integriert hat.
Angehängte Dateien:
-
updated_new.PNG
17 KB -
cs7t_18049_parts-side.png
5,2 MB
:
Bearbeitet durch User
Ich glaub das KI war von Visteon. das kann man am S/N am Gehäuse erkennen. Dissasemblieren um das Ding zu verstehen ist ein sehr langer und aufwendiger Weg. Ich bezeichne das sogar als next to impossible - aber das ist nur meine subjektive Sicht. Was ist das Ziel? Sollte der Tacho woanders verbaut werden, braucht man eig. nur die original K-Matrix z.B. als DBC und die Pinbelegung des Hauptsteckers, daraufhin kann man sich eine Gateway basteln die alles Mögliche an Eingangswerten auf CAN umsetzt. Besser wäre es mit einem Debugger live reinzugehen. Könnte aber sein, dass die Release-SW den Debugger bereits im Bootloader deaktiviert. Zu deinem Anliegen, dass "CS7T-14C026-BF", "CS7T-14C026-DE" und "CS7T-14C088-BE" rein rechnerisch nicht hineinpassen. Vermutlich werden die Files nicht vollständig verwendet - so etwas kannst du gut sehen, wenn du nach dem Update die MCU wieder ausliest und das Ergebnis wieder mit den 3 Files vergleichst z.B. mit Beyond compare. Da kannst du gleich sehen, welche Binärsequenzen sich in dem Target befinden. Vorausgesetzt die 3 Files sind unverschlüsselt bzw. ungescrammt. Sehr oft sind solche Files ein Konglomerat verschiedener Varianten und der Bootloader erkennt welche Variante vorliegt und flasht nur die passenden Anteile. Zu den Grundlagen des Tachos: HW: Der dicke Automotive-Stecker hat Stromversorgung (KL30 + KL31) dann eventuell KL15 Eingang, das wäre die Leitung vom Zündschlüssel (es sei denn die ist da bereits virtuell über CAN angebunden) Dann eventuell ein Paar analoge und/oder digitale I/Os, eins oder zwei CANs und eventuell LIN. Auf der Platine selbst, wie bereits richtig erkannt Treiber für Schrittmotoren und LEDs (Hintergrundbeleichtung, Warnlampen, Segmentanzeigen). Piezo. BTW. diese Schrittmotoren können nur 4 Schritte pro 360 Grad, also 45° pro Schritt. Die feine Auflösung geht über Microstepping. Oft ist die Achse aus Plexiglas, durch diese wird dann mit einer LED der Zeiger beleuchtet. SW: Die Software basiert auf einem OSEK OS bzw. Autosar. Das heißt es ist ein Multitasking-OS drauf. Ansonsten ganz viele Softwaretreiber für die Peripherie und darauf basierend entweder verschiedene Applikations-Tasks (inkl. Diagnose/UDS/ISOTP Stack etc.), falls noch OSEK, ansonsten jede menge SWCs, falls Autosar. Funktionsprinzip: KL30 +12V und KL31 GND liegen in der Regel permanent an. Über KL15 oder über CAN-Aktivität wird das KI aufgeweckt und Bootet. Danach reagiert es zyklisch auf Eigabewerte z.B. über CAN und zeigt dem Fahrer irgendwas an. Zusätzlich wird auch über CAN was zurückgesendet - mindestens Netzwerkmanagementsignale. (ist natürlich erstmal eine sehr sehr einfache Darstellung). Der Kilometerstand im EEPROM ist sicherlich mit der ID des EEPROMS und des SX verschlüsselt und außer im KI, wahrscheinlich auch in anderen Stellen abgelegt. Die möglichen Manipulationen, die ich bisher bei diesen KIs gesehen habe, waren meistens Eingriffe kurz vor der Anzeige. D.h. kurz vorm Beschreiben des Registers, der im Display den KM-Wert anzeigt. Da fügt man einen Jump zu einem eigens geschriebenen stück Code, der den Wert erst verkleinert, bevor dieser geschrieben wird. Andere Manipulationen sind meistens auf Insiderwissen zurückzuführen. Die Nicht-Insider-Manipulationen sind über Diag auslesbar, weil der Diagtester plötzlich einen ganz anderen Wert zeigt. Beispiel für Funktionen: 1. Vom Steuergerät ABS/ESP kriegt man vier verschiedene Raddrehzahlen (von den Zählrädchen). Die vier werte werden über eine Formel gemittelt und mit dem Lenkwinkelsensor verrechnet um so die Geschwindigkeit und die gefahrenen Kilometer zu errechnen. Die Geschwindigkeit wird über einen kleinen Softwarefilter gedämpft (damit der Zeiger nicht zappelt) und dem Fahrer mit einem Schrittmotor angezeigt. 2. Die Drehzahl wird vom Motorsteuergerät über CAN übermittelt und nach der Filterung im KI angezeigt. 3. Die Kühlwassertemperatur wird als sensorwert über CAN mitgeteilt und beim Überschreiten eines Schwellwertes (mit Hysterese) geht im KI eine Warnleuchte an und der Piezo piepst. 4. außer der UDS Diagnose läuft permanent Zyklisch die Überwachung verschiedener Sensoren und der Software selbst. Das ist für den Fahrer nicht außensichtig erkennbar. Aber im Fehlerfall piepst und leuchtet irgendwas und es wird ein DTC im EEPROM abgelegt. (Wobei die Engine-Check vom KI i.d.r. nur angezeigt wird, aber nicht im KI EEP abgespeichert).
:
Bearbeitet durch User
Roman B. schrieb: > > Dissasemblieren um das Ding zu verstehen ist ein sehr langer und > aufwendiger Weg. Ich bezeichne das sogar als next to impossible - aber > das ist nur meine subjektive Sicht. Meinst Du dieses spezielle Steuergerät oder allgemein? Das ist alles "nur" eine Sache der Erfahrung und hängt davon ab was man aus einer ECU Firmware an Erkenntnis herausholen will. Geht es z.B. um den UDS Security Access kommt man teilweise sehr schnell ans Ziel (wenn man darin Erfahrung hat, das kann man nicht oft genug betonen).
Ich meine das wirklich Allgemein. Wobei ganz klar bei sehr kleinen ECUs, wie z.B. Anhängesteuergerät es wesentlich einfacher ist den zu "reverse-engineeren". 2011 klingt interessant - ist das noch Visteon oder Conti? Den UDS Security Access kriegt man ausgehebelt, wenn man mit nem Debugger reingeht und versucht im CAN-Input einen Breakpoint auf die Message (oder irgendeinen Wert davon) zu setzen, die den Key enthält, der vom Tester an das KI geht. Es wird erstmal der Falsche Key sein, aber nach einigen 100 - 1000 Jumps ist irgendwo der Jump der if-then construktion, die entscheidet, ob der KEY korrekt war. Im assembler ist das dann BEQ/LBEQ für Branch equal/Long branch equal oder BCS/LBCS für carry flag jump oder ähnlich. Wenn man den Jump erst entdeckt hat, kann man vor der Decision den Zero-Flag oder den Carry Flag manipulieren. Damit springt er in die ensprechende Session auch wenn der Key falsch ist. Falls der Flashbereich nicht CRC geschützt ist, kann man versuchen so eine Stelle mit JMP o.ä. mit nem Hexeditor zu patchen, so dass die SW trotz eines falschen Keys immer in den Modus springt. Das finden des Jumps ist eben etwas schwierig und aufwendig.
:
Bearbeitet durch User
Roman B. schrieb: > Dissasemblieren um das Ding zu verstehen ist ein sehr langer und > aufwendiger Weg. Ich bezeichne das sogar als next to impossible - aber Exakt. Ich denke das eine Firmware in dieser Größe nicht via Disassemblierung vollständig zu verstehen oder wieder in Quellcode zurückzuführen ist. Darum geht es mir auch garnicht. Ich finde es einfach faszinierend auf diese Weise in Hardware "einzutauchen" und gern würde ich bestimmte Komponenten verstehen und ggf. damit rumspielen. Auch um z.B. interne, versteckte Funktionen zu finden. > braucht man eig. nur die original K-Matrix z.B. als DBC An die man selbstverständlich nicht ran kommt, zumindest nicht legal. Sie ist auch nicht Bestandteil der Firmware sondern nur über entsprechende Funktionen implementiert. > und die Pinbelegung des Hauptsteckers, daraufhin kann man sich Die wiederum ist das einfachste. Hier helfen die Schaltpläne vom Fahrzeug. Das habe ich alles. Auch CAN-Gateways und auch schon Simulationen dafür für z.B. Drehzahl usw. Aber es gibt doch noch einiges was ich nicht kenne. > Besser wäre es mit einem Debugger live reinzugehen. Könnte aber sein, > dass die Release-SW den Debugger bereits im Bootloader deaktiviert. "Live" würde ja bedeuten, im Fahrzeug. Das mache ich nicht. Ggf. würde ich einen CAN-Mitschnitt abspielen. Das KI sollte keinen Unterschied erkennen ;-) > Zu deinem Anliegen, dass "CS7T-14C026-BF", "CS7T-14C026-DE" und > "CS7T-14C088-BE" rein rechnerisch nicht hineinpassen. Vermutlich werden > die Files nicht vollständig verwendet - so etwas kannst du gut sehen, Was sollte das aber für einen Sinn ergeben? Ich kenne so einige Firmware-Files und die waren letztlich immer vollständig im Modul enthalten. Eher umgekehrt, das im Modul mehr ist als in der Firmware. Denn z.B. die Vector-Tabellen oder Bootloader sind da nicht enthalten. Die Firmware ist ja in der Regel als Update gedacht und nicht für eine initiale Betankung. > wenn du nach dem Update die MCU wieder ausliest und das Ergebnis wieder Genau das habe ich ja versucht. Durch das in der MCU verwendete Paging ist das aber nicht ganz trivial. > die 3 Files sind unverschlüsselt bzw. ungescrammt. Sehr oft sind solche Ne, das Zeug ist noch aus einer Zeit wo man sowas nicht gemacht hat. Auch die MCU hat keinen Ausleseschutz. > Segmentanzeigen). Piezo. BTW. diese Schrittmotoren können nur 4 Schritte > pro 360 Grad, also 45° pro Schritt. Die feine Auflösung geht über 45° pro Schritt? Das wäre ein wenig "grob" für eine Geschwindigkeitsanzeige, meinst Du nicht? ;-) Aber die HW ist hier garnicht so interessant. Viel mehr interessiert mich die Software und wie das intern alles funktioniert. > Die Software basiert auf einem OSEK OS bzw. Autosar. Das heißt es ist > ein Multitasking-OS drauf. Ansonsten ganz viele Softwaretreiber für die > Peripherie und darauf basierend entweder verschiedene Applikations-Tasks > (inkl. Diagnose/UDS/ISOTP Stack etc.), falls noch OSEK, ansonsten jede > menge SWCs, falls Autosar. > Der Kilometerstand im EEPROM ist sicherlich mit der ID des EEPROMS und Wo der liegt weiss ich bereits, auch wie man den berechnet. > Andere Manipulationen sind meistens auf Insiderwissen zurückzuführen. Das denke ich auch. Irgendwer hat da sein Wissen zu Geld gemacht. > 1. Vom Steuergerät ABS/ESP kriegt man vier verschiedene Raddrehzahlen > (von den Zählrädchen). Die vier werte werden über eine Formel gemittelt Da fängt es an interessant zu werden. Die Radimpulse kommen ja von einem Zahnrad welches an einem Initiator (Hallsensor) vorbeilaufen. Diese gehen meist zum ABS-Modul und von dort kommen dann CAN-Botschaften die entsprechende Werte enthalten. Daraus lässt sich dann u.a. die Geschwindigkeit und zurückgelegte Entfernung berechnen.
Dieter schrieb: > Roman B. schrieb: >> >> Dissasemblieren um das Ding zu verstehen ist ein sehr langer und >> aufwendiger Weg. Ich bezeichne das sogar als next to impossible - aber >> das ist nur meine subjektive Sicht. > > Meinst Du dieses spezielle Steuergerät oder allgemein? Das ist alles > "nur" > eine Sache der Erfahrung und hängt davon ab was man aus einer ECU > Firmware > an Erkenntnis herausholen will. Geht es z.B. um den UDS Security Access > kommt man teilweise sehr schnell ans Ziel (wenn man darin Erfahrung hat, > das kann man nicht oft genug betonen). Eigentlich allgemein, aber als ein mögliches Beispiel ist dieses doch auch ganz gut. Es hat jede Menge externe Komponenten über die man ggf. auch verfügen kann (LEDs, etc.). Zudem habe ich das Teil zum basteln zur Verfügung. _Habe aber auch noch weitere Dinge... UDS wäre schonmal ein gutes Thema... Ich versuche so ran zu gehen das ich mit eine externe Komponente suche, z.B. eine LED und dann nachvollziehe wie diese HW-Technisch an die MCU gekoppelt ist. Dann versuche ich die Stellen im Code zu finden die mit dem Port arbeiten um dann ggf. die höheren Funktionen zu finden.
Roman B. schrieb: > Ich meine das wirklich Allgemein. Wobei ganz klar bei sehr kleinen ECUs, > wie z.B. Anhängesteuergerät es wesentlich einfacher ist den zu > "reverse-engineeren". Tja, ich hätte hier noch ein Parkpilot-System mit gleicher MCU, oder ein Komfortsteuergerät für Türschließung, auch mit diesem MCU-Typ. > 2011 klingt interessant - ist das noch Visteon oder Conti? Visteon. > Den UDS Security Access kriegt man ausgehebelt, wenn man mit nem > Debugger reingeht und versucht im CAN-Input einen Breakpoint auf die > Message (oder irgendeinen Wert davon) zu setzen, die den Key enthält, Die Security-Keys kann man bei diesen Modellen sogar noch per Brute-Force ermitteln. Die haben keine Intrusion-Detection, schalten nicht ab. Habe ich vor langer Zeit mal gemacht, nur so zum Spaß. Viel einfacher wäre es natürlich den Code zu finden und auf welche Tabellen dieser zurückgreift. > der vom Tester an das KI geht. Es wird erstmal der Falsche Key sein, > aber nach einigen 100 - 1000 Jumps ist irgendwo der Jump der if-then > construktion, die entscheidet, ob der KEY korrekt war. Im assembler ist Tja, genau das wäre mal was... mit einem Debugger habe ich so noch nicht viel gemacht, denn meist werden diese nur bei Verwendung mit eigenem Quellcode erklärt und zum Einsatz gebracht. > Das finden des Jumps ist eben etwas schwierig und aufwendig. Genau, wo anfangen?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.