Atelier de reprogrammation
La même modification appliquée sur une série de véhicules identiques, sans repasser par l'éditeur hexadécimal à chaque fois.
Prototype interactif iNOREP
Capturez la modification
une seule fois.
Rejouez-la sur toute la flotte.
iNOREP compare un dump d'origine et un dump modifié, en extrait les blocs d'octets qui changent, et réapplique ce patch sur n'importe quel autre dump du même calculateur. Sans éditeur hexadécimal, sans recopie d'offsets à la main, sans envoyer un seul octet sur un serveur.
- 0
- octet envoyé au serveur
- 1
- capture pour N véhicules
- .json
- format d'échange ouvert
EDC17C46_ORI.bindump d'origine
0001A2F01F2933606A747EABB5BFECF6007BA8B2
0001A300BCE9F3FD07343E48757FFA27313B4572
0001A3107C86B3BDC7D1FE7983B0BAC4CEFB050F
0001A3203C46505AF8020C39434D7A848E98C5CF
0001A330D977818B95C2CCD6030D17214E58D300
0001A3400A14414B555F8C96A0CDD7525C89939D
offset 0x0001A2F00 octet réécritvérification des octets d'origine active
Aperçu du moteur de comparaison, en conditions réelles dans le navigateur.
Le geste que ça remplace
Une modification de cartographie validée sur un véhicule doit souvent être rejouée sur dix autres. C'est là que se perdent les heures, et que se produisent les erreurs de recopie.
À la main, aujourd'hui
- Ouvrir les deux dumps dans un éditeur hexadécimal
- Repérer les plages modifiées à l'oeil, noter les offsets sur un papier
- Recopier les octets à la main sur chaque nouveau dump
- Espérer que la version logicielle du véhicule suivant soit identique
Avec iNOREP
- Déposer le dump d'origine et le dump modifié
- Le diff octet à octet sort les blocs, avec offset et octets attendus
- Le patch part dans la bibliothèque, exportable en .json
- Sur le dump suivant, les octets attendus sont vérifiés avant écriture
Quatre étapes, aucune ligne de commande
01
Charger les deux dumps
Le fichier d'origine et le fichier modifié sont lus dans le navigateur. Taille, CRC32 et cohérence sont contrôlés avant toute comparaison.
02
Extraire le patch
Comparaison octet à octet. Les différences proches sont regroupées en blocs lisibles, avec leur offset et les octets attendus.
03
Nommer et ranger
Le patch rejoint la bibliothèque avec son calculateur, sa catégorie et ses tags. Export et import au format .json entre ateliers.
04
Appliquer en sécurité
Sur le dump cible, chaque bloc n'est écrit que si les octets attendus sont bien là. Sinon il est ignoré et signalé, jamais écrasé.
Deux rôles, une application
Choisissez votre rôle pour explorer le prototype.
Poste technicien
Parcourt le catalogue Marque / ECU / catégorie, charge son dump cible, applique le patch avec vérification des octets d'origine et télécharge le fichier patché.
OuvrirAdministrateur
Crée et gère les patchs, le référentiel et les habilitations.
Entrer comme administrateurPoste de travail
Compare un dump original et un dump modifié, capture le patch, puis l'applique sur un nouveau dump cible avec vérification des octets d'origine.
OuvrirBibliothèque de patchs
Catalogue des patchs de l'atelier : blocs, offsets, compatibilité, import et export au format JSON pour les échanges entre ateliers.
OuvrirRéférentiel
Gestion des marques, des ECU et des catégories qui structurent le catalogue vu par les techniciens.
OuvrirSupervision atelier
Journal de toutes les opérations, indicateurs de la session, habilitations des postes et règles de sécurité appliquées avant écriture.
OuvrirSur le terrain
Lecture au banc
Dump lu hors véhicule, comparé au fichier de référence, patch rejoué puis contrôlé par son CRC32 avant réécriture.
Intervention en clientèle
Le patch reçu d'un fournisseur arrive en .json, il est vérifié bloc par bloc avant d'être appliqué au dump du véhicule.
Ce que la démo fait vraiment
Tout ce qui suit est jouable tout de suite dans le prototype, y compris avec vos propres fichiers .bin.
Comparaison octet à octet
Aucun échantillonnage, aucun résumé. Chaque octet des deux dumps est comparé.
Vérification des octets d'origine
Un bloc dont les octets attendus sont absents à l'offset n'est jamais écrit. Il est ignoré et journalisé.
CRC32 sur chaque fichier
Empreinte calculée à la lecture et après écriture, pour tracer précisément ce qui a été produit.
Bibliothèque exportable
Format .json lisible, un patch ou toute la bibliothèque, pour échanger entre postes et entre ateliers.
Journal d'opérations
Fichier traité, patch appliqué, blocs écrits et refusés, résultat. Exportable en CSV.
Traitement 100% local
Lecture et écriture dans le navigateur. Les dumps ne quittent jamais le poste de travail.
Questions fréquentes
Non. La lecture et l'écriture passent par les API de fichiers du navigateur. Aucun octet ne sort du poste, il n'y a ni serveur de traitement ni base de données dans ce prototype.
Le contrôle de compatibilité compare la taille et cherche les octets attendus à chaque offset. Si un bloc ne retrouve pas ses octets d'origine, il est refusé et le rapport indique ce qui a été trouvé à la place. Vous obtenez une application partielle explicite, jamais une écriture à l'aveugle.
Oui. La bibliothèque importe un fichier .json au format d'échange iNOREP, ou un simple tableau de patchs. Un fichier mal formé est refusé avec un message qui dit précisément quel bloc pose problème.
Non, et c'est volontaire. Chaque famille de calculateur a son propre algorithme propriétaire. iNOREP se limite à un CRC32 de contrôle sur le fichier, et laisse le recalcul du checksum constructeur à l'outil de flashage.
La limite est un réglage de l'atelier, réglable de 4 à 32 Mo dans la console de supervision. Les dumps de démonstration font 256 et 512 Ko pour rester légers dans la démo.