Le reverse en­gi­nee­ring d’un logiciel

Au départ, la rétro-in­gé­nie­rie s’ap­pli­quait à la cons­truc­tion mécanique. Aujourd’hui, avec les tech­no­lo­gies de scan 3D, la to­mo­gra­phie in­for­ma­ti­sée, le contrôle par ultrasons et autres tech­niques, nous sommes en mesure de collecter de pré­cieuses in­for­ma­tions sur le fonc­tion­ne­ment d’une machine ou d’un appareil mécanique. De son côté, l’in­gé­nie­rie a pour but de concevoir et d’assembler les dif­fé­rents com­po­sants d’un produit pour en faire un appareil fonc­tion­nel. Le reverse en­gi­nee­ring (in­gé­nie­rie inversée) retourne quant à lui tout le processus.

L’in­gé­nie­rie inversée a pour but de cerner le fonc­tion­ne­ment des dif­fé­rents com­po­sants d’un système pour com­prendre le fonc­tion­ne­ment de l’ensemble. C’est la raison pour laquelle on applique parfois cette technique sur les produits de ses con­cur­rents. On se donne ainsi les chances d’améliorer son propre produit et de l’adapter pour le rendre plus com­pé­ti­tif sur le marché. Le reverse en­gi­nee­ring est utilisé dans toutes sortes d’autres contextes, et ne se limite pas à du matériel. Comment et pourquoi pratique-t-on le reverse en­gi­nee­ring sur des logiciels ?

Le reverse en­gi­nee­ring du code permet aux analystes pro­gram­meurs d’inverser les processus de dé­ve­lop­pe­ment et de pro­duc­tion d’un logiciel et ainsi découvrir ce qui passe dans les coulisses d’un programme. La dé­cons­truc­tion et le dé­ve­lop­pe­ment inversé d’un logiciel vous per­met­tent d’accéder au code-source d’une ap­pli­ca­tion. Une fois que son code est compris, le logiciel devient un livre ouvert, ac­ces­sible à tous les experts. Il est alors possible de com­prendre l’ar­chi­tec­ture du programme, son mode de fonc­tion­ne­ment et sa structure interne, pour ensuite le modifier ou le réu­ti­li­ser en partie. Les in­for­ma­tions que vous procure le dé­ve­lop­pe­ment inversé d’un logiciel sur ses processus, per­met­tent de corriger des erreurs de pro­gram­ma­tion. Dans le domaine des logiciels, on utilise avant tout le reverse en­gi­nee­ring pour dé­ve­lop­per de nouveaux produits, pour iden­ti­fier des bugs ou pour analyser les produits des con­cur­rents.

On utilise le reverse en­gi­nee­ring autant pour analyser des produits in­dus­triels que pour la re­cons­truc­tion d’un logiciel. La re­cons­truc­tion de logiciel est gé­né­ra­le­ment composée d’un des trois processus suivants :

• L’accès au code-source du logiciel
• La com­pré­hen­sion des règles qui régissent le protocole de com­mu­ni­ca­tion
• La création ul­té­rieure d’un nouveau modèle

On entend par code-source le texte rédigé dans un langage de pro­gram­ma­tion pour dé­ve­lop­per un logiciel. L’or­di­na­teur traduit ce texte par­fai­te­ment lisible par des hommes dans un langage-machine qu’il comprend lui-même. Pour accéder au code-source d'un logiciel, il faut donc inverser le processus de tra­duc­tion de votre machine. Pour ce faire, on va par exemple utiliser un dé­com­pi­la­teur. Il s’agit d’un logiciel capable de re­cons­ti­tuer un texte-source lisible à partir d’un code-machine binaire. Ce processus, con­sis­tant à traduire un code machine binaire en un texte lisible par les hommes se fait alors au­to­ma­ti­que­ment.

