La rétro-ingénierie en informatique est un sous-domaine de la rétro-ingénierie appliquée aux systèmes, logiciels ou appareils informatiques. Elle a pour but d'analyser un système pour en créer une représentation à un plus haut niveau d'abstraction. Les objectifs de la rétro-ingénierie sont multiples, certains pouvant être autorisés voire nécessaires, et d'autres plus malveillants sont combattus de différentes méthodes.

La rétro-ingénierie informatique regroupe l'ensemble des techniques et des outils liés à la compréhension d'un système logiciel et/ou matériel^[1] existant, sans le bénéfice des spécifications originales^[2]. Réalisée généralement en deux phases, elle consiste en l'identification des composants du système et de leurs relations, puis leurs représentations à un niveau d'abstraction plus élevé et plus compréhensible par les humains (spécifications, documentations, plans, schémas)^[3]. Cela n'implique ni la modification, ni la création d'un nouveau système fondé sur cette rétro-ingénierie. C'est un processus d'analyse, et non d'altération ou de réplication^[4]. Le résultat de cette analyse peut être particulièrement bénéfique, ou complètement inexploitable, selon la personne effectuant la rétro-ingénierie, et sa connaissance de l'objet étudié^[5]. Ces résultats seront d'autant plus bénéfiques grâce à l'utilisation d'outils dédiés^[3] et le futur de la rétro-ingénierie sera fondé sur des preuves d'efficacité de ces méthodes et outils dans un contexte donné^[6].

La rétro-ingénierie est un défi technique pour plusieurs raisons (liste non exhaustive) :

• l'intention du programmeur n'est pas claire ;
• le problème initial peut ne pas être résolu correctement ;
• le code a été altéré pour répondre à des besoins de maintenance ;
• le logiciel est un portage d'un environnement différent ;
• la plateforme matérielle a changé ou évolué ;
• la sémantique du langage a changé.

C'est principalement pour cela que les mainteneurs de logiciel doivent souvent faire des suppositions, telles : « que fait ce module ? », « pourquoi cette opération est-elle réalisée de cette façon »^[7] ?». Un des autres défis clé de l'analyse de programme est de prendre en compte la haute dynamicité. Les langages de programmation les plus répandus aujourd'hui permettent l'utilisation de ce concept, qui constitue un mécanisme de développement puissant, mais qui rend son analyse plus difficile. Par exemple, les langages comme Java introduisent les concepts de réflexion et la possibilité de charger des classes pendant l’exécution du programme^[8]. La rétro-ingénierie est passée d'une analyse à une dimension (statique), à une analyse à deux dimensions (statique et dynamique). Elle tend à en ajouter une troisième, qui consiste en l'étude de l'historique des données extraites des dépôts de logiciels^[9].

La rétro-ingénierie a deux objectifs principaux : la redocumentation et la récupération du modèle de conception. La redocumentation a pour but de produire une vue alternative d'un modèle, au même niveau d'abstraction. La récupération du modèle de conception vise à recréer les modèles d'abstraction à partir du code source, de la documentation existante, de la connaissance des experts ainsi que toutes autres sources d'informations^[10]. Le but de la rétro-ingénierie d'un logiciel est d'améliorer sa compréhension globale, autant pour sa maintenance que pour son développement futur. Son analyse sera menée selon les axes suivants^[11]:

• faire face à la complexité : création de méthodes et outils, combinés aux environnements CASE^{[note 1]}, afin de fournir un moyen d'extraire des informations pertinentes ;
• générer des vues alternatives : les représentations graphiques sont considérées comme des aides à la compréhension ;
• récupérer l'information perdue : l'évolution d'un système de taille conséquente entraîne la perte d'information, les modifications ne sont généralement pas documentées ;
• détecter les effets de bord : la conception initiale ou les modifications successives peuvent entraîner des effets de bords involontaires ;
• créer des abstractions : la discipline nécessite des méthodes et outils afin de créer des abstractions à un niveau plus haut ;
• faciliter la ré-utilisation : la rétro-ingénierie peut aider à trouver des logiciels potentiellement ré-utilisables.

Au-delà de la maintenance logicielle, la rétro-ingénierie peut être utilisée dans d'autres domaines, notamment à des fins de tests ou d'audit de sécurité et de vulnérabilités^[3].

Une quantité significative de litiges légaux impliquant les logiciels informatiques se concentrent autour de la rétro-ingénierie^[12].

