MAZDA-626-GE-Club Deutschland

von **Kampfkuchen** » Do 7. Mai 2026, 13:20

Der Hyperfokus kickte mal wieder und aus "Ich will mal was ausprobieren" wird ein etwas umfangreicheres Projekt, von dem ich mich gerade wenig ablassen kann

Nach ungefähr 15 Stunden Arbeit teile ich mal meine Ergebnisse

Mazda 626 GE V6 ECU Reverse Engineering

Gehäuse und Label - leider nicht vollständig sichtbar

Es geht um das reverse Engineering einer ECU "KL05D" - ich meine es müsste für einen KLDE sein, vermutlich Facelift? (Ich bin sicher Rx7 kann hier direkt Klarheit schaffen).
Ein Kollege erzählte mir von Ghidra, einem Reverse-Engineering Repo der NSA (ja, DER NationalSecurityAgency) mit der man unzählige Microcontroller-ROMs reverse engineeren kann. Und um das mal zu testen hab ich was gesucht, mit dem man das machen könnte. Dabei war das einzige was mir in den Sinn kam ein KL05D Steuergerät, das ich noch rumliegen hatte, weil MarS damals nichts damit anzufangen wusste.
Also war der logische Schritt:

Sichtung der Bauteile

PCBA Oberseite der Steuereinheit innerhalb des Steuergerätes

Zu sehen ist erstmal die MCU, die Beschriftung sagt was von DENSO, das ist erstmal sehr schlecht, da Denso überhaupt keine MCUs hergestellt hat - das spricht also hart für einen gelabelten Mikroprozessor. Mithilfe der Bezeichnung "SC402617FN" lässt sich aber doch etwas finden - HIER fand sich eine gute Basis für den Anfang.
"All I have figured out is that the chip number is SC402655CFN185 made by Motorola, and also made by Freescale as SC90078EFR2. From forums on miata.net there is an indication that this chip is based on the 68HC11 platform."
HC11 ist ein sehr guter Hinweis - laut einigen Quellen steht das "SC" für "SemiCustom" - was das bedeutet durfte ich noch herausfinden. Am ehesten passt also der "MC68HC711P2CFN4" Link zum Datenblatt
Für den HC11 gibt es auch ein Ghidra-Decoder-Repo - ultra nice. Link zum Repo

Somit steht dem Auslöten des EPROMs nichts sinnvolles mehr im Wege, gesagt getan und den Inhalt gedumpt. Link zum Dump

Bevor wir zum Schritt der Firmware-Analyse gehen sind aber noch viele Hardwareinformationen notwendig.
Dazu eine kurze Zwischeninformation wie so ein System arbeitet

Systemexkurs - Mikroprozessor
Es handelt sich bei der Architektur um eine der "Von Neumann Architektur". Das bedeutet erstmal grob, dass sich ROM, RAM, IOs, Timer, ADCs etc alle den gleichen Speicherbereich teilen, es gibt hier keine getrennten Speicher. Das heißt grob, dass es nur einen großen Adressbereich gibt, in dem wir alles finden. Das ist deutlich einfacher nachzuvollziehen.
Der Mikroprozessor hat einen 16-bit Adressbus und einen 8-Bit Datenbus. Im Prinzip wird mit dem Adressbus der jeweilige externe Baustein aktiviert und adressiert und dann über den Datenbus eingelesen. Die externen Komponenten teilen sich hier den Adress- und Datenbus.
Um es leichter verständlich zu machen: Das Programm sagt "Hole Daten aus der Adresse 0x2400", dann schaltet der Adressbus die Leitungen auf diese Adresse, in diesem Fall aktiviert sich der Timer-Baustein und gibt seine Daten auf dem Datenbus aus, die im Mikroprozessor eingelesen werden.

Daher ist es sehr wichtig zu wissen welcher Baustein mit welcher Adresse aktiviert wird um zu wissen in welcher Adresse welche Daten auffindbar sind, denn hierüber werden höchstwahrscheinlich die Einspritzventile, Zündung, Magnetventile u.s.w. angesteuert.

Weiter gehts...
Das System hier besteht aus einem externen ROM (EPROM, hier liegt das Programm, Konstanten, Lookup-Table, Kennwerte etc), einem externen RAM (Arbeitsspeicher), mindestens einem Input-Buffer, einem PIA (stellt quasi zwei externe 8-Bit GPIO-Ports zur verfügung, also 16 Ein/Ausgänge), einem programmierbarem Timer-Baustein (diesem kann man zeitkritische Aufgaben geben, der dann seine Ausgänge in bestimmten Konfigurationen schaltet).
Anhand der Adressleitungen konnte ich die einzelnen Adressbereiche identifizieren.