Si le code binaire n’est pas re­cons­trui­sible, on peut recourir à un dé­sas­sem­bleur. Ce type de programme permet de trans­for­mer le langage machine codé de façon binaire en un langage as­sem­bleur, lisible par les hommes. Celui-ci pourra être analysé de façon manuelle. Dans la plupart des cas, les pro­gram­meurs ne réus­sis­sent pas à re­cons­ti­tuer l’in­té­gra­lité du code source. En principe, ce n’est pas trop grave, car le but du reverse en­gi­nee­ring est de pouvoir percevoir l’idée du programme, et pas vraiment de pouvoir recopier le code source dans son ensemble. Même avec des codes partiels, il est possible de réaliser des analyses dy­na­miques de pro­grammes ou de corriger certains bugs. Ce sont avant tout les analystes-pro­gram­meurs qui utilisent des dé­com­pi­la­teurs et des dé­sas­sem­bleurs.

Le reverse en­gi­nee­ring est également utilisé par les pro­gram­meurs devant dé­ve­lop­per par exemple des pilotes pour des systèmes d’ex­ploi­ta­tion, dont la structure et le mode de fonc­tion­ne­ment sont con­fi­den­tiels et non-do­cu­men­tés. Au moyen d’un sniffer (renifleur), il est possible d’accéder aux règles qui régissent un protocole de com­mu­ni­ca­tion. Le sniffer est un uti­li­taire qui permet d’analyser les flux de données au sein d’un réseau. Un tel uti­li­taire va par exemple constater les par­ti­cu­la­ri­tés dans les échanges de données entre deux appareils. Analyser ces modes de com­mu­ni­ca­tion permet aux pro­gram­meurs de com­prendre les règles qui dé­fi­nis­sent le protocole en question.

Dans un tel cas de figure, on parle de res­tau­ra­tion de code plutôt que de reverse en­gi­nee­ring. On modifie alors le code source d’un logiciel et on le reporte dans un nouveau modèle, où il sera traité et re­tra­vaillé. De cette manière il est possible de créer, de compléter et de do­cu­men­ter certains éléments de logiciels avec le Langage de Mo­dé­li­sa­tion Unifié UML.

On peut utiliser le reverse en­gi­nee­ring de code de pro­gram­ma­tion dans toutes sortes de domaines, et à des fins diverses :

• Pour gérer et contrôler la qualité de son propre logiciel et ses fonc­tion­na­li­tés
• Pour pour­suivre le dé­ve­lop­pe­ment de son propre logiciel
• Pour analyser des pro­to­coles de com­mu­ni­ca­tion réseau
• Pour détecter des virus, des chevaux de Troie, des logiciels de chantage et autres pro­grammes mal­veil­lants
• Pour le portage ou l’entretien d’un aban­don­ware (logiciel abandonné)
• Pour iden­ti­fier des erreurs dans un logiciel
• Analyse générale du format d’un fichier pour en com­prendre la structure
• Amé­lio­ra­tion de com­pa­ti­bi­li­tés lo­gi­cielles avec des pla­te­formes et des logiciels de pres­ta­taires tiers
• Uti­li­sa­tion de fonctions non-do­cu­men­tées d’une pla­te­forme

Par ailleurs, on peut recourir à un reverse en­gi­nee­ring de logiciel pour analyser les produits des con­cur­rents. Bien qu’un bon nombre d’en­tre­prises in­ter­di­sent le reverse en­gi­nee­ring de leurs produits, le stipulant dans les con­di­tions de licence, l’analyse de pro­to­coles n’est pas soumise à des res­tric­tions ju­ri­diques. C’est notamment lié au fait que le logiciel n’est pas soumis à l’analyse au moyen d’outils de reverse en­gi­nee­ring. De telles clauses con­trac­tuelles sont d’ailleurs illégales dans un bon nombre de pays. Les uti­li­sa­teurs d’un logiciel ont gé­né­ra­le­ment le droit de soumettre le logiciel à un reverse en­gi­nee­ring pour vérifier le caractère sécurisé du logiciel et pour corriger d’éventuels bugs.

Le dé­ve­lop­pe­ment inversé d’un logiciel permet aux pro­gram­meurs et aux dé­ve­lop­peurs de mieux com­prendre le fonc­tion­ne­ment des ap­pli­ca­tions nu­mé­riques. Il facilite aussi la cor­rec­tion des erreurs de pro­gram­ma­tion et vous apporte de pré­cieuses in­for­ma­tions quand vous dé­ve­lop­pez votre propre logiciel.