Anti Disassembling Techniques

From UIC

Anti Disassembling Techniques

Infos
Author:	quequero
Email:
Website:	http://quequero.org
Date:	25/04/2009 (dd/mm/yyyy)
Level:
Language:	Italian
Comments:	Un saluto a tutte le persone che il sisma del 6 Aprile ci ha portato via.

Introduzione

Stavo curiosando tra i tutorial della UIC in cerca di spunti per sviluppare delle tecniche anti-disasm per ARM e mi sono accorto che... Non c'e' neanche un tutorial sulle tecniche anti-disasm per x86. Ok, dal momento che sto a letto malaticcio (e ho appena preso IDA 5.4 ;p) non mi posso esimere dal colmare questo vuoto, quindi oggi parleremo di tecniche che possono essere utilizzare per cercare di ingannare sia i disassembler che i debugger (o meglio... I disassembler dei debugger).

Tools

• Mr. Brain
• IDA
• OllyDbg
• Qualunque altro disassembler conosciate

Essay

Il compito del disassembler e' quello di trasformare il codice macchina in codice mnemonico, che risulta piu' semplice da interpretare per gli umani. In questo ambito possiamo identificare modalita' di funzionamento differenti che ci tornano utili per raggruppare i disassembler in due grandi famiglie:

• Linear Sweep Disassemblers: disassemblano un'istruzione per volta
• Recursive Traversal Disassemblers: iniziano a disassemblare dall'entry-point e proseguono fino alla prima istruzione di branch (jmp, jnz, jb etc...) per poi riprendere a disassemblare direttamente da quel punto.

Tra i Linear Sweep Disassemblers troviamo il buon vecchio SoftICE, objdump e WinDbg. Tra i Recursive Traversals Disassemblers troviamo invece la vecchia cara IDA, OllyDbg e l'ottimo PEBrowse. Per riuscire a confondere un disassembler dobbiamo capire come funziona, e gia' questa suddivisione ci da' un'idea generale del loro modus operandi. Ma dalla nostra abbiamo un'arma molto potente: su x86 le istruzioni non sono a lunghezza fissa (come accade su ARM e su tutti i RISC ad esempio) ma possono essere lunghe da un byte in su, una situazione che senz'altro ci da' spazio di manovra per confondere il motore di disassembly, e come se non bastasse nulla ci vieta di mescolare dati e codice. A conti fatti sembra che sia piu' semplice fare del buon codice offuscato che un buon disassembler, ed in effetti e' cosi' (che sorpresa eh ;p), per una serie di ragioni che vedremo a breve.

Junk Bytes

Confondere un disassembler significa, essenzialmente, fare in modo che interpreti uno o piu' byte di dati come l'inizio di un'istruzione. Ancora una volta siamo fortunati perche' su x86 gli opcode che rappresentano l'inizio di un'istruzione sono ben 248 su 256, percio' non avremo sicuramente problemi a trovare quello che fara' per noi. Come primo test proviamo ad inserire nel codice dei byte di spazzatura ed a vedere come reagiscono i disassembler, quindi prendiamo questo piccolo programma e compiliamolo:

Per chi non la conoscesse, l'istruzione _emit serve ad inserire nel codice un byte che desideriamo e che in teoria dovrebbe rappresentare un opcode. Cominciamo ora il nostro studio: compiliamo il programma disabilitando le ottimizzazioni e la creazione delle info di debug (cosi' da non produrre il .pdb che tanto aiuterebbe la brava IDA ;p), disassembliamo poi il codice ottenuto con il Linear Sweep Disassembler di Visual Studio:

Come vedete la strategia di disassemblare un'istruzione per volta non consente di riconoscere il nostro junk byte come tale che quindi diviene parte di un'istruzione di or, il risultato del disassembler e' quindi sbagliato. Vediamo ora come si comporta un normale Recursive Traversal Path disassembler come IDA v5.4:

La strategia adottata da disassembler piu' evoluti e' sicuramente piu' funzionale, il junk byte viene immediatamente identificato come tale, ed il risultato del disassembly e' corretto, ma in cosa differisce questo approccio dal primo? Nel caso di Visual Studio il disassembling e' un procedimento cieco che prende il primo byte e lo disassembla alla prima istruzione possibile, IDA invece e' in grado di identificare quelle porzioni di codice che non vengono mai toccate dal programma, e che quindi possono essere considerate come componenti estranei. Se vi state chiedendo come fa e' presto detto: viene calcolata la destinazione di tutte le istruzioni di branch, se un dato ramo di codice non viene raggiunto da nessun branch, allora viene marcato come estraneo. In effetto il nostro junk byte non viene raggiunto o richiamato da nessuno, quindi e' corretto isolarlo. Ma a questo punto dovrebbe esservi venuta un'ideuzza per confondere anche la bella IDA vero?

Opaque Predicates

Con questo termine Linn e Debray definirono un predicato che, in maniera non ovvia, torna sempre TRUE o FALSE. Come vedremo si tratta di un trucchetto efficace per confondere i Recursive Traversal Disassemblers, anche se torneremo a fine paragrafo sul discorso per una breve precisazione. Creare un predicato opaco e' un'operazione abbastanza semplice, guardate questo pezzetto di codice:

La variabile a viene inizializzata a 0 e mai piu' toccata, quindi il primo if() sara' vero e finiremo sempre sulla goto senza mai attraversare l'istruzione _emit. Questo e' un predicato opaco poiche' quello che viene tradotto in codice come un salto condizionale, e' a tutti effetti un jmp in piena regola. Disassembliamo nuovamente questo programma con IDA (il risultato che verrebbe con Visual Studio gia' lo conosciamo) ed esaminiamone il risultato:

Con questo semplicissimo trucco siamo riusciti a confondere anche IDA. Diamo invece uno sguardo al codice utilizzando l'ultima Beta disponibile di OllyDbg 2:

A quanto pare, nonostante la differenza in termini di denaro OllyDbg sembra essere piu' intelligente di IDA :>. In effetti prima abbiamo detto che e' necessario creare un predicato opaco che non sia ovvio per il disassembler... Bene, cambiamo un pochino le carte in tavola e vediamo chi riesce a starci dietro, compiliamo il seguente codice:

In questo caso abbiamo aggiunto un ramo else al predicato, in modo da costringere il motore di disassembly ad eseguire un'analisi piu' approfondita. Passiamo l'eseguibile ad IDA e vediamone il responso:

IDA non riesce a disassemblare correttamente il codice, come vediamo viene messo in EAX un valore anomalo che poi viene spostato all'interno della variabile a, cosa che nel codice da noi scritto non succede. Tuttavia possiamo assistere alla risincronizzazione del motore, infatti vediamo che un'istruzione e' stata interpretata come dati, la successiva come codice (in maniera errata) e poi dalla terza in poi il disassembler e' stato capace di riprendere il normale flusso, infatti il codice successivo e' rappresentato correttamente. Vediamo ora OllyDbg cosa riesce a fare:

A quanto pare anche OllyDbg e' caduto sotto i colpi della nostra ascia, questo ci fa ben sperare :) e se siete curiosi sappiate che anche il Linear Sweep Disassembler di Visual Studio presenta lo stesso identico risultato. In verita' dovremmo rimanere abbastanza sorpresi dal fatto che certi trick funzionino, abbiamo chiamato questi costrutti predicati opachi, ma e' evidente che non si tratta di predicati indecibili (se non a runtime), ma di predicati il cui risultato e' gia' deciso, ed in maniera piuttosto esplicita, gia' a compile time. Questo e' segno che il lavoro svolto dal disassembler e' estremamente gravoso e allo stato attuale nessun motore, tra quelli provati, e' in grado di seguire correttamente il flusso del programma. In sostanza possiamo dire che di opaco in questi predicati c'e' ben poco e l'occhio esperto del reverser sara' in grado di notare immediatamente il trucco. Nel caso appena visto potremmo fare anche di meglio, ad esempio inserendo dei junk byte che nel disassemblato non facciano apparire le altre istruzioni come data, questo e' solo un'esercizio ma l'idea di fondo resta la stessa: basta mettere il disassembler davanti ad un albero decisionale e potenzialmente saremo in grado di mandarlo in crisi, come se non bastasse i predicati appena visti possono essere complicati a piacimento :).

Fake Return Points

Un'altra strategia che confonde facilmente i disassembler e' quella che mi sono permesso di battezzare come Fake Return Points. I disassembler assumono infatti che l'istruzione eseguita al ritorno di una funzione sia quella immediatamente successiva alla CALL stessa, vediamo quindi cosa succede se quest'assunzione diviene errata.

Al momento cosa fa func() non e' importante, l'importante e' che ci sia una chiamata a funzione, vediamo il risultato di IDA (non riporto quello di Olly visto che e' identico):

Vediamo chiaramente che il disassembler si desincronizza all'indirizzo 00401056 e riprende a disassemblare correttamente soltanto all'indirizzo 00401060. La risincronizzazione e' dovuta solo al fatto che a quell'indirizzo c'e' la destinazione di un branch, altrimenti avrebbe continuato a disassemblare in maniera errata ancora per molti byte. Utilizzando questo approccio dobbiamo pero' stare molto attenti alla calling convention utilizzata, a questo scopo faccio una brevissima ma necessaria digressione.

Standard Calling Convention

Windows utilizza quella che e' stata ribattezzata Standard Calling Convention, sebbene non sia il vero standard (rappresentato dalla C Calling Convention, accettata da tutti fuorche' Microsoft) funziona in questo modo: i parametri della funzione vengono salvati sullo stack in right-to-left order e prima di tornare al chiamante i parametri utilizzati devono essere liberati. Questa convention conserva lo stato di tutti i registri ad eccezione di: EAX, ECX ed EDX (ed i relativi RAX, RCX ed RDX). Quindi dopo una chiamata _stdcall tutti i registri, ad eccezione di quelli appena nominati, saranno inalterati. Ovviamente dovendo liberare lo stack all'interno della chiamata, non e' possibile utilizzare questa convention per le funzioni che prendono un numero variabile di parametri (printf() su tutte). Guardiamo un esempio di chiamata a funzione con questa calling convention:

Il disassemblato appare cosi':

Lo stack viene ripulito all'interno di func() quindi possiamo inserire quello che vogliamo dopo la chiamata a func(), senza doverci preoccupare di compromettere il funzionamento del programma.

C Calling Convention

A differenza della precedente la _cdecl richiede che sia il chiamante, e non la funzione stessa, a liberare i parametri dallo stack dopo il ritorno dalla funzione. Come la _stdcall anche la _cdecl garantisce la conservazione dello stato di tutti i registri ad eccezione di: EAX, ECX ed EDX. Questa e' la convention utilizzata per default dalla suite di GCC/G++ ed in generale per tutte le chiamate (anche su Windows) che utilizzano un numero variabile di parametri. Ecco un esempio di codice:

Ed ecco come appare il disassemblato:

Nel main vediamo che dopo la chiamata a func() lo stack viene ripulito, in questo caso non possiamo utilizzare il trick del fake return point dal momento che non possiamo inserire codice immediatamente dopo la chiamata.

Fastcall Convention

Nelle fastcall i parametri delle funzioni vengono passati in ECX ed EDX, i restanti sullo stack nel solito right-to-left order. Come per la _stdcall anche nelle fastcall i parametri utilizzati sullo stack vengono liberati dal chiamante e non dalla funzione. Ricompiliamo un piccolo esempio:

E guardiamone di nuovo il disassemblato:

In questo caso i parametri sono soltanto due quindi vengono passati direttamente sui registri, se fossero stati tre uno sarebbe stato passato sullo stack che poi sarebbe stato ripulito direttamente all'interno di func().

C++ Calling Convention

Per il C++ abbiamo un'ulteriore convenzione dal momento che oltre ai soliti parametri, in maniera invisibile per lo sviluppatore viene sempre passato il puntatore al this. Non esistendo uno standard definito per questa convention, ogni compilatore utilizza la propria: Microsoft definisce la thiscall convention dove il this viene passato in ECX (per tutte le funzioni membro non statiche) ed il resto viene trattato ugualmente a una comune _stdcall. G++ invece passa il this sempre come primo parametro e tratta il resto come una comune _cdecl.

Torniamo ai Fake Return Points

E' quindi evidente che per utilizzare questo trick dobbiamo esplicitamente utilizzare una chiamata _stdcall, altrimenti il compilatore inserirebbe del codice dopo la funzione che non ci consentirebbe di utilizzare alcun trick anti-disassembly, poiche' non sarebbe possibile inserire dei junk bytes senza compromettere la funzionalita' del programma stesso. Nell'esempio che segue sposteremo il return point in avanti di un byte e modificheremo lo stato di una variabile globale. Anche qui fate attenzione perche' se compilate il programma con l'opzione per omettere il frame pointer non troverete il return point dentro EBP ma dentro ESP.

Ecco IDA come disassembla il codice:

L'istruzione subito dopo la chiamata viene disassemblata in maniera errata ed anche il resto fino al punto in cui il disassembler riesce a risincronizzarsi. Anche stavolta vediamo OllyDbg come si comporta:

Olly e' decisamente piu' attento in questo caso e non si lascia fregare facilmente, infatti e' in grado di identificare correttamente entrambi i junk byte. Suggerimento: provate a simulare l'epilogo di una funzione con la direttiva __asm all'interno di un predicato e vedete cosa accade dentro IDA.

Indirect Jumps

Se vogliamo vedere l'inferno in Terrra... Possiamo confondere ulteriormente le idee al disassembler utilizzando una vasta gamma di funzioni indirette insieme ai predicati opachi. Guardate questo esempio (ok potevo farlo in assembly, ma VS mi tornava piu' comodo ;p):

Questa volta utilizziamo due variabili: a che viene utilizzata per il predicato opaco e mark che viene utilizzata per un jmp. Nel ramo del predicato che viene eseguito a runtime non facciamo altro che muovere dentro mark l'indirizzo di label. Nel ramo che invece non viene mai eseguito, copiamo dentro mark l'indirizzo del main. Poi aggiungiamo un secondo predicato opaco che semplicemente scrive il byte 0xB8, l'istruzione successiva carica in EAX il contenuto di mark e poi ci salta. Il disassembler non puo' sapere cosa conterra' EAX e quindi evitera' in toto di fare assunzioni a riguardo, infatti guardate cosa succede dentro IDA:

Ahhh dolore e sofferenza, vediamo subito che il disassembler inizia a vacillare all'indirizzo 0040101A, infatti dal suo punto di vista viene caricato in EAX un'indirizzo che appartiene al secondo byte di un'istruzione. Ma e' poco dopo il secondo predicato opaco che inizia il delirio: il disassembler perde completamente il filo, tant'e' che non riesce neanche piu' ad identificare il termine della funzione. Vediamo ora lo stesso codice come appare all'interno di OllyDbg:

OllyDbg come sempre si comporta decisamente meglio, ma neanche lui e' riuscito ad identificare il jmp eax, pur riuscendo a recuperare la sincronizzazione molto prima di IDA che invece e' andata avanti per decine di byte (che non ho messo nel codice per brevita').

Jump Tables

Un'altra strategia utile sia contro il disassembling che contro il reversing in se e' quella di utilizzare le tecniche appena viste insieme a delle jump table. Una jump table (che poi e' ne' piu' ne' meno il risultato in asm di uno switch in C) consente di spezzare il flusso del programma e di confondere notevolmente il disassembler, vediamo subito un codice di esempio:

Ok prendetevi un momento di tempo per capire il codice, quella che vedete e' una funzione simile alla tolower(), in pratica data una lettera in ingresso ne torna il relativo carattere in lowercase, altrimenti il carattere stesso nel caso si tratti di un simbolo/numero o di una lettera gia' minuscola. La funzione attraversa tre step:

1. Controlla che la lettera passata non sia un numero, in caso termina il ciclo
2. Controlla che la lettera non sia gia' minuscola, in caso termina il ciclo
3. Controlla che la lettera non sia un simbolo (in caso termina il ciclo) altrimenti la converte in lowercase

A livello logico possiamo identificare tre step separati, e quindi possiamo fare una cosa inutile e dannosa: separare questi tre step il piu' possibile, ma come? L'idea che mi e' venuta e' stata quella di inserire la routine all'interno di uno switch() che dispatcha l'esecuzione alla subroutine corretta leggendo il valore di un counter a, che viene incrementato ad ogni loop di 2. Quindi il programma entra nel while(), entra nello switch, lo switch porta l'esecuzione su una label che a sua volta torna nel ciclo. Tanto per capirci si tratta di un ciclo esteso verso l'esterno. Il tutto condito con dei predicati opachi rappresentati da dei case che di fatto non vengono mai eseguiti (quelli con numero dispari), e con dei junk byte posti al di sotto di ogni case che comunque non vengono mai eseguiti perche' l'istruzione precedente e' sempre un jmp (e questo non dovrebbe ingannare il disassembler). E' da notare che il target di ogni jmp all'interno dei case viene riempito a runtime e quindi il disassembler non e' (ma dovrebbe esserlo) in grado di stabilire gli indirizzi di destinazione. Vediamo IDA cosa ci tira fuori... Preparatevi spiritualmente:

Ero gia' confuso quando ho scritto il codice, ora sono confuso ancora di piu' e a dirla tutta... Anche IDA non sembra avere le idee chiare :). OllyDbg al contrario offre un disassemblato piu' coerente e meno istruzioni vengono disassemblate in maniera errata.

Conclusioni

Ora avete tutti gli strumenti necessari per sviluppare tante belle tecniche anti-disasm, sperimentate l'inlining delle funzioni, l'outlining, l'interleaving e fate in modo di mettere il disassembler sempre davanti a delle scelte che non possono essere calcolate correttamente se non a runtime. Allo stato attuale i disassembler non sono ancora molto intelligenti, percio' ognuno di noi puo' trarre vantaggio dal fatto che un semplice predicato opaco puo' metterli in crisi praticamente tutti.

Un predicato realmente opaco e' possibile?
Per rispondere a questa domanda servirebbe una dimostrazione formale, non so se ne esistano gia' ma ad occhio (e potrei sbagliarmi) penso che non sia possibile se assumiamo che il programma finale sia comunque deterministico, analizziamo alcuni casi:

1. Il predicato viene deciso dal valore di un parametro scritto nel codice -> Il predicato non e' realmente opaco perche il valore e' deducibile anche staticamente.
2. Il predicato viene deciso da un valore ottenuto indirettamente, magari dal sistema (es: GetTickCount()) -> Il predicato e' opaco ma il programma non e' piu' deterministico.
3. Il predicato viene deciso da un parametro indiretto del sistema (es: GetTickCount() ^ GetTickCount() o un valore impostato da un thread esterno) -> Il predicato non e' opaco perche' possiamo calcolare staticamente il codominio della funzione che manipola il parametro.

Se riuscite a trovare una falla nel ragionamento e avete un'idea di come ottenere un predicato realmente opaco fatemi sapere.

Ringraziamenti & Bibliografia

• Un saluto a tutti i miei conterranei Abruzzesi in questo momento di grande dolore, quello del 6 Aprile 2009 sara' un giorno duro da dimenticare.
• Obfuscation of Executable Code to Improve Resistance to Static Disassembly, Linn/Debray.
• Reversing Secrets of Reverse Engineering Code, Eldad Eilam
• The IDA Pro Book

Disclaimer