A TAXONOMY OF OBFUSCATING TRASFORMATIONS Funes Daniel 809619 Salvador Carlo 803776 Corso di Analisi e Verifica dei Programmi 2006/2007.

Presentazione sul tema: "A TAXONOMY OF OBFUSCATING TRASFORMATIONS Funes Daniel 809619 Salvador Carlo 803776 Corso di Analisi e Verifica dei Programmi 2006/2007."— Transcript della presentazione:

1 A TAXONOMY OF OBFUSCATING TRASFORMATIONS Funes Daniel 809619 Salvador Carlo 803776 Corso di Analisi e Verifica dei Programmi 2006/2007

2 INTRODUZIONE Il software contiene informazioni riservate ed è una proprietà intellettuale di chi lo produce: Codice Algoritmi Chiavi segrete Attraverso le tecniche di analisi dei programmi (DataFlow Analysis) è possibile analizzare il comportamento di un software e rubarne i segreti. Con abbastanza risorse in tempo e sforzo, un programmatore è capace di fare il reverse engineering di una applicazione, soprattutto se sviluppata in un linguaggio come Java, distribuita in formato semplice da decompilare.

3 PROTEZIONE DEL SOFTWARE: Scenario Una volta creata lapplicazione deve essere distribuita in qualche forma(codice nativo, bytecode). Alice e Bob sono due sviluppatori software, Bob è malintenzionato (algoritmi, strutture dati). La protezione avviene attraverso mezzi legali o tecnici. Le strategie tecniche sono: vendere i servizi, cifrare il codice, compilatore just-in-time, offuscamento del codice.

4 ALICE E BOB: vendere i servizi

5 ALICE E BOB: cifratura e compilatori just-in -time

6 ALICE E BOB: offuscamento del codice Alice da in input lapplicazione ad un offuscatore, con vantaggi e svantaggi. Il livello di sicurezza aggiunto da unoffuscatore ad unapplicazione dipende da: la potenza degli algoritmi di offuscamento, la quantità di risorse (tempo e spazio) disponibili al deoffuscatore.

7 TRASFORMAZIONI OFFUSCANTI: classificazione Le trasformazioni si classificano e si valutano rispetto alla loro: potenza: grado di confusione causato nellutente malizioso; resilienza: quanto il codice offuscato è resistente ad un attacco deoffuscante; costo: quanto overhead è aggiunto allapplicazione originale.

8 TRASFORMAZIONI OFFUSCANTI: definizione Sia t:P P una trasformazione di un programma sorgente P in un altro programma P. t:P P è una trasformazione offuscante se P e P hanno lo stesso comportamento osservabile e più precisamente devono essere mantenute le seguenti condizioni: se P fallisce nel terminare o termina con una condizione di errore allora P potrebbe terminare oppure no, altrimenti, P deve terminare e produrre lo stesso output di P.

9 VALUTAZIONE DELLLE TRASFORMAZIONI OFFUSCANTI: metriche di complessità E(X) è la complessità di un componente software X. F è una funzione o metodo, C è una classe, e P è un programma. μ1μ1Lunghezza del programma E(P) aumenta col numero di operatori e di operandi in P μ2μ2Cyclomatic Complexity E(F) aumenta col numero di predicati in F μ3μ3Complessità annidata E(F) aumenta con il numero di livelli annidati di predicati condizionali in F μ4μ4Complessità del flusso di dati E(F) aumenta col numero di riferimenti a basic block in F μ5μ5Complessità fan- in/out E(F) aumenta col numero di parametri formali di F, e con il numero di strutture dati globali lette o aggiornate da F

10 VALUTAZIONE DELLLE TRASFORMAZIONI OFFUSCANTI: metriche di complessità μ6μ6Complessità delle strutture dati E(P) aumenta con la complessità delle strutture dati statiche dichiarate in P. La complessità di una variabile scalare è costante; La complessità di un array aumenta col numero di dimensioni e con la complessità del tipo degli elementi; La complessità un record aumenta con il numero e la complessità dei suoi campi.

