Doctorant :
Stéphane Colmire
Voir le profil
Intitulé
Rétro-ingéniérie et problèmes inverses
Thèse dirigée par :
Dominique Raynaud
Résumé :
Cette recherche a pour objectif d’examiner la portée et les limites de la rétro- ingénierie informatique matérielle (moins étudiée que la rétro-ingénierie logicielle) en envisageant son rapport aux problèmes inverses.
Définitions
On ne dispose d’aucune définition satisfaisante de la rétro-ingénierie. On peut dire provisoirement que la rétro-ingénierie part d’un donné empirique et s’efforce d’en comprendre la conception. A ce titre, elle affronte des problématiques analogues aux problèmes inverses en science. Appliquée aux artefacts technologiques, la rétro-ingénierie postule que schémas techniques et les diagrammes constructeurs sont incomplets et qu’en fonctionnement le matériel présentera un écart révélateur d’erreurs de conception ou de données non documentées. Partant, elle se donne pour finalité de compléter les schémas techniques conçus par ingénierie en soumettant les artefacts qui en sont issus à des tests. Dans le domaine informatique, la rétro-ingénierie peut aider à améliorer la fiabilité des processeurs pour ce qu’ils font le mieux: le calcul. Les constructeurs n’ont de cesse d’ajouter des jeux d’instructions à ceux de base, et ce n’est pas toujours sans conséquence. On se souvient du « bogue » de la division du calcul en virgule flottante chez Intel qui amena chercheurs et ingénieurs à exiger des garanties dans l’implémentation matérielle des algorithmes. Surtout, les recherches en mathématiques sont susceptibles de profiter à ces calculateurs ultra-rapides que sont les ordinateurs. D’un autre côté, le terme de problème inverse désigne toute activité cognitive, pure ou appliquée, qui regarde des indices comme les conséquences d’une cause à découvrir. Plus formellement, les « problèmes inverses » s’opposent aux « problèmes directs » dans ces définitions: Définition 1: Un problème direct est un problème dont la recherche suit la séquence logique ou le cours des événements des prémisses à la conclusion, ou de la cause aux effets. Définition 2: Un problème inverse est un problème dont la recherche remonte la séquence logique ou le cours des événements de la conclusion aux prémisses, ou des effets aux causes (Bunge 2006: 150). De la découverte des lois physiques à l’établissement du diagnostic médical, de la spectroscopie à l’enquête policière, les exemples de problèmes inverses abondent dans toutes les sphères d’activité, mais il existe assez peu de travaux consacrés aux aspects épistémologiques impliqués par cette classe de problèmes.
Cadre de la thèse
La recherche prendra appui sur un ensemble de travaux portant d’une part sur l’informatique (Domas 2017) et la technologie (Raynaud 2016a), d’autre part sur l’épistémologie des problèmes inverses. Cette dernière est développée au carrefour de l’épistémologie interne issue des domaines où la notion de problème inverse est connue (Ulhmann 2003; Woodbury 2003) et de l’épistémologie professionnelle, en particulier celle de Mario Bunge, qui est l’un des rares philosophes à avoir étudié le sujet (Bunge 2006, 2012). L’orientation de la thèse relève principalement de l’épistémologie de la technologie: il s’agira étudier les modes de raisonnement utilisés par les ingénieurs dans la rétro-ingénierie informatique et, plus généralement, les modes de raisonnement impliqués par les problèmes inverses dans d’autres domaines.
Méthode : Comparaison avec les problèmes inverses.
Nous essaierons de caractériser les particularités de la rétro-ingénierie informatique en la comparant à plusieurs problèmes inverses connus. Les problèmes inverses sont nombreux: reconstruction des géométraux à partir des vues perspectives (Degl’Innocenti 1985; García-Salgado 2005; Kourniatis 2019 versus Raynaud 2016b, 2021), déchiffrement des langues écrites disparues par Champollion (Champollion 1822-1833) puis François Desset (Desset 2020), etc. Il faudra au préalable définir des critères de sélection des problèmes inverses utilisés dans la comparaison. Le plan de partage interne qui sépare la rétroingénierie matérielle et la rétroingénierie logique, pourrait informer cette sélection: 1. Les méthodes de rétroingénierie matérielle sont en général destructives pour l’artefact utilisé. Toutefois, de nouvelles méthodes non destructives sont à l’étude. Il s’agit par exemple des méthodes de laminographie ptychographique aux rayons X (Ptychographic X-Ray laminography) qui consistent à bombarder une puce électronique par un rayonnement pour n reconstruire une image 3D, et détecter d’éventuels défauts de fabrication (Bachelot 2021). 2. Les méthodes de rétroingénierie logique ne sont pas destructives. Il s’agit ici d’entrer des données aléatoires dans un système pour en reconstituer le fonctionnement. L’exemple central est ici celui des travaux menés par Alan Turing (Turing 1939-1942) pour casser le code ENIGMA, et ceux de Christopher Domas sur le fuzzing pour tester des logiciels) (Domas 2017). Les catégories: « méthodes destructives/non destructives » et « méthodes matérielles/logiques » sont applicables à d’autres problèmes inverses. Par exemple, les méthodes de caractérisation des pigments utilisés sur les tableaux peuvent être chimiques (destructives) ou optiques (non-destructives) (Hayem 2015). Les méthodes de déchiffrement des hiéroglyphes par Champollion, ou plus récemment de l’élamite linéaire, par François Desset, sont des méthodes logiques, non matérielles. Une fois la base de problèmes inverses constituée, elle permettra de tester l’existence de propriétés transversales, permettant de savoir si la rétroingénierie informatique est une classe de problèmes inverses ou si elle présente des caractères particuliers, irréductibles aux problèmes inverses.
Attendus de la thèse
Une question centrale est celle de l’effectivité de la rétro-ingénierie informatique. Dans son article Breaking the x86 ISA (Domas 2017), Christopher Domas déplore l’absence de processus établis, standardisés, en matière de rétro-ingénierie matérielle. L’inclusion de la rétro-ingénierie dans la classe des problèmes inverses est susceptible d’éclairer ce diagnostic. En effet, pour pouvoir aboutir à une solution par voie inverse, les problèmes doivent avoir une certaine structure et remplir certaines conditions. C’est la question de « l’inversibilité » (invertibility). Celle-ci se définit par la structure du problème direct correspondant: « Si la solution à un problème direct est une carte 1:1 comme la fonction exponentielle, alors la solution au problème inverse correspondant existe et est unique » (Bunge 2006: 159). On distingue sur cette base, les problèmes inverses qui ont une solution unique (type 1) et ceux qui ont des solutions multiples (type 2). Tous les problèmes inverses n’ont donc pas nécessairement une solution. Les problèmes inverses de type 2 ne peuvent être résolus qu’en faisant un certain nombre d’hypothèses additionnelles. Cette structure est analogue à celle qu’on rencontre dans l’analyse de la causalité. La cartographie des particularités de la rétro-ingénierie informatique et l’élucidation de ses rapports aux problèmes inverses, devraient permettre d’évaluer les enjeux de la rétro-ingénierie informatique et de réinterpréter les difficultés auxquelles elle fait face.
Financements :
Autofinancement