Cosa fa il decompilatore Ghidra e cosa non recupera
Ghidra analizza istruzioni, flusso di controllo, convenzioni di chiamata, simboli e tipi per rappresentare una funzione come pseudocodice leggibile. Decompiler è utile per individuare rami decisionali, cicli, argomenti, valori restituiti e relazioni tra chiamanti e funzioni chiamate.
L'output non è il C o C++ originale. La compilazione rimuove nomi e tipi, unisce espressioni, riordina operazioni e incorpora funzioni. Considera ogni nome, tipo ed espressione un'ipotesi di lavoro. Una conclusione solida deve essere coerente anche con le istruzioni del Listing e le referenze vicine.
Questa pagina tratta il Decompiler. Per creare un progetto, importare un file, eseguire Auto Analysis e imparare CodeBrowser, inizia dal tutorial Ghidra per principianti.
Il pseudocodice è una mappa leggibile del comportamento macchina, non una prova del sorgente originale.
Aprire Decompiler e sincronizzarlo con Listing
Apri il programma in CodeBrowser dopo la fine di Auto Analysis. Se il pannello è nascosto, scegli Window > Decompiler. Seleziona una funzione definita nel Listing o in Symbol Tree: il pseudocodice deve aggiornarsi e mettere in evidenza la frase legata all'istruzione corrente.
Parti da un riferimento affidabile: stringa unica, chiamata API importata, simbolo esportato, messaggio di errore o punto di ingresso noto. Segui le referenze fino alla funzione chiamante e attendi il completamento dell'analisi in background.
Se Ghidra non riconosce una funzione, definiscine i limiti solo quando disassembly e referenze li confermano. Un linguaggio del processore o un image base errati richiedono prima la correzione dell'importazione.
- 1
Scegliere un riferimento
Trova una stringa, un simbolo, un'importazione o un indirizzo collegato al comportamento da spiegare.
- 2
Seguire la referenza
Apri la funzione che usa il riferimento e controlla lo stesso punto in Listing, Symbol Tree e Decompiler.
- 3
Attendere l'analisi
Poi leggi input, chiamate, condizioni, scritture e valore restituito.
Leggere il pseudocodice Ghidra senza fidarsi ciecamente
Leggi prima firma, tipo restituito, parametri e convenzione di chiamata. Nomi come param_1, local_18, FUN_00401230 e undefined8 indicano che mancano prove, non gli identificatori originali. Segui origine, modifiche e utilizzo di ogni valore.
Individua poi condizioni, cicli, chiamate, accessi alla memoria e percorsi di ritorno. Apri le funzioni chiamate, torna con la cronologia di navigazione e controlla le referenze prima di assegnare uno scopo. L'evidenziazione incrociata collega ogni espressione alle istruzioni reali.
Le ottimizzazioni possono rendere complessa un'espressione semplice oppure nascondere più operazioni in un output troppo pulito. Verifica nel Listing direzione dei salti, costanti, segno, aritmetica dei puntatori ed effetti collaterali.
| Indizio | Significato probabile | Cosa verificare |
|---|---|---|
| param_1 / local_10 | Parametro o locale sconosciuto | Usi, stack, chiamanti |
| FUN_... | Funzione senza nome | Chiamanti, stringhe, importazioni |
| undefined4 / undefined8 | Dimensione nota, tipo incerto | Registri, cast, memoria |
| goto / ciclo insolito | Flusso ricostruito | Destinazioni e Function Graph |
| molti cast | Conflitto di tipo o firma | Segno, puntatori, prototipo |
Migliorare l'output con nomi, firme e tipi
La qualità cresce quando il progetto contiene fatti più precisi. Rinomina una funzione solo se chiamate, stringhe, importazioni o flusso dati ne confermano il ruolo. Assegna alle variabili nomi basati sulla responsabilità e usa i commenti per prove e incertezze.
Una firma errata diffonde cast e aritmetica dei puntatori ingannevoli in tutti i chiamanti. Correggi valore restituito, parametri e convenzione di chiamata. Applica strutture, enum, array e puntatori quando offset o costanti ricorrenti li giustificano.
Esegui una sola modifica supportata alla volta e riesamina i chiamanti. È il modo più semplice per annullare un'ipotesi plausibile ma sbagliata.
- 1
Rinominare simboli stabili
Usa nomi descrittivi solo quando le prove visibili sostengono quel ruolo.
- 2
Correggere il prototipo
Sistema ritorno, parametri, convenzione e profondità del puntatore prima delle variabili locali.
- 3
Applicare tipi riutilizzabili
Crea strutture ed enum per offset e costanti che ricorrono in più funzioni.
- 4
Rivedere i chiamanti
Controlla che la nuova firma chiarisca le funzioni vicine senza creare contraddizioni.
Confermare le conclusioni in Listing e Function Graph
Listing registra istruzioni e dati per indirizzo. Usalo per confermare quale confronto controlla un ramo, se un valore ha segno, dove torna una chiamata e se una scrittura avviene prima o dopo un controllo.
Function Graph aiuta con condizioni annidate, ritorni anticipati e cicli. Segui gli archi vero e falso, identifica i blocchi condivisi e torna a Decompiler per spiegare ogni percorso in modo conciso.
Per risultati importanti annota indirizzo della funzione, istruzione o blocco decisivo, referenze e livello di confidenza. Queste prove restano valide anche se nuovi tipi cambiano l'aspetto del pseudocodice.
Perché la decompilazione appare errata o incompleta
Un output scadente spesso indica dati di analisi mancanti. Controlla linguaggio del processore, compiler specification, mappa memoria, image base, limiti della funzione, firma e risultati degli analizzatori prima di accusare il Decompiler.
Offuscamento, codice impacchettato, assembly manuale, chiamate indirette, eccezioni, ottimizzazione aggressiva e codice automodificante limitano il recupero. Riduci la domanda a un ramo, una struttura o un chiamante invece di aspettarti sorgente pulito per tutto il programma.
| Sintomo | Causa probabile | Controllo successivo |
|---|---|---|
| Nessuna funzione | Limiti non definiti | Referenze e disassembly |
| Istruzioni senza senso | Linguaggio o base errati | Importazione e mappa memoria |
| Troppi cast | Firma o tipi errati | Prototipo, segno, puntatori |
| Chiamate mancanti | Flusso indiretto o analisi incompleta | XRefs e siti di chiamata |
| Pseudocodice molto complesso | Ottimizzazione o offuscamento | Porzioni più piccole e Function Graph |
Procedura ripetibile di 20 minuti
Usa un programma tuo, un binario open source, una sfida didattica o un file che sei autorizzato ad analizzare. Importalo in un ambiente isolato, esegui Auto Analysis, trova una stringa di successo o errore e spiega la funzione decisiva con parole tue.
Rinomina solo simboli giustificati, correggi una firma o un tipo, confronta la condizione principale nel Listing e usa Function Graph se il flusso non è chiaro. Concludi con una frase e gli indirizzi che la sostengono. Poi passa all'automazione con PyGhidra.
Consulta la guida ufficiale Decompiler. Installa la versione verificata con la guida di installazione Ghidra e salva i progetti prima di aggiornarli.
- 0–5 minuti: trovare una stringa, importazione, simbolo o indirizzo affidabile.
- 5–10 minuti: leggere input, chiamate, condizioni, scritture e ritorno.
- 10–15 minuti: migliorare un nome, una firma o un tipo con prove.
- 15–20 minuti: verificare il percorso decisivo e annotare la conclusione.
FAQ sul decompilatore Ghidra
Ghidra recupera il codice sorgente originale?
No. Produce pseudocodice simile al C dal codice macchina e dai dati di analisi. Nomi, commenti, tipi e struttura esatta sono normalmente persi.
Come si apre la finestra Decompiler?
Apri un programma in CodeBrowser, scegli Window > Decompiler se il pannello è nascosto e seleziona una funzione definita nel Listing o in Symbol Tree.
Perché compaiono undefined8 e molti cast?
Ghidra conosce la dimensione ma non ha prove per il tipo, oppure la firma è errata. Controlla chiamanti, registri, segno, profondità dei puntatori e offset ricorrenti.
Ghidra può decompilare C++?
Può analizzare codice nativo prodotto da C++, ma template, classi, eccezioni, inlining, ottimizzazione e simboli rimossi rendono l'output meno simile al sorgente.
Devo fidarmi di Decompiler o Listing?
Usa entrambi. Decompiler accelera la comprensione; Listing offre prove per indirizzo su rami, chiamate, costanti, memoria ed effetti collaterali.