Questo articolo guida alla comprensione di Radare2, non come semplice disassemblatore, ma come ambiente modulare e flessibile per il reverse engineering. L’obiettivo non è imparare comandi a memoria, ma sviluppare un modello mentale coerente del binario, padroneggiando navigazione, configurazioni ed euristiche per trasformare dati grezzi in informazioni interpretabili.

“everything is open source if you can reverse engineer” HCF

Indice dei contenuti

  1. La filosofia Unix e l’approccio di Radare2
  2. Installazione, Aggiornamenti, r2pm e hardening dell’ambiente
  3. Padronanza della navigazione: seek, block size & co.
  4. Analisi Euristica

La filosofia Unix e l’approccio di Radare2

Radare2 non è un disassemblatore tradizionale, ma possiamo definirlo come un motore modulare accessibile tramite una shell a riga di comando. I comandi seguono una struttura coerente e prevedibile: una volta compresi i prefissi e la logica di base, molte funzionalità diventano deducibili senza doverle memorizzare. Questo approccio permette di lavorare in modo sistematico, riducendo la dipendenza da scorciatoie o interfacce guidate.

File, memoria e sessione di debug vengono trattati come un unico spazio di lavoro. Non esiste una distinzione netta tra analisi statica e dinamica: si opera sempre sugli stessi oggetti, cambiando solo il contesto. Il modello basato su seek e block consente di spostarsi e operare su porzioni specifiche del binario in modo efficiente, anche su file di grandi dimensioni, a patto di sapere sempre dove ci si trova.

Radare2 fornisce solo l’output strettamente necessario. Non interpreta i risultati né suggerisce percorsi di analisi. Questa scelta favorisce l’automazione e lo scripting, ma soprattutto impone tanto studio: l’analista deve guidare attivamente il processo, mantenendo il controllo sul flusso e sulle ipotesi, invece di affidarsi allo strumento per “spiegare” il binario.

Installazione, Aggiornamenti, r2pm e hardening dell’ambiente

Un ambiente Radare2 professionale richiede attenzione fin dall’installazione: le versioni dei repository standard sono inadeguate, perché spesso obsolete, e l’unico approccio efficace è la compilazione diretta dal sorgente, mantenuta aggiornata con una routine di ricompilazione frequente. L’installazione va eseguita in un contesto isolato (VM o container) e completata con r2pm, il gestore di pacchetti che abilita plugin essenziali come r2ghidra, integrando la decompilazione avanzata direttamente nel workflow da terminale.

git clone https://github.com/radareorg/radare2
cd radare2
sys/install.sh

Una volta installato il framework principale, molte delle funzionalità più avanzate diventano accessibili tramite r2pm, il gestore di pacchetti di Radare2. r2pm permette di installare e mantenere plugin sviluppati dalla community che estendono il framework senza modificare l’installazione di base. A differenza del core, opera interamente nello spazio utente, evitando la necessità di privilegi elevati per aggiornamenti e manutenzione.

Tra i plugin disponibili, r2ghidra è di fatto indispensabile in un contesto di analisi moderna. Integra il decompilatore di Ghidra direttamente all’interno di Radare2, rendendo possibile affiancare una rappresentazione pseudo-C al codice assembly durante l’analisi, senza uscire dalla shell né cambiare strumento. Questo riduce drasticamente il contesto mentale richiesto per passare tra livelli di astrazione diversi.

L’inizializzazione di r2pm e l’installazione di r2ghidra rappresentano quindi un primo passo obbligato in qualsiasi configurazione orientata a un’analisi reale, ripetibile e mantenibile nel tempo.

r2pm -s <word>  ;cerca i pacchetti che corrispondono a una parola
r2pm -Uci <pkg> ;aggiorna il database ed esegue un'installazione pulita di un pacchetto
r2pm -u <pkg>   ;disinstalla il pacchetto specificato
r2pm -l <pkg>   ;elenca i pacchetti installati

L’hardening dell’ambiente è l’ultimo passaggio: la sandbox interna, configurata via .radare2rc, riduce la superficie di attacco durante l’analisi di binari ostili:

Aggiungi queste linee al tuo file ~/.radare2rc

e cfg.sandbox = true       ;abilita la sandbox
e cmd.depth = 10           ;limita la ricorsione dei comandi per prevenire l'esaurimento dello stack
e http.allow = false       ;disabilita il server web interno per sicurezza

Una struttura ordinata delle directory e l’uso dei Project di Radare2 sono fondamentali per garantire continuità e riproducibilità dell’analisi. Questo permette di riprendere il lavoro in qualsiasi momento mantenendo contesto, stato e ipotesi già formulate. Solo in queste condizioni  è possibile concentrarsi sulla logica del binario, senza interferenze dovute all’ambiente di lavoro.

Nel caso di malware o binari potenzialmente ostili, è necessario attivare la sandbox impostando e cfg.sandbox = true. Questa configurazione isola l’ambiente di Radare2, impedendo l’esecuzione di comandi di sistema e riducendo la superficie d’attacco durante l’analisi. L’uso della sandbox non è opzionale: rappresenta una misura di base per operare in sicurezza su campioni possibilmente malevoli.

r2 -P my_analysis /bin/ls  ;apre il binario assegnando un nome al progetto
[0x00400000]> Ps           ;salva lo stato del progetto
[0x00400000]> P            ;ricarica lo stato del progetto

L’uso del parametro -P garantisce la persistenza di flag, commenti e analisi tra diverse sessioni di lavoro. È importante ricordare che il progetto salva lo stato logico e le euristiche applicate, permettendo di riprendere indagini complesse senza perdere il progresso accumulato.

Padronanza della navigazione: seek, block size & co.

Radare2 non opera su un file come su un flusso continuo, ma lavora sempre su una porzione limitata di dati. Il file e la vista sono concetti distinti: in ogni momento l’analisi è riferita solo all’area attualmente osservata. Questo modello deriva dalla necessità di operare su dump di grandi dimensioni, anche superiori alla memoria disponibile, senza doverli caricare interamente.

La vista è definita da due parametri: il seek, che indica l’offset corrente all’interno del file, e il block size, che stabilisce la quantità di dati visualizzati o analizzati. Tutti i comandi agiscono esclusivamente all’interno di questa finestra.

Comprendere il rapporto tra seek e block è essenziale. Comportamenti apparentemente anomali — come stringhe non trovate, disassemblaggi incompleti o dati che sembrano assenti — non indicano necessariamente una mancanza di informazioni, ma il fatto che l’analisi stia operando su un’area diversa del binario.

Il puntatore di ricerca è il vero cursore di Radare2: determina dove ti trovi e si muove solo tramite comandi, non tramite scorrimento visivo. Il comando s permette di posizionarlo con precisione usando indirizzi, simboli o espressioni matematiche. Questo abilita una navigazione basata sulla struttura logica del binario anziché sullo scorrimento passivo, favorendo il ragionamento sugli indirizzi e la costruzione di una mappa mentale solida del file.

s 0x4000         ;sposta il cursore all'indirizzo assoluto 0x4000
s+ 32            ;sposta il cursore in avanti di 32 byte
s- 0x10          ;sposta il cursore all'indietro di 16 byte (0x10 in esadecimale)
s entry0+0x20    ;sposta il cursore 32 byte dopo l'entry point (punto di ingresso)
s ..             ;sposta il cursore all'inizio del blocco corrente

La navigazione tramite s non è limitata a indirizzi statici, ma supporta anche espressioni aritmetiche, ad esempio s entry0+0x20. L’uso corretto degli offset e dell’allineamento dei dati consente di spostarsi con precisione tra le diverse strutture logiche del binario.

Dopo ogni spostamento, il prompt riflette il nuovo offset corrente (ad esempio [0x00004000]>). Questo valore può essere verificato in qualsiasi momento con ?v $$, che restituisce l’offset di seek in formato esadecimale. Tutti i comandi di output, come px, pdf o pD, producono risultati a partire da quell’indirizzo.

La dimensione del block rappresenta una delle principali fonti di confusione per chi è alle prime armi. Radare2 utilizza di default un valore ridotto, tipicamente 256 byte, e limita l’analisi e il disassemblaggio ai dati inclusi in quella finestra. Se una funzione eccede il block size, il disassemblaggio si interrompe, anche in corrispondenza di istruzioni incomplete. Non si tratta di un errore, ma di un limite imposto dalla vista corrente.

La dimensione del blocco si controlla tramite il comando b. Aumentarla è spesso necessario durante analisi più estese o ricerche complesse, ma valori eccessivi possono impattare negativamente le prestazioni, soprattutto su target con I/O lento. Per questo motivo, un’analisi efficace richiede un adattamento continuo del block size in funzione dell’obiettivo immediato.