La législation est restée longtemps imprécise, avec des concepts mal compris^[12]. Là où auparavant le secret commercial se heurtait au manque de textes de loi (en témoigne le nombre d'articles sur le sujet au début des années 2000), la législation autour de la rétro-ingénierie trouve aujourd'hui ses réponses notamment autour de la jurisprudence. (cas Sega v. Accolade^[13] et Bowers v. Baystate Technologies (en) par exemple)

La légalité de la rétro-ingénierie dépend beaucoup de l'intention et du pays :

En Europe, la Computer Programs Directive (en) (Article 5 et 6^{[14],[15],[16]}, ainsi que la révision de 2009^[17]) tolère la rétro-ingénierie pour des buts d'interopérabilité, mais interdit toute reproduction commerciale ou la publication d'informations obtenues via rétro-ingénierie.

Aux États-Unis, la publication des brevets permet d'étudier un système sans rétro-ingénierie (mais empêche toujours l'exploitation commerciale). La rétro-ingénierie des logiciels, spécifiquement, est en général prohibée directement dans le CLUF^{[note 2]}, qui peut prévaloir sur certaines lois (voir Bowers v. Baystate Technologies (en)). Mais comme en Europe, le DMCA^{[note 3]} autorise la rétro-ingénierie pour l'interopérabilité^[18].

Au Japon, la loi japonaise sur le copyright (en) n'interdit pas explicitement la rétro-ingénierie. Elle précise cependant ne pas s'étendre aux langages de programmation, loi ou algorithmes^[19].

Enfin en Australie, autre grand acteur des technologies de l'information, la loi sur le copyright australienne (en) (notamment par son amendement de 2006), proscrit toute forme de contournement des protections faites pour empêcher la copie ou la reproduction, sauf dans des cas spécifiques tels que : étude/recherche, critique/journalisme, parodie, procédure judiciaire.

Une étude a été menée à l'université de Missouri-Rolla. Des cours sur les techniques de rétro-ingénierie et l'étude de produits réels ont été ajoutés au cursus. 77 % des étudiants pensent que ces cours ont renforcé les concepts présentés durant les cours magistraux. Et 82 % veulent que les cours futurs suivent également cette approche. Cela rend les cours plus pratiques, intéressants, et fun^[20].

Le premier avantage de l'enseignement de la rétro-ingénierie est une meilleure compréhension des concepts logiciels et du fonctionnement matériel. Effectivement, tous ces concepts sont cachés derrière notre OS^{[note 4]} et notre IDE^{[note 5]} préféré mais sont indispensables à tout informaticien. Il est extrêmement bénéfique de se plonger dans un code source inconnu, dans du matériel ou des protocoles qui nous sont étrangers. De plus, lire et analyser du code écrit par des programmeurs plus expérimentés est très formateur^[20].

Ensuite, l'évolution des technologies nous conduit à maintenir et migrer de plus en plus de systèmes hérités. Il faut donc comprendre et pouvoir modifier ces systèmes dont la compréhension n'est pas triviale. La rétro-ingénierie met à disposition un certain nombre d'outils qui permettent de résoudre ces problématiques. C'est pourquoi leur enseignement permet de former des ingénieurs capables de s'adapter à ces problématiques^[21].

Enfin, la rétro-ingénierie est l'art de disséquer, de s'auto-motiver, et de construire ses capacités de réflexion logique^[22].

Commencée avec le besoin de maintenance et modernisation des vieux logiciels^[23], la rétro-ingénierie s'est montrée un outil parfait pour pallier ce problème^[24]. Cependant, au-delà de cette nécessité économique, la rétro-ingénierie s'avère aussi indispensable pour plusieurs cas notables. On peut par exemple retrouver des applications sur des systèmes récents tels que iOS^[25], ou sur du matériel comme des circuits^[26] ou des semi-conducteurs^[1].

D'autres cas d'applications incluent la documentation d'un programme ou de ses bases de données relationnelles, l'identification d'éléments réutilisables, la restauration d'architecture, celle de patrons de conception, le calcul de l'impact d'un changement, le renouvellement des interfaces graphiques^[27], l'identification des clones, la traduction d'un programme, la réalisation d'une migration^[3]...

Il s'est révélé de plus en plus nécessaire, au fur et à mesure que les développeurs d'origine des systèmes déménageaient ou disparaissaient, de pouvoir comprendre et modifier l'existant^[28]. Il faut en effet comprendre les intentions du logiciel pour le moderniser et le porter sur des systèmes modernes, notamment avec l'avènement des applications web où d'anciennes applications sont converties vers ce nouveau support^[24]. Afin d'effectuer ces transitions, les abstractions des systèmes existants vers des langages de modélisation modernes tels que l'UML^{[note 6]} sont nécessaires^[29] Une fois le modèle extrait, il devient possible de l'implémenter sous une autre forme, selon le format de E. J. Byrne^[30].

La rétro-ingénierie occupe une place importante en sécurité informatique. Elle peut être utilisée autant pour l'attaque que pour la défense^[31]. Pour un attaquant, elle permettra de connaître les vulnérabilités d'un système. Pour un expert en sécurité, elle sera utilisée pour comprendre comment fonctionnent les programmes malicieux, tels que les virus, les rootkits ou d'autres types de menace^[32].

Dans la lutte contre la cybercriminalité le temps est très souvent un élément important, c'est pourquoi les méthodes de rétro-ingénierie en sécurité sont toujours en évolution pour pouvoir être maîtrisées et appliquées efficacement contre les menaces^[33].

Appliquer une rétro-ingénierie sur un élément ou un système complet reste un excellent moyen d'apprentissage^[21]. Mais ces études permettent aussi de réaliser l'interopérabilité de plusieurs autres éléments avec un système tiers. C'est aussi un vaste sujet de recherche dans l'objectif d'améliorer les outils de sécurité^[34], comme cité précédemment.

De nombreux outils et méthodes ont été créés afin d'aider les mainteneurs de logiciels à comprendre la structure et les comportements d'un système. Dans la plupart des cas, il n'est pas surprenant que ces outils soient développés, ou que leur développement soit largement influencé, par une application spécifique. Cela implique une disponibilité d'outils de rétro-ingénierie nombreux et variés, à la fois en termes de fonctionnalités, et de méthodes de visualisation fournies. Cependant, il est difficile de juger de l'efficacité de ces outils de manière objective, surtout lorsqu'il s'agit de prototype de recherche, développé comme des preuves de concept, en appuis de nouvelles méthodes^[6]. Comme la plupart des domaines d'application ont des caractéristiques uniques et spécialisées, il est essentiel que ces boîtes à outils doivent être à la fois extensibles et polyvalentes^[35].

Ces dernières années ont vu le développement de plusieurs techniques et outils d'analyse de programme. Certains d'entre eux se base sur l'analyse statique, tandis que les plus récents utilisent de plus en plus souvent l'analyse dynamique en complément. Bien que cette dernière puisse être chère et incomplète, elle est nécessaire pour faire face à de nombreux problème de rétro-ingénierie ou l'analyse statique seule ne suffise pas^[36]. Il est important de distinguer les méthodes et techniques d'un côté, et les outils de l'autre. En effet, une méthode ou technique est une solution pour un ou plusieurs problèmes connus (par exemple la récupération du modèle de conception). Un outil est une application qui implémente et supporte l'utilisation d'une ou de plusieurs méthodes. Autrement dit, chaque méthode peut être implémentée de différentes manières par plusieurs outils^[5].

Lors de l'évolution d'un logiciel, des changements sont appliqués au code source pour ajouter des fonctions, corriger des bogues, et en améliorer la qualité. Dans un système peu documenté, le code est la seule source d'information fiable. C'est pour cela que le processus de la rétro-ingénierie se focalise sur la compréhension du code. Cependant, il ne contient pas toutes les informations nécessaires. Typiquement la connaissance de l'architecture, les compromis de conception, les contraintes de développement, et les domaines d'application qui n'existent que dans l'esprit des développeurs. De plus, lorsque l'analyse ne se concentre qu'a un bas niveau d'abstraction, elle fait perdre la vision d'ensemble du système^[37]. Les recherches du début des années 1990 étaient axées sur la récupération des architectures de haut-niveau et sur les diagrammes à partir de code procédural. L'utilisation des langages orientés objet et le langage de modélisation unifié UML ont introduit le besoin de rétro-ingénierie des modèles UML à partir du code source^[38]. Le développement de ces langages a été accompagné par l'utilisation des patrons de conception. Du point de vue de la rétro-ingénierie, l'identification des patrons de conception dans le code source vise à promouvoir la réutilisation et l'évaluation de la qualité du code^[39].

