Hello, quelqu'un saurait comment extraire les données sur des ECUs?

C'est beaucoup trop vague mais de toute façon le reverse c'est interdit par le règlement du forum...

Je dirais juste que extraire les réglages c'est probablement juste lire une puce mémoire; par contre savoir à quoi correspondent ces données c'est une toute autre histoire. Les fabriquants de voitures sont très peu bavards de manière générale.

PS: Quel lien avec la prog? Et le C?

Alors le C c'est le langage que je vais retrouver au niveau des calculateurs. C'est celui que Ghidra va prendre en compte... Evidemment savoir à quoi correspondent les données est un défi... je me demandais si les fichiers ARXML liés aux fichiers C pourraient être utile pour celà, sinon il faut enquêter tel un Sherlock holmes... Je veux retrouver des defeat devices, il y en a encore depuis le dieselgate de 2017... Il s'agit de faire appliquer la loi européenne. Mais pour celà on doit extraire le code, et faire donc face à des défis techniques... Pour ma part je fais partie d'un groupe de travail sur le thème de la pollution sonore des véhicules motorisés en Europe. Toute aide serait la bienvenue...

Non, au niveau des calculateurs c'est du code machine avec n'importe quel language de prog qui peut être à l'origine. Peut-être que c'est toujours le C qui est utilisé mais j'en doute un peu vu la "simplicité" du C vs la complexité des calculateurs de bagnoles.
 
Appliquer la Loi c'est très bien, mais il faut faire attention: Est-ce que la même Loi (européenne ou française) autorise ce travail de reverse? Et comme je disais, c'est un travail monstre de toute façon, même avec Ghidra.

 
c'est esentiellement du C écrit a la mano entrecoupé de modèles générés via matlab, le tout baignant dans le turbo-cancer qu'est le framework Autosar.

Ah oui, j'avais entendu parler des modèles Matlab, à priori bien gonflés au niveau code. Ca doit être très drôle à faire du reverse sur ce genre de chose...

oui, déjà que le C généré est imbitable et quasi indébuggable, alors l'asm derrière