Tags: électronique crypto voiture
Après un problème de non démarrage sur ma camionnette (Jumper 2), qui semble venir de l'anti démarrage, je me suis mis en tête de comprendre comment les choses électronique marchent dans mon véhicule. Je ne voyais pas pourquoi payer cher chez un concessionnaire pour juste brancher leurs outils tout fait... Puis, je bidouille de l'informatique/électronique tous les jours, pourquoi je pourrais pas comprendre et réparer moi même ? Une histoire de sécurité ? En voyant la suite, on comprend que c'est une vaste blague.
Je n'avais pas la "valise" pour ce véhicule, je l'ai commandé (la version "full chip", vu qu'il faut passer parle K-line dans mon cas, et pas le CAN comme pour les voitures plus récentes), et en attendant qu'elle arrive, j'ai quand même regardé quoi faire.
Je me disais que le code PIN du véhicule (que je n'avais pas), nécessaire pour ré-associer des nouvelles clefs et pour le démarrage de secours, était sans doute dans une eeprom/flash dans l'ordinateur de bord.
Bon, théoriquement il m'était aussi possible de passer chez Citroen pour récupérer ce code PIN (chose que j'ai faite un peu après). Mais je trouve plus simple de démonter mon ECU que de passer chez un concessionnaire.
Spoiler: Ce code pin se trouve bien sur l'eeprom de l'ECU, et du immobox. Sur le net, des "sachant" semblent dire que pour mon modèle, c'est pas possible de retrouver le pin (eeprom/flash) de l'ECU. Bon, en fait je verrai plus tard que si, et c'est très facile. Aussi, le pin est en clair dans l'eeprom de l'immobox.
Donc j'ai récupéré/ouvert le ECU (engine control unit). C'est écrit dessus: "BOSCH, 0281010932, 1336824080, D2841AWFS" et j'ai fait des recherches internet là dessus. On tombe essentiellement sur des "forum" de bidouilleurs de BSI (pour boitier de servitude intelligent) / ECU (ou alors sur des revendeurs de pièces détachées), et souvent le calculateur est dit un "EDC15C7".
On tombe toujours sur les mêmes termes "immo off", "boot mode", "pin decoder"... beaucoup de termes, toujours les mêmes, jamais vraiment expliqués, donc on imagine qu'il y a un monde parallèle.
Ce genre de problème de démarrage semble courant, et ce qui semble fait, c'est de neutraliser tout le système d'immobilisation du véhicule ("immo off"). Il y a des outils "boites noires" et des softs souvent chers, j'imagine à destination de garagistes. Les forums semblent aussi plein de garagistes, ou de gens qui bidouillent plein de voitures. Aussi, ces forums sont aussi plein de gens qui veulent bidouiller le calculateur pour avoir plus de puissance...
À vrai dire, il y a beaucoup de "bruit", et souvent les gens ne savent pas exactement ce qu'ils font. Leur but c'est juste de redémarrer/réparer une voiture, et pas de faire joujou avec de l'electro-informatique et de comprendre comment ça marche. Souvent, il semble qu'ils utilisent des techniques valables sur un ECU sur un autre, avec des fois des succès, et sinon, bein c'est pas grave, on essaye une autre bidouille. Souvent des gens changent des bytes au hasard dans les eeprom ("remplace tous les 0x42 par des 0xFF"...). Des fois cela change les caracteristiques du moteur, cela allume des voyants qu'il faudrait pas, mais bon, pas grave tant que ca démarre.
Sur les forums, il faut généralement être inscrit/validé pour pouvoir avoir accès aux fichiers partagés (souvent sur des trucs genre "Mega", quand ils ne sont pas déjà supprimés), fichiers qui sont souvent soit protégés par mot de passe qu'il faut mendier/payer, pour des logiciels fonctionnant sous windows, souvent protégés par un fichier licence ou dongle, et qui faut payer des centaines d'euros. Puis souvent ils marchent avec des dispositifs de programmation qu'il faut acheter à côté (MPPS, galileo, kess, Pango...), et qui peuvent être très chers.
On comprend quand même un moment qu'il semble quand même y avoir des "sources" du "savoir", qui ont fait les choses bien en regardant l'électronique des ECU (mais qui vendent des solutions toutes faites plutôt que de documenter pour tout le monde). Le reste semble beaucoup être des copier-coller de copier-coller, de bidouilles, de repost de repost...
Demander des trucs sur ces forums, c'est chiant, on a l'impression de se faire voir de haut par des gens qui utilisent des termes qu'il ne comprennent même pas. Et surtout, faut les aduler pour le peu de savoir qu'il ont. L'"open source" et le partage de savoir, j'imagine que c'est une insulte pour eux.
Donc, c'est une comunauté de garagistes avec "formation" electronique, qui font ca pour en vivre de façon plus ou moins légale. Pour bricoler sa propre voiture, c'est pas une solution.
Je trouve dommage qu'il y ait si peu d'info "ouvertes" sur cela. Il y a quelques rares initiatives (comme http://opengarages.org/handbook/ par exemple), mais rien qui peut m'aider.
On peut trouver cela "normal", se dire que des gens en "vivent". Mais expliquer les choses ne va pas tuer le buisness. Tout le monde comprend comment marche un moteur, pourtant on va quand même chez le garagiste en cas de problème. Les manips, même en electronique, restent compliquées et risquées. Le matos utilisé par eux est cher, mais c'est justement car rien n'est ouvert. En informatique "normale", les gens ne gardent les solutions pour eux, et il y a quand même un gros marché de "réparation". On peut aussi croire que qu'expliquer les choses rendraient les vols de voiture plus facile. Or, c'est tout le contraire qui se passe.
Donc, j'ai voulu comprendre les bases, et faire des choses "solides". Et de documenter ici "for the record" et en demarche d'ouverture.
Bon, je préviens tout de suite, c'est pas fait "pour réparer le plus rapidement possible si vous avez le même problème", c'est fait pour comprendre. Et aussi, si vous avez le même problème et que vous vous voulez juste "que cela remarche", et vous pigez pas les 3/4 de ce que je raconte, passez par un garagiste. Par contre, si vous vous reconnaissez dans la démarche d'ouverture et de partage des connaissances, je serais heureux de discuter de cela.
Donc on regarde l'électronique. Chez moi, j'ai un ECU qui contrôle l'injection et d'autres trucs du moteur, mais qui se "bloque" si le boitier d'immobilisation n'est pas content.
On regarde ce qu'il y a dans le ECU. Chez moi, un proc Infineon 16 bits "automotive", qui semble être d'une famille souvent utilisée pour les ECU.
On arrive après quelques recherches à trouver de quel processeur il s'agit vraiment (le marquage ne le dit pas tout de suite, car c'est un marquage pour bosch) : un SAK-C167CR-4RM, et le datasheet est dispo. Ah, enfin du concret.
Autour du proc, deux IC dont tout le monde parle sur les forums: une flash AMD... et une eeprom de 1KB que tout le monde appelle par ce qu'il y a écrit dessus: 5P08 (ou 5P08C3), mais avec le vrai nom ST95P08, c'est plus clair. Là aussi, les datasheet sont dispo.
Mais il y a d'autres puces. Autant regarder tout de suite. Beaucoup semblent être juste des truc "remarqués" pour bosch, ce qui complique un peu la chose.
Sur un coté, que des "sop8" : l'eeprom déjà mentionnée, 2x IR2015S (mosfet driver?), B57498 (=? LM2904 / dual opamp), B57554 (=? LM2903 / Dual Comparators), ST 431AIA (=? TS431 is a low-voltage, three-terminal, adjustable shunt voltage reference), et un "3029042 2342492" que je n'ai pas trouvé.
De l'autre coté (en plus du CPU et de la flash): trois trucs "bosch": un 30402 (qui est peut être un BOSCH ECU Board Drive IC Auto Engine Power Driver IC), un "30344", un "30421" (ces deux là, j'ai rien trouvé dessus), et une dernière puce NEC assez étrange: NEC UPD790008GF(A1)-3BA. Je trouve dans un premier temps rien d'intéressant sur cette puce (à part des gens qui en revendent). le uPD suggère un MCU, dans la lignée des uPD 78. Il y a une étiquette collée dessus avec écrit 3 lignes : "110131 301930 010932" (la dernière ligne est comme le "0 281 010 932" du ECU...). Quelques photos sur le net de ECU ont aussi une telle étiquette avec 3 lignes, sur la même puce. J'ai vu quelqu'un émettre l'hypothèse que c'est une "puce de sécurité" (ce qui correspondrait à l'étiquette). Spoiler: cette puce est toujours un mystère pour moi, car j'ai trouvé toute la "crypto" que je cherchais dans le code flash externe.
Dans l'eeprom (voir après dump mémoires), on remarque assez rapidement un code 32 bits, le même qui sera dans l'immobox, et répété 3 fois de suite (chez moi à partir de la position 0x182). Une fois changé, la voiture ne veut plus de mon PIN pour ke démarrage de secours. Le code pin est donc codé dedans. En fait, après désassemblage/petite analyse du code dans la flash, on comprend comment le pin est codé dans ce code de 2*8 bits. Si on écrit le code en hexa (byte par byte) "xy zt rs vw", Le code PIN sera "sztxy", avec la convention 0=>7, A=>1 B=>2 C=>3 D=>4 E=>5 F=>6 (et les autres, ça change pas). Dans le code de la flash, on peut aussi retrouver le "protocole" de discussion avec l'immobox, dont on parlera plus tard.
Chez moi, il y a aussi un boitier "immobilizer" (immobox pour les intimes) CODE2_FIAT, "delphi". C'est le boitier qui lit (en sans contact) et vérifie la puce dans la clef (via une antenne dans le neumann). Au démarrage, l'ECU demande au boitier immobox si une clef reconnue est détectée, et se bloque si c'est pas le cas.
L'immobox est relié à l'ECU par un fil (qui est aussi en protocole "K-line", du série 12 volts 4800 bauds sur 1 ligne), et aussi à la prise OBD (on board diagnostic) et diagbox (le logiciel PSA) peut directement communiquer avec lui.
Dans mon cas, il semble que c'est ce boitier immo qui déconne: il me marque des choses bizarres via DIAGBOX, et ne veut pas associer de clef avec le code PIN d'origine, qui est bon puisqu'il permet de démarrer en mode de secours. D'autre témoignages sur des forum me font pense que c'est un truc assez courant: le problème peut arriver si il y a des (micro)coupures de courant au mauvais moment, ce qui était mon cas.
La puce dans la clef est une ID48 EM4170 (ou pre/post modele) ("megamos crypto"), qui utilise un protocole crypto à challenge, propriétaire, sans contact (125khz), qui été partiellement cassé (Dismantling Megamos Crypto: Wirelessly Lockpicking a Vehicle Immobilizer, Roel Verdult, D. Garcia, Barış Ege). J'ai joué un peu avec ça, et j'ai fait un article "spécial" https://www.arthy.org/blog/id48.
Dans ce boitier immo, il y a une puce "megamos res", un MCU NEC uPD 780022A et une eeprom 93LC56B. Le PCB est double couche, et facilement tractable.
On trouve pas d'info sur la puce "megamos res", mais j'imagine qu'il fait la partie "tranceiver" pour communiquer avec le "transpondeur" (la puce sans EM4170).
Le MCU a une ROM interne de 16K et apparemment pas d'eeprom. En le voulant très fort, il est possible de la décapsuler, la passer au microscope et lire le code du masque rom.
Je ne sais pas si l'algo "propriétaire" coté tranceiver de l'EM4170 est dans la puce megamos, ou dans le MCU.
En lisant l'eeprom, (et en comparant la contenue de l'eeprom avec une eeprom d'un autre boitier "fonctionnel"), on voit qu'il "manque des trucs" dans mon eeprom d'immobox HS: y a plein de zones à FF où il devrait y avoir des choses. Je soupçonne donc un problème électrique, qui a mis le MCU dans un état merdique, et qui a bousillé ce qu'il y avait dessus... Donc j'imagine que les clefs d'association avec les ID48 dans mes clefs sont foutues. Néanmoins certaines parties sont toujours correctes: le code PIN (visible en clair si on affiche l'eeprom en hexa), et un numéro de 32 bits qui est le même qu'un numéro dans l'eeprom de l'ECU, et sert d'association.
Le format de l'eeprom n'a pas l'air très compliqué.
Le premier huitième contient 64 bits, puis que des zéros. Il semble qu'il s'agisse des "id" des deux clefs enregistrées (32 bits chacune). Le deuxième huitième contient entre autres le code pin, le code d'association avec l'ECU. Le deuxième quart ne contient que 32 bits, puis que des zéros. Bizarrement, les 16 derniers bits sont les mêmes que les 16 derniers bit du premier huitième... Le 3me quart est presque identique au 1er quart (à part quelques octets à la fin). le 4ème quart contient les numéros de série en ASCII (les mêmes que sur l'étiquette de l'immobox), et le reste sert apparemment à stocker des "défauts" (16bits par défaut)
En changeant le code d'association ECU-immobox (32 bits) dans l'eeprom de l'ECU, le démarrage de secours ne fonctionne plus. Le code pin est donc "codé" dans ces 32 bits. De plus, en hexa, 3 chiffres correspondent aux 3 derniers chiffres du PIN. Mais je ne sais pas comment les 2 premiers chiffres sont "codés"...
Bon, l'immobox a cramé, les clefs privées sont perdues. Que faire ?
Aller chez PSA: bon, ça douille, et ils se posent pas forcement beaucoup de question. Certains s'en retrouvent avec une facture de 1500 euros, car au final ils ont tout changé (y compris ECU...), alors que cela n'etait pas nécessaire.
Aller chez un garagiste qui fait de l'électronique. Sans doute la solution la plus intéressante pour un "lambda". Bon, j'imagine qu'ils ne se valent pas tous... Et on sait pas vraiment ce qu'il va faire, et si il va le faire bien, rien flinguer. J'imagine qu'il y a de grandes chances qu'on se retrouve avec un "immo off", peut être même sans le savoir, donc pas cool. Certain se retrouvent même avec le code d'un autre ECU (immooffisé), pas pour le même moteur.
Réparer l'immobox: J'imagine qu'il faut comprendre de A à Z l'immobox, ou acheter un immobox vierge, et j'imagine qu'un lambda peut pas acheter un immobox vierge, et qu'il faut passer par PSA.
Faire soi même un immo off. "La solution de base", c'est flinguer l'immo, cela me plaît pas. Mais j'ai toujours envie d'avoir un immo, mais pas forcement celle d'origine (de toutes façons l'ID48 est pété et beaucoup de méthodes de "vol" ne sont pas documentées). Idéalement un truc que je programme à ma sauce sur un MCU.
Simuler l'immobox: il existe des emulateurs d'immobox pas trop cher, en plus on peut rajouter un truc à sa sauce par dessus pour toujours avoir un immo. Mais à part ça, je ne trouve aucun code libre ou explication de protocoles.
Une fois qu'on a compris comment le protocole ECU <=> immobox marche, faire son truc soi même. Bon, vu que ID48 est sans doute pétée pour les voleurs de voiture, c'est clairement la meilleure solution.
Différentes solutions pour réparer les choses demandent généralement de dumper les mémoires (pour extraire les pin, virginiser ou masquer du code pour qu'il ne vérifie plus les choses...) Donc:
Pour les lire, pas besoin de boite noire pour electro-bidouilo-garagiste.
Pour l'eeprom, j'ai essayé avec un CH431A et un logiciel sous windows "AsProgrammer" (j'ai pas réussi à le faire depuis les outils dispo sous linux). Mais ce que j'obtiens n'avait pas l'air de correspondre à d'autres dumps que j'ai trouvé sur le net: tout est décalé d'un octet
J'ai donc fait mon propre code pour lire, avec un ESP8266, en regardant le opérations depuis le datasheet, sans utiliser le SPI hardware pour pas me chier dessus. Effectivement, le dump avec le programme windows m'avait tout décalé d'un octet. Sans doute qu'il est prévu pour des eeprom plus grandes, qui demandent un octet de plus dans l'adresse, et toute la lecture est décalée.
Pour la flash, il est théoriquement aussi possible de dessouder, et de lire (et/ou écrire) avec le device/code de son choix, ou de faire avec ce qui traîne dans sa grotte (mais bon avec la suite, pas besoin de le faire).
Puis le proc est basé sur le jeu d'instruction documenté C167, qui peut, de plus être désassemblé par IDA. Cool. Mais pas glop: il ne semble pas y avoir de jtag ou de truc de debug du genre.
Chez moi (et cela semble souvent le cas) le proc contient une ROM interne de 32k. Il y a du code dans la rom interne, et la flash. Pour pouvoir désassembler, il faudrait les deux, et a priori, c'est pas gagné pour le code en interne.
Comment faire ? C'est là que le "boot mode" joue. En fait, le CPU a un mode "série", ou "mode BSL" (="bootstrap loader"), documenté, qui peut être activé en mettant un certain pin (P0L.4, le numéro 104 sur mon package) à 0v au reset. Ce pin est aussi un pin utilisé pour un bus de la mémoire flash, d'où le fait de faire un "pull down" depuis un pin bizarre de la flash pour le faire passer en ce qu'ils appellent le "boot bode". En mode BSL, on peut uploader, en série, un code de (32 octets) qui sera mis dans la ram interne, et lancé. Ce code de 32 bytes permet de charger un plus gros programme, toujours par le port série. On peut même trouver chez Infineon un programme gratuit 'minmon' qui upload un code qui permet de lire/écrire la mémoire. Donc là aussi, rien besoin de "spécial", tout est dispo gratuitement et documenté.
En regardant le datasheet, on voit qu'il y a théoriquement un autre moyen d'exécuter dès le reset le code qu'on veut: un pin \EA (pin num 94) qui permet de booter sur la rom externe à la place de l'interne. Mais bon, visiblement pas besoin de ça pour le moment.
Après, il faut savoir comment "parler" au MCU avec le port série. On pourrait directement se brancher sur les 2 pins RX/TX du MCU, mais les "boites noires" genre MPPS n'en ont pas besoin. Il doit y avoir plus simple... Le "bus K-line" est un fait juste un bus série où tout passe sur un fil, et en 12V. Il y a des puces spéciales pour passer du "UART classique TX/RX" au K-line. Mais on peut le faire aussi avec une petite poignée de composants que tout le monde a.
On peut facilement regarder ce qui se passe entre les deux. Un simple "level shifter" avec 2 résistances, et on branche sur un analyseur logique (pour ma part, toujours mon bon vieux cypress fx2 avec sigrok/pulseview, en uart 4800 bauds). Dans mon cas (avec un immobox flinguée), on voit puis plusieurs fois de suite "05 10 10 10 10 10", et enfin 15. Sur une immobox qui marche, on voit "05", puis 5 octets (pour déverrouiller), et enfin un 06.
Après avoir un peu joué, on comprend assez facilement: l'ecu envoie "05" pour dire "envoie moi le déverrouillage". Le déverrouillage est une séquence de 5 octets, dont le 4 derniers (xorés avec l'octet précèdent) sont le code d'association. L'ecu envoie 06 si c'est bon, réessaye si c'est pas bon, et si il en a marre, il envoie 15 pour dire que c'est pas bon.
Donc la seule chose qui change est le premier octet de la séquence de 5. Il semble que l'ecu (en position 0x180 de l'eeprom) et l'immobox ont un compteur 8 bits, qui est incrémenté à chaque déverrouillage. Le premier octet est un "scrambling" de cet octet. Ainsi, on ne peut pas rejouer. Déjà, on fait pas grand chose avec 8 octets, mais il semble en plus que c'est juste des xors facilement devinables, en fonction de la valeur modulo 4.
L'ecu peut aussi envoyer "85 xx" si il est "vierge" (si il n y a pas de '55' juste après les 3 copies du codes d'assoc dans l'eeprom). Là l'immobox renvoie un séquence de 6 octets : le premier est le scrambling de xx, les 4 suivants toujours le code d'assoc (xoré avec le byte précédent), et le dernier une somme de contrôle: la somme des 5 premiers bits envoyés modulo 256. Puis l'ecu envoie "86" et l'immobox renvoie la même chose (sans doute pour vérification). l'ECU semble terminer par "87 84" si tout va bien, et l'ecu enregistre le code d'assoc, met le compteur à 0, et l'immobox fait de même.
Ceci semble confirmé en regardant le code assembleur dans l'ECU. On remarque qu'il y a d'autres messages, quand les choses vont mal à un moment ou un autre (mauvaise somme de contrôle par exemple). Mais donc rien qui sert vraiment pour faire son propre immobox.
Bon, malheureusement rien de solide point de vue sécurité, mais d'un autre coté, on peut facilement faire son propre immobox à sa sauce.