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
:
Bearbeitet durch User
Man findet in den Daten unter anderem "Copyright 1998, Visteon Corp". Sind die mit deinem Vorgehen einverstanden? Das könnte teuer werden. In Fernost oder Osteuropa findest du Firmen, die solche Jobs übernehmen.
...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.
Georg G. schrieb: > Sind die mit deinem Vorgehen einverstanden? Das könnte teuer werden. Wenn er die so gewonnenen Erkenntnisse gewerblich ausnutzen möchte, könnte das sein. Wenn er aber nur für seine alte Karre einen neuen Schlüssel haben will, sehe ich ... FUD.
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.
Georg G. schrieb: > Aber das mag jeder für sich selbst entscheiden. Das kann vor allem Ralf für sich selbst entscheiden.
...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.
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.
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.