Les protocoles réseaux régulent la communication entre plusieurs entités par la définition d'une syntaxe et une sémantique des messages, ainsi que l'ordre dans lequel ils doivent être échangés. Récupérer les spécifications d'un protocole peut jouer un rôle important dans certains contextes, comme lors de l'implémentation de mécanismes de défense tel que les pare-feu ou les systèmes de détection d'intrusion. Cependant il est difficile de produire ces spécifications, notamment pour les protocoles fermés ou non documentés, qui nécessitent l'utilisation de la rétro-ingénierie afin de déterminer le sens et la structure des messages^[40].

La sécurité logicielle des cartes à puce est un enjeu important si l'on considère l'usage élargi qu'elles ont depuis leur apparition (cartes bancaires, SIM^{[note 7]}, passeport...). La rétro-ingénierie est un moyen d'analyse des cartes à puce invasif et destructif. L'attaquant retire les couches de la carte les unes après les autres et les photographie à l'aide d'un microscope électronique. Avec cette technique, il est possible de révéler entièrement la partie logicielle et matérielle des cartes à puce. Le problème principal pour l'attaquant étant de tout replacer dans le bon ordre pour comprendre le fonctionnement de l'ensemble. Les ingénieurs essaient de dissimuler les clés et les opérations en mélangeant par exemple les positions de la mémoire, par exemple le brouillage de bus^[41]. Dans certains cas, il est possible d'utiliser une sonde afin de mesurer les voltages tant que la carte est encore opérationnelle. Ici, les ingénieurs utilisent des capteurs afin de détecter et d’empêcher ce type d'attaque^[42]. L'attaque par matériel personnalisé des cartes à puce est peu utilisée car elle requiert un gros investissement en termes d'efforts et d'équipements spécialisés, qui ne sont généralement disponibles qu'aux grands fabricants de puces. De plus, le bénéfice de cette attaque est faible de par l'utilisation d'autres techniques de sécurité telle que les shadow accounts.

Même si les moyens de rétro-ingénierie avancée tels que les microscopes électroniques restent inabordables pour le grand public, certains outils sont accessibles à tous. C'est le cas surtout pour les outils de rétro-ingénierie logicielle. Dans ce domaine, plusieurs débogueurs ou désassembleur se sont démocratisés. C'est le cas par exemple d'IDA Pro, qui reste le plus utilisé et le plus connu^[43]. En 2019, la NSA a publié son propre outil, Ghidra, jusque-là exclusivement interne.

Il est à noter que la plupart des outils se dirigent vers une abstraction à partir de l'implémentation du système, alors qu'il est tout à fait possible, sans outil, d'étudier et d'analyser des fragments d'un système : exigences, design, code, cas de test, pages de manuel, etc^[10]... afin de tirer des conclusions sur le système lui-même.

Actuellement, de nombreux logiciels (boîtes à outils) sont disponibles pour aider les rétro-ingénieurs dans leur travail. Par exemple, "the Design Maintenance System" (DMS) développé par Semantic Designs, TXL, la boîte à outils Stratego... mettent à disposition des outils pour parser le code source et effectuer des transformations automatiques basées sur des règles définies^[36].

Les logiciels d'analyse de code source qui ont été le plus développés durant ces dernières années sont les extracteurs d'informations, capables, avec ou sans le parsing du code source, d'extraire des informations intéressantes sur le code source analysé. are MOOSE, SrcML, Columbus, or Bauhaus sont autant de logiciels de ce type. La diffusion des différents extracteurs a souligné le besoin d'un schéma commun pour les représenter : GXL ou le métamodèle FAMIX utilisé dans MOOSE^[38].

De nombreux autres outils sont également mis à disposition tels que the Rigitool, CodeCrawler, Seesoft, SHriMP, et sv3D :

• the Rigitool permet de visualiser une vue de l'architecture globale du logiciel ;
• sv3D propose une vue 3D des métriques des logiciels analysés ;
• CodeCrawler combine l'affichage d'entités software et leurs relations, avec une vue des métriques du logiciel analysé ;
• Program Explorer permet la visualisation d'informations dynamique lors de l'exécution du programme : traces d'exécution^[8].

De nombreux outils sont également mis à disposition des chercheurs pour la rétro-ingénierie matérielle^[44]. On peut par exemple citer :

• l'analyse de circuits électroniques par Rayons X ;
• la décomposition des différentes couches matérielles grâce à des bains d'acide sulfurique ou par des bombardements d'ions ou par polissage ;
• l'analyse des couches matérielles au microscope électronique.

