Unpacking

Il packing comprime o cifra il vero codice di un programma e lo racchiude in un piccolo stub. Durante l'esecuzione, lo stub estrae il codice originale in memoria e lo esegue.

Gli autori di malware usano il packing per eludere le firme e ostacolare l'analisi statica.

Un binario impacchettato mostra poche stringhe, poche importazioni e un'elevata entropia. Il codice significativo rimane nascosto finché lo stub non viene eseguito.

L'unpacking recupera il codice originale, permettendo di analizzarlo staticamente ed estrarre gli IOC effettivi.

Strumenti come Detect It Easy (DIE) e PEiD identificano i packer noti tramite la firma. Anche l'elevata entropia e una tabella delle importazioni molto piccola sono indizi significativi.

Tra i packer più comuni figurano UPX, ASPack e Themida.

UPX è un packer comune e non dannoso che può essere sottoposto a reverse engineering con il proprio strumento. L'opzione -d decomprime il binario riportandolo alla forma originale.

Molti campioni reali usano UPX o una versione leggermente modificata di UPX, quindi questo è spesso il primo tentativo.

I packer personalizzati non possono essere annullati con uno strumento. Si lascia invece che lo stub si scompatti in memoria, quindi si acquisisce il risultato.

Il piano è il seguente: eseguire il campione sotto un debugger, interromperlo subito dopo il completamento dell'unpacking e fare il dump del codice appena rivelato.

L'Original Entry Point (OEP) è il punto a cui passa l'esecuzione una volta terminato l'unpacking. Raggiungere l'OEP significa che il codice reale si trova ora in memoria.

Le tecniche per individuarlo includono osservare un salto lontano fuori dallo stub oppure impostare un breakpoint sulla memoria in cui lo stub scrive e che poi esegue.

Un trucco comune consiste nell'impostare un breakpoint hardware sullo stack (lo stub ripristina spesso i registri subito prima di saltare all'OEP) oppure un breakpoint sulle chiamate API comuni utilizzate dal codice scompattato.

Quando il breakpoint scatta sull'OEP, il codice originale è completamente decodificato.

Sull'OEP, esegua il dump della memoria del processo in un nuovo file. Strumenti come Scylla (integrato in x64dbg) o PE-sieve acquisiscono l'immagine scompattata.

Il dump ora contiene le istruzioni reali, ma potrebbe non essere ancora eseguibile autonomamente.

Dopo il dump, la Import Address Table è spesso danneggiata perché il packer ha risolto le importazioni durante l'esecuzione. Scylla può ricostruire la IAT, così il file ottenuto dal dump può essere analizzato.

Una volta corrette le importazioni, può caricare il dump pulito in Ghidra o IDA.

Oltre al packing, il malware utilizza altre tecniche di offuscamento: stringhe cifrate decodificate durante l'esecuzione, istruzioni inutili, appiattimento del flusso di controllo e controlli anti-debugging.

Queste tecniche vengono contrastate caso per caso, spesso combinando il tracing dinamico con una lettura statica paziente.

Dopo aver eseguito il dump e ricostruito le importazioni, verifichi il risultato ripetendo l'analisi statica: ora dovrebbe vedere molte più stringhe e una tabella delle importazioni popolata.

Se l'entropia è tornata normale e le API sono visibili, l'unpacking è riuscito e il codice reale è pronto per essere analizzato.

Ricordi che cosa indica l'OEP durante l'unpacking manuale.

Ora conosce l'unpacking:

• Il packing nasconde il codice reale; lo si rileva con DIE/PEiD, l'elevata entropia e il ridotto numero di importazioni.
• I packer noti come UPX vengono scompattati con uno strumento (upx -d).
• Per i packer personalizzati, esegua il campione sotto un debugger, individui l'OEP, esegua il dump con Scylla e ricostruisca le importazioni.
• Le altre tecniche di offuscamento (stringhe cifrate, anti-debug) vengono gestite caso per caso.

Ha completato il corso di reverse engineering del malware.