Ce récit relate une expérience professionnelle où le reverse engineering a permis de résoudre un problème industriel lié au protocole Modbus, un standard de communication largement utilisé dans l’automatisation. L’auteur, employé dans une usine il y a vingt ans, décrit comment son entreprise avait acquis un système d’automatisation clé en main auprès d’un autre site industriel. Ce système comprenait des contrôleurs gérant des équipements électriques, une interface SCADA pour visualiser les processus, et une communication basée sur Modbus en mode ASCII. Bien que la documentation technique fût complète – incluant schémas, descriptions des registres et commandes –, l’adaptation du logiciel existant aux besoins spécifiques de la direction posait problème.

L’objectif était d’intégrer une logique personnalisée, mais l’auteur, peu familier avec Modbus à l’époque, rencontra un obstacle inattendu lors de ses premiers tests. Après avoir formé manuellement une requête conforme à la spécification (par exemple `:1103006B00037E`), le contrôleur ne répondait pas, alors que le logiciel d’origine fonctionnait sans difficulté depuis le même poste. Une analyse via un sniffer réseau révéla que la somme de contrôle (LRC) calculée par le logiciel officiel différait de celle obtenue par l’auteur : `18` au lieu de `7E`. Malgré des vérifications répétées et l’utilisation d’outils dédiés à Modbus confirmant sa méthode, l’écart persistait.

Sous la pression de la direction, l’auteur se tourna vers le reverse engineering du logiciel propriétaire. En désassemblant le code et en examinant pas à pas la routine de calcul du LRC, il découvrit une anomalie : au lieu de traiter les octets bruts du message (comme le prévoit le protocole), les développeurs originaux convertissaient d’abord chaque caractère en son code ASCII avant de sommer ces valeurs. Par exemple, le caractère `'1'` (code `31` en hexadécimal) était additionné tel quel, plutôt que d’utiliser sa valeur numérique `1`. Cette approche non standard expliquait la divergence des sommes de contrôle. Une fois ce mécanisme compris, l’auteur put adapter ses requêtes et établir une communication fonctionnelle avec les contrôleurs.

L’anecdote illustre comment une apparente simplicité technique peut cacher des particularités implémentatives, nécessitant parfois une analyse approfondie pour les déjouer. L’auteur souligne avec humour que la satisfaction tirée de cette résolution fut d’autant plus grande que le problème s’était révélé complexe. Le récit met en lumière l’importance de la persévérance, de la curiosité technique, et des outils comme les disassembleurs pour surmonter des obstacles en milieu industriel, où la documentation, même détaillée, ne couvre pas toujours les spécificités des implémentations logicielles.