L'informatique étant omniprésente, la protection des données est devenue une priorité. Les données étant manipulées par des logiciels, souvent dans un environnement connecté, si le logiciel est vulnérable, les données le sont également. C'est pourquoi les applications sont devenues également une forme de donnée, qu'il faut protéger du vol et des usages malicieux^[45].

Étant donné l'investissement énorme en argent, temps, et capital intellectuel pour le développement d'un logiciel, la protection contre le piratage est un enjeu majeur de l'industrie du logiciel^[45].

Pour prévenir la distribution illégale de logiciels par des pirates, les développeurs vont essayer de placer certaines protections sur le programme. Un pirate va essayer, par rétroingénierie, d'enlever cette protection, et plus précisément, trouver et enlever le code qui implémente la protection, sans altérer le fonctionnement normal de l'application. Plusieurs méthodes de protection existent^[46] :

Les fichiers de licence

Les programmes utilisant cette protection vont vérifier l'existence, et la conformité d'un fichier de licence qui confirme l'authenticité de la copie. Contourner une telle protection nécessite de la rétro-ingénierie de l'application pour identifier le code qui effectue cette vérification et l'éliminer ou le contourner.

Protections matérielles

Il s'agit ici de contrôler la présence d'un composant matériel tel qu'un CD, un périphérique USB... La technique est similaire au fichier de licence, si ce n'est qu'il est possible d'ajouter du contenu indispensable à l'exécution de l'application sur le périphérique matériel. Dès lors, un simple contournement de la protection ne fonctionne pas. Cependant, on peut également effectuer de la rétro-ingénierie sur les périphériques matériels.

Tamperproofing

Il ne s'agit plus ici de vérifier si le logiciel a été acquis correctement ou non, mais plutôt de vérifier qu'il n'a pas été altéré. Que ce soit par un utilisateur malveillant, ou par un logiciel qui viendrait se "greffer" au programme. Dès qu'une modification non désirée est découverte, on va désactiver certaines, ou toutes les fonctionnalités du logiciel. Cette technique peut être implémentée dans le logiciel en soi, ou par un service tiers, comme le système d'exploitation par exemple. Plusieurs méthodes sont possibles pour implémenter cette technique : checksums, des gardes (logiciels) qui se vérifient entre eux, vérification de résultats intermédiaires de l'exécution d'un programme^[47] ...

Souvent, il est indispensable de cacher le code, le rendre difficile à lire. Cependant, rendre du code totalement impossible à lire n'est pas possible. Car avec beaucoup de temps et de ressources, on peut même reconstituer une application complexe sur base du code machine. Le but de l'offuscation est donc de rendre la rétro-ingénierie économiquement non viable, la rendre tellement complexe que cela couterait moins cher en temps et en ressources de réécrire l'application à partir de rien^[48].

Malgré le fait que l'offuscation puisse rendre le code moins efficace, il s'agit d'une technique relativement peu couteuse qui attire de plus en plus l'attention^[49].

Christian Collberg et Clark Thomborson ont classé les techniques d'offuscation en plusieurs catégories^[50] :

Lexicale

Il s'agit de modifier les noms de variables, méthodes, classes... pour enlever leur sens.

Contrôle

Lorsque le code est compilé, de nombreux prédicats peuvent être directement évalués et on peut ainsi couper une partie du code qui ne sera jamais exécuté. Il s'agit ici de rendre tous les prédicats non prédictibles à la compilation de sorte que le code soit plus complexe car non "nettoyé" lors de la compilation.

Données

Les données peuvent également être modifiées de sorte qu'elles soient décomposées en plusieurs morceaux. Une variable pourrait par exemple être décomposée en deux variables qu'il faut additionner pour trouver la valeur initiale.

Structurelle

Il s'agit de modifier la structure de l'application, en extrayant des morceaux de code en procédures, divisant les procédures existantes en sous-procédures...

Logiciels:

• (en) Martin Nečaský, « Reverse engineering of XML schemas to conceptual diagrams », APCCM '09 Proceedings of the Sixth Asia-Pacific Conference on Conceptual Modeling,‎ 2009 (ISBN 978-1-920682-77-4, lire en ligne)
• (en) Hugo Bruneliere, Jordi Cabot, Frédéric Jouault et Frédéric Madiot, « MoDisco: a generic and extensible framework for model driven reverse engineering », ASE '10 Proceedings of the IEEE/ACM international conference on Automated software engineering,‎ 2010 (ISBN 978-1-4503-0116-9, DOI 10.1145/1858996.1859032, lire en ligne)
• (en) Vinita, Amita Jain et Devendra K. Tayal, « On reverse engineering an object-oriented code into UML class diagrams incorporating extensible mechanisms », ACM SIGSOFT Software Engineering Notes,‎ 2008 (DOI 10.1145/1402521.1402527, lire en ligne)
• (en) Óscar Sánchez Ramón, Jesús Sánchez Cuadrado et Jesús García Molina, « Model-driven reverse engineering of legacy graphical user interfaces », ASE '10 Proceedings of the IEEE/ACM international conference on Automated software engineering,‎ 2010 (ISBN 978-1-4503-0116-9, DOI 10.1145/1858996.1859023, lire en ligne)
• (en) R. Kollmann, P. Selonen, E. Stroulia, T. Systa et A. Zundorf, « A study on the current state of the art in tool-supported UML-based static reverse engineering », Reverse Engineering, 2002. Proceedings. Ninth Working Conference on,‎ 2002 (DOI 10.1109/WCRE.2002.1173061, lire en ligne)
• (en) M.E. Joorabchi et A. Mesbah, « Reverse Engineering iOS Mobile Applications », Reverse Engineering (WCRE), 2012 19th Working Conference on,‎ 2012 (DOI 10.1109/WCRE.2012.27, lire en ligne)
• (en) C. Treude, F.F. Filho, M. Storey et M. Salois, « An Exploratory Study of Software Reverse Engineering in a Security Context », Reverse Engineering (WCRE), 2011 18th Working Conference on,‎ 2011 (DOI 10.1109/WCRE.2011.30, lire en ligne)
• (en) David R. Harris, Howard B. Reubenstein et Alexander S. Yeh, « Reverse engineering to the architectural level », ICSE '95 Proceedings of the 17th international conference on Software engineering,‎ 1995 (DOI 10.1145/225014.225032, lire en ligne)
• (en) Rudolf K. Keller, Reinhard Schauer, Sébastien Robitaille et Patrick Pagé, « Pattern-based reverse-engineering of design components », ICSE '99 Proceedings of the 21st international conference on Software engineering,‎ 1999 (DOI 10.1145/302405.302622, lire en ligne)
• (en) Michele Lanza et Stephane Ducasse, « Polymetric views - A lightweight visual approach to reverse engineering », Software, IEEE (Volume:29, Issue: 9),‎ 2003 (DOI 10.1109/TSE.2003.1232284, lire en ligne)
• (en) Rainer Koschke, « Software visualization in software maintenance, reverse engineering, and re-engineering: a research survey », Journal of Software Maintenance and Evolution: Research and Practice (Volume:15, Issue: 2),‎ 2003 (DOI 10.1002/smr.270, lire en ligne)

Matériel:

• (en) Randy Torrance et Dick James, « The state-of-the-art in semiconductor reverse engineering », DAC '11 Proceedings of the 48th Design Automation Conference,‎ 2011 (ISBN 978-1-4503-0636-2, DOI 10.1145/2024724.2024805, lire en ligne)
• (en) J. Kumagai, « Chip detectives [reverse engineering] », Spectrum, IEEE (Volume:37, Issue: 11),‎ 2000 (DOI 10.1109/6.880953, lire en ligne)
• (en) K. Carlson et B. Hauptmann, « Reverse engineering for board test », AUTOTESTCON, 2009 IEEE,‎ 2009 (DOI 10.1109/AUTEST.2009.5314092, lire en ligne)
• (en) Pramod Subramanyan, Nestan Tsiskaridze, Kanika Pasricha, Dillon Reisman, Adriana Susnea et Sharad Malik, « Reverse engineering digital circuits using functional analysis », DATE '13 Proceedings of the Conference on Design, Automation and Test in Europe,‎ 2013 (ISBN 978-1-4503-2153-2, lire en ligne)

(en) Wolfgang Rankl et Wolfgang Effing, Smart Card Handbook, Wiley, 2004, 1120 p. (ISBN 978-0-470-85669-7, présentation en ligne)

• (en) David C. Musker, « Protecting & Exploiting Intellectual Property in Electronics », IBC Conferences, 10 June 1998,‎ 1998 (lire en ligne)

Protocole:

• (en) J. Antunes, N. Neves et P. Verissimo, « Reverse Engineering of Protocols from Network Traces », Reverse Engineering (WCRE), 2011 18th Working Conference on,‎ 2011 (DOI 10.1109/WCRE.2011.28, lire en ligne)
• (en) Juan Caballero, Pongsin Poosankam, Christian Kreibich et Dawn Song, « Dispatcher: enabling active botnet infiltration using automatic protocol reverse-engineering », CCS '09 Proceedings of the 16th ACM conference on Computer and communications security,‎ 2009 (ISBN 978-1-60558-894-0, DOI 10.1145/1653662.1653737, lire en ligne)

Sémantique:

• (en) A. Kuhn, S. Ducasse et T. Girba, « Enriching reverse engineering with semantic clustering », Reverse Engineering, 12th Working Conference on,‎ 2005 (DOI 10.1109/WCRE.2005.16, lire en ligne)

Description:

• (en) Elliot J. Chikofsky et James H. Cross II, « Reverse engineering and design recovery: a taxonomy », Software, IEEE (Volume:7, Issue: 1),‎ 1990 (DOI 10.1109/52.43044, lire en ligne)
• (en) Paolo Tonella, Marco Torchiano, Bart Du Bois et Tarja Systä, « Empirical studies in reverse engineering: state of the art and future trends », Empirical Software Engineering (Volume : 12, Issue : 5),‎ 2007 (DOI 10.1007/s10664-007-9037-5, lire en ligne)
• (en) Erich Buss et John Henshaw, « A software reverse engineering experience », CASCON '10 CASCON First Decade High Impact Papers,‎ 1991 (DOI 10.1145/1925805.1925808, lire en ligne)
• (en) Hausi A. Müller, Jens H. Jahnke, Dennis B. Smith, Margaret-Anne Storey, Scott R. Tilley et Kenny Wong, « Reverse engineering: a roadmap », ICSE '00 Proceedings of the Conference on The Future of Software Engineering,‎ 2000 (ISBN 1-58113-253-0, DOI 10.1145/336512.336526, lire en ligne)
• (en) Gerardo Canfora et Massimiliano Di Penta, « New Frontiers of Reverse Engineering », FOSE '07 2007 Future of Software Engineering,‎ 2007 (ISBN 0-7695-2829-5, DOI 10.1109/FOSE.2007.15, lire en ligne)
• (en) Steven She, Rafael Lotufo, Thorsten Berger, Andrzej Wąsowski et Krzysztof Czarnecki, « Reverse engineering feature models », ICSE '11 Proceedings of the 33rd International Conference on Software Engineering,‎ 2011 (DOI 10.1145/1985793.1985856, lire en ligne)

Éducation:

• (en) Muhammad Raza Ali, « Why teach reverse engineering? », ACM SIGSOFT Software Engineering Notes,‎ 2005 (DOI 10.1145/1082983.1083004, lire en ligne)
• (en) William Mahoney et Robin A. Gandhi, « Reverse engineering: is it art? », ACM Inroads,‎ 2012 (ISSN 2153-2184, DOI 10.1145/2077808.2077826, lire en ligne)
• (en) P. Fagette, « Reverse Engineering by Design : Using History to Teach », Pulse, IEEE (Volume:4, Issue: 1),‎ 2005 (DOI 10.1109/MPUL.2012.2228596, lire en ligne)
• (en) I. Klimek, M. Keltika et F. Jakab, « Reverse engineering as an education tool in computer science », Emerging eLearning Technologies and Applications (ICETA), 2011 9th International Conference on,‎ 2011 (DOI 10.1109/ICETA.2011.6112599, lire en ligne)

Légal:

• (en) Brian C. Behrens et Reuven R. Levary, « Practical legal aspects of software reverse engineering », Communications of the ACM,‎ 1998 (DOI 10.1145/269012.269017, lire en ligne)
• (en) Pamela Samuelson, « Reverse engineering under siege », Communications of the ACM,‎ 2002 (DOI 10.1145/570907.570919, lire en ligne)
• (en) C. Cifuentes et A. Fitzgerald, « Is reverse engineering always legal? », IT Professional (Volume:1, Issue: 2),‎ 1999 (DOI 10.1109/6294.774940, lire en ligne)
• (en) « Council Directive 91/250/EEC of 14 May 1991 on the legal protection of computer programs », Eur-lex.europa.eu, 1991 (consulté le 29 mai 2011)
• (en) P. B. Hugenholtz, « The future of the public domain: identifying the commons in information law », Kluwer Law International, 2006 (ISBN 978-90-411-2435-7, consulté le 29 mai 2011), p. 321
• (en) Jenkins, « Trade Mark and Patent Attorneys », Jenkins.eu (consulté le 29 mai 2011)
• (en) « DIRECTIVE 2009/24/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 23 April 2009 on the legal protection of computer programs », 2009 (consulté le 29 mai 2011)
• (en) « 17 USC § 1201 - Circumvention of copyright protection systems », Cornell University Law School, 1998 (consulté le 3 décembre 2013)
• « Le reverse engineering (ou rétro-ingénierie) expliqué », Qualys Security Community, 2008 (consulté le 3 décembre 2013)

