Por que usar a NotHoly para engenharia reversa

Engenharia reversa é leitura. Você já tem Ghidra, radare2 ou IDA aberto, e a parte lenta é entender um dump de decompilador, nomear os locais e escrever o script que renomeia os próximos duzentos. Um modelo ajuda aí, mas só se aceitar a pergunta sem sermão e ler o que você cola. A NotHoly faz os dois. Você mantém as suas ferramentas, e o modelo explica a saída e escreve os scripts. O caso de uso de engenharia reversa tem o fluxo mais longo; aqui é sobre por que encaixa.

#Cole a saída, receba uma explicação e um script

A saída do decompilador e do disassembler é a entrada. Cole uma função do Ghidra, um bloco do radare2 ou uma listagem do IDA, e o modelo explica o que ela faz, nomeia a estrutura que vê e marca as partes que parecem uma checagem de limite, uma rotina de decode ou um parser. Peça um script e ele escreve um para a sua ferramenta: um passe em Ghidra Python que renomeia por padrão, uma sequência de comandos radare2, um trecho de IDAPython, um hook de Frida para logar uma chamada. O script roda na sua máquina, contra a sua amostra, nunca a nossa. Como o modelo não recusa a tarefa, uma rotina de unpacking, um loop ofuscado, um truque anti-debug ou uma checagem de licença é lida como qualquer outro código, desde que o trabalho esteja no seu escopo.

r2 -q -c "pdf @ sym.main" ./bin | notholy "explain this function and write a radare2 script to rename the locals"

#Um primeiro olhar antes da ferramenta pesada

Anexe um binário no chat, ou rode notholy analyze, e as ferramentas estáticas dão uma primeira passada sem abrir o decompilador. Para um ELF ou PE você recebe o SHA-256, o tamanho, a entropia, o formato, o entry point, as seções e os imports. Para uma amostra você também recebe as strings e uma prévia de disassembly do começo do arquivo. Um APK dá o manifest e o texto de cada entrada, e um arquivo compactado dá a sua árvore. Cada arquivo é parseado num sandbox descartável sem rede e com raiz só de leitura, nada nele é executado, e um pickle de Python é desmontado com pickletools, nunca carregado. Entropia alta e uma tabela de imports curta já bastam para decidir se uma amostra vale a hora no Ghidra. A referência de arquivos lista os tipos e limites.

#O que mais está ao alcance

A base de conhecimento é parte do modelo, então uma pergunta sobre um packer, um formato de arquivo ou uma convenção de chamada traz técnica curada com uma fonte e licença em cada trecho. Uma string de versão que você recupera vai direto para um lookup de CVE que devolve CVSS, EPSS e status KEV com datas. Tanto a base de conhecimento quanto os dados de CVE leem pela CLI e pela API também, então um lote de amostras pode ser triado de um script, e o mesmo modelo que explicou a função rascunha o relatório que vai com ela. O mesmo modelo que rascunhou o relatório transforma um formato recuperado em um parser, então você vai dos bytes a um script que funciona sem trocar de ferramenta.

#Onde não encaixa

A plataforma não decompila. Não há decompilador nem grafo de fluxo de controle do nosso lado, e a prévia de disassembly embutida para no começo do arquivo e numa contagem curta de instruções, então a listagem de verdade vem do seu próprio Ghidra ou IDA. Nada é executado e não há análise dinâmica, nem debugger nem emulação, então o comportamento de uma amostra empacotada em tempo de execução é seu para observar no seu laboratório. Imagens dão só dimensões, sem OCR ainda. E o modelo pode ler um offset errado, inventar uma API ou explicar uma função errado, então trate a explicação como pista e confira contra os bytes.

Mantenha o seu decompilador e deixe o modelo ler a saída dele. Ponha um saldo pequeno em preços, cole uma função e peça o script.