b 0x1000         ;imposta la dimensione del blocco a 4096 byte (4KB)
b+ 100           ;aumenta la dimensione del blocco di 100 byte
b                ;stampa la dimensione attuale del blocco

L’esecuzione di b senza argomenti restituisce la dimensione corrente in esadecimale. Dopo aver aumentato la dimensione del blocco, i comandi che elaborano i dati, come p= (entropy bars) o pD (disassembly), copriranno ora un intervallo di memoria più ampio a partire dal puntatore di ricerca corrente. Comandi come pd (senza la ‘f’), px (hexdump), pD (disassembly) o p= (entropia) sono legati strettamente alla dimensione del blocco corrente.

Esistono anche comandi che non sono block based. pdf (Print Disassembly Function) è un comando “intelligente” che generalmente ignora il limite del blocco perché si basa sull’analisi del grafo della funzione.

Mentre pd è limitato rigidamente dalla dimensione del blocco (b), pdf sfrutta i metadati dell’analisi per ricostruire l’intera funzione. Usare pdf permette quindi di superare i confini visivi senza dover regolare continuamente la finestra di lettura.

Nelle analisi avanzate, però, la navigazione avviene spesso tramite pattern più che indirizzi noti. A questo scopo serve la famiglia di comandi /, che costituisce il motore di ricerca di Radare2. Essa rispetta i limiti di finestra e di ricerca già visti, ma può essere configurata per eseguire ricerche globali.

Un aspetto da considerare durante la ricerca è l’allineamento dei dati. Su molte architetture, istruzioni e strutture devono essere allineate a 4 o 8 byte; questo rende immediata la ricerca di stringhe, ma più delicata l’individuazione di opcode o sequenze di istruzioni specifiche.

Radare2 supporta diverse modalità di ricerca: sequenze esadecimali grezze, mnemonici assembly e pattern di dati ad alta entropia, come quelli associabili a materiale crittografico. I risultati vengono salvati come search flag, consentendo di navigarli in modo sequenziale tramite i comandi di risultato successivo o precedente. In questo modo, l’output della ricerca diventa un insieme strutturato di punti di interesse, immediatamente riutilizzabili durante l’analisi.

/ lib            ;cerca la stringa "lib"
/x 9090          ;cerca i byte esadecimali (NOP NOP)
/a jmp eax       ;cerca l'istruzione assembly

Radare2 elenca i risultati di una ricerca con i relativi indirizzi, creando flag temporanei (ad esempio hit0_0, hit0_1) che permettono di ispezionare il contesto con comandi come s, pdf, pi o pd. Se non compaiono risultati attesi, occorre verificare che la configurazione consenta la ricerca oltre il blocco corrente o le sezioni mappate.

La padronanza della navigazione include anche la sincronizzazione tra CLI e rappresentazioni visive: la modalità visiva (V) lega il puntatore di ricerca ai tasti freccia, offrendo un’esperienza tipo editor esadecimale, mentre la modalità Visual Graph (VV) mostra il flusso di controllo delle funzioni con riquadri e frecce ASCII. In entrambe le modalità si manipola comunque un puntatore nella mappa di memoria, e combinando la precisione dei comandi CLI con la visione spaziale dei grafici si ottiene una navigazione fluida e veloce attraverso i binari.

Fig 1.  Modalità Visual Graph

Fig 2. Modalità a Finestre (v+Invio, m per accedere al Menù)

Analisi Euristica e Configurazioni

Radare2 è un ambiente flessibile che si adatta alla natura del binario analizzato, e raramente basta affidarsi alle impostazioni predefinite. Per affrontare architetture non standard, eseguibili offuscati o dump grezzi, è necessario configurare manualmente variabili, limiti e euristiche tramite i comandi e (eval). Queste variabili, organizzate gerarchicamente, controllano ogni aspetto dello strumento, dalla sintassi di disassemblaggio alla visualizzazione, e richiedono in particolare di impostare correttamente architettura e profondità di bit, oltre a gestire cache, emulazione e decodifica delle stringhe, garantendo così un’analisi precisa e affidabile.

e asm.arch = arm    ;forza l'architettura ARM
e asm.bits = 32     ;forza la modalità a 32 bit
e scr.color = 1     ;abilita l'output a colori
e ? asm.arch        ;stampa l'aiuto/descrizione per questa variabile

