Hacking into NavFX

Der Titel ist zugegeben etwas reißerisch, beschreibt aber ganz gut die geplante Vorgehensweise die uns evtl. mal in die Lage versetzt die Abläufe und Funktionen im Navi nicht nur zu verstehen sondern auch auf unsere Bedürfnisse anpassen zu können. Es geht also weniger um die Elektronik und Reparatur sondern die Software im Gerät. Hierbei sollten wir uns erstmal nur dem Ford Navigationssystem FX widmen. Der Aufbau des NX und MCA sind nahezu identisch mit dem FX, also kann man sicher auch das Wissen darauf adaptieren. Es sei noch erwähnt das diese Gerätebasis auch im VW-Konzern als "RNS310" verwendet wird, wie auch bei Opel und sicher weiteren Herstellern.

Hacking hat immer viel mit Wissen zu tun und so bleibt es nicht aus sich mit einigen Dingen sehr intensiv auseinandersetzen zu müssen. Wer sich vom Thema angesprochen fühlt und dazu was beitragen kann ist herzlich willkommen! Gern unterstütze ich durch Zusendung eines Testkandidaten, denn FXe hab ich ein paar hier rumliegen.

Los gehts...!

Demontage und identifizierung der Komponenten

Das FX besteht grundlegend aus zwei Teilen, einem Hauptgehäuse mit dem Mainboard und einem Frontteil mit einem Grapfikboard:

Das Mainboard lässt sich durch lösen sämtlicher Schrauben komplett vom Gehäuse entfernen. Das Grafikboard kann abgenommen werden nachdem man die Steckkontakte für das LCD-Display und seine Hintergrundbeleuchtung gelöst hat.

Sowohl auf dem Mainboard als auch auf dem Grafikboard befindet sich ein Mini-Computer, bestehend aus einer CPU, RAM, Flash und IO-Bausteinen. Im Wiki gibt es bereits eine Seite mit der Erklärung der darauf befindlichen Bauteile sowie Datenblätter: https://mk4-wiki.denkdose.de/grundlagen/aud…avi_fx/teardown

Hier mal eine schematische Darstellung des gesamten Radios:

Hintertürchen finden

Das System kenn zwei Arten die interne Software zu aktualisieren:

1.) Per SD-Karte
Hierauf sind Navigationsdaten, aber auch Sprachdateien enthalten. Möchte man die Systemsprache ändern bedarf dies zum Teil einer SD-Card. Ohne SD scheint es immer eine eingestellte Sprache (z.B. "Deutsch") zu geben und einen Fallback "Englisch". Weiterhin kann die SD noch ein Update für den Navigationsrechner enthalten.

2.) Per CD
Damit werden Firmwareupdates eingespielt, oder aber auch Navigationsdaten wie sie auf der SD drauf sind.

Für beide Updatedatearten gilt, das der Datenträger bestimmte Dateien enthält die vom System beim einlegen des selbigen als Update-Software erkannt und speziell behandelt werden. Beim Firmwareupdate wird vermutlich zunächst ein spezielles Update-Programm vom Datenträger in den Arbeitsspeicher des Mini-Computers gelesen und zur Ausführung gebracht. Dieses wiederum übernimmt dann das einlesen und speichern vom Rest des Updates. Einige Komponenten verfügen über internen Flash-Speicher, andere über externen. Klar dürfte sein, das diese mit den neuen Daten überspielt werden. Das Problem bei einem abgebrochenen Update ist, das System wieder in einen Zustand zu bekommen in dem es den Updater einlesen und ausführen kann. Das könnte u.U. durch andere Schnittstellen erfolgen, die direkten Zugang zum RAM oder Flash haben. Dabei ist es wichtig zu wissen ob man über den extern aufgelöteten oder den Chip-internen Flash/RAM spricht. Was genau wo drin steckt ist noch unklar, aber der Zugriff darauf wird sich deutlich unterscheiden.

Den Update-Mechanismus sehe ich als Chance das System mit eigener Software zu bespielen. Sicher wird es sich aber gegen "Fremde" Inhalte schützen. Wie dieser Schutz aussieht ist noch zu klären, denkbar ist vieles bis hin zu digitalen Signaturen, aber wenigstens Prüfsummen oder "shared secrets" (Passwörter).

Letztlich muss sich das was auf einer Update-SD drauf ist in Teilen ja wieder in den Flash-Speichern des Radio wiederfinden.

3.) Per Download-Schnittstelle
Der Hersteller muss ja auch irgendwann mal eine initiale Betankung durchgeführt haben. Dies geschieht in der Regel im fertig montierten Zustand, kurz vor der Qualitätskontrolle. Oft kommen hier standardisierte Schnittstellen wie JTAG zum Einsatz. Die Entwickler erfinden dabei auch nicht das Rad neu, bedienen sich also oft den für die Chips vorgesehenen Techniken wie sie auch auf den Entwicklungsboards zum Einsatz kommen. Oft werden auch Beispieldesigns der Chip-Hersteller fast 1zu1 übernommen, weil es Entwicklungskosten spart.

Da im Gerät verschiedene Mikrocontroller werkeln kann man sich gut vorstellen das es nicht nur eine Schnittstelle gibt. Neben der Initialbetankung mit Software dienen diese aber auch der Qualitätskontrolle und Fehlerdiagnose. Diese Form von Schnittstellen bieten einem Zugang zu Hard- und Software und ggf. auch um mit dem System in Dialog zu treten.

Software Reverse Engineering

Das was man auf den Flash-Speichern der Mikrocontroller oder den aufgelöteten Chips findet ist reiner Maschinencode, also quasi das Endprodukt einer Entwicklung. Sowas programmiert heutzutage niemand mehr direkt, es wird in Hochsprachen wie "C" entwickelt und mittels Compiler zunächst in Assembler (eine maschinennahe Sprache) und schließlich in Maschinencode (den CPU-Befehlen) übersetzt. Dieser wird dann wie eine Datei in einen Flashspeicher hochgeladen und beim start einer CPU ausgeführt.

Noch komplizierter wird das bei einem FPGA. Das sind im prinzip nur programmierbare Logikbausteine. Ein FPGA bekommt keine Software sondern eine Konfiguration mit deren Hilfe sich der Baustein zu einem IC, einem Mikrocontroller oder gar einer CPU macht. Auch hier wird mit einer Entwicklungsumgebung die Funktion "programmiert", in einen Binärstrom gewandelt und anschließend in den Chip hochgeladen.

Zugriff auf diese Entwicklungsumgebungen und den Quellcode haben wir nicht. Im besten Fall haben wir die Möglichkeit die einzenen Flash-Speicher auszulesen. "Im besten Fall" bedeutet, wenn dies nicht vom Chip verhindert wird. Bei externen Flash-Chips ist das sehr unwahrscheinlich, bei internen eher die Regel. Auch könnten Chips eine Sperre gegen das überschreiben des aktuellen Inhalts mit neuer Software besitzen. Bei sicherheitskritischen Chips gibt es sogar sowas wie eine "Selbstzerstörung" bzw. Lockdown bei unlegitimiertem Zugriff.