Offuscation:

• (en) C.S. Collberg et C. Thomborson, « Watermarking, tamper-proofing, and obfuscation - tools for software protection », IEEE Transactions on Software Engineering, vol. 28, n^o 8,‎ 28 août 2002, p. 735–746 (DOI 10.1109/TSE.2002.1027797, lire en ligne, consulté le 11 février 2013)
• (en) Cullen Linn et Saumya Debray, « Obfuscation of executable code to improve resistance to static disassembly », CCS '03 Proceedings of the 10th ACM conference on Computer and communications security,‎ 2003 (ISBN 1-58113-738-9, DOI 10.1145/948109.948149, lire en ligne)
• (en) Praveen Sivadasan, P SojanLal et Naveen Sivadasan, « JDATATRANS for array obfuscation in Java source codes to defeat reverse engineering from decompiled codes », COMPUTE '09 Proceedings of the 2nd Bangalore Annual Compute Conference,‎ 2009 (ISBN 978-1-60558-476-8, DOI 10.1145/1517303.1517318, lire en ligne)
• (en) Gleb Naumovich et Nasir Memon, « Preventing piracy, reverse engineering, and tampering », Computer, IEEE (Volume:36, Issue: 7),‎ 2003 (DOI 10.1109/MC.2003.1212692, lire en ligne)

Outils:

• (en) Markus von Detten, Matthias Meyer et Dietrich Travkin, « Reverse engineering with the reclipse tool suite », ICSE '10 Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering - Volume 2,‎ 2010 (ISBN 978-1-60558-719-6, DOI 10.1145/1810295.1810360, lire en ligne)
• (en) Vitaly Chipounov et George Candea, « Reverse engineering of binary device drivers with RevNIC », EuroSys '10 Proceedings of the 5th European conference on Computer systems,‎ 2010 (ISBN 978-1-60558-577-2, DOI 10.1145/1755913.1755932, lire en ligne)
• (en) Cory Q. Nguyen et James E. Goldman, « Malware analysis reverse engineering (MARE) methodology & malware defense (M.D.) timeline », InfoSecCD '10 2010 Information Security Curriculum Development Conference,‎ 2010 (ISBN 978-1-4503-0202-9, DOI 10.1145/1940941.1940944, lire en ligne)
• (en) Rudolf Ferenc, Arpad Beszedes, Mikko Tarkiainen et Tibor Gyimothy, « Columbus - reverse engineering tool and schema for C++ », Software Maintenance, 2002. Proceedings. International Conference on,‎ 2002 (DOI 10.1109/ICSM.2002.1167764, lire en ligne)
• (en) Tarja Systä, Kai Koskimies et Hausi Müller, « Shimba—an environment for reverse engineering Java software systems », Software: Practice and Experience (Volume: 31, Issue: 4),‎ 2001 (DOI 10.1002/spe.386, lire en ligne)
• (en) Nija Shi et Ronald A. Olsson, « Reverse Engineering of Design Patterns from Java Source Code », Automated Software Engineering, 2006. ASE '06. 21st IEEE/ACM International Conference on,‎ 2006 (DOI 10.1109/ASE.2006.57, lire en ligne)
• (en) Giuseppe Antonio Di Lucca, Anna Rita Fasolino et Porfirio Tramontana, « WARE: a tool for the reverse engineering of Web applications », Software Maintenance and Reengineering, 2002. Proceedings. Sixth European Conference on,‎ 2002 (DOI 10.1109/CSMR.2002.995811, lire en ligne)
• (en) Aoun Raza, Gunther Vogel et Erhard Plödereder, « Bauhaus – A Tool Suite for Program Analysis and Reverse Engineering », Lecture Notes in Computer Science Volume 4006,‎ 2006 (DOI 10.1007/11767077_6, lire en ligne)
• (en) E. J. Byrne, « A Conceptual Foundation for Software Re-Engineering », ICSM,‎ 1992 (DOI 10.1109/ICSM.1992.242539, lire en ligne)

• Portail de l’informatique