Dabei erstmal die einzelnen Komponenten identifizieren - hilft erstmal eine Übersicht zu schaffen was überhaupt realistisch an den Bussen hängt.

hier

Nun ist die Adresszuordnung wichtig für die Firmware. Das heißt, ich muss nachprüfen wo welche Adressleitungen hingehen um nachzuvollziehen unter welcher Adresse welcher IC erreichbar ist.

Habe ich "kurzerhand" alle Bauteile vom PCB entfernt und eingescant:

PCB Ober- und Unterseite der Steuereinheit innerhalb des Steuergerätes

Damit kann man dann wunderbar die Leitungen markieren und nachverfolgen, das ganze sieht dann so aus:

Reverse Engineering der Hardware im Prozess

Zuerst einmal: Leider passt zwar der Footprint und das Gehäuse im Datenblatt der vermuteten MCU perfekt auf die vorhandene, aber leider ist das Pinout komplett anders. Hier passt gar nichts. Das heißt aber nicht, dass es nicht so ist, sondern nur, dass Denso hier vermutlich ein anderes Pinout bestellt hat. Hauptsache proprietär, yay.

Daraus entstanden dann folgende Map-Erkenntnisse:

Damit haben wir schon eine ziemlich gute Memory-Map. Hier wird sich dann einiges im Code aufklären, was hier wohl plausibel ist u.s.w.
Für die GPIOs und Timer sollten noch die Signale ermittelt werden, dann kann man im Code direkt mappen was Einspritzdüsen, Zündung, Magnetventiile etc sind.
Schwierig sind leider interne GPIOs und der ADC, da das Pinout leider gar nicht zum Datenblatt passt und man nur weiß "Pin 55", aber nicht "PortA:1" - das muss man dann rätseln - wird aber sicherlich machbar sein. Wenn man im Pseudocode sowas sieht wie "Rev >= 4000 dann 0x2401:7 ==1", dann ist klar, dass das VRIS1 ist.

Analyse des ROMs

Der eigentlich spannende Teil kommt jetzt: Die Firmware-Analyse.
Mithilfe der bereits ermittelten Adressbereiche kann man also schonmal im Code relativ gut sehen welche Registerzugriffe wohl was sein könnten. Allerdings ist dieser Prozess schwer hier zu beschreiben, weshalb ich da eher nur bedingt drauf eingehen werde und eher den aktuellen Stand mitteile, so wie neue Erkenntnisse. Wenn der Stand interessiert, der kann sich gern im GitHub-Repo umschauen, da ist das Ghidra-Projekt enthalten, so wie alle anderen Erkenntnisse die ich so gesammelt habe.

Aktuellster Stand (07.05.2026)

Neben den bereits erwähnten Memory-Maps habe ich bisher folgende Funktionen gefunden:

Wozu eigentlich?

Zuerst war das nur reines Interesse ob es überhaupt machbar wäre, dann verselbstständigte sich das ganze und nun bin ich schon ziemlich weit. Darum kamen natürlich auch diverse Fragen auf, was der Kern des ganzen werden könnte.

Was kann man denn jetzt mit den Infos anfangen?: Eigentlich sehr simpel. Wir könnten die Firmware beliebig umprogrammieren, das Mapping anpassen, wann was passiert, VRIS dauerhaft an. Theoretisch ließe sich die ECU auch um weitere Eingänge erweitern, da noch viel frei ist. Aber das für mich interessanteste ist ein anderer Fakt:
Durch die Architektur mit dem externen Adress- und Datenbus eröffnet sich eine ganz interessante Möglichkeit: Das Mitlesen der Daten. Das Ziel dieses Projektes wäre ein Adapter, der statt des EPROMs gesteckt wird mit einem Mikrocontroller, der den Inhalt des ROMs hat und diesen emuliert, außerdem kann er alle Register mitlesen.
Das bedeutet:

Der Mikrocontroller kann dann eine Serielle-Schnittstelle bereitstellen an der ein Umsetzer für CAN- bzw K-Line hängt, also schlichtweg OBD. So wie einer USB oder Bluetooth-Schnittstelle um jederzeit die Daten auch per anderer Geräte wie Laptop o.ä. auszulesen. Ein externes Display mit Verbrauchs- und Temperaturdaten wäre auch simpel denkbar.

GitHub-Repo

Alle meine Erkenntnisse und gesammelten Daten werde ich in dieses Repository einpflegen. Das umfasst auch die Datenblätter, Bilder, Firmware, Ghidra-Projekt, Stromlaufpläne u.s.w.
https://github.com/Battlecake91/Mazda_626_ECU_ReverseEngineering/tree/master