Digitando “e asm.arch” (senza il segno di uguale) verrà visualizzato il valore corrente. Se si modifica l’architettura, l’esecuzione di pd (print disassembly) mostrerà immediatamente le istruzioni interpretate secondo le nuove regole. Se l’output sembra contenere istruzioni non valide o “spazzatura”, è probabile che l’architettura o la profondità di bit siano errate.

e anal.hasnext = 0    ;assume che la funzione termini dopo una chiamata che non ritorna
e anal.depth = 16     ;limita la profondità della ricorsione a 16 livelli
aaa                   ;esegue l'analisi avanzata con le impostazioni correntisettings

Per mantenere un flusso di lavoro stabile, Radare2 consente di persistere configurazioni e comandi tramite il file .radare2rc. Questo file viene caricato automaticamente all’avvio e può contenere alias, impostazioni grafiche e limiti di sicurezza, evitando di dover riconfigurare l’ambiente a ogni sessione.

I comandi di analisi seguono una gerarchia che riflette la profondità dello scanning. aa esegue un’analisi di base dei simboli e del flusso di controllo. aaa estende l’analisi includendo emulazione, utile per risolvere salti indiretti e chiamate calcolate. aaaa, attualmente sperimentale, spinge ulteriormente questo processo ma può risultare costoso in termini di tempo e risorse, soprattutto su binari di grandi dimensioni.

Un approccio più controllato prevede una prima ricognizione con aa, seguita da interventi mirati su aree di interesse tramite comandi come af e ax. Questo metodo, spesso indicato come Black Book, permette di integrare manualmente riferimenti incrociati e ricostruire il grafo di controllo in modo accurato, mantenendo l’analisi reattiva e sotto controllo.

af @ 0x402000    ;analizza una singola funzione a questo indirizzo
axC 0x402005 0x403000 ;aggiunge manualmente un riferimento di esecuzione del codice
afl              ;elenca le funzioni per verificare che la nuova funzione appaia

Dopo l’analisi, afl conferma la presenza della funzione individuata e l’ispezione con pdf mostra i riferimenti incrociati aggiunti, segno che Radare2 ha integrato correttamente le relazioni nel grafo di controllo.

Conclusione

Radare2 va considerato come un ambiente di lavoro più che come un singolo strumento. Il suo utilizzo richiede un approccio metodico, basato sulla costruzione progressiva di un modello mentale del binario anziché sull’affidamento a interfacce guidate o rappresentazioni grafiche. Installazione controllata, configurazione coerente, navigazione consapevole e gestione delle euristiche di analisi fanno parte dello stesso processo e incidono direttamente sulla qualità dei risultati.

Ogni comando modifica lo stato dell’analisi: cambia il contesto di osservazione, aggiorna le ipotesi in corso o introduce nuovi riferimenti. In questo modello, Radare2 non interpreta i dati al posto dell’analista né propone conclusioni automatiche. Fornisce strumenti e meccanismi che devono essere applicati in modo intenzionale, decidendo quando sfruttare l’automazione e quando intervenire manualmente per correggere o integrare l’analisi.

Questo livello di controllo, unito all’assenza di percorsi predefiniti, consente di condurre il reverse engineering come un processo strutturato e ripetibile, riducendo l’approccio esplorativo non guidato e mantenendo piena tracciabilità delle decisioni prese durante l’analisi.

Autore:

HCF: hacker artist, reverse engineer, battle programmer e malware & cybersecurity analyst.

HCF ME: hcfme.substack.com

blog: spaghetti-hacker.blogfree.net

Halt and Catch Fire, indicato con la sigla mnemonica di HCF, è un’istruzione fittizia del linguaggio assembly, intesa prevalentemente come uno scherzo, che è stata usata per definire istruzioni solitamente non documentate che portano la CPU in uno stato da cui può essere fatta uscire solo con un reset; solitamente con la sigla HCF si descrive una o più istruzioni non documentate presenti in molte architetture e utilizzate per poter effettuare agevolmente particolari test durante lo sviluppo dei prodotti, ma che non sono da utilizzarsi nella normale operatività.

Il “Reverse Engineering” è l’esigenza, la pretesa da parte degli utenti di poter aprire, esplorare, modificare la tecnologia, secondo le proprie esigenze, ampliare e quindi sviluppare nuove caratteristiche per adattare ogni cosa al quadro tecnologico, che è sempre in evoluzione.

flag{we_beleaf_in_your_re_future}

Ti è piaciuto l’articolo? Seguici su Linkedin per sostenerci!

consigliati