O que o descompilador do Ghidra faz e o que não recupera
O Ghidra analisa instruções, fluxo de controle, convenções de chamada, símbolos e tipos para representar uma função como pseudocódigo legível. O Decompiler ajuda a encontrar ramificações, loops, argumentos, valores de retorno e relações entre funções chamadoras e chamadas.
A saída não é o C ou C++ original. A compilação remove nomes e tipos, combina expressões, reorganiza operações e incorpora funções. Trate nomes, tipos e expressões como hipóteses. Uma conclusão confiável também deve fazer sentido nas instruções do Listing e nas referências próximas.
Esta página é focada no Decompiler. Para criar um projeto, importar um arquivo, executar Auto Analysis e aprender o CodeBrowser, comece pelo tutorial do Ghidra para iniciantes.
Use o pseudocódigo como um mapa legível do comportamento da máquina, não como prova do código-fonte original.
Abrir o Decompiler e sincronizar com o Listing
Abra o programa no CodeBrowser depois que Auto Analysis terminar. Se o painel estiver oculto, escolha Window > Decompiler. Selecione uma função definida no Listing ou Symbol Tree; o pseudocódigo deve mudar para essa função e destacar a instrução correspondente.
Comece por uma referência confiável: string exclusiva, chamada de API importada, símbolo exportado, mensagem de erro ou ponto de entrada conhecido. Siga as referências até a função chamadora e espere a análise em segundo plano terminar.
Se não houver função, defina os limites somente quando o disassembly e as referências sustentarem essa decisão. Linguagem de processador ou image base incorretas exigem corrigir primeiro a importação.
- 1
Escolher uma referência
Encontre uma string, símbolo, importação ou endereço ligado ao comportamento estudado.
- 2
Seguir a referência
Abra a função que usa o item e confirme o mesmo local em Listing, Symbol Tree e Decompiler.
- 3
Aguardar a análise
Depois leia entradas, chamadas, condições, gravações e valor de retorno.
Como ler o pseudocódigo do Ghidra sem confiar demais
Leia primeiro a assinatura: retorno, parâmetros e convenção de chamada determinam toda a função. Nomes como param_1, local_18, FUN_00401230 e undefined8 significam que faltam evidências, não que esses eram os identificadores originais. Acompanhe a origem, as mudanças e o uso de cada valor.
Depois identifique condições, loops, chamadas, acessos à memória e caminhos de retorno. Abra funções chamadas, volte pelo histórico de navegação e consulte referências antes de atribuir um propósito. O destaque cruzado liga cada expressão às instruções exatas.
Otimizações podem tornar uma expressão simples complexa ou esconder várias operações em uma saída limpa demais. Confirme no Listing a direção dos saltos, constantes, sinal, aritmética de ponteiros e efeitos colaterais.
| Indício | Significado provável | O que verificar |
|---|---|---|
| param_1 / local_10 | Parâmetro ou variável desconhecida | Usos, pilha e chamadores |
| FUN_... | Função sem nome | Chamadores, strings e imports |
| undefined4 / undefined8 | Tamanho conhecido, tipo incerto | Registradores, casts e memória |
| goto / loop estranho | Fluxo reconstruído | Destinos e Function Graph |
| muitos casts | Conflito de tipo ou assinatura | Sinal, ponteiro e protótipo |
Melhorar a saída com nomes, assinaturas e tipos
A qualidade melhora quando o projeto contém fatos melhores. Renomeie uma função somente quando chamadas, strings, imports ou fluxo de dados comprovarem seu papel. Nomeie variáveis pela responsabilidade e use comentários para registrar evidências e incertezas.
Uma assinatura errada espalha casts e aritmética de ponteiros enganosos por todos os chamadores. Corrija retorno, parâmetros e convenção de chamada. Aplique estruturas, enums, arrays e ponteiros quando offsets ou constantes recorrentes justificarem esses tipos.
Faça uma mudança comprovada por vez e revise os chamadores. Assim fica mais fácil desfazer uma hipótese atraente, mas incorreta.
- 1
Renomear símbolos estáveis
Use nomes descritivos apenas quando a evidência visível apoiar a função.
- 2
Corrigir o protótipo
Ajuste retorno, parâmetros, convenção e profundidade de ponteiro antes das variáveis locais.
- 3
Aplicar tipos reutilizáveis
Crie estruturas e enums para offsets e constantes repetidos.
- 4
Revisar chamadores
Verifique se a nova assinatura esclarece funções próximas sem contradições.
Confirmar conclusões no Listing e Function Graph
O Listing registra instruções e dados por endereço. Use-o para confirmar qual comparação controla uma ramificação, se o valor tem sinal, onde uma chamada retorna e se uma gravação ocorre antes ou depois de uma verificação.
Function Graph ajuda com condições aninhadas, retornos antecipados e loops. Siga as arestas verdadeiras e falsas, identifique blocos compartilhados e volte ao Decompiler para explicar cada caminho de forma curta.
Em descobertas importantes, registre endereço da função, instrução ou bloco decisivo, referências e grau de confiança. Essas evidências continuam úteis quando tipos posteriores mudam a aparência do pseudocódigo.
Por que a descompilação parece errada ou incompleta
Uma saída ruim normalmente indica dados de análise ausentes. Verifique linguagem do processador, compiler specification, mapa de memória, image base, limites da função, assinatura e resultados dos analisadores antes de culpar o Decompiler.
Ofuscação, código empacotado, assembly manual, chamadas indiretas, exceções, otimização agressiva e código automodificável limitam a recuperação. Reduza a pergunta a uma ramificação, estrutura ou chamador em vez de esperar código limpo para o programa inteiro.
| Sintoma | Causa provável | Próxima verificação |
|---|---|---|
| Sem função | Limites não definidos | Referências e disassembly |
| Instruções sem sentido | Linguagem ou base errada | Importação e mapa de memória |
| Casts demais | Assinatura ou tipos errados | Protótipo, sinal e ponteiros |
| Chamadas ausentes | Fluxo indireto ou análise incompleta | XRefs e locais de chamada |
| Pseudocódigo muito complexo | Otimização ou ofuscação | Trechos menores e Function Graph |
Fluxo repetível de prática em 20 minutos
Use um programa próprio, binário de código aberto, desafio educativo ou arquivo que você tenha autorização para analisar. Importe em um laboratório isolado, execute Auto Analysis, encontre uma string de sucesso ou erro e explique a função decisiva com suas palavras.
Renomeie apenas símbolos justificáveis, corrija uma assinatura ou tipo, compare a condição principal no Listing e use Function Graph se o fluxo estiver confuso. Termine com uma conclusão e os endereços que a sustentam. Depois avance para a automação com PyGhidra.
Consulte a ajuda oficial do Decompiler. Instale a versão verificada com o guia de instalação do Ghidra e faça backup dos projetos antes de atualizar.
- 0–5 minutos: encontrar string, import, símbolo ou endereço confiável.
- 5–10 minutos: ler entradas, chamadas, condições, gravações e retorno.
- 10–15 minutos: melhorar um nome, assinatura ou tipo com evidências.
- 15–20 minutos: verificar o caminho decisivo e registrar a conclusão.
FAQ do descompilador do Ghidra
O Ghidra recupera o código-fonte original?
Não. Ele gera pseudocódigo semelhante a C a partir do código de máquina e da análise. Nomes, comentários, tipos e estrutura exata normalmente foram perdidos.
Como abrir a janela Decompiler?
Abra um programa no CodeBrowser, escolha Window > Decompiler se o painel estiver oculto e selecione uma função definida no Listing ou Symbol Tree.
Por que aparecem undefined8 e muitos casts?
O tamanho é conhecido, mas o tipo não tem evidência suficiente, ou a assinatura está errada. Revise chamadores, registradores, sinal, ponteiros e offsets repetidos.
O Ghidra consegue descompilar C++?
Ele analisa código nativo gerado de C++, mas templates, classes, exceções, inlining, otimização e símbolos removidos reduzem a semelhança com o fonte.
Devo confiar no Decompiler ou no Listing?
Use os dois. O Decompiler acelera a compreensão; o Listing fornece evidência por endereço para confirmar ramificações, chamadas, constantes, memória e efeitos colaterais.