von **Mazda RX-7 SA** » Do 7. Mai 2026, 22:14

Kampfkuchen hat geschrieben:Es geht um das reverse Engineering einer ECU "KL05D" - ich meine es müsste für einen KLDE sein, vermutlich Facelift? (Ich bin sicher Rx7 kann hier direkt Klarheit schaffen).

Leider nicht! Dieses Kürzel ist mir noch ned untergekommen. Denke, dass es eine im GE verbaute Variante ist die sich von jenen in den Xedos verbauten unterscheidet. GE V6 hab ich leider ned.

Aber spannend ist das allemal!

Allerdings frage ich mich:

Kampfkuchen hat geschrieben:Was kann man denn jetzt mit den Infos anfangen?: Eigentlich sehr simpel. Wir könnten die Firmware beliebig umprogrammieren, das Mapping anpassen, wann was passiert, VRIS dauerhaft an. Theoretisch ließe sich die ECU auch um weitere Eingänge erweitern, da noch viel frei ist. Aber das für mich interessanteste ist ein anderer Fakt:
Durch die Architektur mit dem externen Adress- und Datenbus eröffnet sich eine ganz interessante Möglichkeit: Das Mitlesen der Daten. Das Ziel dieses Projektes wäre ein Adapter, der statt des EPROMs gesteckt wird mit einem Mikrocontroller, der den Inhalt des ROMs hat und diesen emuliert, außerdem kann er alle Register mitlesen.
Das bedeutet:

Live-Daten
Live-Anpassung des Mappings
Live-Anpassung der Firmware

Der Mikrocontroller kann dann eine Serielle-Schnittstelle bereitstellen an der ein Umsetzer für CAN- bzw K-Line hängt, also schlichtweg OBD. So wie einer USB oder Bluetooth-Schnittstelle um jederzeit die Daten auch per anderer Geräte wie Laptop o.ä. auszulesen. Ein externes Display mit Verbrauchs- und Temperaturdaten wäre auch simpel denkbar.

Welche Vorteile siehst du bei der Lösung im Vergleich zu einem wirklich modernen frei-programmierbaren Steuergerät?
Ich kann verstehen, dass es reizvoll ist sowas zu versuchen, wenn man "aus der Branche ist" und sich damit auskennt. Kenn ich von mir auch....
Aber ich sehe da in der Lösung keine Vorteile, selbst wenn man den Aufwand bis zum Ziel nicht gewichtend einbezieht.

von **Kampfkuchen** » Do 7. Mai 2026, 22:25

Mazda RX-7 SA hat geschrieben:Leider nicht!

Schade

- Soweit ich mich erinnere stammt das Steuergerät aus einem 626 GE V6, aber ich kenne das Baujahr nicht. Ich werde mal MarS direkt fragen ob er sich erinnert.

Mazda RX-7 SA hat geschrieben:Welche Vorteile siehst du bei der Lösung im Vergleich zu einem wirklich modernen frei-programmierbaren Steuergerät?
Ich kann verstehen, dass es reizvoll ist sowas zu versuchen, wenn man "aus der Branche ist" und sich damit auskennt. Kenn ich von mir auch....
Aber ich sehe da in der Lösung keine Vorteile, selbst wenn man den Aufwand bis zum Ziel nicht gewichtend einbezieht.

Meiner Abschätzung nach wäre ein fertiges Design inkl. fertiger Bestückung aus JLCPCB(China) hier bei ~20-40€ pro Stück, wenn ich gleich 10 fertigen lasse. Von Eurocircuits (ziemlich Normgerecht, geht auch Automotive-Grade) schätzungsweise bei 80-100€/Stk je nach Menge.
Zumindest preislich könnte hier ein freiprogrammierbares Steuergerät nicht mithalten. Dann hast du den Vorteil, dass die Klopfsensorlogik bei den meisten freiprogrammierbaren nicht vorhanden ist oder extrem schwer umsetzbar (das ist halt überhaupt nicht trivial und es gibt keine universelle Lösung, jedes Motorenmodell muss für sich eine eigene Anpassung erfahren). Man hätte keine Verkabelungsschwierigkeiten.
Ich sag mal, wenn dann wäre der Plan wirklich -> EPROM raus, Platine drauf -> Fertig.

Ansonsten, ganz ehrlich, ich weiß nicht ob ich das überhaupt soweit bringe. Es ist erstmal einfach pures Interesse und ist derzeit ein Selbstläufer, weil es einfach Spaß macht das Rätsel zu lösen :mrgreen:

Und wenn man am Ende was sinnvolles dabei rausziehen kann, umso besser. Aber in erster Linie: Ich wollte wissen ob's geht.

