Bonjour! Je veux faire du reverse engineering sur des ECUs de voiture. Je me pose des questions sur la connexion à réaliser (OBD ou pas) et le format de données que je vais obtenir. Je peux prendre Ghidra je suppose pour l'analyse.
Bonjour! Je veux faire du reverse engineering sur des ECUs de voiture. Je me pose des questions sur la connexion à réaliser (OBD ou pas) et le format de données que je vais obtenir. Je peux prendre Ghidra je suppose pour l'analyse.
Bonjour,
Concernant la prise ODB elle ne te remontra que la liste des défauts du véhicule. Liste définie par les fabricants.
Si tu veux voir ce qui ce passe entre les ECU et les capteurs il faudra lire les données sur les bus CAN mais aussi Flexray et Lin car certaines voitures ont des bus de comm différents. Les données seront du binaire et difficilement interprétable puisque tu ne saura pas qui parle/repond (le maître, l'esclave ?)
Il faudrait se placer non pas sur le bus mais plutôt derrière les transceivers CAN (par exemple) maitre et esclave car à ces endroits tu as des UART Rx Tx bien plus facile à interpréter.
Les données sont une chose, et c'est utile de les connaitre... d'autant plus que le système embarqué d'une voiture est distribué au niveau granulaire des sous fonctions... Donc Sur une chaîne de bout-en-bout type capteurs-fonctions intermédiaires-actionneurs, on peut non seulement retrouver un code réparti sur plusieurs ECUs mais également des variables introduites depuis encore d'autres calculateurs... Ces dernières sans doute récoltables par le biais de ce que tu m'as dit, si j'en désire les valeurs. Il me manquera la partie code des ECUs puisque je vais tâcher de comprendre le fonctionnement (même si j'avoue que je m'attend à une tâche colossale). J'ai pensé ouvrir l'ECU dont je veux récupérer le programme et faire un full BDM car la cartographie n'est pas ce qui m'intéresse le plus.
En effet il faudra que je m'adapte au type de réseau mis en place... Comment te connecte tu pour récupérer les données UAT? Je suppose qu'il faut un programme de déchiffrage spécifique?
En effet c'est loin d'être simple.
Oui ouvrir un ECU est une bonne idée.
Un ECU c'est un microcontrôleur au quel on a ajouté un transceiver BUS CAN pour le maitre (le calculateur) ou un capteur/actionneur suivi d'un microcontrôleur au quel on a ajouté un transceiver BUS CAN pour les esclaves. Selon où on se trouve dans la voiture ça peut être du BUS LIN (des capteurs simples genre porte ouverte/fermée) ou même du FlexRay.
Pour reprogrammer le microcontrôleur il faut bien souvent une sonde JTAG mais encore faut il avoir le programme à mettre dedans. Lire le programme existant c'est pas gagné car quasiment tous les microcontrôleurs ont des systèmes de verrouillage anti-lecture. Parfois le microcontrôleur permet de mettre à jour une map/emplacement mémoire spécifique mais il faut savoir comment faire ça et pas sur que ce soit documenté quelque part.
Mon oscilloscope et beaucoup d'autres permettent de faire ça. Beaucoup d'oscillo ont des décodeurs de protocole, le mien fait CAN et LIN pour l'automobile. Ici dans cet exemple (c'est précisément mon oscillo) est directement mis sur le bus CAN, mais il aurait pu être placé entre le microcontrôleur et le transceiver CAN auquel cas il aurait fallu activer le décodage UART
Alors ça ne fait pas tout évidement, l'oscillo décode la trame CAN, tu vois les données, le CRC etc...mais il faut arriver à savoir a quoi correspondent ses données (le maître qui pose une question ? Un capteur qui répond ? La donnée que je vois correspond à quoi ?). C'est ça la tâche colossale !
![]()
Tu veux dire qu'ils sont cryptés, c'est celà?
En tout cas belle explication illustrée! Il me semble que des programmes can sniffer récupèrent aussi les données, et permettent de voir en direct l'effet des actions sur des commandes de la voiture... Une façon de coller un nom sur qui fait quoi?
Non ce n'est pas crypté, c'est un simple mode anti-lecture.
A moins que tu ne possèdes le programme d'origine, lorsqu'il est activé tu ne peux pas lire le programme existant dans le microcontrôleur, tu peux l'effacer si tu veux ou le programmer c'est à dire écraser l'ancien programme avec un nouveau programme. Tu ne peux pas par exemple, lire le programme en faire une copie et le remettre dans d'autres microcontrôleurs.
Si tu as une photo d'un ECU démonté et que j'arrive à lire la référence des composants, il est possible qu'on trouve la doc du microcontrôleur pour voir s'il a cette option anti-lecture (même si je suis quasi sur que c'est le cas)
Après faut voir comment le fabricant a prévu son coup pour les mises à jours. Il n'a peut être pas activé l'anti-lecture.
Regarde cette vidéo par exemple :
A un moment, on voit la référence du microcontrôleur, un TC1766 de chez Infineon. La doc constructeur du micro est ici : https://www.infineon.com/dgdl/Infine...1368a9b40e0224
On peut voir qu'il peut être programmé une seule fois pour toujours (OTP One Time Programming) donc ça si c'est activé alors là... on ne peut même pas l'effacer ou le reprogrammer. On voit qu'on peut mettre même mettre un mot de passe pour temporairement désactiver la protection anti-lecture.
Ce micro a plusieurs mémoires
Ca semble évident que les paramètres de réglages du calculateur sont dans la mémoire paramètre tandis que dans l'autre mémoire on va retrouver le programme.
Ce micro a même un bootloader qu'on peut activer en mettant la broche 118 (/TESTMODE) au +5V, et je suis a peu prés sur que c'est ce que le gars qui soude à fait dans la vidéo plus haut. Un bootloader c'est ça :
Donc la protection anti-lecture n'est peut être pas activé partout.Envoyé par Traduit du site Arduino
Oui ça doit exister je pense, le plus compliqué c'est d'arriver à trouver qui parle et qui répond car si je mettais mon oscillo sur le bus CAN d'une voiture j'imagine que le nombre de ligne serait tellement gros qu'arriver à s'y retrouver serait très très très compliqué. Quand on a juste un maitre et 3 ou 4 esclaves ça va mais dans une voiture....
Partager