Haben wir dann, wie auch immer einen solchen Flash-Inhalt als Datei auf unserem PC bleibt die einzige Möglichkeit um zu verstehen was da im Gerät passiert, mit Hilfe eines Decompilers aus dem Maschinencode wieder Assembler zu machen und diesen zu studieren. Aufgrund der Arbeitsweise von Compilern und der Zuhilfenahme von Bibliotheken können aus einigen wenigen Zeilen C-Code hunderte von Assembler-Anweisungen resultieren. Das zu "verstehen" ist wahrlich große Kunst und ein immenser Zeitaufwand. Eine solche Form des Reverse-Engineering wird kaum einer durchführen...

Effektiver ist es eine Debug-Schnittstelle zu verwenden. Hierbei stehen die CPU und eine Software auf dem PC mittels einer speziellen Schnittstelle in Kontakt. Über den PC kann man die CPU anweisen Befehle schrittweise auszuführen, oder bis zur nächsten Sprunganweisung (Funktion) oder nach einer solchen, usw. Dabei kann man sich die Registerwerte und Speicherstellen anzeigen lassen und auch beeinflussen. Auch ist es möglich beim Zugriff auf bestimmte Speicherstellen die Befehlsausführung zu stoppen. So lassen sich z.B. kontextbezogene Funktionen finden oder welche die auf Daten wie Texte, Bilder, etc. zugreifen.

Jedes Programm hat eine Hauptschleife. In ihr werden üblicherweise zunächst die Zustände der Eingabekanäle geprüft, dann diese Daten verarbeitet und ggf. Unterfunktionen angesprungen und am Ende die Ausgabekanäle gesetzt. Danach beginnt das ganze wieder von neuem. Auch wenn das Gerät nichts zu tun scheint, werkelt es in ihm ganz gewaltig. Funktionen die länger brauchen werden schrittweise durchgeführt, also bei jeder Iteration etwas mehr, bis die Ausführung vollständig ist.

Diese Loop lässt sich mit einem Debugger gut ermitteln und nachvollziehen. Von hier ausgehend kann man dann wichtige Unterfunktionen finden, z.B. beim drücken einer Taste, nach dem Eingang einer CAN-Botschaft, vor dem ausgeben einer Nachricht, etc. Durch loggen auf Speicherstellen bekommt man wiederrum mit, welche Funktion z.B. auf einen Meldetext oder eine Grafik zugreift.

Wie bekommt man dann eigene Funktionen ins System?

Das ist die große Frage! Mangels Quellcode kann man die Software nicht abhändern, neu compilieren und aufspielen, man kann nur etwas "umbiegen" und ggf. erweitern. Ein Beispiel: Wir möchten die Funktion einer Taste unter bestimmten Bedingungen ändern. D.H. die integrierte Funktion soll nicht oder nur in bestimmten Betriebsbedingungen ausgeführt werden. Hat man den Einsprungpunkt für die Tastenbehandlungsroutine gefunden, kann man an dieser Position einen Sprungbefehl setzen der zu einem ganz anderen Speicherpunkt führt. An diese Stelle platziert man seine eigene Software die entscheidet ob die besagte Taste gedrückt wurde und was nun zu tun ist. Soll die Standardfunktion ausgeführt werden, springt man einfach wieder an die ursprüngliche Stelle zurück. Ansonsten führt man den eigenen Programmcode aus und kehrt zum Aufrufer zurück.

Das klingt sooo einfach, ist in der Praxis aber nur mit viel Hintergrundwissen möglich. Denn man muss die möglichen Nebeneffekte eines solchen Aufrufes kennen und ggf. nachstellen.

Das eigene Programm kann man dann durchaus in C schreiben und für den jeweiligen Prozessor übersetzen. Als Ablagestelle bietet sich ein unbelegter Bereich im Flash an. Einen solchen gibt es praktisch immer, da kein Programm einen Speicher völlig belegt, das wäre Zufall. Meist halten sich die Entwickler auch noch großzügig Platz für eigene Erweiterungen oder Debug-Code der später rausfliegt. Um einen solchen Code inkl. der Veränderungen am bestehenden dann im Gerät zum laufen zu bekommen muss man natürlich wissen ob über den Speicher irgendwo Checksummen gebildet und geprüft werden. Ganz nebenbei sind hervorragende Programmierkentnisse natürlich Pflicht.

Zuletzt muss man noch einen Weg finden die geänderten Inhalte wieder in die Flash-Speicher hochzuladen.

Wo anfangen?

Puh, das klingt alles wenig vielversprechend... Stimmt! Niemand hat gesagt das hacken einfach ist

Um sich nicht gleich am Anfang wegzuschießen sollte man einen Weg finden die Flash-Speicher auszulesen und wieder mit der richtigen Software befüllen zu können, quasi eine Art Backup anzulegen. Die externen Chips könnte man dazu auslöten und mit einem Lesegerät auslesen. Beschreiben sollte ebenso gehen. Die internen Flashes werden kniffliger. Hier muss man das Datenblatt studieren und einen Weg finden der vom Chip vorgesehen ist. Das wird von Chip zu Chip unterschiedlich sein.

Basierend darauf lassen sich die Auswirkungen von einem Firmwareupdate per CD gut überprüfen. Ein Binärvergleich köntne aufschluß geben wo welche Teile/Dateien des Updates im Gerät landen. Durch unkritische Änderungen, z.B. Buchstaben eines Meldungstextes, kann überprüft werden ob die Updatedaten manipulationssicher sind.

Testaufbau

Als Equipment sollte man neben einem PC über ein Labornetzteil verfügen. Das FX lässt sich mit einer Betriebsspannung von 9-16V betreiben (es ist sowohl unter- als auch überspannungsgesichert) und hat eine Stromaufnahme von ca. 1,2A (ohne Lautsprecher und GSP). Das Netzteil sollte also dauerhaft wenigstens 2A liefern können ohne dabei abzurauchen

Ohne CAN-Bus fällt das Gerät nach ca. 1h in den Tiefschlaf. Um "ausgeschalteten" (Geräteknopf) bzw. "Pin-Abfrage" Modus deutlich schneller.

Um an alle Teile gut ranzukommen empfiehlt es sich das Gehäuse weitestgehend zu entfernen. Das CD-Laufwerk muss nicht zwingend angeschlossen sein, man kann aber das kurze Flachbandkabel problemlos durch ein längeres ersetzen und somit das Laufwerk seitlich platzieren.

Als Schnittstelle zum Gerät konnte ich bislang die JTAG-Ports von Mainboard und Grafikboard ermitteln. Als JTAG-Adapter kommt erstmal alles in Frage. Ich selbst verfüge über einen Segger J-Link Edu (ca. 50,- €) und einem USB-Blaster II Clone (ca. 10,- €).