In Zukunft ist das vermutlich sogar noch wichtiger als jetzt, je nach Teileverfügbarkeit könnte man so auch auf alternative Teile umswitchen und programmiert dann einfach ein paar Parameter um und passt das Steuergerät darauf an. Ich hatte auch darüber nachgedacht ob Breitband-Lambdas eine sinnvolle Option wären.

Aber wie gesagt... Erstmal einfach, weil's bockt.

von **Mazda RX-7 SA** » Do 7. Mai 2026, 22:53

Kampfkuchen hat geschrieben:Aber wie gesagt... Erstmal einfach, weil's bockt.

Ja, das verstehe ich schon.

Kampfkuchen hat geschrieben:Meiner Abschätzung nach wäre ein fertiges Design inkl. fertiger Bestückung aus JLCPCB(China) hier bei ~20-40€ pro Stück, wenn ich gleich 10 fertigen lasse. Von Eurocircuits (ziemlich Normgerecht, geht auch Automotive-Grade) schätzungsweise bei 80-100€/Stk je nach Menge.
Zumindest preislich könnte hier ein freiprogrammierbares Steuergerät nicht mithalten.

In der Theorie.
Wie schaut die Praxis in dem Fall aus? Gibts da dann eine Software dazu, um die Abstimmung von einem Abstimmungs-Profi machen zu lassen der keine Ahnung von Mikro-Kontrollern hat? Halte ich für den wichtigsten Aspekt.

Kampfkuchen hat geschrieben:Dann hast du den Vorteil, dass die Klopfsensorlogik bei den meisten freiprogrammierbaren nicht vorhanden ist oder extrem schwer umsetzbar (das ist halt überhaupt nicht trivial und es gibt keine universelle Lösung, jedes Motorenmodell muss für sich eine eigene Anpassung erfahren).

Ja, das ist komplex. Wenn man aber die Abstimmung auf einen bestimmten Sprit machen lässt und davon nicht abweicht kann man darauf auch gut verzichten. Vorallem beim KL als Sauger.

Kampfkuchen hat geschrieben:Man hätte keine Verkabelungsschwierigkeiten.

Das wiederum hängt ab von der Betrachtungsweise bzw. der eigenen Prioritäten. Ich zb mache lieber eine einmalige Anpassung der Verkabelung, wenn ich dann die Vorteile eines modernen frei-programmierbaren Steuergeräts nutzen kann.

von **Kampfkuchen** » Do 7. Mai 2026, 23:54

Mazda RX-7 SA hat geschrieben:In der Theorie.
Wie schaut die Praxis in dem Fall aus? Gibts da dann eine Software dazu, um die Abstimmung von einem Abstimmungs-Profi machen zu lassen der keine Ahnung von Mikro-Kontrollern hat? Halte ich für den wichtigsten Aspekt.

Hardwarekosten sind in dem Fall aus Erfahrungswerten konservativ (also eher nach oben) geschätzt. Da ich keine Gewinnabsichten hege, wären hier natürlich keine Marge oder ähnliches drin, reiner Materialpreis.
Was das Abstimmen beim Profi angeht, ja da habe ich absolut keine Erfahrungen. Kann ich nicht beantworten ob da jemand wäre, der was selbstgeschriebenes nutzen wollen würde. Mein Plan wäre, sollte ich wirklich soweit gehen da einen Adapter zu haben, durchaus eine Software zu haben, mit der man die Map anpassen kann. Ob sich dann ein Abstimmer drauf einlässt, kann ich nicht sagen. Das Ziel wäre aber durchaus etwas in Anlehnung an existierende Mapping-Software.

Mazda RX-7 SA hat geschrieben:Das wiederum hängt ab von der Betrachtungsweise bzw. der eigenen Prioritäten. Ich zb mache lieber eine einmalige Anpassung der Verkabelung, wenn ich dann die Vorteile eines modernen frei-programmierbaren Steuergeräts nutzen kann.

Ehrlich gesagt sehe ich das Anpassen der Kennlinien erstmal gar nicht so als Scope - sondern in erster Linie Live-Daten inkl. Fehlerspeicher.

Ich bin aktuell soweit, dass scheinbar auch ein Status-Register für Misfire-Detection existiert.

MAZDA-626-GE-Club Deutschland

Motorsteuergerät - KL05 - Reverse Engineering

Motorsteuergerät - KL05 - Reverse Engineering

Re: Motorsteuergerät - KL05 - Reverse Engineering

Re: Motorsteuergerät - KL05 - Reverse Engineering

Re: Motorsteuergerät - KL05 - Reverse Engineering

Re: Motorsteuergerät - KL05 - Reverse Engineering

Wer ist online?