jjyg/metasmEste é o repositório principal do metasm, um montador / desmontador / compilador gratuito escrito em ruby
Autor: Yoann Guillot
Visão geral básica:
O Metasm permite que você interaja com formatos de executáveis (ExeFormat): PE, ELF, Mach-O, Shellcode, etc. Existem três abordagens para um ExeFormat:
Scripts prontos para uso podem ser encontrados no subdiretório samples/; verifique os comentários nos cabeçalhos dos scripts. Você também pode tentar o argumento --help se estiver se sentindo sortudo.
Para mais informações, consulte o subdiretório doc/. Os arquivos de texto podem ser compilados para html usando o script misc/txt2html.rb.
Aqui está uma breve visão geral do funcionamento interno do Metasm.
Assembly:
Ao compilar, você começa a partir de um texto-fonte (String ruby, consistindo principalmente em uma sequência de instruções/dados/diretivas de preenchimento), que é analisado.
A string é entregue a uma instância de Preprocessor (que lida com #if, #ifdef, #include, #define, /* */ etc, e deve ser 100% compatível com gcc -E), que é encapsulada em um AsmPreprocessor para fontes de assembly (para lidar com definições de macros de asm, 'equ' e comentários ';' de asm). A interface para fazer isso é ExeFormat#parse(text[, filename, lineno]) ou ExeFormat.assemble (que chama .new, #parse e #assemble).
O (Asm)Preprocessor retorna tokens para o ExeFormat, que os analisa como Data, Padding, Labels ou diretivas de parser. Diretivas de parser sempre começam com um ponto. Elas podem ser genéricas (.pad, .offset...) ou específicas do ExeFormat (.section, .import, .entrypoint...). Elas são tratadas por #parse_parser_instruction(). Se o ExeFormat não reconhecer uma palavra, ela é entregue à sua instância de CPU, que é responsável por analisar Instructions (ou lançar uma exceção). Todos esses tokens são armazenados em um ou mais arrays no atributo @source do ExeFormat (o @source do Shellcode é um Array; para PE/ELF é um hash [nome da seção] => [Array de dados analisados]). Todo valor imediato pode ser um Expression arbitrário (veja adiante).
Você pode então montar a fonte em seções binárias usando ExeFormat#assemble.
Uma vez que os binários das seções estejam disponíveis, o executável binário completo pode ser gravado em disco usando ExeFormat#encode_file(filename[, format]).
PE e ELF incluem um recurso de autoimportação que permite a criação automática de dados relacionados a importações para funções conhecidas específicas do SO (por exemplo, chamadas não resolvidas para 'strcpy' gerarão dados para que o binário seja vinculado à biblioteca libc em tempo de execução).
Os arquivos samples/{exe,pe,elf}encode.rb podem receber um arquivo de código-fonte asm como argumento e compilá-lo em um executável funcional.
As classes de CPU são responsáveis por analisar e codificar instruções individuais. O parser Ia32 atual usa a sintaxe Intel (por exemplo, mov eax, 42). O parser genérico reconhece labels como uma string no início de uma linha seguida por dois-pontos (por exemplo, 'some_label:'). Labels locais no estilo GCC podem ser usadas (por exemplo, '1:', referidas usando '1b' (para trás) ou '1f' (para frente); podem ser redefinidas quantas vezes forem necessárias). Dados são especificados usando notação estilo 'db' (por exemplo, 'dd 42h', 'db "blabla", 0') Veja samples/asmsyntax.rb
EncodedData:
No Metasm, todos os dados binários são armazenados como um EncodedData. EncodedData tem 3 atributos principais:
EncodedData também tem um #virtsize (para, por exemplo, seções .bss) e um #ptr (offset interno usado ao decodificar coisas).
Você pode aplicar fixup em um EncodedData, com um Hash nome de variável => valor (o valor deve ser um Expression ou um valor numérico). Ao fazer isso, o alvo de cada realocação é vinculado usando o binding, e se o resultado for calculável (nenhum nome de variável externo usado no Expression), o resultado é codificado usando as informações de tamanho/sinal/endianness da realocação. Se houver overflow (tentar armazenar 128 em uma realocação de 8 bits com sinal), uma exceção EncodeError é lançada. Use o tipo :a32 para permitir truncamento de overflow silencioso. Se o alvo da realocação não for numérico, o alvo permanece inalterado se você usar EncodedData#fixup, ou é substituído pelo alvo vinculado com #fixup!.
Desmontagem:
Este código é encontrado no arquivo-fonte metasm/decode.rb, que define a classe Disassembler.
O desmontador precisa de um ExeFormat decodificado (para poder dizer quais dados estão em qual endereço virtual) e de um entrypoint (um endereço virtual ou nome de exportação). Ele pode então começar a desmontar instruções. Quando encontra um Opcode marcado como :setip, ele pergunta à CPU o destino do salto (um Expression que pode envolver valores de registradores, por exemplo, jmp eax) e faz backtrace das instruções até encontrar o valor numérico.
Ao decodificar, o Disassembler mantém um hash #decoded associando endereços (expressões/inteiros #normalize()d) a DecodedInstructions.
A desmontagem gera um grafo de InstructionBlock. Cada bloco contém uma lista de DecodedInstruction e ponteiros para o próximo/bloco anterior (por endereço).
O desmontador também rastreia acessos a dados por instruções e armazena Xrefs para eles. Os parâmetros de backtrace podem ser ajustados, e a profundidade máxima a considerar pode ser alterada especificamente para backtraces :r/:w (xrefs de memória de instrução) usando #backtrace_maxblocks_data. Quando um Expression é rastreado via backtrace, cada bloco percorrido é marcado para que loops sejam detectados, e para que, se um novo caminho de código for encontrado para um bloco existente, os backtraces possam ser retomados usando esse novo caminho.
O desmontador faz muito poucas suposições e, em particular, não supõe que as funções retornarão; elas só retornarão se o backtrace das instruções 'ret' for conclusivo. Isso é bastante poderoso, mas também implica que qualquer erro no processo de backtracking pode levar a uma parada total; e também significa que o desmontador é bastante lento.
O método especial #disassemble_fast pode ser usado para contornar isso quando o código é conhecido por ser bem-formado (ou seja, ele assume que todas as chamadas retornam).
Quando uma subfunção é encontrada, uma DecodedFunction especial é criada, que contém um resumo dos efeitos da função (como uma DecodedInstruction turbinada). Isso permite que o backtracker 'pule' subfunções, o que melhora muito a velocidade. As DecodedFunctions podem ser baseadas em callbacks, para permitir um comportamento muito dinâmico. Chamadas de funções externas criam DecodedFunctions dedicadas, que contêm algumas informações de API (por exemplo, informações de stack fixup, acessos básicos a parâmetros...) Essas informações podem ser derivadas de um cabeçalho C analisado anteriormente. Se nenhum protótipo de função C estiver disponível, uma entrada especial 'default' é usada, que assume que a função tem uma ABI padrão.
