Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
Strumenti/GitHubGitHub/dodo-sec/astaroth-deobfuscator
Analisi StaticaReverse EngineeringAnalisi MalwareAnalisi di Binari
GitHubdodo-sec/astaroth-deobfuscator

astaroth-deobfuscator

Script Python IDA per deofuscare la DLL injector Astaroth/Guildma

Vedi Repository
8143 anni faNon ancora revisionato

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

astaroth-deobfuscator

Script IDA Python per deoffuscare la DLL injector di Astaroth/Guildma

Quando ho provato ad analizzare la DLL injector di una recente campagna Astaroth/Guildma (grazie a questo diario del SANS ISC), mi sono imbattuto in un tentativo di offuscamento davvero fastidioso.

Una funzione (che ho chiamato time_waster_3000 nell'immagine qui sotto) viene chiamata oltre 1.000 volte (!!!) in tutta la DLL. Questa funzione riceve sei stringhe hardcoded come argomenti, insieme a una word casuale. La funzione stessa è un labirinto di operazioni aritmetiche che, per quanto ne so, non hanno alcuno scopo pratico (a parte far perdere tempo a chi fa reverse engineering). Ecco come appare DLLEntry con quelle fastidiose chiamate:

DLL Entry prima della deoffuscazione

Lo scopo di questo script IDA Python è nascondere tutti i blocchi di codice che coinvolgono una chiamata a questa funzione spazzatura, insieme ai suoi argomenti. Ecco come appare DLLEntry dopo l'esecuzione dello script:

DLL Entry dopo la deoffuscazione

Considerazioni importanti

  • Lo script funziona individuando una chiamata alla funzione di padding, rappresentata da call sub_CHANGEME nello script. Pertanto, è necessario rinominarla nello script con il nome della funzione trovata nel campione che si sta analizzando. Ad esempio, cambiando idc.print_operand(x, 0) == 'sub_CHANGEME' in idc.print_operand(x, 0) == 'sub_431000'.

  • Ho scelto di iterare sull'istruzione call sub_CHANGEME invece che sui push degli argomenti. Il motivo è semplice: le stringhe hardcoded sono presenti in più punti del binario; quindi, quando ho provato a cercare le istruzioni push che coinvolgevano gli offset di tali stringhe, lo script non riusciva a trovare tutte le occorrenze di questi dati spazzatura.

  • In precedenza lo script funzionava nascondendo ogni singola istanza del passaggio degli argomenti e della chiamata alla funzione di padding come un unico blocco compresso. Poiché la funzione viene chiamata più volte di seguito, ciò produceva enormi spazi vuoti nella vista del disassembly. Ho aggiornato lo script per nascondere le occorrenze sequenziali di questo padding in un unico blocco compresso, il che migliora davvero la leggibilità.

Scarica lo strumento