Ein Speicheroszi, Logikanalyzer und natürlich einem Flash-Chip Reader für große Chips wären sehr hilfreich. Ebenso wie entsprechendes Lötgerät um die Chips ggf. aus- und wieder einlöten zu können.

Erste Ergebnisse

Mit dem Segger J-Flash ist es mir bereits einmal gelungen die Firmware aus dem Mainboard-Flash via JTAG herunterzuladen. Ich weiss aber inzwischen das es eine USB-Download-Schnittstelle im Gerät gibt, nur noch nicht wie man diese benutzt. Womöglich geht das nur mittels spezieller Treiber und Software.

Ebenso verfügt das Grafikboard über eine JTAG-Schnittstelle.

Zitat von TychoGold

Hallo (ich kenne deinen Namen noch immer nicht),

puh, viel Text.

Wie sieht dieser Firmwaredump aus und welchen Prozessor bedient der Flash? Interessant wäre erstmal, welche Prozessoren auf dem Board verbaut sind und wie viel internen Speicher diese haben. So kann man abschätzen, ob eventuell nur ein Bootloader im Prozessor steckt oder doch etwas mehr Programmcode.
Wenn das zweite der Fall ist, wirds schon schwierig, denn üblicherweise wird ein Lockbit gesetzt, sodass sich der Code nicht mehr auslesen lässt. Prozessoren von Atmel und auch eine PICs hatten ein paar Exploits (glaube es war die Varianz der Speisespannung), mit welcher dieser Schutz überwunden werden konnte.
Aber erstmal zurück zu deinem initialen Dump: Lässt sich wieder vernünftiger Assembler daraus generieren oder ist der Flashinhalt verschlüsselt? Ich muss dir in diesem Punkt nämlich widersprechen - externer Flash kann sehr wohl verschlüsselt abgelegt werden, gerade bei DRM-getriebenen Produkten wie einem Navigationssystem ist das nicht unwahrscheinlich.

Grüße
Tycho

Zitat von TychoGold

Hallo (ich kenne deinen Namen noch immer nicht),

Das macht doch nix, ich weiß doch wen Du meinst und "Go4IT" reicht mir hier im Forum völlig Dir als Informatiker brauche ich ja nix über die Bedeutung und Nutzen von Aliasen im Netz erzählen...

Zitat von TychoGold

puh, viel Text.

Ja, ich wollte noch ne Warnung an den Anfang setzen, wie "ACHTUNG: Hier folgt viel Text. Viel Text kann zu erhöhten Lesereaktionen führen. In seltenen Fällen auch zu Kopfschmerzen und epileptischen Anfällen."
Ich versuch mich jetzt aber kurz zu fassen. Das war ja nur eine Einleitung...

Zitat von TychoGold

Wie sieht dieser Firmwaredump aus und welchen Prozessor bedient der Flash?

Ausgehend davon das der für uns interessante Teil vom Prozessor auf dem Mainboard bedient wird ist das so:

Der OMAP5948 (1) (Texas Instruments) ist eine Sonderbaureihe für Automotive-Hersteller. Es gibt darüber keinerlei öffentlich verfügbare Dokumentation. Ich habe aber herausgefunden das er ein Hybrid aus einer ARM9-CPU (ARM926EJ-S) und einem C55-DSP (TMS320C55x) ist (evtl. ist es auch ein TMS320C674x DSP, das konnte ich nicht eindeutig klären). Seine Spezifikation entspricht wohl der des OMAP-L138. Hier mal ein Blockdiagramm davon und den wichtigsten Parametern:

* 375-456 MHz RISC MPU
* 375-456 MHz Fixed- and Floating-Point DSP
* 32- and 16-Bit Instructions (ARMv5TEJ-Kompatibler Befehlssatz)
* Little-Endian Architektur
* Embedded ICE-RT for Real-Time Debug

Direkt mit ihm verbunden ist der Spansion Flash S29GL256N10 auf dem Mainboard (2). Er hat eine Kapazität von 32 MB. Ebenso angeschlossen sind die beiden MT46V64M8 RAM-Chips (ja, genau die die so gern kaputt gehen) die dem Prozessor zu insgesamt 128MB RAM verhelfen. In den 64KB ROM (vermutlich ein Flash) wird wohl eher nur ein BIOS oder ein Bootloader drin stecken, oder garnix. Mit seinem DMA-Controller wäre er schnell genug um direkt vom Flash zu booten.

Zitat von TychoGold

Wenn das zweite der Fall ist, wirds schon schwierig, denn üblicherweise wird ein Lockbit gesetzt, sodass sich der Code nicht mehr auslesen lässt.

Dazu habe ich folgendes zum OMAP gefunden:

>> For security-enabled devices, TI’s Basic Secure Boot lets users protect proprietary intellectual property (IP) and prevents external entities from modifying user-developed algorithms. By starting from a hardwarebased "root-of-trust", the secure boot flow ensures a known good starting point for code execution. By default, the JTAG port is locked down to prevent emulation and debug attacks; however, the JTAG port can be enabled during the secure boot process during application development. The boot modules are encrypted while sitting in external nonvolatile memory, such as flash or EEPROM, and are decrypted and authenticated when loaded during secure boot. Encryption and decryption protects the users’ IP and lets them securely set up the system and begin device operation with known, trusted code. <<

>> Basic Secure Boot uses either SHA-1 or SHA-256, and AES-128 for boot image validation. Basic Secure Boot also uses AES-128 for boot image encryption. The secure boot flow employs a multilayer encryption scheme which not only protects the boot process but also offers the ability to securely upgrade boot and application software code. A 128-bit device-specific cipher key, known only to the device and generated using a NIST-800-22 certified random number generator, is used to protect user encryption keys. When an update is needed, the customer uses the encryption keys to create a new encrypted image. Then the device can acquire the image through an external interface, such as Ethernet, and overwrite the existing code. <<

Zitat von TychoGold

Prozessoren von Atmel und auch eine PICs hatten ein paar Exploits (glaube es war die Varianz der Speisespannung), mit welcher dieser Schutz überwunden werden konnte.

Nennt sich "Glitching". Das Prinzip war den Prozessor aus seiner vorgeschriebenen Bootsequenz zu bringen um die Codesperre zu überwinden. Alles andere als einfach zu tun und hierfür auch nicht anwendbar. Alle modernen Chips haben Brown-Out-Detection, Clock-Checking und Anti-Glichting drin. Auf der Ebene läuft da leider schon lange nix mehr...

Zitat von TychoGold

Aber erstmal zurück zu deinem initialen Dump: Lässt sich wieder vernünftiger Assembler daraus generieren oder ist der Flashinhalt verschlüsselt?

Nein, der ist "lesbar", zumindest glaube ich das weil er gespickt ist mit Text und teilweise auch Pfadangaben, etc. Schau mal ins ZIP rein...

Zitat von TychoGold

Ich muss dir in diesem Punkt nämlich widersprechen - externer Flash kann sehr wohl verschlüsselt abgelegt werden

