Reverse engineering de MCU

Remarque : tous les logiciels sont protégés par un mot de passe. Après avoir téléchargé le code, veuillez nous envoyer un e-mail, Mikatech vous enverra le mot de passe.

 

Un désassembleur est un programme informatique qui traduit le langage machine en langage assembleur — l'opération inverse de celle d'un assembleur. Un désassembleur diffère d'un décompilateur, qui cible un langage de haut niveau plutôt qu'un langage assembleur. Le désassemblage, la sortie d'un désassembleur, est souvent formaté pour la lisibilité humaine plutôt que pour une entrée dans un assembleur, ce qui en fait principalement un outil de reverse engineering.

Le code source en langage assembleur permet généralement l'utilisation de constantes et de commentaires du programmeur. Ceux-ci sont généralement supprimés du code machine assemblé par l'assembleur. Si c'est le cas, un désassembleur opérant sur le code machine produirait un désassemblage dépourvu de ces constantes et commentaires ; la sortie désassemblée devient plus difficile à interpréter pour un humain que le code source annoté original. Certains désassembleurs utilisent les informations de débogage symbolique présentes dans les fichiers objets tels que ELF. L'Interactive Disassembler permet à l'utilisateur humain de créer des symboles mnémoniques pour des valeurs ou des régions de code lors d'une session interactive : l'intuition humaine appliquée au processus de désassemblage rejoint souvent la créativité humaine dans le processus d'écriture de code.

Le désassemblage n'est pas une science exacte : sur les plates-formes CISC avec des instructions de largeur variable, ou en présence de code auto-modifiant, il est possible qu'un même programme ait deux ou plusieurs désassemblages raisonnables. Déterminer quelles instructions seraient réellement rencontrées lors de l'exécution d'un programme se réduit au problème de l'arrêt, qui est prouvé insoluble.

Écrire un désassembleur qui produit du code qui, une fois assemblé, produit exactement le binaire original est possible ; cependant, il y a souvent des différences. Cela pose des exigences sur l'expressivité de l'assembleur. Par exemple, un assembleur x86 fait un choix arbitraire entre deux codes binaires pour quelque chose d'aussi simple que "MOV AX,BX". Si le code original utilise l'autre choix, le code original ne peut tout simplement pas être reproduit à un moment donné. Cependant, même lorsqu'un désassemblage parfaitement correct est produit, des problèmes subsistent si le programme nécessite une modification. Par exemple, la même instruction de saut en langage machine peut être générée par un code assembleur pour sauter vers un emplacement spécifié (par exemple, pour exécuter un code spécifique), ou pour sauter d'un nombre spécifié d'octets (par exemple, pour sauter par-dessus une branche indésirable). Un désassembleur ne peut pas savoir ce qui est prévu, et peut utiliser l'une ou l'autre syntaxe, générant un désassemblage qui reproduit le binaire original[citation nécessaire]. Cependant, si un programmeur veut ajouter des instructions entre l'instruction de saut et sa destination, il est nécessaire de comprendre le fonctionnement du programme pour déterminer si le saut doit être absolu ou relatif, c'est-à-dire si sa destination doit rester à un emplacement fixe, ou être déplacée pour sauter à la fois les instructions originales et ajoutées.

 

Exemples de désassembleurs

Un désassembleur peut être autonome ou interactif. Un désassembleur autonome, lorsqu'il est exécuté, génère un fichier en langage assembleur qui peut être examiné ; un désassembleur interactif montre immédiatement l'effet de chaque changement effectué par l'utilisateur. Par exemple, le désassembleur peut initialement ne pas savoir qu'une section du programme est en réalité du code, et la traiter comme des données ; si l'utilisateur spécifie qu'il s'agit de code, le code désassemblé résultant s'affiche immédiatement, permettant à l'utilisateur de l'examiner et de prendre d'autres mesures lors de la même session.
Tout débogueur interactif inclura un moyen de visualiser le désassemblage du programme en cours de débogage. Souvent, le même outil de désassemblage sera fourni comme un désassembleur autonome distribué avec le débogueur. Par exemple, objdump, qui fait partie de GNU Binutils, est lié au débogueur interactif gdb.

IDA
OllyDbg est un débogueur d'analyse au niveau assembleur 32 bits
OLIVER et SIMON incluent des désassembleurs pour Assembleur, COBOL et PL/1

 

 

Décompilateur

Un décompilateur est un programme informatique qui effectue l'opération inverse de celle d'un compilateur. C'est-à-dire qu'il traduit un code programme à un niveau d'abstraction relativement bas (généralement conçu pour être lisible par une machine plutôt que par un humain) en une forme ayant un niveau d'abstraction plus élevé (généralement conçu pour être lisible par un humain). Les décompilateurs ne reconstruisent généralement pas parfaitement le code source original, et peuvent varier considérablement dans l'intelligibilité de leurs sorties. Néanmoins, les décompilateurs restent un outil important dans le reverse engineering logiciel.

