%%
… prima ancora di toccare un debugger - o quasi!…
Per prima cosa, in assoluto, ha senso cercare di capire quali librerie vengono usate dal binario. Questo è un trucco che ho imparato ad OBTS per l’analisi statica del malware. L’esempio é triviale: se un eseguibile ha dipendenze con librerie per la gestione della cam, potrebbe avere un payload pensato per rubare immagini ambientali. Vedremo con piú precisione questa tecnica in azione proprio sul malware. In generale, l’obbiettivo deve essere capire cosa viene importato dall’eseguibile. Anche (e specie!) a runtime.
Il secondo quick win é ottenere le stringhe del binario. “ai bei vecchi tempi” abbiamo grabbato password in chiaro proprio dai binari. Certo, ora le practice di sviluppo sono migliorate… ma anche no! Altrimenti tutta la schiera immane di pentester che sono in giro farebbe la fame.
Comportamento di base: il binario si connette ad internet? Se sí, a cosa? Perché? Che dati si scambia?
Un’altra domanda che mi pongo sempre é: il binario é stato “strippato”? Quanto rimane dei simboli originali nell’assembly? E no, non serve l’assembly. Basta lanciare di nuovo strip sul binario. Anche questa tecnica verrà largamente illustrata.
Protezioni “visibili”. Per fare un esempio Apple, la prima cosa da chiedersi é se il programma é codesign-ed, quali sono gli entitlements. Ma ci sono moltissimi aspetti da controllare - io stesso me ne scordo sempre la maggior parte :). NX, RELRO, etc. - me ne scordo sempre.
Questo ci porta alla gestione della memoria e degli indirizzi. Il binario é - position-independent (PIE/ASLR)? Nel qual caso, come calcolare gli indirizzi?
Il prossimo step sarà capire se il binario é packed, offuscato, cifrato in qualche modo.
Infine, ci dobbiamo fare un’idea della architettura, se é il caso, delle ABI.
L’output di questa fase dovrebbe essere avere una serie di artefatti quali:
queste informazioni ci permetteranno di creare una prima ipotesi di architettura. %%
Scrivo questo post per formalizzare alcuni concetti sul Reverse Engineering, e per condividere la metodologia che verrà usata in questi post.
Non si tratta di una metodologia incisa nella pietra, io stesso non la seguo sempre integralmente.
Questo approccio mi sembra il più logico e funzionale tra quelli che ho provato. Il flusso é stato derivato dagli standard del penetration testing, e da quanto ho visto durante i miei trascorsi traditori da sviluppatore di exploit per applicativi linux.
Si potrebbe obiettare che Linux é uno pseudo-SystemV mentre il layer posix di macOS deriva da BSD, tuttavia vedremo che i concetti di fondo siano consistenti e applicabili in entrambi gli ambienti.
Forniamo una prima modellazione del metodo che useremo. Per quantoo approssimativa e brutale, permutando dal penetration testing:
Ho deliberatamente scelto di usare il modello del pentesting perchè da un lato lo conosco bene, da un altro, alcuni trucchi e raccomandazioni che si danno in quell’ambito sono oro quando si parla di reversing. La più importante? In 25 anni di penetration testing ho imparato che:
Eseguire con precisione la fase di reconnaissance è cruciale: se fatta bene, metà del test è già fatto.
Di contro, va detto che nel reversing non esiste una vera e propria fase di attacco, quindi dobbiamo specializzare cosa intendiamo per reconnaissance.
Immagino che i