Danke für die Zusammenfassung, Jay1980. Jay1980 und ich tüfteln seit dem Frühjahr zusammen daran, das ASR dauerhaft deaktivieren zu können, oder alternativ den RS-Sportmodus auf einen Standard-ABS-Block bringen zu können.
@Marianpol
Es ist bekannt, dass der Algorithmus in einer DLL von CLIP steckt, aber bisher konnten wir da nicht weiter nachforschen. Ich habe in der Zwischenzeit durch Manipulation der Versionsdaten im EEPROM und Anpassung von Datenbankdateien im CLIP es geschafft, verschiedene Firmwares auf einen GT220 Block (47660 2272R) auf dem Schreibtisch zu flashen. Es ist in den Datenbankdateien einsehbar, dass es verschiedene Hardwareversionen gibt. Beim Flash einer kompatiblen Firmware gibt es keine Probleme, allerdings habe ich auch versucht, eine 2 KB Firmware von einem TCE180 zu flashen, da wir vermuten, dass diese "näher" am RS liegt und weitere Änderungen erlaubt. Dabei landete der ABS-Block aber dauerhaft im Bootloader im Fehlermodus (dies ließ sich durch Reprog auf eine kompatible Firmware beheben). Das Platinenlayout zwischen einem 2272R Block (GT220) und einem 0043R Block (RS) unterscheidet sich nicht (zumindest auf der Oberseite, wo sich die MCU und der EEPROM befinden), nur der EEPROM ist anders (2 KB vs. 4 KB). Der Gedanke ist daher, den 4 KB EEPROM im 2272R Block gegen einen 2 KB EEPROM zu tauschen, und die TCE180-Firmware noch einmal zu flashen. Leider ist das alles mangels verfügbarer Zeit nicht so schnell machbar. Eine Möglichkeit, die Firmwaredateien zu decrypten, würde es ermöglichen, die Unterschiede zwischen den Firmwares genauer zu analysieren.
Allerdings besteht diese aus rohen CAN/UDS-Befehlen an den ABS-Block, um die entsprechenden Bytes in den Flash und den EEPROM zu schreiben. Hast du einen Parser, der hieraus einen (teilweisen) Flash-Dump und erstellen kann?
Auf dem Schreibtisch schreiben wir die EEPROMs mit einem Hardwareprogrammer. Das ist sehr bequem und geht ganz schnell. Falls du den Seed/Key-Algorithmus für den Flash via CAN-Bus kennst, würde es das erleichtern, Testläufe im Auto zu machen. Der Flash via Renolink dauert nämlich 45 Minuten für 4 KB. Das lässt sich schneller implementieren, denn laut Analyse der CAN-Kommunikation geschieht beim EEPROM write via Renolink unnötigerweise vorher ein vollständiger Read, der leider über eine Methode umgesetzt wurde, die an sich bereits sehr langsam ist.
Gruß
Miki4
EDIT:
Marianpol war schneller mit seiner Nachricht.
Das hört sich sehr interessant an. Ich habe auch schon durch die Flash-Experimente herausgefunden, dass der modellindividuelle Kalibrationsbereich im 4 KB EEPROM bei 0x359 beginnt und am Ende mit der Versionsnummer und Checksumme abschließt. Dieser gesamte Bereich ist bei 4 KB Firmwares durch die Checksumme gesichert. Interessant ist, dass es zwei Firmwares gibt, die exakt den gleichen Kalibrationsbereich haben, nur die Versionsnummer am Ende, die noch zum Kalibrationsbereich gehört, ist anders. Das bedeutet, dass die Checksumme am Ende auch anders ist. Das könnte helfen, die Checksummenalgorithmus zu knacken. Das ist uns bisher nicht gelungen, wäre aber extrem hilfreich. Da du offenbar Erfahrung mit IDA hast, könntest du vielleicht auf diesem Weg an den Checksummenalgorithmus kommen? Wenn wir diese berechnen können, ist es sehr wahrscheinlich, die ASR Schwelle bei diesen Blöcken deaktivieren bzw. auf 255 km/h setzen zu können.
Wir haben beide auch untersucht, bei welcher Geschwindigkeit sich das ABS reaktiviert. Im Tacho steht dabei 43 km/h. Das ABS sagt via Diagnose allerdings 40 km/h. Wir führen das auf die Abweichung des Tachos zurück. Der dazu passende Hex-Wert 0x28 liefert im Kalibrationsbereich einige Treffer, wovon sich einige in verschiedenen EEPROM-Dumps decken. Wir vermuten, dass einer davon für die ASR-Schwelle zuständig ist.
Welche RS-Firmware genau hast du gefunden? Wir konnten keine finden. Es gab zwei oder drei heiße Spuren in den CLIP/Reprog Datenbanken, allerdings haben diese sich als falsch herausgestellt. Falls du eine echte RS-Firmware hast, wäre das ebenso ein Schritt in Richtung RS-Sportmodus auf normalen ABS-Blöcken. In dieser Hinsicht hatte ich ursprünglich angedacht, den Flash des RS-Blocks auszulesen. Ein paar Versuche mittels entsprechenden UDS-Befehlen schlug fehl. Ich hatte es im Bootloader-Modus nach dem gescheiterten 2-KB-Firmwareflash versucht, da ich gehofft hatte, dass im Bootloader hierfür kein Seed-Key-Verfahren mehr durchgeführt wird. Aktuell liegt auf meinem Schreibtisch ein XPROG, mit dem ich versuchen möchte, an den Flash des RS-Blocks zu kommen. Dazu komme ich wahrscheinlich Ende Januar / Anfang Februar. Aber das ist auch noch alles Tappen im Dunkeln, da es keinerlei Pinouts für diese Custom-MCU gibt.
Ich habe auch diverse EEPROM-Dumps von originalen Blöcken und von den Flash-Experimenten. Sobald ich zu Hause bin, stelle ich diese gerne zur Verfügung.
Was genau meinst du mit "[...]
und mit dem Speicherinhalt des Controllers vergleichen."?
Hast du das disassemblen und decompilieren mal mit Ghidra versucht? Dieses soll den Motorola-Befehlssatz unterstützen. Ich hatte das Reprog-File vor längerer Zeit mal in Ghidra geladen, sah vielversprechend aus. Allerdings natürlich nur bruchstückhaft, da das Reprog-File ja kein richtiger Flash-Dump ist.
Falls es Schwierigkeiten mit der Übersetzung gibt, ich kann auch polnisch.
Vielleicht sollten wir die Konversation bzgl. des Sportmodus in den von mir dafür erstellten Thread verschieben:
Megane 3 - [Recherche] Nachrüstung des ESP-Sportmodus Ich habe die Verschiebung der entsprechenden Beiträge aus diesem Thread bei der Moderation angefragt.
Anbei das Layout vom 2272R (GT220 und andere) und 0043R (RS) Block. Außerdem eine Sammlung von EEPROM-Dumps für Analyse- und Vergleichszwecke. Diese sind von ABS-Blöcken hauptsächlich aus Megane 3, u.a. von meinem Wagen und von Jay, aber auch vom Scenic 3, Laguna3 und Mercedes aus diversen Quellen im Internet und von meinen Flash-Experimenten auf dem Schreibtisch. Ebenso ABS-only Module. Dies unter folgendem Link: *entfernt*
EDIT2: Downloadlink entfernt auf Wunsch der Moderation.
