Reverse engineering : tentatives de remonter d'un code exécutable à son code source (qu’est-ce qu’il fait, identification de malveillances, hack, espionnage, etc.)

cr  01.01.2001      r+  22.10.2024      r-  22.10.2024      Pierre Pinard.         (Alertes et avis de sécurité au jour le jour)

En informatique, l'Ingénierie inverse (Rétro-ingénierie - Reverse engineering) est un terme essentiellement utilisé dans les tentatives de remonter d'un code exécutable à son code source afin de comprendre ce qu'il fait (dont en recherches de malveillances de toutes natures) et, éventuellement, ce qu'il cache (suspicion d'espionnage, dont dans les navigateurs Web), etc.

L'Ingénierie inverse se classe dans l'espionnage industriel (intelligence industrielle, comme les administrations publiques de collecte et traitement d'informations et renseignements économiques dont l'Intelligence Service en Grande-Bretagne) et s'applique, globalement à tous les produits et services.

En matière de logiciels, l'Ingénierie inverse commence par l'utilisation d'outils de désassemblage et de décompilation d'un code exécutable. Si le code est compilé, il est possible d'en obtenir une écriture en « assembleur » (langage de très bas niveau [entendez par là le plus proche du matériel, le plus rapide et le plus technique soit, au niveau intellectuel, le langage de plus haut niveau possible], s'adressant directement aux processeurs). Si le code est un code intermédiaire, type P-Code, Java, .Net, etc. la décompilation permet de remonter directement, ou presque, au code source.

Une autre méthode d'Ingénierie inverse appliquée aux logiciels consiste à considérer l'objet logiciel dont on cherche à comprendre le fonctionnement et le comportement, comme une boîte noire ayant des entrées (des données en entrée), et des sorties (des données en sortie). On entre des jeux d'essai de données en entrée et on observe les sorties pour en déduire :

• Ce qui se passe dans la boîte noire (les algorithmes).

• Les structures des données en entrée comme en sortie, lorsque ces structures sont inconnues.

Cracker un logiciel relève de l'Ingénierie inverse (généralement limitée à la partie du code gérant la protection anticopie/antipiratage).

Analyser un virus pour en déterminer son comportement, ses méthodes de camouflage, ce qu'il fait, etc. relève de l'Ingénierie inverse. Les laboratoires de chacun des antivirus passent leur vie à faire de l'Ingénierie inverse.

La protection par des clauses contractuelles interdisant l'Ingénierie inverse n'est pas dissuasive.

La protection par des brevets est coûteuse, mais empêche une copie pure et simple. L'Ingénierie inverse va alors permettre de comprendre puis d'imiter sans violer le brevet.

Ce problème n'existe pas avec les logiciels « Open Source » dont le code est public (rien n'est caché, tout le monde peut examiner et analyser le code source, et il n'y a alors pas de suspicion).

Les éditeurs de logiciels qui clament que leur logiciel est « Open Source » alors que, simultanément, leurs clauses contractuelles interdisent l'Ingénierie inverse, sont des menteurs et leurs logiciels ne sont pas « Open Source ». C'est le cas de Google avec l'insistant buzz qui fait entendre que Chrome est « Open Source » alors qu'il n'en est rien (seul le moteur de rendu, une infime partie d'un navigateur Web qui n'a aucune interaction avec l'utilisateur) est « Open Source ». Dans les clauses contractuelles, obligatoirement acceptées, des « Conditions d'utilisation de Google Chrome » (dernière vérification le 06.01.2018 - article 9.2) :

• « …/… vous n'êtes pas autorisé (et ne pouvez pas autoriser un tiers) à copier, modifier, créer des travaux dérivés, faire de l'ingénierie inverse, décompiler ou tenter d'extraire de quelque manière que ce soit le code source du Logiciel ou d'une partie de celui-ci …/… »

Rappel : Chrome n'est pas Chromium. Chrome est un navigateur Web propriétaire, simplement utilisant le moteur de rendu de Chromium (sinon, les compilations de l'un et de l'autre donneraient les mêmes condensats (hashcodes).