Nichts anderes habe ich gesagt Bei solch alten Systemen ist es dennoch selten. Aber klar, es gibt sogar spezielle Flash-Speicher mit Verschlüsselungsvorrichtung.

Also ich denke unser erster "Angriffsvektor" könnte das externe Flash vom OMAP auf dem Mainboard (Position (2) auf dem Mainboard) sein. Wenn es uns gelingt dieses ohne aus- und einlöten zu manipulieren sollte schon eine kleine Spielerei machbar sein, wie z.B. Meldungstexte anpassen. Auch würde es mich interessieren was man vom Flash-Inhalt in den Downloaddateien der Update-CD wiederfindet.

Folgendes habe ich über diesen Speicher ermittelt:

• Brand: Spansion (now Cypress)
• Package: 64-ball BGA
• Marking: "GL256N10FAA02"
• Type: S29GL256N10FAA02
• Size: 32MB (256 MBit)
• Architecture: 256 x 64 Kword (16 Bit datamode) sectors
• IO-Voltage: 3.0 V
• 128-word/256-byte sector for permanent, secure identification through an 8-word/16-byte random Electronic Serial Number, accessible through a command sequence
• Advanced Sector Protection
• CFI (Common Flash Interface) compliant

Die Anschlüsse des BGA Gehäuses laufen direkt zum OMAP und zusätzlich auf der Platinenunterseite zu div. MPs (Messpunkten). Folgende Verbindungen konnte ich durchmessen:

(Die Adress- und Datenleitungen laufen jeweils über 33 Ohm Strombegrenzungswiderstände)

Um jetzt den Inhalt zu lesen gibt es aus meiner Sicht drei Strategien:
1.) Chip auslöten (glaub mir DAS wollen wir nicht!) und mit einem Flash-Reader und entsprechendem BGA-Sockel lesen
2.) Überprüfen ob man die IO-Ports des OMAP-Prozessor mit Hilfe von JTAG direkt ansprechen kann um jedes Signal nacheinander selbst zu generieren und auszulesen (langsam)
3.) Ein Programm für den OMAP schreiben, welches über die IO-Pins Daten aus dem Flash ausliest und über JTAG an den PC sendet (schnell)

Fürs erste würde ich Strategie 2) wählen. Den JTAG-Port zum OMAP habe ich ja bereits identifiziert:

Der hier gezeigte Serviceport befindet sich auf der Unterseite des Mainboards und ist durch eine kleine, überklebte Öffnung erreichbar ohne das Gehäuse öffnen zu müssen:

Wichtig für das JTAG-Interface ist, das dieses 3,3V Pegel nutzen kann! Die o.g. JTAG-Pins gehen nämlich direkt und ohne Pegelwandler zum OMAP (nur ein 33 Ohm Widerstand dazwischen):

Im Fall des Segger J-Link kann man den dort verfügbaren 3,3V-Ausgang in den TAP einspeisen (Vio) und dieser stellt dann seine Pegelerkennung sowie die Signalspannung entsprechend ein. Nutz man hier etwas anderes, z.B. einen uController oder Serialinterface dann braucht man einen Pegelwandler oder betreibt diesen ebenfalls mit dem 3,3V Pegel.

Damit man über JTAG auf das Flash zugreifen kann muss die CPU im OMAP angehalten werden. Nur so verhindert man das während dem Direktzugriff auf den Flash etwas anderes im System einen Reset auslöst oder selbst darauf zugreift. Der CPU-HALT ist kein JTAG-Kommando sondern muss als Maschinencode in das RAM des OMAP injiziert und ausgeführt werden. Die Ausführung des HALT Befehls erreicht man durch ändern des Programmcounters (PC) auf die Speicheradresse wo man den Befehl abgelegt hat.
Hat man den "Herzstillstand" erreicht, können die IO-Leitungen entsprechend eingestellt werden. Grundsätzlich sollte das nach diesem Diagramm für Flash-Leseoperationen funktionieren:

Das Datenblatt sagt hierzu:
"To read array data from the outputs, the system must drive the CE# and OE# pins to LOW. CE# is the power control and selects the device. OE# is the output control and gates array data to the output pins. WE# should remain at HIGH.
No command is necessary to obtain array data. Standard microprocessor read cycles that assert valid addresses on the device address inputs produce valid data on the device data outputs."

So könnte eine Leseoperation durchgeführt werden (/WE und /RESET bleiben während der gesamten Operation HIGH):

1.) Adressbits einstellen um die lesende Speicheradresse zu wählen.
Hier ist zu beachten das der Flash im WORD-Modus arbeitet, weil das /BYTE-Signal fest mit 3,3V (HIGH) verdrahtet ist. WORD-Modus bedeutet das bei jedem Zugriff ein 16-Bit Datenwort an DQ0-DQ15 erscheint. Der Spansion-Flash ist für diesen Modus vorbereitet und A0 schaltet nicht Byte- sonder WORD-Weise um. Würde man den Chip im BYTE-Modus betreiben (/BYTE auf GND) dann wäre das niederwertigste Adressbit das "A-1" (A minus 1) auf dem Pin DQ15.
Beim Einsatz eines JTAG-Flash-Reader-Programmes muss man diesen Umstand irgendwo darin einstellen können. Der Flash im FX hat nur 32MB und verwendet daher nur 24 Adressleitungen (A0-A23).

2.) Daten anfordern
/CE auf LOW ziehen und kurz darauf /OE ebenfalls auf LOW. Nun legt der Flash die 16-Bit von der gewählten Adresse an die Datenleitungen DQ0-DQ15 an. Sobald dies geschehen ist signalisiert er das durch LOW-Ziehen von RY/BY.

3.) Daten einlesen
Die Bits über JTAG einlesen und zum PC senden um das Word (16 Bit) in eine Datei zu speichern.

4.) Adresszähler erhöhen
Zeiger auf die nächste Adresse um 1 erhöhen (nächstes WORD) und wieder zu 1.) springen bis 2^24 WORDs eingelesen wurden.

Was fürs auslesen zu klären wäre:
a) Welches JTAG-Interface benutzen wird dafür? (Hätte den Segger J-Link EDU dafür)
b) Welcher ARM-Befehl versetzt die CPU in den HALT Modus? und wie können wir diesen per JTAG ins RAM der CPU übertragen und zur Ausführung bringen?
c) Mit welchem Programm lesen wir die Daten vom Flash in den PC? (ich habe dazu mal den Segger J-Flash genutzt)

Ich möchte kurz (ich versuchs, wirklich!) erklären wie JTAG funktioniert.

Hardware-Unterstützung im Chip

Wenn ein Chip JTAG unterstützt, wie es z.B. beim OMAP5948 der Fall ist, dann sieht das Konstrukt schematisch gesehen so aus:

Zwischen den digital IO-Pin des Chips ("External connections") und seiner internen Verarbeitungselektronik ("Core logic") ist ein zusätzlicher Baustein integriert ("Boundary cell").

Im Normalbetrieb steuert die interne logik des Chip die IO-Ports direkt, liest oder setzt Werte. Die Scan-Zellen verhalten sich passiv. Mittels JTAG kann man nun den Zustand der Scan-Zellen auslesen und erhält somit den aktuell am Pin anstehenden Logikpegel (0 oder 1).

Weiterhin kann man die Scan-Zellen so einstellen, das die Verbindung zwischen dem Pin und der internen Logik getrennt wird. Und jetzt wirds cool: über JTAG lässt sich dann unabhängig von der internen Chiplogik der Pegel an einem Pin lesen aber auch einstellen. Das gleiche für die interne Logik selbst. Man kann also sowohl "nach außen", als auch "nach innen" beliebige und voneinander unabhängige Pegel lesen oder simulieren.

Ein Beispiel

"Ein Taster an der Fahrertür signalisiert ob diese geöffnet oder geschlossen ist. Dieses Signal wird an Pin 15 eines JTAG-Fähigen Chips geführt. '0' bedeutet der Taster und damit die Tür ist geöffnet und '1' bedeutet die Tür ist zu. Die Software in der Corelogic des Chips lässt bei geöffneter Tür und Zündung an einen Warnton erklingen. Jetzt komm ich mit meinem JTAG-Adapter und entkoppele den Pin von der Chiplogik. Dem Chip gaukele ich per JTAG eine '0' vor, obwohl die Tür geöffnet und am Pin korrekterweise eine '1' ankommt."

Mehrere Scan-Zellen bilden ein Scan-Register

Was ich so für einen Pin und eine Zelle beschrieben habe ist im Chip mehrfach vorhanden, das häng vom Chip und seiner JTAG-Implementation ab. Alle diese Zellen bilden eine Kette. Elektrisch gesehen ein langes Schieberegister. Die Daten die man dort einschreiben möchte "schiebt" man auf der einen Seite (TDI) hinein. Gleichzeitig erhält man auf der anderen Seite (TDO) den aktuellen Zustand der Zellen. Jedesmal wenn die JTAG-Signalleitung TCK von 0 nach 1 wechselt, wird der am TDI-Pin anstehende Logikpegel (0 doer 1) in das interne Schieberegister übernommen. Gleichzeitig "fällt" am TDO-Pin des Chips der Logikpegel der letzten Scanzelle heraus. Dieser ist beim Übergang des TCK-Pegel von 1 auf 0 gültig.

Man bestimmt also selbst mit welcher Geschwindigkeit man Daten in das Register hineinschiebt oder herausliest. In der Praxis sind hier nach oben hin natürlich Grenzen gesetzt. Aber vom Kern her ist JTAG ein getaktetes, serielles Protokoll. Über spezielle Pins kann die Geschwindigkeit auch vom Chip vorgegeben werden, ansonsten muss man diese einfach wissen oder ausprobieren. Dieser ganze Vorgang ist völlig unabhängig von der internen Chiplogik. Sich schnell ändernde Pin-Zustände sind also nur erfassbar, wenn man das Scanregister auch schnell ausliest.

Die verschiedenen JTAG-Register

Neben dem Scanzeller-Register (Boundary-Scan-Register), kurz "BSR" gibt es noch weitere Register im Chip. Eines davon ist das Chip-ID Register. Das ist nur lesbar, es ist also egal was man an TDI hineintaktet, and TDO kommt immer dieselbe Bitfolge heraus. Diese Bitfolge identifiziert den Chip. Es gibt lustige Lookup-Tabellen dafür, aber leider lassen die wenigsten Chiphersteller ihre Bausteine registrieren, sodass man daran nicht immer erkennt was man vor der Nase hat. Ein anderes ist das Instruction Register, kurz "IR" genannt. In dieses Register werden JTAG-Befehle hineingeschrieben die den Chip dazu bringen bestimmte Dinge zu tun. Z.B. die CPU anzuhalten oder anderes. Manche Instruktionen benötigen Parameter, oder liefern Daten. Diese findet man dann im Data Register ("DR").

Der Zustandsautomat von JTAG zur Bestimmung des Zielregisters

Damit die JTAG-Logik im Chip weis, welches dieser Register ich gerade auslesen und/oder befüllen möchte muss man einen bestimmten Modus wählen. Genau hierführt dient das TMS-Signal von JTAG. Über eine sog. "State-Machine" wird an diesem seriellen Eingang bestimmt welches register man gerade beschreibt. Seriell bedeutet das man an TMS eine Bitfolge, getaktet durch TCK hineinschreibt. Diese Bitfolge ändert den Zustand der Statemachine:

Alles beginnt im Zustand "Test-Logic-Reset" (links oben im Schaubild). Dieser Zustand ist nach dem einschalten des Chips (oder nach einem kurzen '0' auf den TRST-Pin) aktiv. Dieser Zustand ist "stabil" wie man an dem kleinen Kreis erkennt. D.h. solange am TMS-Eingang eine '1' anliegt ändert sich der Zustand nicht, egal wie oft man TCK pulst. Bei der ersten '0' ändert den Zustand nach "Run-Test/Idle". Auch hier verbleibt die SM solange TMS '0' ist. Der nächste '1'-Pegel lässt die SM zu "Select DR-Scan" wechseln. Schiebt man eine weitere '1' in TMS hinein, ist man bei "Select IR-Scan", usw. Um beispielsweise ohne TRST von einem beliebigen Zustand der SM in den Ausgangszustand (Run-Test/Idle) zu gelangen reicht es die Bitfolge "11111" an TMS zu schreiben. Spielt es mal durch...

Auf die einzelnen JTAG-Befehle möchte ich an dieser Stelle nicht eingehen. Die gebräuchlichsten sind "BYPASS" um TDI über ein 1-Bit Register mit TDO zu verbinden, "EXTTEST" um das BSR an die Pins zu koppeln, "SAMPLE" um Daten der Pins zu lesen, "INTEST" um das BSR an die interne Chiplogik zu binden, usw.

Mehrere JTAG-Fähige Chips bilden eine JTAG-Chain

Zuletzt sollte man noch wissen was eine "JTAG-Chain" ist. JTAG wurde nämlich gebaut um EINE Schnittstelle für VIELE Chips zu sein. Hat man also mehrere, JTAG-Fähige Bausteine auf einem Board, kann man die TDO- und TDI-Pins dieser einfach miteinander verbinden und erhält so ein laaanges Scan-Register:

In der Praxis wurde JTAG zum testen von Baugruppen entwickelt. Man kann darüber Kurzschlüsse, Leitungsunterbrechungen, etc. diagnostizieren. Rein über Software. Später kam man auf die Idee damit auch Debuggen zu können, indem man Speicherinhalte, Prozessorregister usw. zu einer Steuersoftware auf dem PC übermittelt. Oder eben auch den Chip-Flash damit zu programmieren.

Wo ist nun der praktische Nutzen für unser FX-Projekt?

