Suche Keeloq Hersteller Key im Flash S08DZ96

#7945678
Lesenswert?

Hallo Experten,

Einleitung: es gab mal die Firmen Lucas und Rover in England, die ihre Autos mit einer gesetzlich vorgeschriebenen Wegfahrsperre ausgerüstet haben. In den Empfängern wurden als Prozessoren MC68HC05B16 mit einem OneTimeProgrammable ROM verwendet, das gegen Auslesen geschützt ist.

Problem ist, das die 433MHz Handsender zu dem System inzwischen nicht mehr verfügbar sind und ich die Nachbauen muss/will.

Zur Kommunikation wird ein rolling Code KeeLoq Protoll verwendet, von dem ich den Hersteller Key natürlich nicht kenne. Den brauch ich aber, damit die Handsender vom Empfänger akzeptiert werden.

Jetzt bin ich offensichtlich nicht der erste mit dem Problem, sondern die Fa Rover musste sich was überlegen, als die Fa Motorola die Produktion des Prozessors eingestellt hatte. Also habe sie offensichtlich alle Konstruktionsdaten an irgend eine Fa gegeben, die die Empfänger mit einem moderneren Prozessor nachgebaut haben.

Die Wahl fiel damals auf einen Freescale S9S08DZ96

Glücklicherweise ist der NICHT gegen Auslesen gesperrt und ich habe sowohl Flash als auch Eeprom. Im Eeprom steht unter anderem auch der jeweilige 4 Byte Code für einen zugeordneten Handsender.

Frage: ich bin nicht der Held im Disassemblieren und alle meine Versuche hier mit Ghidra oder anderen Programmen was zu erkennen waren bislang erfolglos. Irgendwo im Flash muss der Keeloq Hersteller Key stehen, aber wie finde ich den?

Hat jemand eine Idee für mich, wie/wo ich das finden kann?

VG Ralf

Angehängte Dateien:
: Bearbeitet durch User
#7945693
Lesenswert?

...nun, ich denke die werden da nichts gegen haben.

Bei der Produktion der Empfänger hat der Designer/Programmierer vergessen die Brown-Out Funktion zu deaktivieren. Das führt dazu, das irgend eine Routine aufgerufen wird, wenn das Fahrzeug mal Unterspannung bekommt, und dann fleissig Teile des Speichers löscht.

Für dich als Besitzer heisst das, das sich dein Automobil gerade in einen Briefbeschwerer verwandelt hat.

Ich helfe den Leuten und auch dem Fahrzeughersteller seit mehr als 10 Jahren solche Fälle zu retten. Aber jetzt sind eben auch langsam meine Ersatzteilvorräte aufgebraucht. Der Hersteller hat schon seit vielen Jahren keine mehr.

#7946051
Lesenswert?

Harald K. schrieb:

Wenn er die so gewonnenen Erkenntnisse gewerblich ausnutzen möchte, könnte das sein.

Ralf G. schrieb:

Ich helfe den Leuten und auch dem Fahrzeughersteller seit mehr als 10 Jahren solche Fälle zu retten. Aber jetzt sind eben auch langsam meine Ersatzteilvorräte aufgebraucht.

Noch Fragen? Für mich ist das gewerbliche Nutzung. Und die Hersteller und Versicherungen sind im Umfeld der Wegfahrsperre / Zugangssicherung absolut humorlos. Aber das mag jeder für sich selbst entscheiden.

#7946134
Lesenswert?

...ist das hier ein Forum für Rechtsberatung geworden? :-) Ich bin mir der Grauzone durchaus bewusst. Danke dafür.

Wenn mich da draussen Leute sehnlichst um Hilfe bitten, und ich helfen kann und dabei niemanden schädige, dann versuch ich mein Bestes.

Hier stosse ich aber leider an die Grenzen meiner Fähigkeiten, was die Rekonstruktion des Codes angeht. Ich hab auch schon x Zyklen der gesendeten Codes mit einem RTL2832 aufgezeichnet, NRZ decodiert und Kaiju damit gefüttert - aber leider auch bislang ohne Erfolg.

#7951734
Lesenswert?

Ein paar Informationen zu dem Funkprotokoll des Schlüssels:

Signal Sender: 433 MHz bzw. 315 MHz, OOK moduliert, Differentieller Manchester-Code (Biphase–Mark) mit 512 bit/s. Insgesamt 55 Bits unmittelbar nach Tastendruck, dann Wiederholung der ersten 15 Bits alle 39 ms bis die Taste losgelassen wird.

Beispiel (MSB zuerst, das fehlende LSB des letzten Bytes ist 0):

1
        6B 04 04 10 22 7F CF 
2
        6B 04
3
 39 ms  6B 04
4
 39 ms  ...

Beispiel für mehrmals senden (ohne die 15 Bits Wiederholung):

1
 Fahrzeug Öffnen
2

3
 6B   04 04 10 22   7F CF 
4
 6C   04 04 1B 22   B7 13 