Le terme décompilateur est le plus souvent appliqué à un programme qui traduit des programmes exécutables (la sortie d'un compilateur) en code source dans un langage de (relativement) haut niveau qui, une fois compilé, produira un exécutable dont le comportement est le même que le programme exécutable original. En comparaison, un désassembleur traduit un programme exécutable en langage assembleur (et un assembleur pourrait être utilisé pour le réassembler en un programme exécutable).
La décompilation est l'action d'utiliser un décompilateur, bien que le terme puisse également désigner la sortie d'un décompilateur. Elle peut être utilisée pour la récupération de code source perdu, et est également utile dans certains cas pour la sécurité informatique, l'interopérabilité et la correction d'erreurs.[1][source non fiable] Le succès de la décompilation dépend de la quantité d'informations présentes dans le code en cours de décompilation et de la sophistication de l'analyse effectuée sur celui-ci. Les formats de bytecode utilisés par de nombreuses machines virtuelles (comme la Java Virtual Machine ou le Common Language Runtime de .NET Framework) incluent souvent des métadonnées étendues et des fonctionnalités de haut niveau qui rendent la décompilation tout à fait réalisable. La présence de données de débogage peut permettre de reproduire les noms de variables et de structures originaux et même les numéros de ligne. Le langage machine sans ces métadonnées ou données de débogage est beaucoup plus difficile à décompiler.[2]
Certains compilateurs et outils de post-compilation produisent du code obfusqué (c'est-à-dire qu'ils tentent de produire une sortie très difficile à décompiler). Cela est fait pour rendre plus difficile le reverse engineering de l'exécutable.

 

Conception

Les décompilateurs peuvent être considérés comme composés d'une série de phases, chacune contribuant à des aspects spécifiques du processus global de décompilation.

 

Chargeur

La première phase de décompilation charge et analyse le format de fichier binaire du code machine ou du programme en langage intermédiaire d'entrée. Il doit être capable de découvrir des faits de base sur le programme d'entrée, tels que l'architecture (Pentium, PowerPC, etc.) et le point d'entrée. Dans de nombreux cas, il doit être capable de trouver l'équivalent de la fonction main d'un programme C, qui est le début du code écrit par l'utilisateur. Cela exclut le code d'initialisation d'exécution, qui ne doit pas être décompilé si possible. Si disponibles, les tables de symboles et les données de débogage sont également chargées. Le front-end peut être capable d'identifier les bibliothèques utilisées même si elles sont liées au code, cela fournira les interfaces des bibliothèques. S'il peut déterminer le ou les compilateurs utilisés, cela peut fournir des informations utiles pour identifier les idiomes de code.

 

Désassemblage

La phase logique suivante est le désassemblage des instructions en code machine dans une représentation intermédiaire (IR) indépendante de la machine. Par exemple, l'instruction machine Pentium
mov eax, [ebx+0x04]
pourrait être traduite en IR
eax := m[ebx+4];

 

Idiomes

Les séquences de code machine idiomatiques sont des séquences de code dont la sémantique combinée n'est pas immédiatement apparente à partir de la sémantique individuelle des instructions. Soit dans le cadre de la phase de désassemblage, soit dans le cadre d'analyses ultérieures, ces séquences idiomatiques doivent être traduites en IR équivalent connu. Par exemple, le code assembleur x86 :
cdq eax ; edx est défini comme l'extension de signe de eax
xor eax, edx
sub eax, edx
pourrait être traduit en
eax := abs(eax);
Certaines séquences idiomatiques sont indépendantes de la machine ; certaines impliquent une seule instruction. Par exemple, xor eax, eax efface le registre eax (le met à zéro). Cela peut être implémenté avec une règle de simplification indépendante de la machine, telle que a xor a = 0.
En général, il est préférable de retarder la détection des séquences idiomatiques si possible, vers des étapes ultérieures moins affectées par l'ordre des instructions. Par exemple, la phase de planification des instructions d'un compilateur peut insérer d'autres instructions dans une séquence idiomatique, ou modifier l'ordre des instructions dans la séquence. Un processus de correspondance de motifs dans la phase de désassemblage ne reconnaîtrait probablement pas le motif modifié. Les phases ultérieures regroupent les expressions d'instructions en expressions plus complexes et les modifient en une forme canonique (standardisée), ce qui rend plus probable que même l'idiome modifié corresponde à un motif de niveau supérieur plus tard dans la décompilation.
Il est particulièrement important de reconnaître les idiomes de compilateur pour les appels de sous-programmes, la gestion des exceptions et les instructions switch. Certains langages ont également un support étendu pour les chaînes ou les entiers longs.

 

Analyse de programme

Diverses analyses de programme peuvent être appliquées à l'IR. En particulier, la propagation d'expressions combine la sémantique de plusieurs instructions en des expressions plus complexes. Par exemple,
mov eax,[ebx+0x04]
add eax,[ebx+0x08]
sub [ebx+0x0C],eax

pourrait donner l'IR suivant après la propagation d'expressions :
m[ebx+12] := m[ebx+12] - (m[ebx+4] + m[ebx+8]);

L'expression résultante est plus proche du langage de haut niveau et a également éliminé l'utilisation du registre machine eax. Des analyses ultérieures peuvent éliminer le registre ebx.

 

Analyse de flux de données

Les endroits où le contenu des registres est défini et utilisé doivent être tracés à l'aide d'une analyse de flux de données. La même analyse peut être appliquée aux emplacements utilisés pour les variables temporaires et les données locales. Un nom différent peut alors être formé pour chaque ensemble connecté de définitions et d'utilisations de valeurs. Il est possible que le même emplacement de variable locale ait été utilisé pour plusieurs variables différentes dans différentes parties du programme original. Pire encore, il est possible que l'analyse de flux de données identifie un chemin par lequel une valeur peut circuler entre deux de ces utilisations même si cela ne se produirait jamais ou n'aurait pas d'importance en réalité. Cela peut, dans de mauvais cas, conduire à devoir définir un emplacement comme une union de types. Le décompilateur peut permettre à l'utilisateur de rompre explicitement ces dépendances non naturelles, ce qui conduira à un code plus clair. Cela signifie bien sûr qu'une variable est potentiellement utilisée sans être initialisée et indique donc un problème dans le programme original.

 

Analyse de type

Un bon décompilateur de code machine effectuera une analyse de type. Ici, la façon dont les registres ou les emplacements mémoire sont utilisés entraîne des contraintes sur le type possible de l'emplacement. Par exemple, une instruction and implique que l'opérande est un entier ; les programmes n'utilisent pas une telle opération sur des valeurs à virgule flottante (sauf dans des bibliothèques spéciales) ou sur des pointeurs. Une instruction add entraîne trois contraintes, car les opérandes peuvent être tous deux des entiers, ou un entier et un pointeur (avec des résultats entier et pointeur respectivement ; la troisième contrainte vient de l'ordre des deux opérandes lorsque les types sont différents).

Diverses expressions de haut niveau peuvent être reconnues, ce qui déclenche la reconnaissance de structures ou de tableaux. Cependant, il est difficile de distinguer de nombreuses possibilités, en raison de la liberté que le code machine ou même certains langages de haut niveau comme C autorisent avec les casts et l'arithmétique des pointeurs.

L'exemple de la section précédente pourrait donner le code de haut niveau suivant :
struct T1 *ebx;
struct T1 {
int v0004;
int v0008;
int v000C;
};
ebx->v000C -= ebx->v0004 + ebx->v0008;

 

Structuration

L'avant-dernière phase de décompilation implique la structuration de l'IR en constructions de niveau supérieur telles que les boucles while et les instructions conditionnelles if/then/else. Par exemple, le code machine
xor eax, eax
l0002:
or ebx, ebx
jge l0003
add eax,[ebx]
mov ebx,[ebx+0x4]
jmp l0002
l0003:
mov [0x10040000],eax
pourrait être traduit en :
eax = 0;
while (ebx < 0) {
eax += ebx->v0000;
ebx = ebx->v0004;
}
v10040000 = eax;

Le code non structuré est plus difficile à traduire en code structuré que le code déjà structuré. Les solutions incluent la duplication de certains codes ou l'ajout de variables booléennes.

 

Génération de code

La phase finale est la génération du code de haut niveau dans le backend du décompilateur. Tout comme un compilateur peut avoir plusieurs backends pour générer du code machine pour différentes architectures, un décompilateur peut avoir plusieurs backends pour générer du code de haut niveau dans différents langages de haut niveau.

Juste avant la génération de code, il peut être souhaitable de permettre une édition interactive de l'IR, peut-être en utilisant une forme d'interface utilisateur graphique. Cela permettrait à l'utilisateur d'entrer des commentaires et des noms de variables et de fonctions non génériques. Cependant, ceux-ci sont presque aussi facilement saisis dans une édition post-décompilation. L'utilisateur peut vouloir modifier des aspects structurels, comme convertir une boucle while en boucle for. Ceux-ci sont moins facilement modifiables avec un simple éditeur de texte, bien que les outils de refactorisation de code source puissent aider dans ce processus. L'utilisateur peut avoir besoin d'entrer des informations qui n'ont pas été identifiées lors de la phase d'analyse de type, par exemple en modifiant une expression mémoire en une expression de tableau ou de structure. Enfin, un IR incorrect peut devoir être corrigé, ou des modifications apportées pour rendre le code de sortie plus lisible.