mandiant/flare-emuFramework di emulazione binaria scriptabile che integra IDA Pro/Radare2 con il motore Unicorn per l'analisi automatizzata di malware, la decifrazione di stringhe e l'esplorazione di percorsi di codice su architetture x86, ARM e ARM64.
flare-emu unisce un framework di analisi binaria supportato, come IDA Pro o Radare2, con il framework di emulazione Unicorn per fornire all'utente un'interfaccia facile da usare e flessibile per scrivere script di emulazione. È progettato per gestire tutte le attività di manutenzione necessarie per impostare un emulatore flessibile e robusto per le architetture supportate, in modo che tu possa concentrarti sulla risoluzione dei problemi di analisi del codice. Attualmente, flare-emu supporta le architetture x86, x86_64, ARM e ARM64.
Attualmente fornisce cinque diverse interfacce per soddisfare le tue esigenze di emulazione, insieme a una serie di funzioni helper e utility correlate.
emulateRange – Questa API viene utilizzata per emulare un intervallo di istruzioni, o una funzione, all'interno di un contesto specificato dall'utente. Fornisce opzioni per hook definiti dall'utente sia per singole istruzioni che per quando vengono incontrate istruzioni "call". L'utente può decidere se l'emulatore salterà o chiamerà le funzioni. Questa interfaccia fornisce un modo semplice per l'utente di specificare valori per registri e argomenti dello stack. Se viene specificata una stringa di byte, viene scritta nella memoria dell'emulatore e il puntatore viene scritto nel registro o nella variabile dello stack. Dopo l'emulazione, l'utente può utilizzare le funzioni utility di flare-emu per leggere dati dalla memoria emulata o dai registri, oppure utilizzare l'oggetto di emulazione Unicorn restituito per un'analisi diretta. Una piccola funzione wrapper per emulateRange, chiamata emulateSelection, può essere utilizzata per emulare l'intervallo di istruzioni attualmente evidenziato in IDA Pro.
iterate - Questa API viene utilizzata per forzare l'emulazione lungo rami specifici all'interno di una funzione per raggiungere un determinato target. L'utente può specificare un elenco di indirizzi target, o l'indirizzo di una funzione da cui viene utilizzato un elenco di cross-reference alla funzione come target, insieme a un callback per quando un target viene raggiunto. I target verranno raggiunti, indipendentemente dalle condizioni durante l'emulazione che potrebbero aver causato l'assunzione di rami diversi. Come l'API emulateRange, vengono fornite opzioni per hook definiti dall'utente sia per singole istruzioni che per quando vengono incontrate istruzioni "call". Un esempio di utilizzo dell'API iterate è ottenere qualcosa di simile a ciò che fa il nostro strumento argtracker.
iterateAllPaths - Questa API è molto simile a iterate, tranne per il fatto che invece di fornire un indirizzo target o indirizzi, fornisci una funzione target di cui cercherà di trovare tutti i percorsi ed emularli. Questo è utile quando si esegue un'analisi del codice che vuole raggiungere ogni blocco base di una funzione.
emulateBytes – Questa API fornisce un modo per emulare semplicemente un blob di shellcode estraneo. I byte forniti non vengono aggiunti all'IDB e vengono semplicemente emulati così come sono. Questo può essere utile per preparare l'ambiente di emulazione. Ad esempio, flare-emu stesso utilizza questa API per manipolare un Model Specific Register (MSR) per la CPU ARM64 che non è esposto da Unicorn per abilitare le istruzioni Vector Floating Point (VFP) e l'accesso ai registri. L'oggetto di emulazione Unicorn viene restituito per ulteriori analisi da parte dell'utente.
emulateFrom - Questa API è utile nei casi in cui i confini delle funzioni non sono chiaramente definiti, come spesso accade con binari offuscati o shellcode. Fornisci un indirizzo di partenza ed emulerà fino a quando non rimane nulla da emulare o interrompi l'emulazione in uno dei tuoi hook. Con IDA Pro, questo può essere chiamato con il parametro strict impostato su False per abilitare la scoperta dinamica del codice; flare-emu farà sì che IDA Pro crei le istruzioni man mano che vengono incontrate durante l'emulazione.
Per installare flare-emu per IDA Pro, basta copiare flare_emu.py, flare_emu_ida.py e flare_emu_hooks.py nella directory python di IDA Pro e importarlo come modulo nei tuoi script IDAPython.
Per installare flare-emu per Rizin, assicurati semplicemente che flare_emu.py, flare_emu_rizin.py e flare_emu_hooks.py siano nel percorso di ricerca di Python per importare moduli. Quando si utilizza Rizin come componente di analisi binaria per flare-emu, è richiesto rzpipe.
Per installare flare-emu per Radare2, assicurati semplicemente che flare_emu.py, flare_emu_radare.py e flare_emu_hooks.py siano nel percorso di ricerca di Python per importare moduli. Quando si utilizza Radare2 come componente di analisi binaria per flare-emu, è richiesto r2pipe.
In ogni caso, flare-emu dipende da Unicorn e dai suoi binding Python.
NOTA IMPORTANTE
flare-emu è stato scritto utilizzando la nuova API di IDA Pro 7x, non è compatibile con le versioni precedenti di IDA Pro.
Sebbene flare-emu possa essere utilizzato per risolvere molti diversi problemi di analisi del codice, uno dei suoi usi più comuni è quello di aiutare a decifrare le stringhe nei binari malware. FLOSS è un ottimo strumento che spesso può farlo automaticamente per te cercando di identificare le funzioni di decifratura delle stringhe e utilizzando l'emulazione per decifrare le stringhe passate in ogni cross-reference ad essa. Tuttavia, non è possibile per FLOSS essere sempre in grado di identificare queste funzioni ed emularle correttamente utilizzando i suoi approcci generici. A volte devi fare un piccolo lavoro extra, ed è qui che flare-emu può farti risparmiare molto tempo una volta che ti senti a tuo agio con esso. Esaminiamo uno scenario comune che un analista malware incontra quando ha a che fare con stringhe crittografate.
Hai identificato la funzione per decifrare tutte le stringhe in un binario x86_64. Questa funzione viene chiamata ovunque e decifra molte stringhe diverse. In IDA Pro, dai un nome a questa funzione decryptString. Ecco il tuo script flare-emu per decifrare tutte queste stringhe e inserire commenti con le stringhe decifrate in ogni chiamata di funzione, oltre a registrare ogni stringa decifrata e l'indirizzo in cui è stata decifrata.```
from future import print_function
import flare_emu
def decrypt(argv): myEH = flare_emu.EmuHelper() myEH.emulateRange(myEH.analysisHelper.getNameAddr("decryptString"), registers = {"arg1":argv[0], "arg2":argv[1], "arg3":argv[2], "arg4":argv[3]}) return myEH.getEmuString(argv[0])
def iterateCallback(eh, address, argv, userData): s = decrypt(argv) print("%s: %s" % (eh.hexString(address), s)) eh.analysisHelper.setComment(address, s, False)
if name == 'main':
eh = flare_emu.EmuHelper()
eh.iterate(eh.analysisHelper.getNameAddr("decryptString"), iterateCallback)
In `__main__`, iniziamo creando un'istanza della classe `EmuHelper` da `flare-emu`. Questa è la classe che usiamo per fare tutto con `flare-emu`. Successivamente, utilizziamo l'API `iterate`, fornendole l'indirizzo della nostra funzione `decryptString` e il nome della nostra funzione di callback che `EmuHelper` chiamerà per ogni riferimento incrociato emulato.
La funzione `iterateCallback` riceve l'istanza di EmuHelper, qui chiamata `eh`, insieme all'indirizzo del riferimento incrociato, agli argomenti passati a questa particolare chiamata e a un dizionario speciale chiamato `userData`. `userData` non viene utilizzato in questo semplice esempio, ma pensalo come un contesto persistente per il tuo emulatore in cui puoi memorizzare i tuoi dati personalizzati. Tuttavia, stai attento, perché anche `flare-emu` stesso utilizza questo dizionario per memorizzare informazioni critiche necessarie allo svolgimento dei suoi compiti. Un dato di questo tipo è l'istanza stessa di `EmuHelper`, memorizzata nella chiave "EmuHelper". Se sei interessato, cerca nel codice sorgente per saperne di più su questo dizionario. Questa funzione di callback si limita a chiamare la funzione `decrypt`, stampa la stringa decifrata e crea un commento per essa all'indirizzo di quella chiamata a `decryptString`.
`decrypt` crea una seconda istanza di `EmuHelper` che viene utilizzata per emulare la funzione `decryptString` stessa, che decifrerà la stringa per noi. Il prototipo di questa funzione `decryptString` è il seguente: `char * decryptString(char *text, int textLength, char *key, int keyLength)`. Decifra semplicemente la stringa sul posto. La nostra funzione `decrypt` passa gli argomenti ricevuti dalla funzione `iterateCallback` alla nostra chiamata all'API `emulateRange` di `EmuHelper`. Poiché si tratta di un binario `x86_64`, la convenzione di chiamata utilizza i registri per passare gli argomenti e non lo stack. `flare-emu` determina automaticamente quali registri rappresentano quali argomenti in base all'architettura e al formato del file del binario come determinato da IDA Pro, permettendoti di scrivere codice almeno in qualche modo indipendente dall'architettura. Se si trattasse di `x86` a 32 bit, useresti invece l'argomento `stack` per passare gli argomenti, in questo modo: `myEH.emulateRange(myEH.analysisHelper.getNameAddr("decryptString"), stack = [0, argv[0], argv[1], argv[2], argv[3]])`. Il primo valore dello stack è l'indirizzo di ritorno in `x86`, quindi qui usiamo semplicemente `0` come valore segnaposto. Una volta completata l'emulazione, chiamiamo l'API `getEmuString` per recuperare la stringa terminata da null memorizzata nella posizione di memoria puntata dal primo argomento passato alla funzione.
### flare-emu e idalib
* installa IDA Pro
* installa idalib secondo la guida utente di Hex-Rays
* (attiva l'ambiente virtuale)
* pip install /path/to/IDA/installation/idalib/python
* python /path/to/IDA/installation/idalib/python/py-activate-idalib.py [-d /path/to/active/IDA/installation]
* importa idapro e scrivi il tuo script
* vedi tests/test_flare_emu_idalib.py per un esempio
### Scenario di decifratura semplice di stringhe con Rizin
Usando lo stesso esempio di sopra, non cambia molto quando si lavora con Rizin anziché con IDA Pro. Una differenza è che `flare-emu` è attualmente progettato per essere eseguito come script da riga di comando o all'interno di una shell Python quando si lavora con Rizin. La shell Python è ottima per la risoluzione di problemi ad hoc, mentre lo script da riga di comando è ottimo per l'elaborazione in batch. La versione Rizin dello script sopra appare così (puoi anche omettere il percorso del campione per eseguirlo all'interno di rizin):```
from __future__ import print_function
import sys
import flare_emu
def decrypt(argv, eh):
myEH = flare_emu.EmuHelper(samplePath=sys.argv[1], emuHelper=eh, isRizin=True)
myEH.emulateRange(
myEH.analysisHelper.getNameAddr("decryptString"),
registers={
"arg1": argv[0],
"arg2": argv[1],
"arg3": argv[2],
"arg4": argv[3],
},
)
return myEH.getEmuString(argv[0])
def iterateCallback(eh, address, argv, userData):
s = decrypt(argv, eh)
print("%s: %s" % (eh.hexString(address), s))
eh.analysisHelper.setComment(address, s, False)
if __name__ == "__main__":
eh = flare_emu.EmuHelper(samplePath=sys.argv[1], isRizin=True)
rz = eh.analysisHelper.r
eh.analysisHelper.setName(0x100000D60, "decryptString")
eh.iterate(eh.analysisHelper.getNameAddr("decryptString"), iterateCallback)
Usando lo stesso esempio di cui sopra, non cambia molto quando si lavora con Radare2 anziché con IDA Pro. Una differenza è che flare-emu è attualmente progettato per essere eseguito come script da riga di comando o all'interno di una shell Python quando si lavora con Radare2. La shell Python è ottima per la risoluzione di problemi ad hoc, mentre lo script da riga di comando è ottimo per l'elaborazione batch. La versione dello script sopra con Radare2 si presenta così:```
from future import print_function
import flare_emu
def decrypt(argv, eh): myEH = flare_emu.EmuHelper(samplePath=sys.argv[1], emuHelper=eh) myEH.emulateRange(myEH.analysisHelper.getNameAddr("decryptString"), registers = {"arg1":argv[0], "arg2":argv[1], "arg3":argv[2], "arg4":argv[3]}) return myEH.getEmuString(argv[0])
def iterateCallback(eh, address, argv, userData): s = decrypt(argv, eh) print("%s: %s" % (eh.hexString(address), s)) eh.analysisHelper.setComment(address, s, False)
if name == 'main':
eh = flare_emu.EmuHelper(samplePath=sys.argv[1])
eh.analysisHelper.setName(, "decryptString")
eh.iterate(eh.analysisHelper.getNameAddr("decryptString"), iterateCallback)
Ci sono due differenze con questo script. In primo luogo, il costruttore `EmuHelper` accetta un parametro qui: `samplePath=sys.argv[1]`. Quando viene fornito il parametro `samplePath`, `flare-emu` userà Radare2 con `r2pipe` come suo motore di analisi binaria. Si può anche notare che un secondo parametro viene passato alla seconda istanza di `EmuHelper` creata nella funzione `decrypt`. Il parametro `emuHelper` accetta un oggetto `EmuHelper` esistente e clona la sua memoria quando crea il nuovo oggetto. Inoltre, se si utilizza Radare2, la nuova istanza riutilizza la sessione Radare2 esistente invece di crearne una nuova che aggiungerebbe più overhead. In secondo luogo, `flare-emu` crea una nuova istanza di Radare2 usando `r2pipe.open`, quindi probabilmente non avrà il nome `decryptString` per la funzione che ci interessa. È possibile impostare il nome da soli usando l'oggetto `analysisHelper` di `EmuHelper` in questo modo: `eh.analysisHelper.setName(<qualche indirizzo>, "decryptString")`, oppure si può inserire direttamente l'indirizzo per le chiamate a `iterate` e `emulateRange`.
## [Funzioni di Emulazione](#emulationfuncs)
`emulateRange(startAddr, endAddr=None, registers=None, stack=None, instructionHook=None, callHook=None, memAccessHook=None, hookData=None, skipCalls=True, hookApis=True, strict=True, count=0)` - Emula l'intervallo di istruzioni a partire da `startAddress` e terminando a `endAddress`, esclusa l'istruzione a `endAddress`. Se endAddress è `None`, l'emulazione si ferma quando viene incontrata un'istruzione di tipo "return" all'interno della stessa funzione in cui l'emulazione è iniziata.
* `registers` è un dizionario con chiavi che sono nomi di registri e valori che sono valori di registri. Alcuni nomi di registri speciali sono creati da `flare-emu` e possono essere usati qui, come `arg1`, `arg2`, ecc., `ret` e `pc`.
* `stack` è un array di valori da spingere sullo stack in ordine inverso, molto simile agli argomenti di una funzione in `x86`. In `x86`, ricordarsi di considerare il primo valore di questo array come l'indirizzo di ritorno di una chiamata di funzione e non il primo argomento della funzione. `flare-emu` inizializzerà il contesto e la memoria del thread emulato secondo i valori specificati negli argomenti `registers` e `stack`. Se viene specificata una stringa per uno qualsiasi di questi valori, verrà scritta in una posizione in memoria e un puntatore a quella memoria verrà scritto nel registro o nella posizione dello stack specificata.
* `instructionHook` può essere una funzione da te definita per essere chiamata prima che ogni istruzione venga emulata. Ha il seguente prototipo: `instructionHook(unicornObject, address, instructionSize, userData)`.
* `callHook` può essere una funzione da te definita per essere chiamata ogni volta che viene incontrata un'istruzione di tipo "call" durante l'emulazione. Ha il seguente prototipo: `callHook(address, arguments, functionName, userData)`.
* `hookData` è un dizionario contenente dati definiti dall'utente da rendere disponibili alle funzioni di hook. È un mezzo per persistere dati durante l'emulazione. `flare-emu` usa anche questo dizionario per i propri scopi, quindi bisogna fare attenzione a non definire una chiave già definita. Questa variabile è spesso chiamata `userData` nelle funzioni di hook definite dall'utente a causa della sua denominazione in Unicorn.
* `skipCalls` farà sì che l'emulatore salti le istruzioni di tipo "call" e aggiusti lo stack di conseguenza, il valore predefinito è `True`.
* `hookApis` fa sì che `flare-emu` esegua un'implementazione naïve di alcune delle più comuni funzioni di runtime e libreria di sistema che incontra durante l'emulazione. Questo ti libera dalla preoccupazione di chiamate a funzioni come `memcpy`, `strcat`, `malloc`, ecc., e il valore predefinito è `True`.
* `memAccessHook` può essere una funzione da te definita per essere chiamata ogni volta che la memoria viene acceduta in lettura o scrittura. Ha il seguente prototipo: `memAccessHook(unicornObject, accessType, memAccessAddress, memAccessSize, memValue, userData)`.
* `strict`, quando impostato su `True` (predefinito), controlla le destinazioni dei branch per assicurarsi che il disassemblatore si aspetti istruzioni. Altrimenti salta l'istruzione di branch. Se impostato su `False` quando si usa IDA Pro, `flare-emu` farà sì che IDA Pro crei istruzioni mentre le emula **(DISABILITARE CON CAUTELA)**.
* `count` è il numero massimo di istruzioni da emulare, il valore predefinito è `0` che significa nessun limite.
`iterate(target, targetCallback, preEmuCallback=None, callHook=None, instructionHook=None, hookData=None, resetEmuMem=False, hookApis=True, memAccessHook=None)` - Per ogni target specificato da `target`, viene eseguita un'emulazione separata dall'inizio della funzione contenente fino all'indirizzo del target. L'emulazione sarà forzata lungo i rami necessari per raggiungere ciascun target. `target` può essere l'indirizzo di una funzione, nel qual caso la lista dei target viene popolata con tutti i cross-reference alla funzione specificata. Oppure, `target` può essere una lista esplicita di target.
* `targetCallback` è una funzione che crei e che sarà chiamata da `flare-emu` per ogni target raggiunto durante l'emulazione. Ha il seguente prototipo: `targetHook(emuHelper, address, arguments, userData)`.
* `preEmuCallback` è una funzione che crei e che sarà chiamata prima che l'emulazione per ciascun target inizi. Puoi implementare qui del codice di setup se necessario.
* `resetEmuMem` farà sì che `flare-emu` resetti la memoria di emulazione prima che l'emulazione di ciascun target inizi, il valore predefinito è `False`.
`iterateAllPaths(target, targetCallback, preEmuCallback=None, callHook=None, instructionHook=None, hookData=None, resetEmuMem=False, hookApis=True, memAccessHook=None, maxPaths=MAXCODEPATHS, maxNodes=MAXNODESEARCH)` - Per la funzione contenente l'indirizzo `target`, viene eseguita un'emulazione separata per ogni percorso scoperto attraverso di essa, fino a `maxPaths`.
* `maxPaths` - il numero massimo di percorsi attraverso la funzione che verranno cercati ed emulati. Alcune delle funzioni più complesse possono far sì che la funzione di ricerca del grafo impieghi molto tempo o non finisca mai; regola questo parametro per soddisfare le tue esigenze in un tempo ragionevole.
* `maxNodes` - il numero massimo di blocchi di base che verranno cercati quando si trovano percorsi attraverso la funzione target. Questa è una misura di sicurezza per prevenire tempi di ricerca irragionevoli e blocchi, e probabilmente non necessita di essere modificato.
`emulateBytes(bytes, registers=None, stack=None, baseAddress=0x400000, instructionHook=None, hookData=None)` - Scrive il codice contenuto in `bytes` nella memoria di emulazione a `baseAddress` se possibile ed emula le istruzioni dall'inizio alla fine di `bytes`.
`emulateFrom(startAddr, registers=None, stack=None, instructionHook=None, callHook=None, memAccessHook=None, hookData=None, skipCalls=True, hookApis=True, strict=True, count=0)` - Questa API è utile nei casi in cui i confini delle funzioni non sono chiaramente definiti, come spesso accade con binari offuscati o shellcode. Fornisci un indirizzo di partenza come `startAddr`, ed emulerà finché non c'è più nulla da emulare o fino a quando non interrompi l'emulazione in uno dei tuoi hook. Può essere chiamata con il parametro `strict` impostato su `False` per abilitare la scoperta dinamica del codice; `flare-emu` farà sì che IDA Pro crei istruzioni man mano che vengono incontrate durante l'emulazione.
## [Funzioni Utilità](#utility)
La seguente è una lista incompleta di alcune delle utili funzioni di utilità fornite dalla classe `EmuHelper`.
* `hexString(value)` - Restituisce una stringa formattata in esadecimale per il valore. Utile per logging e istruzioni di stampa.
* `skipInstruction(userData, useAnalysisHelper=False)` - Chiama questa da un hook di emulazione per saltare l'istruzione corrente, spostando il contatore di programma all'istruzione successiva. L'opzione `useAnalysisHelper` è stata aggiunta per gestire i casi in cui il framework di analisi binaria fonde più istruzioni in una pseudo-istruzione e si desidera saltarle tutte. Questa funzione non può essere chiamata più volte da un singolo hook di istruzione per saltare più istruzioni. Per saltare più istruzioni, si consiglia di non scrivere direttamente al contatore di programma se si sta emulando codice ARM poiché ciò potrebbe causare problemi con la modalità thumb. Invece, prova l'API `changeProgramCounter` di `EmuHelper` (descritta sotto).
* `changeProgramCounter(userData, newAddress)` - Chiama questa da un hook di emulazione per cambiare il valore del registro contatore di programma. Questa API gestisce il tracciamento della modalità thumb per l'architettura ARM.
* `getRegVal(registerName)` - Recupera il valore del registro specificato, essendo sensibile all'indirizzamento dei sotto-registri. Ad esempio, "ax" restituirà i 16 bit inferiori del registro EAX/RAX in `x86`.
* `stopEmulation(userData)` - Chiama questa da un hook di emulazione per fermare l'emulazione. Usa questa invece di chiamare l'API Unicorn `emu_stop` in modo che l'oggetto `EmuHelper` possa gestire la contabilità relativa alla funzionalità `iterate`.
* `getEmuString(address)` - Restituisce la stringa di caratteri situata a un indirizzo nella memoria emulata, fino a un terminatore nullo. I caratteri non sono necessariamente stampabili.
* `getEmuWideString(address)` - Restituisce la stringa di "caratteri wide" situata a un indirizzo nella memoria emulata, fino a un terminatore nullo. "Caratteri wide" è inteso in senso lato per riferirsi a qualsiasi serie di byte contenente un byte nullo ogni due byte, come sarebbe il caso per una stringa ASCII codificata in UTF-16 LE. I caratteri non sono necessariamente stampabili.
* `getEmuBytes(address, length)` - Restituisce una stringa di byte situata a un indirizzo nella memoria emulata.
* `getEmuPtr(address)` - Restituisce il valore del puntatore situato all'indirizzo dato.
* `writeEmuPtr(address, value)` - Scrive il valore del puntatore all'indirizzo dato nella memoria emulata.
* `loadBytes(bytes, address=None)` - Alloca memoria nell'emulatore e vi scrive i byte.
* `isValidEmuPtr(address)` - Restituisce `True` se l'indirizzo fornito punta a memoria emulata valida.
* `getEmuMemRegion(address)` - Restituisce una tupla contenente l'indirizzo di inizio e di fine della regione di memoria che contiene l'indirizzo fornito, o `None` se l'indirizzo non è valido.
* `getArgv()` - Chiama questa da un hook di emulazione a un'istruzione di tipo "call" per ricevere un array degli argomenti della funzione.
* `addApiHook(apiName, hook)` - Aggiunge un nuovo hook API per questa istanza di `EmuHelper`. Ogni volta che un'istruzione di chiamata a `apiName` viene incontrata durante l'emulazione, `EmuHelper` chiamerà la funzione specificata da `hook`. Se `hook` è una stringa, ci si aspetta che sia il nome di un'API già hookata da `EmuHelper`, nel qual caso chiamerà la sua funzione di hook esistente. Se `hook` è una funzione, chiamerà quella funzione.
* `allocEmuMem(size, addr=None)` - Alloca memoria emulatore sufficiente a contenere `size` byte. Tenta di onorare l'`address` richiesto, ma se si sovrappone a una regione di memoria esistente, allocherà in una regione di memoria inutilizzata e restituirà il nuovo indirizzo. Se l'indirizzo non è allineato alla pagina, restituirà un indirizzo che mantiene lo stesso offset all'interno della nuova regione allineato alla pagina. Ad esempio, richiedendo l'indirizzo `0x1234` quando `0x1000` è già allocato, potrebbe allocare a `0x2000` e restituire `0x2234`.
# [Scopri di Più](#learn)
Per saperne di più su **flare-emu**, leggi il nostro blog introduttivo all'indirizzo https://www.fireeye.com/blog/threat-research/2018/12/automating-objective-c-code-analysis-with-emulation.html.