Für unser FX und dem externen Flash können wir JTAG einsetzen um die Pins an denen der Flash-Chip am Prozessor-Chip angeschlossen ist so anzusteuern wie wir das wollen, um Daten daraus zu lesen oder hineinzuschreiben. Gleichzeitig entkoppeln wir die CPU von diesen Pins um zu verhindern das uns das darin ablaufende Programm in die Quere kommt.

Ich werde also erstmal Informationen zum JTAG-Interface des OMAP5948 sammeln und hier veröffentlichen, sowie versuchen mit den mir zur Verfügung stehenden Mitteln eine JTAG-Kommunikation mit dem OMAP zu etablieren und and das daran angeschlossene Flash zu kommen, bzw. seine Daten auszulesen.

So, das nächste Rätsel ist geknackt - ich weiss nun wie man ein vollständiges Flash-Dump vom Mainboard über JTAG erstellt !

Das klingt trivial, ist es aber nicht. Mich hat es mehrere Tage (Wochen) gekostet dahinter zu kommen. Es gibt einen kleinen Trick und ich behaupte jetzt mal das ich bislang der einzige im Netz bin der den kennt
Jedenfalls habe ich wochenlang recherchiert, in Foren gepostet und mit anderen Radiobastlern Kontakt gehabt um hinter dieses Geheimnis zu kommen. Der Erfolg war gleich Null, niemand wusste wie das geht. Bestenfalls konnte man einzelne Sektoren auslesen, was den Codeknackern reicht, denn die zu Berechnung des Codes notwendige Information steckt in einem einzigen Sektor. Selbst für diese, eigentlich banale Info, erwarten so manche "hilfsbereite" im Internet eine Zahlung zwischen $100 und $500 !!

Also lüfte ich hier und jetzt mal ganz exklusiv das Geheimnis:

Wie oben bereits beschrieben ist das Flash mit dem OMAP-Prozessor verbunden. Innehalb dieses gibt es eine Unterstützung für den Boot von einem NOR/NAND Flash. Der Prozessor hat die JTAG-Schnittstelle über die man dieses Flash erreichen kann. Mit einem "Segger J-Link EDU" JTAG-Interface und der damit verfügbaren Software "J-Flash" kann man, mit den richtigen Einstellungen eine Verbindung zum JTAG-TAP des OMAP herstellen. Anschließend ermöglicht das Programm einen Lesezugriff auf einen bestimmten Bereich, einzelne ausgewählte Sektoren oder eben des gesamten Flashs.

Liest man einen einzelnen Sektor war alles gut. Jedoch hat der Flash des FX 256 Sektoren. Nach dem lesen muss man das Radio wieder stromlos machen, erneut starten, connecten und kann einen weiteren Sektor lesen. Macht man das so, bekommt man irgendwann(!) auch mal ein vollständiges Abbild vom Flash-Inhalt...

Versucht man mehrere Sektoren hintereinander einzulesen gab es nach einer nicht definierbaren Anzahl Sektoren (so zwischen 5-10) einen Lesefehler. Die JTAG-Verbindung wurde unterbrochen und das Radio hat sich abgeschaltet. Dann musste man einige Minuten warten bis sich die Kondensatoren entleert hatten und damit der Prozessor stromlos war und konnte erneut versuchen. Experimentell habe ich ermittelt das die Anzahl der lesbaren Sektoren davon abhing ob und welche Daten darin standen. Enthielt ein Sektor keine Daten (beim Flash ist dann der Bytewert einer jeden Zelle meist 0xFF) ging das lesen extrem schnell und es wurden deutlich mehr Sektoren übertragen. Der Grund war einfach die Übertragungsgeschwindigkeit, die bei gefüllten Sektoren langsamer war. Das kann eine Optimierung vom Flash-Reader (J-Flash) sein (kompression). Jedenfalls konnte ich ermitteln das zwischen Beginn und Ende eines Readouts max. so 10 Sekunden liegen dürften bis die Übertragung abgebrochen wird.

Das zu wissen ist wertvoll, hilft aber nicht, weil man vor dem auslesen nicht weiss was da an Daten kommt. Also forschte ich weiter. Mein erster Verdacht war ein Watchdog der die Übertragung killt. Unter einem Watchdog versteht man in der Elektronik ein meist in Hardware und oft auch ausserhalb einer CPU befindlichen Überwachungseinheit. Dies ist im Grunde nichts anderes wie ein rückwärts laufender Timer. Nach Ablauf einer voreingestellten Zeit löst dieser einen Reset oder Shutdown aus. Im Regelbetrieb enthält die auf der CPU laufende Software innerhalb ihrer Hauptarbeitsschleife eine Funktion welche den Timer immer zurückstellt, sodass er nicht ausgelöst wird. Stürzt nun die Software ab, wird auch der Timer nicht zurückgestellt In dem Fall führt der Watchdog einen RESET oder SHUTDOWN aus, je nachdem was der Systementwickler sich so ausgedacht hat. Bei Zügen kennt man das schon seit Jahrzehnten, dort nennt man diese Technik etwas zynisch "Totmannschaltung"...

Da ich von anderen Mikrocontrollern (µC's) weiß das diese eine Watchdog-Einheit integriert haben, suchte ich auch zunächst nach diesem im OMAP5948. Dieser ist vermutlich ein Nachfolger des OMAP5912 und Artverwandt mit dem OMAP-L137 bzw. OMAP-L138. Von den letzteren Modellen sind Datenblätter von TI frei verfügbar. Hier konnte ich ermitteln das es darin durchaus eine solche "Abschaltvorrichtung" (Haha, da isse wieder! gibt. Per Default ist dort ein Watchdogtimer beim anlegen der Betriebsspannung aktiv. Dieser resettet die ARM9 CPU nach 10 Minuten. Der Wert kann durchaus von der nach dem Bootvorgang darauf laufenden Software geändert werden. Alle meine Bemühungen diesen Timer zu deaktivieren sind bislang fehlgeschlagen.

Über genaue Boardanalyse und Messungen bin ich aber dann auf einen anderen Baustein gestoßen, dem Radioprozessor. Dies ist ein Motorola (heute Renessas) µPD70F3283. Dieser Chip ist auf Position (4) in diesem Mainboard-Bild zu finden. Der Chip gehört zur V850ES/SG2 Familie von Mikrocontrollern. Auf dem FX-Mainboard ist er für die Steuerung der Spannungsregler, des Tuners, des CAN-Busses, zahlreicher IO-Leitungen verantwortlich. Er arbeitet eher im Hintergrund. Die Schnittstelle zum Benutzer (HMI) bildet der OMAP. Hier läuft die gesamte Steuerung, die Menüs und auch der Navigationsrechner. Jedenfalls konnte ich ermitteln das der Radioprozessor die Reset/Shutdown Leitung des OMAP kontrolliert. Die Kommunikation mit diesem läuft vermutlich über einen SPI-Kanal. Kommt über diesen Kanal keine Kommunikation mehr (was in dem Moment der Fall ist, wo man via JTAG die CPU anhält um ungestört auf das Flash zuzugreifen), dauert es noch exakt 10 Sekunden bis dieser einen Shutdown auslöst. Nun hatte ich endlich die Quelle des Problems gefunden! Der Radioprozessor ist der Watchdog des gesamten Systems.

Mein nächster Versuch war nun diese Verbindung vom Radioprozessor stillzulegen um diesen Reset zu verhinden. Dabei fand ist eine Vorrichtung die es erlaubt den Radioprozessor zu stoppen. Das heißt alle Systeme starten, bis auf diesen Mikrocontroller. Damit kann er auch seine Watchdog-Funktion nicht erfüllen. Wenig überrascht hat es mich, das man diese Vorrichtung über den bereits oben enttarnten Serviceport aktivieren kann.

Nachdem ich das getan hatte startete ich einen erneuten Leseversuch und siehe da: Ich konnte ungestört das komplette Flash auslesen!
Im Endeffekt muss man nur eine Drahtbrückte zwischen diesem Signalpin und GND herstellen und schon wuppt das !

Ein wenig stolz und zufrieden bin ich danach vor den Fernseher und hab mir erstmal ein gutes Glas Wein gegönnt. Dieses Problem hat mich doch nun einige Woche Arbeit gekostet. Alle im Internet zu findenden Personen die das gleiche Problem hatten, sind daran gescheitert und haben es irgendwann aufgegeben...

Für mich geht es jetzt erst richtig los, denn als nächstes will ich herausfinden ob man den Flash auf die gleiche Weise auch beschreiben kann. Zum einen könnte man mit dieser Methode abgebrochene Updates wieder richten, zum anderen bringt es uns näher an unser Ziel dem Radio eigene Software unterzujublen, oder zumindest kleine Anpassungen vorzunehmen.

Es bleibt spannend!!

Zitat von Spike1985

Was interessant sein könnte, wäre die Video Sache.

Video im FX wird ein Traum bleiben. Auch wenn es technisch möglich ist, aber wie beim NX ist auch im FX dann in anderes Grafikboard verbaut. Eine Nachrüstung ist derzeit nir für das MCA möglich.

Ohja, das ganz sicher. Aber ich dachte Du meintest das mit dem Video aufs FX bezogen.
Ja, das wär in der Tat ein interessantes Feature dem MCA einen alternativen Video-On Schalter zu spendieren. Aber bis dahin ist es noch ein langer Weg...
Jetzt werde ich erstmal versuchen den Inhalt des Flash partiell zu ändern. Mal schaun was da rauskommt

Anstelle den Radioprozessor zu stoppen sehe ich noch eine Alternative: Der OMAP und der Radioprozessor "unterhalten" sich über eine serielle SPI-Leitung. Hierüber werden auch die "Heartbeat"-Signale für den Watchdog laufen. Wenn man diese kennt, könnte die Software welche für den Flashdump auf den OMAP geladen wird, auch diesen Heartbeat erzeugen.

Zumindest in der Theorie müsste das funktionieren. Praktisch muss man erstmal wissen welche "Bytes" für das Heartbeat verantwortlich sind. Ich habe die Leitung mal angezapft und mitgeschnitten und glaube zu wissen welche Sequenz das ist. Um es zu testen müsste ich den SPI-Bus bei gestopptem OMAP mal über einen Arduino oder so selbst beschicken und schauen ob das funzt.

Mit dieser Erkenntnis könnte ein findiger Programmierer dann evtl. die Flash-Dump Routine, die vom Segger J-Flash ins SRAM der CPU geladen und ausgeführt wird um die Flashdaten per JTAG zu liefern, um eine solche Sendefunktion erweitert werden.

Genau, es ist dieser Pin 13 auf dem zweiten Debug Header (unbestückt). Den /SEL auf GND und man ist im "Tuareg mode".

Seit ihr denn bezüglich des Pin Algorithmus fündig geworden?

Ich hatte mal Kontakt zu jemand der sich einen QEMU so konfiguriert hat, das er große Teile des Codes in einer Emulation ausführen konnte. Leider fehlt da die ganze Peripherie des Radios und somit geht es da irgendwann nicht weiter. Ein In-System Debugging mit Segger ist da schon erfolgversprechender.

Habt ihr einen Segger Plus zur Verfügung gehabt um das Mainboard Flash auch beschreiben zu können? In der Edu Version geht nämlich mit J-Flash nur lesen und für J-Link müsste man die ganze init Prozedur kennen...

Kenne das RNS nur von Bildern, scheint aber dem FX sehr ähnlich zu sein.

Cool!. Ich habe mir vor ein paar Wochen auch einen JLink aus China bestellt. Mal schauen ob das damit auch klappt wenn er da ist.

Problematisch ist noch det Zugang zum FGS Flash auf dem Graphicboard. Da gibt es zwar auch einen JTAG Port am Cyclone FPGA, aber da komm ich mit dem Segger nicht weiter. Connect geht, abet mit fehlen die Kommandos zum HALT der CPU um auf den Flash zuzugreifen.

Dein Deutsch ist ok und verständlich, auf jeden Fall besser als über Google Translator !

P.S. Habe Dir übers Forum eine persönliche Nachricht geschickt!

Dank der Hilfe von Ibro84 bin ich nun auch in der Lage mit dem Segger EDU und JFlash auch schreibend auf den Flash des Navigationssystems zuzugreifen. Ich kann den Flash löschen, oder nur einzelne Sektoren, sowie programmieren. Hier habe ich noch Probleme, weil das nur in kleinen Schrittchen funktioniert, aber dazu später mal mehr.

Nun habe ich mir mal so einige Dumps von FX, NX und MCAs gezogen und mir auch mal die Struktur und Inhalte der Update-CD angeschaut. Besonders interessiert mich derzeit das Bootstrapping des OMAP5948. Wie jeder Mikrocontroller hat auch dieser eine Einschaltsequenz die bestimmt wie der Chip hochfährt und seine Software lädt. Da es von dem leider kein Datenblatt gibt, kann ich nur mutmaßen wie das funktioniert und annehmen das es genauso, oder ähnlich abläuft wie bei den anderen Prozessoren der TI OMAP-Serie. Prozessoren haben alle einen Program-Counter (PC) welcher in einem Register gehalten wird. Dieser zeigt auf die Speicherstelle mit dem aktuell ausgeführten Befehl und wird nach jedem Befehl erhöht, bzw. kann durch (Sprung)befehle geändert werden. Nach dem Einschalten ist der Inhalt dieses Registers 0, also die allererste erreichbare Speicherstelle. Je nachdem ob so ein Chip ein internes Boot-ROM hat oder so eingestellt ist das er von einem externen Speicher bootet, beginnt er dann dort seine Ausführung.

Auf der Update-CD fürs MCA gibt es z.B. diese Struktur, wie sie auch in der Datei "content.txt" auf der CD selbst hinterlegt ist:

X:\DI_PROJECTS\TOOLS\DOWNLOADTOOLS\MAKEMASTERBIN\RESULTS\DOWNLOADMEDIA\CD_CMPL_WITH_BOOTLOAD
\---dnl
    |   content.txt
    |   
    +---bin
    |   +---nav
    |   |   +---common
    |   |   |       navfx001.uli
    |   |   |       
    |   |   \---ford_hsm
    |   |           navarreg.uli
    |   |           
    |   \---system
    |       \---arion
    |           \---ford_hsm
    |               |   backup.bat
    |               |   basereg.uli
    |               |   boot.bin
    |               |   bootload.bin
    |               |   ffsbat.ena
    |               |   ffsnand.bat
    |               |   fgs.dnl
    |               |   main_ver.bin
    |               |   main_vsn.bin
    |               |   navcrc.bat
    |               |   plattapp.uli
    |               |   plattreg.uli
    |               |   radio.dnl
    |               |   replace.btl
    |               |   sdsapp.uli
    |               |   sdsreg.uli
    |               |   system.elf
    |               |   unbackup.bat
    |               |   
    |               +---ffsbatch
    |               |       scrpt_01.bat
    |               |       scrpt_02.bat
    |               |       scrpt_06.bat
    |               |       scrpt_07.bat
    |               |       scrpt_20.bat
    |               |       
    |               \---ffsbatdata
    |                       scrpt_01.bat
    |                       scrpt_02.bat
    |                       scrpt_06.bat
    |                       scrpt_07.bat
    |                       scrpt_20.bat
    |                       
    \---ford_hsm
        \---ffs
            \---dia

Mein besonderes Interesse gilt dabei der Datei "boot.bin" bzw. "bootload.bin" Ein Vergleich im HEX-Editor zeigt das diese identisch sind. Die Datei hat eine Länge von 0x2284 Bytes. Und EXAKT diese Daten finde ich zum Beginn des Mainboard-Flash Speichers im ersten Sektor.

Zur Info: Der Flash-Chip arbeitet nicht wie ein RAM in dem ich den Inhalt bliebig ändern kann. Man muss einen Bereich (Sektor) erst löschen, also alle Bits auf "1" stellen und kann dann erst einen neuen Inhalt speichern indem die "0" Bits gesetzt werden. Ein solcher Sektor ist beim S29GL512N z.B. 128kb groß (0x20000).

Bei meinen Flash-Versuchen habe ich festgestellt das sich der erste Sektor des Flash weder löschen noch überschreiben lässt, er ist irgendwie Read-Only gesetzt. Ich bin also nicht in der Lage dem Navi irgendeine Änderung an diesem Bootloader im persistenten Flash zu hinterlegen.

Ebenso finde ich auch Inhalte der anderen Dateien der Update-CD an div. Stellen im Flash-Dump wieder. Leider kann ich den Dump hier nicht direkt zum Download hinterlegen, weil zu groß, daher über einen dieser üblen Sharingportale und somit nur 30 Tage abrufbar: https://ufile.io/76b8p

Meine Vermutung ist das dieser Bootloader entweder der "1st stage" bootloader ist, aber wenigstens der "2nd stage", da ich im OMAP ein Boot-ROM vermute. Die Aufgabe des Bootloaders ist es, einige grundlegende Initialisierungen durchzuführen und das Betriebssystem-Image zu laden und zur Ausführung zu bringen. Die Datei "system.elf" riecht förmlich nach sowas.

Bis dato gibt es weder ein Filesystem noch sonst irgendeine Hardware-Unterstützung, also echtes Low-Level. Er steuert auch sicher von welcher Quelle gebootet wird. Wie ich ja schon heraus bekommen hab, gibt es ja eine USB-Schnittstelle (die sogar am Quadlock anliegt, wenn auch mit "gestutzten" Pins) und ich könnte mir gut vorstellen das man zu Entwicklungs und Debugzwecken das Betriebssystem auch darüber von einem PC laden konnte/kann. Diese Funktion ist bei anderen OMAP-Prozessoren ebenfalls vorhanden. Sogar eine UART-Version gibt es davon.

Ich vermute ja immernoch das wenn das interne OS mal geladen ist, man darin auch sowas wie ein Linux-Artiges Filesystem vorfindet, welches aus Verzeichnissen, Dateien und ggf. sogar sowas wie einer Commandshell besteht.

Um hier weiter zu kommen muss man einfach ganz am Anfang beginnen, also beim Boot-Prozess und den muss man erstmal verstehen. Apropos "verstehen". Die Bytes die sich in diesem Bootloader befinden werden direkt als Befehle von der CPU ausgeführt. Es handelt sich also um Maschinencode. Die CPU im OMAP ist eine ARM9 und somit sollte es eigentlich möglich sein die Bytes wieder in Assembler, eine "lesbare" Vorstufe zum Maschinencode zurückzuwandeln, zu Disassemblieren. Dieser code wäre dann etwas(!) verständlicher als die einfachen Bytes und man könnte versuchen daraus schlau zu werden.

Weiterhin bestünde meiner Ansicht nach damit auch die Möglichkeit diesen Code in einer Emulation (z.B. QEMU) für ARM9 CPUs ablaufen zu lassen. Dabei könnte man dann im Einzelschritt genau erkennen was wann wie geschieht.

Soweit die Theorie

Bis das auf dem Bildschirm eine PIN-Eingabe oder ähnliches erscheint ist es aber von dort noch ein weiiiiter Weg. Hier hilf hoffentlich Kollege Zufall und vielleicht auch der ein oder andere ITler im Forum weiter...

Guter Gedanke Tycho und macht absolut Sinn, denn ohne Bootloader geht halt garnix mehr.

Ob der beim Start aber wirklich die Zeit hat Hashes zu bilden... hm, möglich ist alles. Da das Flash manchmal in die Binsen geht zeigen ja auch die zahlreichen Geräte mit Reboot-Loop Fehler

Also im Datenblatt des Spansion S29GL Flash findet man sowohl den zu erwartenden /WE pin (Write Enable) als auch die Möglichkeit den ersten und letzten, sowie aber auch beliebige Sektoren zu schützen. Der Schutz wird durch ein 64 Bit langes Kennwort erbracht. Da der erste Sektor defnitiv beim Update durch die CD überschrieben wird muss es also auch irgendwie per Software gehen.

Ich könnte mal versuchen den TP vom /WE zu finden und mittels Logicanalyzer seinen Pegel aufzeichnen, während ich ein Update laufen lasse. Richtig interessant wird natürlich irgendwann das verwendete Passwort. Aber vielleicht braucht es das auch garnicht und wird einfach zufällig generiert, nur um den Sektor zu schützen. Denn es gibt eine recht simple recoveryprozedur bei der aber das Flash nur komplett gelöscht und nicht ausgelesen werden kann, Dieser Zustand wäre ja ganz gut für ein bevorstehendes Update. Auf der anderen Seite glaube ich das beim Update nicht alles neu ins Flash kommt, dafür sind auf der CD einfach zuwenig Daten. Ich denke das es wirklich eher eine Art Patch ist. Also streichen wir die Full-Erase Theorie mal wieder..,