5
 6D   04 04 13 22   B4 F7 
6
 6E   04 04 1C 22   28 FE 
7
 6F   04 04 1C 22   5E 5C
8

9
 Fahrzeug schließen
10

11
 70   08 08 19 22   ED 43 
12
 71   08 08 18 22   53 24 
13
 72   08 08 1A 22   2E FF 
14
 73   08 08 10 22   28 A1 
15
 74   08 08 1B 22   8C D4

Zur Bedeutung der Bytes:

1
 Byte 0:     "Sequence Counter" (0x00...0xFF)
2

3
 Byte 1...4: High Nibble: für "Rolling Code Time" (Bit 17...Bit 2)
4
 Byte 4:     Bit 1...0  : für "Rolling Code Time" (Bit 1...Bit 0)
5
             "Rolling Code Time" im Beispiel 0x4A. Die "Rolling
6
             Code Time" wird ca. alle sechs Sekunden hochgezählt.
7

8
 Byte 4:     Bit 3...2: Bedeutung unbekannt (vielleicht 
9
             Batteriestatus ?)
10

11
 Byte 1...2: Low Nibble für die Taste (4: Öffnen, 8: Schließen,
12
             2: Bedeutung unbekannt, alles andere vermutlich nicht
13
             verwendet)
14

15
 Byte 3:     Low Nibble: für "Sender ID" (32 Bits) Bits 0..2 des
16
             "Sequence Counter" bestimmen welches 4 Bits es sind
17
             "Sender ID" im Beispiel: 0xCC 0x3B 0x0A 0x89
18

19
 Byte 5...6: Prüfbits (15 Bits) zur Prüfung der gesendeten Daten

Noch mal kurz zur "Rolling Code Time": das ist tatsächlich eine Zeit, der ASIC/Custom Chip im Schlüssel wird dauerhaft von der Batterie versorgt und der 32.768 kHz Quarz schwingt auch wenn keine Taste gedrückt wird. Die Zeit im Beispiel ist so klein weil der Schlüssel erst kurz vor dem Mitschnitt mit Spannung versorgt wurde.

Die Berechnung der Prüfbits (15 Bits) erfolgt durch einen selbst gebastelten Algorithmus. Für die Berechnung werden Daten verwendet, die beim Anlernen eines Funkschlüssels ermittelt werden, sowie von den gesendeten Daten lediglich der "Sequence Counter" (8 Bits). Es werden die Prüfbits für alle angelernten Schlüssel (maximal 4) ermittelt, anhand der passenden Prüfbits weiß man dann welcher Schlüssel gesendet hat. Anhand der "Rolling Code Time" wird geprüft ob der Funkschlüssel synchron zur dazugehörigen Zeit im Fahrzeug ist (mit einer gewissen Toleranz) und nur dann eine Aktion ausgeführt.

Beim Anlernen eines Funkschlüssels muss 8 mal gesendet werden, daraus wird die "Sender ID" bestimmt. Aus der "Sender ID" werden mit einem selbst gebastelten Algorithmus 64 Bytes berechnet und im EEPROM des Mikrocontrollers abgespeichert, diese Daten werden für die Berechnung der Prüfbits des jeweiligen Schlüssels verwendet.

Anhand der Beschreibung sollte klar sein wie schlecht und unsicher das Ganze gemacht ist, auch mit selbst gebastelten Algorithmen könnte man es deutlich besser machen.

Wer sich für die Algorithmen interessiert findet sie in der Firmware. Kleiner Tipp: Es gibt eine Funktion für beide Algorithmen (Berechnen der Daten beim Anlernen und Prüfbits berechnen), diese Funktion muss mehrfach aufgerufen werden bis die jeweilige Berechnung fertig ist. Dadurch wird erreicht dass einzelne Aufgaben ("Tasks") nicht zu lange brauchen, dafür muss man dann aber die "Tasks" entsprechend aufbauen dass sie aus einzelnen Teilen bestehen, die nicht zu viel Rechenzeit verbrauchen.

#8069240
Lesenswert?

Beeindruckende Arbeit! Nicht schlecht.

Ich hatte zu lange zu viel andere Arbeit, aber hab mich der Sache noch mal angenommen. (und mich derweil etwas in Ghidra eingearbeitet) Alle deine Annahmen sind korrekt. Ich hab das nachvollzogen und hab inzwischen einen Prototyp der 100% erfolgreich auf nem ATMega8 mit nem 433MHz Sender läuft. (Hab's mit nem Tiny13A versucht, aber dem war's zu viel)

Einzige Zusatzinfo: auch die Annahme das in Byte 4 Bit2/3 die Batterieinfo ist, ist korrekt. Ich muss noch raus suchen, welches Bit es ist.

Nächster Step: das ganze klein bekommen une nen Tiny1624 nehmen. Der läuft auch mit Uhrenquarz, was dem Timing des Programms sehr zu Gute kommt.

Vielen Dank für deine Hilfe (wieder ein mal)

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren