La Nuova Guida al Cracking

From UIC

La Nuova Guida al Cracking

Infos
Author:	Ntoskrnl
Email:	ntoskrnl@gmail.com
Website:
Date:	??/01/2005 (dd/mm/yyyy)
Level:
Language:	Italian
Comments:

Corre l'anno 2005 (01/2005) e ne è passato di tempo da quando si è vista l'ultima guida al cracking in Italia. Nel frattempo abbiamo attraversato tante cose, nuovi sistemi operativi, nuovi metodi di protezione ecc. Adesso credo che sia giunto il momento di una nuova guida perché si stanno avvicinando grandi cambiamenti. La guida di Xoa è stata scritta quasi 10 anni fa e da allora abbiamo visto come i programmatori sono divenuti sempre più smaliziati e abbiamo visto il proliferarsi di Packers e Crypters. Anche il mondo del cracking è molto cambiato da allora, le crew e i singoli cracker hanno perso totalmente la visibilità. E su ciò qualche considerazione secondo me va fatta, infatti mi sembra interessante riportare qualche spezzone delle mie innumerevoli conversazioni con Xoanon, dato che lui veramente ha potuto vedere l'evolversi della scena. In verità non è una conversazione preparata né tantomeno pensata per esser pubblicata, quindi non è che segua un vero filo logico. I vari - corrispondono a nuova riga.

Xoanon: bah - il reversing è una cosa meccanica è solo il fatto d'averci tempo da buttarci via - non c'è niente di inventivo - purtroppo di sti tempi con i p2p diventà qualcuno nella scena è praticamente impossibile - ai miei tempi si poteva perché c'era + visibilità per i gruppi - oggi chi vuole qualcosa se lo trova in 5 minuti ... è troppo inflazionato oggi - io son diventato qualcuno nei primi anni 90 - ma era facilissimo - non c'era concorrenza - non è paragonabile assolutamente a oggi - beh c'è troppa inflazione oggi - e è stato già scoperto e fatto tutto quello che c'era da fa - indi - è solo una questione di pazienza nel reversing - la bravura ormai non serve + - visto che è solo un fatto di pazienza ... dei vecchi - dei miei tempi - difatti hanno smesso tutti - il gioco non vale la candela - prima crakkavi per avere gli account sugli ftp 0day - oggi con il p2p non serve + - e poi effettivamente prima diventavi qualcuno ... io quando crakkai il bleem - mi idolatravano - oggi pure penso se crakki starforce - un ti caa nessuno (livornese: caga, ndnt) - non c'è + la cultura del crakkà coi p2p - qualcuno crakka,sì - ma non ha la visibilità di prima - prima per trovà la roba crakkata dovevi essè nella scena - avè gli acc sugli ftp - oggi non c'è + questa cosa - causa p2p - indi la gente ignora tutto quello che c'è dietro ... io mi son fatto mezza scena amiga e tutta la scena pc - oggi la scena come s'intendeva prima non esiste più - prima eri forzato a conoscè la gente che crakkava,se non la conoscevi non c'avevi accesso alla roba - oggi non è + così - beh se vuoi avè un po' di visibilità la cosa che rimane oggi - piglia explorer e trova qualche exploit - e facci un worm - così c'hai visibilità ... e cmq,pure scrivè su frack - ripeto,non c'hai + la visibilità di prima - oggi chiunque apre emule e trova qualunque cosa - la maniera per avè visibilità oggi è fare un worm

In effetti i tempi di Xoanon, Fravia, Kill3xx e persino di personaggi come Pietrek, Russinovich ecc. sono passati. In ogni caso i cambiamenti che stanno avvenendo nell'ultimo periodo sono molto grandi e mi hanno convinto a scrivere una nuova guida perché si sta procedendo in una direzione totalmente diversa da quella vista finora. In questa guida non spiegherò roba che si trova già in migliaia di articoli... No, qua vedremo come avvicinarci al futuro del cracking: il .NET.

Introduzione

In effetti mi pare che gli ambienti di cracking siano ancora molto restii a convertirsi, ma d'altronde il .NET è il futuro. Fra due o tre anni la maggior parte delle applicazioni (e persino alcuni driver) saranno compilati in MSIL (MicroSoft Intermediate Language). Certo questo non significa che dobbiamo disimparare il normale assembly (anzi conviene avvantaggiarsi sui processori sull'ia64), ma come ben presto vedrete vi sarà una sempre maggiore proliferazione di applicativi codati in C#, VB.NET e Managed C++. Senza contare tutti gli altri linguaggi che possono aggiungersi alla tecnologia .NET. Grazie al namespace System.Reflection.Emit, infatti, è possibile creare propri compilatori IL per il linguaggio che vogliamo. Insomma il .NET è multipiattaforma, non dipende né dal processore né dal sistema operativo in uso. Tutto quel che gli occorre è che sia installato il framework tramite il quale funziona. Persino le applicazioni dei palmari e dei telefonini con Windows Mobile installato hanno subìto una forte crescita di applicativi .NET (infatti anche io a paragone fatto tra l'Embedded VC++ e il .NET, ho scelto di programmare in .NET per il mio palmare (e appena uscito il compact framework 2.0 sarà veramente molto potente)), ed è facilmente comprensibile il perché: non è necessario compilare il proprio programma per tutti i diversi processori sul mercato (bisogna poi dire che anche sul Symbian è possibile installare un framework .NET). Oltretutto c'è da dire che il .NET farà il suo vero debutto con longhorn e le migliaia di nuove classi che dovrebbe apportare il nuovo sistema operativo. Classi che renderanno il Win32 obsoleto, questo è certo. Come prima cosa quindi prima di passare al cracking, dobbiamo vedere cosa crackare: ovvero l'IL.

MicroSoft Intermediate Language

L'IL è un linguaggio intermedio che sta tra il linguaggio nel quale abbiamo programmato e il codice macchina. Generalmente siamo abituati a scrivere un programma, compilarlo e trovarci di fronte a un eseguibile con all'interno codice macchina. Al posto del codice macchina avremmo appunto l'IL. La differenza tra codice macchina e IL è che quest'ultimo non dipende appunto dalla macchina sulla quale viene eseguito dato che si tratta di un'astrazione (pseudo assembly) facilmente convertibile nel codice macchina del processore sul quale viene eseguito. Il .NET usa in maniera molto efficiente un meccanismo di conversione da pseudo-assembly a assembly chiamato JIT (Just In Time) che traduce il codice solo quando è necessario, questo riduce drasticamente il tempo di caricamento, oltretutto una volta convertita una parte di codice non vi sarà bisogno di riconvertirla durante l'esecuzione dell'eseguibile. Se siete interessati a sapere di più riguardo all'architettura .NET vi consiglio un libro apposito (anzi sarebbe il caso, dato che probabilmente capirete a fondo l'IL solo se conoscete anche il framework su cui gira), adesso passeremo direttamente ad occuparci di codice IL. Nonostante il fatto che si possa anche programmare in IL (compilando coll'utility ilasm.exe, fornita dalla MS), noi partiremo disassemblando (è per questo che siamo qui). Tanto poi, programmando o analizzando codice, l'IL s'impara comunque. Però prima di disassemblare ci serve un programma compilato in IL, siccome dobbiamo partire da qualcosa di facile mi sono fatto un piccolo programma in C#. Ecco il codice:

Compiliamolo e otterremo un programma che non fa niente, ma che ci basterà per dare un primo sguardo all'IL. Adesso per disassemblare possiamo sia usare ildasm.exe (fornito dalla MS e situato nella cartella del SDK) oppure usare il nostro solito IDA. Comincio con lo spiegare ildasm dato che probabilmente è quello per la maggior parte di voi meno familiare. Apriamo il prog compilato con ildasm e troveremo una cosa di questo genere:

Il significato dei vari simboli ve lo pasto direttamente dal MSDN.

Se clickiamo sul metodo main due volte otterremo una finestra che ci mostra il suo codice:

Tutto ciò che inizia con un "." in IL sta per una direttiva, in questo caso indichiamo un metodo, tutto ciò, invece, che non è preceduto da punti, sono le istruzioni da eseguire. La direttiva entrypoint indica appunto l'entrypoint del codice, è una direttiva che in un assembly può esser usata una sola volta. Se nello stesso assembly la usate più volte e provate a compilare con ilasm.exe, quest'ultimo vi darà errore. I metodi sono delimitati dalle parentesi graffe, ciò nonostante è opportuno concludere il metodo con ret. L'attributo hidebysig nasconde il metodo a classi derivate. Se adesso clickiamo sul triangolino rosso della classe vedremo:

Da qui vediamo che la nostra classe è un'estensione della classe System.Object. Ciò comporta l'esistenza dovuta del costruttore ctor. Ora prima di continuare una tabella coll'instruction set (framework 1.1) e relativi opcodes.

Se vi servono informazioni aggiuntive riguardo alle specifiche dell'instruction set potete consultare l'MSDN oppure il documento "Partition III CIL.doc" nella cartella "\SDK\v1.1\Tool Developers Guide\docs" del vostro Visual Studio.

Sì, lo so, il linguaggio vi pare ancora molto estraneo, ma vedrete che vi ci abituerete presto, anzi l'IL come vedrete non è nemmeno difficile. E poi considerate un vantaggio: potrete reversare applicazioni per ogni dispositivo che supporta .NET, quindi, oltre al pc, palmari e telefoni, senza dover imparare una nuova sintassi. Come piccolo schemettino di gruppi principali di istruzioni possiamo dire che:

• i vari bgt, ble, bne, br ecc. sono i jump.
• i conv servono per convertire grandezze diverse di valori (tipo da byte a qword ecc.).
• i vari ldc, ldarg, ldelem ecc. corrispondono ai push (prendete per buono che tutte le istruzioni che cominciano con ld sono dei push).
• i vari stloc, starg, stelem ecc corrispondo ai pop (st*).

Per il resto molte istruzioni sono le stesse (quelle logico/matematiche ad esempio (xor, and, mul, sub ecc.)), anche se esistono anche dei falsi amici (il pop in IL non corrisponde esattamente al pop in asm). Ad ogni modo queste cose le vedrete strada facendo. Se avete un dubbio su un'istruzione, ricorrete alla tabella.

Vediamo una nuova applicazione che fa qualcosina in più rispetto a quella che abbiamo visto prima. Per adesso affianco il codice C# al disassemblato per rendere le cose più chiare, fra poco però smetterò di farlo e passeremo direttamente a vedere il codice in IL cercando di capire cosa fa.

Questo codice non fa altro che chiamare la funzione Calc dalla Main, questa funzione ha tre parametri, un intero e due byte, i bit dell'intero vengono shiftati di un numero pari ad a più b. Dopodiché nella main viene stampato il risultato. In questo caso immettendo 65535 (FFFFh) come numero originale e shiftando di 8 bit otterremo 255 (FFh) come risultato. La ReadLine all'interno del codice l'ho messa affinché il programma non si chiuda subito se eseguito ma aspetti un input da parte dell'utente. Sì il codice non serve a nulla ma basta a noi per dare un occhio al linguaggio. Vediamo adesso il codice coll'ildasm. Partiamo dalla main:

Allora l'IL è stack based come fra poco potremmo ben vedere, .maxstack ci dice che all'interno di questo metodo non vengono caricati sullo stack (virtual stack ovviamente) mai di più di 3 valori. La lista e l'inizializzazione delle variabili locali del metodo viene effettuata tramite .locals init, in questo caso ne abbiamo una sola (Res che è un Int32). Analizziamo la riga di codice che immediatamente segue.

Questa istruzione pusha un Int32 sull'evaluation stack, sarebbe il nostro 65535. A seguire vi sono le istruzioni ldc.i4.3 e ldc.i4.5 che pushano i valori 3 e 5 (se il numero è piccolo (tra 0 e 8) è possibile usare ldc.i4 seguito da un punto e il numero da pushare, ricordate che non è che si può fare per ogni valore ciò). Come potete notare lo stack nell'IL non è come quello a cui siamo abituati, ovvero LIFO (Last In, First Out). Nell'IL i parametri vengono pushati nell'ordine che la funzione prevede.

Viene chiamata la funzione. L'ildasm ci fornisce anche namespace e classe del metodo chiamato. Vediamo poi l'istruzione:

Questa istruzione poppa (da pop) il valore corrente sulla cima dello stack e lo mette nella lista delle variabili locali all'index 0. In pratica mette il valore di ritorno della funzione che sta in cima allo stack dentro a Res (variabile locale).

Pusha sullo stack la stringa "Result: ". In verità pusha un reference alla stringa che si trova nella metadata dell'eseguibile.

Chiama l'overload per stringhe della funzione Write.

Pusha la variabile locale a index 0 (Res) sullo stack.

Chiama l'overload della funzione WriteLine per interi a 32 bit. Dopodiché chiama la ReadLine.

Rimuove il valore corrente in cima allo stack (sarebbe il valore di ritorno di ReadLine che in ogni caso non mettiamo in nessuna variabile, quindi basta toglierlo di mezzo con pop senza usare stloc). Segue il ret che conclude il metodo. Bene, adesso passiamo alla funzione Calc.

Dove:

Caricano sullo stack i tre argomenti passati al metodo. Il numero che segue ldarg specifica la posizione dell'argomento. Il primo è OriginalNumber (0) seguono a e b.

Somma i due valori in cima allo stack, in questo caso a e b, e pusha il risulato in cima allo stack. Dopo questa operazione il nostro stack avrà questo aspetto:

OriginalNumber
ResultOfAddBetweenA_And_B ; cima dello stack

Poi:

Pusha sullo stack in forma di int32 il valore di 8bit che segue l'istruzione, in questo caso 31d (ildasm ci mostra un numero decimale, attenzione). Quindi il nostro stack adesso avrà questo aspetto:

OriginalNumber
ResultOfAddBetweenA_And_B
NumberOf31Decimal ; cima dello stack

Quindi:

questo and viene effettuato tra la somma di a-b e il numero 31. In pratica questo and serve ad assicurarsi che il nostro numero non superi 31. Vi chiederete come mai. È presto detto, l'and fa in modo che possiamo usare lo shift anche come rotate. Se per esempio vogliamo shiftare di 32 posizioni, lui fa l'and con 31 e torna 0, quindi shifta di 0, dato che col rotate shiftando di 32 posizioni ci ritroveremmo il numero non modificato in mano. Ad ogni modo, essendo il nostro numero 8, esso resta come è e ci ritroviamo con questo stack:

OriginalNumber
NumberOf8 ; cima dello stack

Shifta a destra l'original number di 8 posizioni e pusha il risultato sullo stack (essendo esso il valore di ritorno segue il ret. Insomma come abbiamo già visto nel main il valore di ritorno di un metodo si trova in cima allo stack e non in eax (vabbe' ovvio non abbiamo registri) come siamo abituati.

Siccome so che limitarsi ad analizzare codice non è molto divertente, iniziamo col cracking. Tanto le istruzioni che ancora non avete visto le imparerete via via. Per ora basta che siate entrati nella logica dell'Intermediate Language.

Cracking

Partiamo immediatamente da un esempio facilissimo. Stavolta non vi faccio vedere prima il codice, dato che adesso siamo nel paragrafo di cracking e poi l'esempio è veramente banale. Dato che tutto il codice sta nel main vi incollo solo quello:

Allora:

Ci chiede di immettere una stringa.

Prende la stringa (valore di ritorno della funzione ReadLine) e la pusha sullo stack.

Converte la stringa in un intero a 32bit.

Prende il valore di ritorno, ovvero il numero convertito e lo pusha sullo stack.

pusha sullo stack 29Ah (666d).

Fa lo xor tra 666d e il numero da noi immesso. Ci ritroviamo ovviamente il risultato sullo stack.

Prende il risultato dallo stack (mettendolo nella stessa variabile del numero immesso) e lo pusha sullo stack.

Pusha sullo stack il valore 539h (1337d).

Eccoci arrivati al salto condizionale. Questa istruzione salta all'istruzione all'offset IL_0029 se i due valori sullo stack sono uguali. Se il salto non viene eseguito (ovvero se i valori non coincidono) ci troviamo di fronte questo codice:

ldstr e call mi sembrano chiari. br.s però non l'avete ancora visto, si tratta del salto incondizionale (jmp) che ci porta al termine del programma. Se invece i valori coincidono e il salto viene eseguito, ci troviamo qua:

Ovvero il programma risulta registrato. Ora, è chiaro che l'algo è molto banale:

E la risoluzione è evidente, basta inserire come seriale 1955. Proviamo però adesso a crackare il programma, cioè modificare le istruzioni, visto che tecnicamente per averlo crackato è quello che ci manca. Per fare tutto ciò sarebbe però utile che il nostro amatissimo disassembler ci desse anche gli opcode delle varie istruzioni (nonché l'indirizzo da dove inizia il metodo in questione). Niente di più semplice, è sufficiente andare sul menu dell'ildasm sotto la voce view e clickare su "Show Bytes". Riapriamo adesso il codice del main:

Come ci dice il disassembler sotto la direttiva .entrypoint il metodo inizia al RVA 2050h, che nel nostro caso corrisponde al file offset 1050h. Il salto condizionale da patchare è:

E lo possiamo invertire, oppure convertire in salto incondizionale. In verità in IL non ha molto senso invertire il salto dato che gli opcode hanno la stessa lunghezza, quindi è meglio renderlo incondizionale. Per fare ciò dobbiamo sostituire l'opcode 2Eh con 2Bh. Però Alt, in IL le cose sono un po' diverse dall'assembly, e dobbiamo fare alcune considerazioni in più. Queste considerazioni riguardano lo stack. Noi siamo abituati al cmp che non fa uso di alcuno stack, ma in IL i valori da confrontare sono sullo stack, quindi se trasformiamo un salto condizionale in uno incondizionale (che ovviamente non prenderà nessun valore dallo stack) dobbiamo assicurarci di non impegnare lo stack. Quindi:

È necessario patchare col nop (00h) i due ld e poi rimpiazzare 2Eh con 2Bh. Prendiamo un hex editor e patchiamo, fatto ciò ci ritroviamo di fronte questo codice:

Adesso il programma, se eseguito, si registra con qualsiasi valore che immettiamo. Adesso facciamo il reversing di qualcosa di più complesso (a livello di IL s'intende), tanto patchare lo sappiamo già fare. Stavolta si lavora su un programma con finestre. Apriamo l'ildasm e ci troviamo di fronte a questo:

In questo caso, come vedete ho messo solo una window, due label, due text box (user name, serial) e un bottone per registrarsi. Si parte dal codice del bottone che sarebbe btnRegister_Click. Per verificare che sia effettivamente quella la routine che si occupa del click del bottone, è sufficiente guardarsi il codice nella routine InitializeComponent (routine che vi è per ogni window, infatti lì vengono settati gli attributi della window e delle sue child). Quando arrivate a questa routine non spaventatevi troppo, è molto codice (più child ha la window, più codice vi è), ma dovreste trovare velocemente cosa cercate.

Viene creato un EventHandler dalla funzione btnRegister_Click e settato come event handler per quel determinato bottone. In effetti se avete già programmato con .NET siete molto avvantaggiati perché dovreste sapere come vengono inizializzate le finestre. Andiamo al codice del click:

Non svenite, procediamo passo passo.

Prende la lunghezza dello UserName (ricordate che dopo la get_Length il valore di ritorno sta in cima allo stack).

Confronta la lunghezza con 6. Ovvero salta a IL_0027 se la lunghezza dello user name è minore di 6. Alla locazione IL_0027 troviamo un ret, quindi il nostro user name non deve essere minore di 6 caratteri altrimenti usciamo dalla funzione.

Prende la lunghezza del seriale.

Se uguale a 14d, salta a IL_0028. Altrimenti esce dalla funzione.

Converte la stringa dello user name in un array di char e lo mette nella lista delle variabili locali all'index 0. Se guardiamo le variabili locali:

Come vedete le prime due sono array di char.

Prende la stringa del seriale, la converte in array di char e la mette nella seconda variabile locale. Quindi riassumendo char[] V_0 contiene lo user name, mentre char[] V_1 il seriale.

Si apre un blocco try, ovvero vi è un exception handler. Ovviamente a qualsiasi reverser già qua sorgerebbe un dubbio.

Allora, pusha sullo stack l'array di char dello user name, pusha l'index 0, pusha sullo stack l'elemento dell'array al dato index. In pratica, parlando in pseudo-codice. sarebbe un push UserNameArray[Index]. Adesso in cima allo stack abbiamo il primo carattere di questo array.

Ficca il carattere nella terza variabile locale (un char appunto).

Pusha il valore 3.

Pusha sullo stack il primo carattere dello user name.

Lo moltiplica per due.

Gli toglie metà (ricordate che la seconda variabile locale contiene il valore originale del carattere).

Lo divide per se stesso. Quindi il risultato di div adesso sarà 1, valore che quindi avremo sullo stack.

Sottrae 1 a 1.

Compie la divisione con il risultato della sottrazione sul valore 3 precdentemente pushato. Quindi alla fine dei conti avremo un 3 / 0. Che ovviamente porta a un'eccezione. Andiamo a