jjyg/metasmCeci est le dépôt principal de metasm, un assembleur / désassembleur / compilateur gratuit écrit en ruby
Auteur : Yoann Guillot
Aperçu de base :
Metasm vous permet d'interagir avec les formats d'exécutables (ExeFormat) : PE, ELF, Mach-O, Shellcode, etc. Il existe trois approches pour un ExeFormat :
Des scripts prêts à l'emploi se trouvent dans le sous-répertoire samples/, consultez les commentaires dans les en-têtes des scripts. Vous pouvez aussi essayer l'argument --help si vous vous sentez chanceux.
Pour plus d'informations, consultez le sous-répertoire doc/. Les fichiers texte peuvent être compilés en html à l'aide du script misc/txt2html.rb.
Voici un bref aperçu des composants internes de Metasm.
Assemblage :
Lors de la compilation, vous partez d'un texte source (String ruby, consistant principalement en une séquence d'instructions/données/directives de bourrage), qui est analysé.
La chaîne est confiée à une instance de Preprocessor (qui gère #if, #ifdef, #include, #define, /* */ etc., et devrait être 100 % compatible avec gcc -E), laquelle est encapsulée dans un AsmPreprocessor pour les sources assembleur (afin de gérer les définitions de macros asm, 'equ' et les commentaires asm ';'). L'interface pour cela est ExeFormat#parse(text[, filename, lineno]) ou ExeFormat.assemble (qui appelle .new, #parse et #assemble).
Le (Asm)Preprocessor renvoie des jetons à l'ExeFormat, qui les analyse comme des Data, Padding, Labels ou directives d'analyse. Les directives d'analyse commencent toujours par un point. Elles peuvent être génériques (.pad, .offset...) ou spécifiques à l'ExeFormat (.section, .import, .entrypoint...). Elles sont gérées par #parse_parser_instruction(). Si l'ExeFormat ne reconnaît pas un mot, il est transmis à son instance CPU, qui est responsable de l'analyse des instructions (ou lève une exception). Tous ces jetons sont stockés dans un ou plusieurs tableaux dans l'attribut @source de l'ExeFormat (le @source de Shellcode est un Array, pour PE/ELF c'est un hash [nom de section] => [Array de données analysées]). Chaque valeur immédiate peut être une Expression arbitraire (voir plus loin).
Vous pouvez ensuite assembler la source en sections binaires à l'aide de ExeFormat#assemble.
Une fois les binaires de section disponibles, l'exécutable binaire complet peut être écrit sur le disque à l'aide de ExeFormat#encode_file(filename[, format]).
PE et ELF incluent une fonctionnalité d'autoimport qui permet la création automatique de données liées aux imports pour des fonctions connues spécifiques à l'OS (par exemple, les appels non résolus à 'strcpy' généreront des données afin que le binaire soit lié à la bibliothèque libc à l'exécution).
Les scripts samples/{exe,pe,elf}encode.rb peuvent prendre un fichier source asm en argument et le compiler en un exécutable fonctionnel.
Les classes CPU sont responsables de l'analyse et de l'encodage des instructions individuelles. L'analyseur Ia32 actuel utilise la syntaxe Intel (par exemple mov eax, 42). L'analyseur générique reconnaît les labels comme une chaîne au début d'une ligne suivie de deux-points (par exemple 'some_label:'). Les labels locaux de style GCC peuvent être utilisés (par exemple '1:', référencés via '1b' (en arrière) ou '1f' (en avant) ; ils peuvent être redéfinis autant de fois que nécessaire.) Les données sont spécifiées à l'aide de la notation de style 'db' (par exemple 'dd 42h', 'db "blabla", 0') Voir samples/asmsyntax.rb
EncodedData :
Dans Metasm, toutes les données binaires sont stockées sous forme d'EncodedData. EncodedData possède 3 attributs principaux :
EncodedData possède également un #virtsize (par exemple pour les sections .bss), et un #ptr (offset interne utilisé lors du décodage des choses)
Vous pouvez appliquer un fixup à un EncodedData, avec un Hash nom de variable => valeur (la valeur doit être une Expression ou une valeur numérique). Lorsque vous faites cela, la cible de chaque relocalisation est liée à l'aide du binding, et si le résultat est calculable (aucun nom de variable externe utilisé dans l'Expression), le résultat est encodé à l'aide des informations de taille/signe/endianness de la relocalisation. En cas de dépassement (essayer de stocker 128 dans une relocalisation signée 8 bits), une exception EncodeError est levée. Utilisez le type :a32 pour permettre une troncature silencieuse en cas de dépassement. Si la cible de la relocalisation n'est pas numérique, la cible est inchangée si vous utilisez EncodedData#fixup, ou elle est remplacée par la cible liée avec #fixup! .
Désassemblage :
Ce code se trouve dans le fichier source metasm/decode.rb, qui définit la classe Disassembler.
Le désassembleur nécessite un ExeFormat décodé (pour pouvoir dire quelles données se trouvent à quelle adresse virtuelle) et un point d'entrée (une adresse virtuelle ou un nom d'export). Il peut ensuite commencer à désassembler les instructions. Lorsqu'il rencontre un Opcode marqué comme :setip, il demande au CPU la destination du saut (une Expression qui peut impliquer des valeurs de registres, par exemple jmp eax), et effectue un backtrace des instructions jusqu'à ce qu'il trouve la valeur numérique.
Lors du décodage, le Disassembler maintient un hash #decoded associant des adresses (expressions/entiers #normalize()s) à des DecodedInstructions.
Le désassemblage génère un graphe d'InstructionBlock. Chaque bloc contient une liste de DecodedInstruction, et des pointeurs vers le bloc suivant/précédent (par adresse).
Le désassembleur trace également les accès aux données par les instructions, et stocke des Xrefs pour ceux-ci. Les paramètres de backtrace peuvent être ajustés, et la profondeur maximale à considérer peut être modifiée spécifiquement pour les backtraces :r/:w (xrefs mémoire des instructions) à l'aide de #backtrace_maxblocks_data. Lorsqu'une Expression fait l'objet d'un backtrace, chaque bloc parcouru est marqué afin que les boucles soient détectées, et afin que si un nouveau chemin de code est trouvé vers un bloc existant, les backtraces puissent reprendre en utilisant ce nouveau chemin.
Le désassembleur fait très peu d'hypothèses, et en particulier ne suppose pas que les fonctions vont retourner ; elles ne le feront que si le backtrace des instructions 'ret' est concluant. C'est assez puissant, mais implique aussi que toute erreur dans le processus de backtracking peut conduire à un arrêt complet ; et signifie également que le désassembleur est assez lent.
La méthode spéciale #disassemble_fast peut être utilisée pour contourner ce problème lorsque le code est connu pour être bien formé (c'est-à-dire qu'elle suppose que tous les appels retournent)