11 VALUTAZIONE DELLLE TRASFORMAZIONI OFFUSCANTI: metriche di complessità μ7μ7Metrica 00E(C) aumenta con: μ7a, il numero di metodi in C, μ7b, la profondità (la distanza dalla radice) di C nellalbero di ereditarietà μ7c, il numero di sottoclassi dirette di C μ7d, il numero di altre classi alle quali C è associata μ7e, il numero di metodi che possono essere eseguiti in risposta allinvio di un messaggio ad un oggetto di C μ7f, il grado di quali metodi di C non fanno riferimenti allo stesso insieme di variabili distanza.

12 TRASFORMAZIONI OFFUSCANTI: potenza della trasformazione Sia T una trasformazione che conserva il comportamento | t: P P cioè che trasforma un P sorgente in un P. Sia E(P) la complessità di P. T pot (P), la potenza di T rispetto al P, è la misura di quanto T cambia la complessità di P. T pot (P)=E(P)/E(P)-1. T è una trasformazione offuscante potente se: T pot (P)>0. Si misura in (low, medium, high).

13 TRASFORMAZIONI OFFUSCANTI: resilienza della trasformazione Data T locale se ha effetto su un singolo basic block di un grafo del flusso di controllo (CFG), globale se ha effetto sullintero CFG, interprocedurale se ha effetto sul flusso di informazioni tra le procedure, interprocesso se ha effetto sulle interazioni tra thread di controllo in esecuzione indipendente. Si misura su una scala che va da trivial a one-way.

14 TRASFORMAZIONI OFFUSCANTI: resilienza della trasformazione Sia T una trasformazione che conserva il comportamento | t : P P. T res (P) è la resilienza di T rispetto al programma P. T res (P) è one-way se linformazione è rimossa da P in modo che P non possa più essere ricostruito da P. Altrimenti T res =resilienza(T sforzo D, T sforzo P). La resilienza è la f definita dalla matrice seguente:

15 TRASFORMAZIONI OFFUSCANTI: costo della trasformazione E loverhead di tempo/spazio che una trasformazione aggiunge ad unapplicazione. E classificato su una scala a 4 punti (free, cheap, costly, dear). T cost (P) è loverhead in termini di tempo/spazio in P rispetto a P e può essere: dear, se P richiede una quantità esponenziale di risorse rispetto a P. costly, se P richiede più di O(n^p ), p>1, risorse rispetto a P. cheap, se P richiede più di O( n ) risorse rispetto a P. free, se P richiede più di O(1) risorse rispetto a P. T qual (P), la qualità di una trasformazione T è definita come: T qual (P)=(T pot (P),T res (P),T cost (P)).

16 TRASFORMAZIONI DEL CONTROLLO Le TRASFORMAZIONI DEL CONTROLLO tentano di oscurare il flusso di controllo dellapplicazione sorgente: Aggregazione : spezzano le computazioni logicamente affini oppure fonde computazioni non logicamente affini; Ordine di controllo : randomizza lordine con cui le computazioni sono eseguite; Computazioni del flusso di controllo : inseriscono nuovo codice (creano molto overhead).

17 TRASFORMAZIONI DEL CONTROLLO: predicati opachi Una variabile V è opaca nel punto p di un programma, se V ha una proprietà q in p che è conosciuta al momento delloffuscamento. Indicheremo ciò con V p^ q o con V^q se p è libero dal contesto. Un predicato P è opaco nel punto p di un programma, se il suo esito è conosciuto al momento delloffuscamento. Indicheremo con P p ^F o con P p ^T. Misura del costo aggiunto di un costrutto opaco : free, …, dear.

18 TRASFORMAZIONI DEL CONTROLLO: costrutti opachi trivial rotto solo attraverso unanalisi locale statica. unanalisi locale è ristretta ad un singolo basic block del CFG. weak rotto solo attraverso unanalisi globale statica. Unanalisi globale è ristretta ad un singolo CFG.

19 TRASFORMAZIONI DEL CONTROLLO: trasformazioni computazionali Inseriamo codice morto o irrilevante; Aumentando le metriche μ2 e μ3; Inseriamo codice morto o irrilevante;

20 TRASFORMAZIONI DEL CONTROLLO: trasformazioni computazionali Estendere le condizioni dei cicli: il predicato usato x^2(x+1)^2=0(mod 4) è sempre valutato true.

21 TRASFORMAZIONI DEL CONTROLLO: trasformazioni computazionali Convertire un grafo di flusso riducibile ad uno non riducibile. Trasformazioni language-breaking:

22 TRASFORMAZIONI DEL CONTROLLO: trasformazioni computazionali Rimuovere le chiamate a libreria e gli idiomi della programmazione; Molti programmi scritti in Java si basano sulle chiamate alle librerie standard e sui clichè (o pattern). Aggiungere operatori ridondanti P e Q possono assumere tutti i valori il cui quoziente sia 2 ogni volta che lespressione (2') è raggiunta.

23 TRASFORMAZIONI DEL CONTROLLO: trasformazioni computazionali Parallelizzazione del codice Si possono creare due processi fantoccio che non eseguono nessun compito utile. Possiamo spezzare una sezione sequenziale dellapplicazione in sezioni multiple eseguite in parallelo.

24 TRASFORMAZIONI DEL CONTROLLO: trasformazioni per aggregazione Chi programma usa lastrazione procedurale per vincere alcune difficoltà. Queste astrazioni vengono rimosse utilizzando: Inlining, Outlining, Interleaving, Clonazione. Si procede nel modo seguente: Il codice che il programmatore ha allegato insieme in un metodo deve essere sparpagliato nel programma. Il codice che sembra non essere logicamente connesso deve essere aggregato in un metodo.

25 TRASFORMAZIONI DEL CONTROLLO: trasformazioni per aggregazione Metodi Inline e Outline Inline: si rimpiazza una chiamata a procedura con il corpo della procedura chiamata e si rimuove la procedura: altamente resiliente (generalmente one-way); non cè più traccia dellastrazione. Outlining: si trasforma una sequenza di espressioni in una subroutine

26 TRASFORMAZIONI DEL CONTROLLO: trasformazioni per aggregazione Metodi Inline e Outline. Nei linguaggi object oriented come Java, linlining può non sempre essere una trasformazione totalmente one-way. Lattuale procedura chiamata dipenderà dal tipo di m determinato a run-time. Occorre applicare linlining a tutti i possibili metodi e ramificare su m.

27 TRASFORMAZIONI DEL CONTROLLO: trasformazioni per aggregazione Metodi interleave. La scoperta del codice interfogliato è un difficile compito di reverse engineering. Lidea: fondere i corpi e la lista dei parametri dei due metodi; aggiungere un parametro extra (o parametro globale) per discriminare tra le chiamate ai metodi individuali.

28 TRASFORMAZIONI DEL CONTROLLO: trasformazioni per aggregazione Metodi di clonazione. Per capire il comportamento di una subroutine sono importanti anche i differenti ambienti in cui è stata chiamata. Idea : offuscare il punto di una chiamata ad un metodo per far sembrare che differenti routine sono state chiamate.

29 TRASFORMAZIONI DEL CONTROLLO: trasformazioni per aggregazione

30 TRASFORMAZIONI DEI DATI: Storage e Encoding Trasformazioni che oscurano le strutture dati usate nellapplicazione sorgente. Le trasformazioni storage tentano di scegliere una classe di immagazzinamento non naturale sia per i dati dinamici che per quelli statici Es. storage int i; a[i]=3; le trasformazioni encoding tentano di scegliere codifiche non naturali per i comuni tipi di dati Es. encoding 0000000000001100 sarà interpretato come 12.

31 TRASFORMAZIONI DI STORAGE E ENCODING: Cambiare la codifica Viene sostituito i con i=c 1 *i + c 2. c 1 e c 2 sono costanti. Introduce overhead in termini di tempo desecuzione ma può essere deoffuscato usando le comuni tecniche di analisi dei compilatori.

32 TRASFORMAZIONI DI STORAGE E ENCODING: Promozione di variabili Promuovere le variabili da una classe di memorizzazione ad una più generale. Bassa potenza e resilienza, ma usate in modo congiunto con altre trasformazioni sono molto efficienti. Promozione di una varibile da integer ad un oggetto integer Promozione di una varibile da locale a globale, questa trasformazione incrementa la metrica μ5.

33 TRASFORMAZIONI DI STORAGE E ENCODING: Splitting delle varibili (1) Variabili di tipo Boolean o con raggio dazione ridotto posso essere spezzate in più variabili. V=[p 1,..,p k ] ( V di tipo T, p i di tipo U). La potenza, la resilienza, e il costo di questa trasformazione crescono con laumentare di k, ma di solito k<= 3 a causa del costo della trasformazione troppo elevato. Per spezzare una variabile V in due variabili p e q è necessario fornire: Una funzione f(p,q)=V, Una funzione g(V), Nuove operazioni che possano essere effettuate su p e q.

34 TRASFORMAZIONI DI STORAGE E ENCODING: Splitting delle varibili (2)

35 TRASFORMAZIONI PER AGGREGAZIONE: Fusione di variabili scalari In un programma object oriented il controllo è organizzato attorno alle strutture dati, che un reverse engineering prova a ricostruire. Quindi è importante per un offuscatore provare a nasconderle. Due o più variabili scalari V 1,…, V k posso essere fuse in ununica variabile V m : Laritmetica sulle variabili individuali deve essere trasformata in unaritmetica su V m, Fusione di due variabili integer a 32 bit X e Y in una a 64 bit Z, usando la funzione Z(X,Y) =2 32 * Y + X.

36 TRASFORMAZIONI PER AGGREGAZIONE: Ristrutturare array Operazioni su array : splitting(1-2), merging(3-5),folding(6-7),flatting(8-9)

37 TRASFORMAZIONI PER AGGREGAZIONE: Modificare le relazioni di ereditarietà Si dice che la classe C 2 eredita dalla classe C 1 e indichiamo ciò con ( ). la complessità di una classe cresce con la sua ampiezza (gerarchia di ereditarietà). Idea : aumentiamo lampiezza della gerarchia (μ7) Fattorizzazione, Inserimento di classi fantoccio Variante : falsa rifattorizzazione. Problema : bassa resilienza. Soluzione : usate in modo combinato.

38 VALORI E PREDICATI OPACHI: uso di alias Lanalisi statica interprocedurale è significativamente complicata ogni volta che cè possibilità daliasing. Infatti, differenti versioni di precise analisi statiche sugli alias hanno dimostrato che questo è un problema NP-hard. Lidea di base è di costruire una struttura dinamica complessa e mantenere un insieme di puntatori in questa struttura.

39 VALORI E PREDICATI OPACHI: uso di thread I programmi paralleli sono molto più difficili da analizzare rispetto alla loro controparte sequenziale. La ragione di ciò è la loro semantica interfogliante: n espressioni in una regione parallela. Idea base analoga a quella che usa gli alias struttura dati globale aggiornato da thread Vantaggi i predicati opachi richiedano nel caso peggiore tempo esponenziale per essere rotti grado molto alto di resilienza Si combinano gli effetti di interfogliamento e aliasing.

40 DEOFFUSCAMENTO E TRASFORMAZIONI PREVENTIVE Architettura di un tool di deoffuscazione Java. L'input principale del tool è un'applicazione costituita da un insieme di file class Java offuscati. L'output del tool è un insieme di file class deoffuscati che possono essere convertiti in sorgenti Java da un decompilatore.

41 DEOFFUSCAMENTO E TRASFORMAZIONI PREVENTIVE Trasformazioni preventive innerenti: Rendono le tecniche di deoffuscamento più difficili, Poca potenze, molta resilienza. Trasformazioni preventive mirate: esplorare i problemi conosciuti nei correnti deoffuscatori o nei decompilatori, Es. il decompilatore Mocha.

42 IDENTIFICARE E VALUTARE I COSTRUTTI OPACHI La parte più difficile del deoffuscamento è identificare e valutare i costrutti opachi : Locali, Globali, Interprocedurali. locale globale

43 IDENTIFICARE E VALUTARE I COSTRUTTI OPACHI : Pattern Matching Un deoffuscatore può usare la conoscenza delle strategie impiegate dagli offuscatori conosciuti per identificare i predicati opachi. regole di pattern-matching che possano identificare i predicati opachi comunemente usati. Loffuscatore dovrebbe evitare di usare un numero limitato di predicati opachi; Utilizzo di costrutti opachi sintatticamente simili ai costrutti usati nellapplicazione reale.

44 IDENTIFICARE E VALUTARE I COSTRUTTI OPACHI: slicing del programma Uno slice di un programma P rispetto ad un punto p e ad una variabile v, consiste di tutte le espressioni di P che possono aver contribuito al valore di v nel punto p. Il deoffuscatore creerà quindi degli slice per ogni variabile da esaminare, al fine di eliminare falso codice e unire pezzi di codice logicamente legati. Loffuscatore deve rendere difficile lo slicing Aggiungendo parametri alias, Aggiungendo dipendenze alle variabili.

45 IDENTIFICARE E VALUTARE I COSTRUTTI OPACHI: Analisi Statistica(1) Un deoffuscatore può sfruttare un programma offuscato per analizzare il risultato di tutti i predicati e avvisare il reverse engineer di qualunque predicato che restituisce sempre lo stesso valore di verità. Predicati che si verificano in casi eccezzionali.

46 IDENTIFICARE E VALUTARE I COSTRUTTI OPACHI: Analisi Statistica(2) Loffuscatore dovrebbe quindi favorire i predicati Predicati opachi con side-effect.

47 ARCHITETTURA DI UN TIPICO OFFUSCATORE JAVA Permette di inserire dei profili per evitare che trasformazioni troppo costose siano applicate a parti del codice usate molto frequentemente. Contiene un gran numero di trasformazioni.

48 ALGORITMI DOFFUSCAMENTO: ciclo principale SelectCode restituisce il prossimo codice oggetto sorgente che deve essere offuscato. SelectTransform restituisce la trasformazione che dovrebbe essere usata per offuscare il particolare codice oggetto sorgente. Apply applica le trasformazioni al codice oggetto sorgente e di conseguenza aggiorna lapplicazione. Done determina quando il livello doffuscamento richiesto è stato ottenuto.

49 ALGORITMI DOFFUSCAMENTO: strutture dati Per ogni codice oggetto sorgente S e per ogni routine M: P s (S) linsieme dei costrutti del linguaggio che il programmatore ha usato in S. A(S) ={T 1 V 1, …, T n V n } è un mapping tra le trasformazioni T i e i valori V i. I(S) è la priorità doffuscamento di S. R per ogni routine M, R(M) è il rango del tempo desecuzione di M.

50 ALGORITMI DOFFUSCAMENTO: funzioni di qualità Restituiscono informazioni di tipo numerico riguardanti ogni trasformazione: T res (S) - restituisce una misura della resilienza della trasformazione T quando è applicata al codice oggetto sorgente S. T pot (S) - restituisce una misura della potenza della trasformazione T quando è applicata al codice oggetto sorgente S. T cost (S) - restituisce una misura del tempo desecuzione e delloverhead di spazio aggiunto da T a S. P t - mappa ogni trasformazione T nellinsieme dei costrutti del linguaggi che T aggiungerà allapplicazione.

51 ALGORITMI DOFFUSCAMENTO: ALGORITMO 1 (offuscamento del codice) 1. Caricare lapplicazione C 1,C 2,… da offuscare a. Codice sorgente oppure b. Codice oggetto 2. Caricare il codice contenuto nei file delle librerie L 1,L 2,.. 3. Costruire una rappresentazione interna dellapplicazione a. Un grafo di controllo del flusso per ogni routine di A b. Un call-graph per le routine in A c. Un grafo di ereditarietà per le classi di A. 4. Costruire R(M) e P s (S) usando lalgoritmo 5, I(S) usando lalgoritmo 6 e A(S) usando lalgoritmo 7.

52 ALGORITMI DOFFUSCAMENTO: ALGORITMO 1 (offuscamento del codice) 5. Applicare le Trasformazioni offuscanti allapplicazione REPEAT S:=SelectCode(I); T:=SelectTrasformation(S,A); Applica T ad S ed aggiorna le strutture dati rilevanti del punto 3 UNTIL Done(ReqObf,AcceptCost,S,T,I) 6. Ricostruisci il codice oggetto sorgente offuscato in una nuova applicazione offuscata X.

53 ALGORITMI DOFFUSCAMENTO: ALGORITMO 2(SelectCode) Input Il mapping della priorità di offuscamento I come computato dallalgoritmo 6 Output: un codice oggetto sorgente S. I mappa ogni codice oggetto sorgente S in I(S). Trattiamo I come una coda a priorità Selezioniamo S in modo da massimizzare I(S)

54 ALGORITMI DOFFUSCAMENTO: ALGORITMO 3 (Select Transform) Input Un codice oggetto sorgente S. La mappa di appropriatezza computata dallAlgoritmo 7 Output: Una trasformazione T Due aspetti importanti da considerare T deve essere inglobata in modo naturale con il resto del codice S Alto livello di appropiatezza in A(S) T deve rendere alti livelli di offuscamento con bassi costi di overhead

55 ALGORITMI DOFFUSCAMENTO: ALGORITMO 3 (Select Transform) Restituisci una trasformazione T tale che: Dove ω 1,ω 2,ω 3 sono costanti definite dallimplementazione

56 ALGORITMI DOFFUSCAMENTO: ALGORITMO 4 (Done) Svolge vari compiti Aggiorna la coda a priorità I La riduzione è basata su una combinazione resilienza/potenza Aggiorna anche ReqObf e AcceptCost Determina se la condizione di terminazione è stata raggiunta.

57 ALGORITMI DOFFUSCAMENTO: ALGORITMO 5 (informazioni pragmatiche) Input Unapplicazione A I = {I 1,I 2,..} Output: R(M), P s (S) Si computano le informazioni pragmatiche Dinamiche Uso di profiler su I Calcolare R(M) per ogni routine/basic block Statiche Calcolare P s (S)

58 ALGORITMI DOFFUSCAMENTO: ALGORITMO 5 (informazioni pragmatiche) FOR S:=ogni codice oggetto sorgente in A DO O := linsieme di operatori che S usa; C := linsieme dei costrutti del linguaggio ad alto livello (WHILE,eccezzioni,threads,etc.) che S usa; L := linsieme di classi/routine di libreria che S referenzia; Ps(S) := O U C U L; END FOR

59 ALGORITMI DOFFUSCAMENTO: ALGORITMO 6 (priorità delloffuscamento) Input unapplicazione A R(M) Output: I(S) Possibili euristiche per I(S) possono essere Se molto tempo è speso ad eseguire una routine M, allora M è probabilmente una procedura importante che dovrebbe essere pesantemente offuscata Il codice complesso è più probabile che contenga importanti segreti commerciali che semplice codice

60 ALGORITMI DOFFUSCAMENTO: ALGORITMO 7(appropiatezza delloffuscamento) Input Unapplicazione A costituita dai file C 1,C 2,… P t,P s (S),A(S) Output: A(S) FOR S := ogni codice oggetto sorgente in A DO FOR T := ogni trasformazione DO V := grado di somiglianza tra e P t (T) e P s (S); A(S) := A(S) U {T V}; END FOR

61 CONCLUSIONI (1) Metodo migliore di offuscamento è quello che ha il miglior rapporto costo,resilienza,potenza: Gli offuscatori commerciali usano una combinazione di trasformazioni: Package/Class/Method/Field renaming, Control Flow Obfuscation, String Encryption. In oltre attuano una ottimizzazione del codice per incrementare al massimo le performance. Trade-off tra protezione e prestazione. Protegge solo parti del codice. Usare gli offuscatori come ottimizzatori di codice, per ridurre le dimensioni delle applicazioni e renderle più performanti.

62 CONCLUSIONI (2) Reverse Engeneering sempre possibile, si deve avere un costo elevato per effettuarla. Offuscamento può introdurre bug nel codice. Difficoltà nel debug del codice Lo sviluppatore a volte dovrà mantenere 2 versioni dellapplicazione. Uno sguardo avanti: Obsfucation tool sempre più presenti nel processo di creazione del software, inclusi in strumenti di sviluppo come visual studio 2005. Interessi commerciali che portano a investimenti per la protezione del software.

63 BIBLIOGRAFIA Software protection and Application Security: Understanding the Battleground (A. Main and P.C. van Oorschot), LNCS 2003 A Taxonomy of Obfuscating Transformation (C. Collberg, C. Thomborson and D. Low), TR 1998 Wikipedia, the free encyclopedia. (2002), Obfuscated code, http://www.wikipedia.com/wiki/obfuscated+code http://www.wikipedia.com/wiki/obfuscated+code Metrics for Measuring The Effectiveness of Obfuscators (N.Naeem, M.Batchelder, L.Hendren), Sable, 2006.