Questa pagina web, negli anni, è stata la più visitata perchè presa come riferimento per l'eventuale acquisto di un obfuscator. Purtroppo, il più delle volte, si valuta un prodotto solo dal prezzo e non dalle reali caratteristiche: quello che nessuno dice è che la protezione di alcuni prodotti viene eliminata in poco tempo con danni enormi per tutte le Aziende.
* * * * *
Negli ultimi anni, l'offuscamento del codice è venuto alla ribalta come la "soluzione a basso costo" utile a migliorare la sicurezza del nostro software: si rendere difficile - ad un attacker- la comprensione del funzionamento interno di un software.
Un obfuscator O può essere considerato come un "efficiente compilatore" che, da un programma P, genera un nuovo programma O(P) con le stesse funzionalità ma con una struttura interna incomprensibile.
La sicurezza di un obfuscator è di tipo probabilistico: per garantire sicurezza è necessario provare che non esiste nessuna tecnica capace di violare, in tempi brevi, una determinata protezione.
La sola modifica del formato Portable Executable (PE) standard non può bloccare l'analisi sugli assembly .NET
Un'altra tecnica obsoleta - ancora presente in .NET Reactor (ed altri) - consiste nel modificare il valore di NumberOfRvaAndSizes da 0x10 a 0x0F: tale modifica "blocca apparentemente" solo .NET Reflector con il seguente messaggio di errore:
Oppure altre modifiche ai metadati che producono i seguenti errori:
Tutte queste tecniche vengono automaticamente bypassate con:
...e, nel frattempo, tutti hanno copiato tutto!
N.B.: Le modifiche al formato PE
fino ad ora evidenziate non funzionano
con le applicazioni: WP7, WPF-Browser, Silverlight, ect. (in quanto
eseguite
in una "sandbox protetta" con pre-verifica della struttura)
Una cattiva implementazione dei predicati-opachi (ovvero di espressioni il cui valore può essere deciso a priori) ha, invece, pregiudicato la corretta progettazione di trasformazioni al codice. In particolare per due prodotti:
si è riscontrato una resilienza trivial (quanto un costrutto è resistente ad un deobfuscator) che viene bypassata con l'analisi statica e con l'uso di pattern matching di funzioni ben definite.
Dotfuscator affida, quindi, la protezione del codice al renaming ed a salti-condizionali del tipo: if-true, if-false, oppure al check di due valori (if 6>5, ect.):
per una modifica automatica si usa:
...e, all'attacker, non rimane che fare un banale "copia-incolla" del codice!
Xenocode, invece, affida, la protezione del codice al renaming ed a salti-condizionali del tipo:
il codice è sempre leggibile ed è ancora possibile fare un "copia-incolla"! Per affinare la qualità del codice decompilato è possibile bypassare questa tecnica con l'uso di:
Come già detto la sicurezza di un obfuscator è di tipo probabilistico. A partire dal lontano 2007, alcuni competitors, anzichè capire il perchè si intraprendono determinate strategie di protezione, le hanno direttamente implementate in altri prodotti: sia gratuiti che commerciali.
Oggi, è facile, assistere ad un vero e proprio "effetto-boomerang": è stato provato, infatti, che esistono tecniche capaci di violare determinate tecniche (obsolete e datate 2005 ma continuano ad essere utilizzate).
Le tecniche obsolete riguardano:
che vengono, ora, eliminate "sfruttando" il nuovo decompilatore ILSpy:
che portano alla decompilazione per tutti i software "offuscati" con:
ed ora, chi si è affidato a tali prodotti, può fare solo un "mea-culpa": la qualità di un obfuscator non si valuta dal solo prezzo finale!
IsValidName: verifica presenza nomi con caratteri non stampabili
Controllo di validità, ad esempio, nella lettura dei nomi dei metodi
...risultato finale direttamente sull'assembly di un obfuscator!
ed ora che i nomi dei membri sono "unici", si procede con un "copia-incolla" del codice!
Quando un obfuscator inizia a cadere sotto i colpi dei vari de-obfuscator automatici si cerca di correre ai ripari. Invece di sperimentare nuove tecniche si continua a copiare le implementazioni dei "competitors". Stranamente nei seguenti obfuscators:
si scopre una tecnica comune ma ormai, da tempo, obsoleta! Dato il semplice metodo con un argomento stringa, ed il suo codice in assembler-IL:
si nota la presenza delle seguenti istruzioni: ldtoken, pop
Il token passato (sia esso MethodInfo, FieldInfo o Type) viene convertito in RuntimeHandle e pushato sullo stack per poi essere immediatamente poppato! ...in pratica nessuna modifica al codice!
Tale strategia "blocca" solo .NET Reflector (per una funzionalità non implementata) e getta "fumo negli occhi" a chi deve valutare realmente le potenzialità di un obfuscator!
Basta spiare il codice con un altro decompilatore (ILSpy, ect.) per capire il fallimento totale di tale tecnica...ed il codice "ritenuto sicuro" appartiene già ad un altro!
Modificando la sequenza di byte:
il codice torna visibile anche sotto .NET Reflector!
Dato che la signature per l'istruzione ldtoken può variare (i 4 bytes dopo D0), è possibile automatizzare la sostituzione utilizzando, ad esempio, CFF Explorer (con uno script per il replace dei bytes).
Considerata la frenetica evoluzione dei decompilatori .NET, è necessario rivedere radicalmente l'approccio alla protezione del codice .NET
Poichè un aggressore avrà sempre bisogno di un decompilatore per ricostruire il codice in un linguaggio di programmazione ad alto livello, è necessario modificare la struttura interna (variabili, valori numerici, array, call, ect.) in modo che la decompilazione del nuovo formato produca un codice sorgente che sia estremamente difficile da capire per un essere umano, e praticamente impossibile da ricompilare con un "normale" compilatore:
In anteprima, il nuovo ed innovativo approccio alla protezione del software:
Goliath .NET Obfuscator altera la struttura di un assembly .NET (.exe o .dll) in modo tale che la decompilazione del nuovo formato produca un codice sorgente che sia estremamente difficile da capire per un essere umano, e praticamente impossibile da ricompilare con un "normale" compilatore:
In anteprima, il nuovo ed innovativo approccio alla protezione del software:
Il canone di manutenzione consente di usufruire di assistenza tecnica illimitata e, in automatico, degli aggiornamenti software:
