Que ce soit en reconstruisant un moteur de voiture ou en schématisant une phrase, les gens peuvent apprendre beaucoup de choses simplement en les démontant et en les remontant. Voilà, en quelques mots, le concept qui sous-tend l’ingénierie inverse : décomposer quelque chose afin de le comprendre, d’en construire une copie ou de l’améliorer.
Un processus qui, à l’origine, ne s’appliquait qu’au matériel informatique, la rétro-ingénierie s’applique désormais aux logiciels, aux bases de données et même à l’ADN humain. La rétro-ingénierie est particulièrement importante avec le matériel et les logiciels informatiques. Les programmes sont écrits dans un langage, par exemple C++ ou Java, qui est compréhensible par d’autres programmeurs. Mais pour fonctionner sur un ordinateur, ils doivent être traduits par un autre programme, appelé compilateur, dans les uns et les zéros du langage machine. Le code compilé est incompréhensible pour la plupart des programmeurs, mais il existe des moyens de reconvertir le code machine dans un format plus convivial pour l’homme, notamment grâce à un outil logiciel appelé décompilateur.
L’ingénierie inverse est utilisée à de nombreuses fins : comme outil d’apprentissage ; comme moyen de fabriquer de nouveaux produits compatibles et moins chers que ce qui existe actuellement sur le marché ; pour rendre l’interopérabilité des logiciels plus efficace ou pour établir un pont entre les données de différents systèmes d’exploitation ou bases de données ; et pour découvrir les fonctionnalités non documentées des produits commerciaux.
Un exemple célèbre de rétro-ingénierie concerne la société Phoenix Technologies Ltd, basée à San Jose, qui, au milieu des années 1980, voulait produire un BIOS pour PC qui serait compatible avec le BIOS propriétaire du PC IBM. (Un BIOS est un programme stocké dans un micrologiciel qui est exécuté au démarrage d’un PC ; voir Étude rapide sur la technologie, le 25 juin).
Pour se protéger contre les accusations d’avoir simplement (et illégalement) copié le BIOS d’IBM, Phoenix a procédé à sa rétro-ingénierie en utilisant ce que l’on appelle une approche en » salle blanche « , ou » muraille de Chine « . Tout d’abord, une équipe d’ingénieurs a étudié le BIOS d’IBM – environ 8 Ko de code – et a décrit tout ce qu’il faisait de manière aussi complète que possible, sans utiliser ni faire référence à aucun code réel. Phoenix a ensuite fait appel à une deuxième équipe de programmeurs qui n’avaient aucune connaissance préalable du BIOS d’IBM et n’avaient jamais vu son code. Travaillant uniquement à partir des spécifications fonctionnelles de la première équipe, la seconde équipe a écrit un nouveau BIOS qui fonctionnait comme spécifié.
Le BIOS Phoenix résultant était différent du code IBM, mais à toutes fins utiles, il fonctionnait de manière identique. En utilisant l’approche de la salle blanche, même si certaines sections du code se trouvaient être identiques, il n’y avait pas de violation du droit d’auteur. Phoenix a commencé à vendre son BIOS à des entreprises qui l’ont ensuite utilisé pour créer les premiers PC compatibles avec IBM.
D’autres entreprises, comme Cyrix Corp. et Advanced Micro Devices Inc. ont réussi à faire de la rétro-ingénierie sur les microprocesseurs d’Intel Corp. pour fabriquer des puces compatibles Intel moins coûteuses.
Peu de systèmes d’exploitation ont fait l’objet d’une rétro-ingénierie. Avec leurs millions de lignes de code – comparés aux quelque 32 Ko des BIOS modernes – leur rétro-ingénierie serait une option coûteuse.
Mais les applications sont mûres pour la rétro-ingénierie, car peu de développeurs de logiciels publient leur code source. Techniquement, une interface de programmation d’applications (API) devrait permettre aux programmes de fonctionner facilement ensemble, mais les experts affirment que la plupart des API sont si mal écrites que les fabricants de logiciels tiers n’ont guère d’autre choix que de faire de la rétro-ingénierie sur les programmes avec lesquels ils veulent que leur logiciel fonctionne, juste pour assurer la compatibilité.
Angles éthiques
L’ingénierie inverse peut également exposer des failles de sécurité et des pratiques de confidentialité douteuses. Par exemple, la rétro-ingénierie de Digital : Convergence Corp. a révélé que chaque lecteur possède un numéro de série unique qui permet au fabricant de l’appareil de marier les codes scannés avec les données d’enregistrement de l’utilisateur et ainsi de suivre les habitudes de chaque utilisateur dans les moindres détails – une caractéristique jusqu’alors non publiée.
Les récentes démarches juridiques soutenues par de nombreux grands fabricants de logiciels et de matériel, ainsi que par l’industrie du divertissement, érodent la capacité des entreprises à faire de la rétro-ingénierie.
« La rétro-ingénierie est légale, mais il y a deux domaines principaux dans lesquels nous voyons des menaces à la rétro-ingénierie », explique Jennifer Granick, directrice de la clinique de droit et de technologie de la Stanford Law School à Palo Alto, en Californie. L’une des menaces, qui n’a pas encore été testée par les tribunaux, provient des licences « shrink-wrap » qui interdisent explicitement à quiconque ouvre ou utilise le logiciel d’en faire l’ingénierie inverse, dit-elle.
L’autre menace provient du Digital Millennium Copyright Act (DMCA), qui interdit la création ou la diffusion d’outils ou d’informations qui pourraient être utilisés pour briser les protections technologiques qui protègent les logiciels contre la copie. En juillet dernier, sur la base de cette loi, la société Adobe Systems Inc., basée à San Jose, a demandé au FBI d’arrêter Dmitry Sklyarov, un programmeur russe, alors qu’il se trouvait aux États-Unis pour une conférence. Sklyarov avait travaillé sur un logiciel permettant de craquer le cryptage des fichiers de livres électroniques d’Adobe.
Le fait est que même une rétro-ingénierie conforme aux règles de l’art nécessite souvent de briser de telles protections, et le DMCA autorise la rétro-ingénierie à des fins de compatibilité.
« Mais vous n’êtes pas autorisé à voir si le logiciel fait ce qu’il est censé faire », dit Granick, et vous ne pouvez pas non plus le regarder à des fins d’enquête scientifique. Elle propose une analogie : « Vous avez une voiture, mais vous n’avez pas le droit d’ouvrir le capot ».
|
|
||||
|
Schwartz est un écrivain indépendant à Arlington, Mass. Contactez-le à l’adresse [email protected].