Il crackme in questione è protetto con FSG (si può notare immediatamente dalla signature "FSG!" presente fra i primi bytes del file), per risolvere il problema basta cercare su internet un qualsiasi unpacker per FSG. Come si può vedere non esistono editbox, ma analizzando la ImportTable possiamo trovare alcune funzioni interessanti: CreateFile, GetFileSize etc. (si tratta quindi di una keyfile protection). Passiamo a vedere il listato:

00401B65 push edi ;Nel buffer di destinazione ci sono i primi 16 bytes del keyfile

La routine che abbiamo appena visto è molto semplice, non fa altro che andare ad aprire un file già esistente, che dev'essere di 128 bytes, e ne legge il contenuto, estrapolandone da esso i primi 16 bytes che andranno a finire in un buffer specifico. Continuiamo con l'analisi:

 

I primi 16 bytes del nostro keyfile vengono decriptati (attraverso uno bswap ed uno xor), e alla fine la routine controlla che il primo byte non sia 0 ed il sedicesimo sia NULL (questo ci fa pensare che i primi 16 bytes opportunamente trattati devono darci una stringa NULL-Terminated)

00401BAF jnz short loc_401B9D

Adesso andiamo ad analizzare la subroutine 00401206

004012B3 xchg C, D

Come si può vedere, nella routine sono utilizzati due MagicValues (classica definizione delle costanti crittografiche) 456C6091h e 0AA7110C3h che con una piccola ricerca ci indicano che siamo in presenza di un Ruby Hash, da notare però che in questo caso la routine è leggermente modificata, se ricordate edx ha un counter settato a 2, e di conseguenza otteremo un hash di 16d bytes. Passiamo alla prossima porzione di routine, che implementa un semplicissimo Engine Polimorfico, che genera un set limitato di istruzioni basandosi sull'hash appena determinato:

 

Ho saltato molte parti di codice, perchè non vale la pena andare a commentare ogni singola linea codice, ma solamente capire come funziona il nostro Engine:

Come potete vedere il funzionamento dell'Engine non è molto complesso, ad ogni ciclo prende un carattere del nostro hash e lo filtra attraverso una struttura decisionale che contiene un ben definito range di opcodes. Dopo aver iterato l'intero hash, a 00401CEDh abbiamo una banale routine che modifica il nostro hash 4 bytes per volta, che vanno poi a costituire un nuovo input per l'Engine. Se andiamo a fare un pò di conti vediamo, che dal nostro hash vengono generati 1C6h bytes di codice, ed osservando approfonditamente gli opcodes usati nella struttura dell'engine, possiamo notare che il nuovo codice userà un set limitato di istruzioni, e cioè:

 

Andiamo ad analizzare adesso la prossima porzione di codice, che costituisce la prima applicazione del codice appena generato:

 

Il codice è molto semplice, vengono presi 24 bytes dal nostro keyfile e decriptati attraverso l'algoritmo polimorfico, ed infine confrontati con la stringa "Polymorphis by Kwasek :)" se sono uguali, possiamo passare alla prossima parte del crackme, altrimenti l'esecuzione salta ad unregistered. Il nostro compito è quindi generare un algoritmo polimorfico con le istruzioni reversate, ed applicare la stringa "Poly...." in modo da ottenere una serie di bytes, che decriptati ci danno la stessa "Poly...", come reversare le istruzioni lo vedremo in fase di keygenning, ora possiamo tranquillamente procedere con la nostra analisi..

Questa parte dovrebbe risultarvi molto familiare, si tratta sempre del nostro Engine, che stavolta utilizza opcodes che rientrano nelle istruzioni MMX. La solita routine, modifica il nostro hash, per un totale di 1C6h bytes di istruzioni mmx polimorfiche. Il set di istruzioni in questo caso è:

Lo schema di protezione è praticamente identico a quello già visto, con la sola accezione che qui vengono usate istruzioni mmx e la stringa è lunga 64 bytes. La tecnica di reverse è sempre la stessa, dobbiamo elaborare un engine che generi le istruzioni mmx reversed. Procediamo con la prossima parte di codice:

00401E9E jmp short loc_401EEA ;Altrimenti salta ad UNREGISTERED

Questa che abbiamo visto, è l'ultima parte di protezione, la struttura rimane invariata, abbiamo infatti delle call che decriptano porzioni di keyfile, che poi vengono confrontate con le solite stringhe. Andiamo quindi ad analizzare queste call, e più precisamente la call 00401F33h:

Ho tagliato molta parte del codice, ma possiamo una cosa molto strana, ci sono numerose chiamate a 0040208Dh, andiamo a vedere cosa succede in questa call:

 

Il codice è abbastanza semplice, i bytes del keyfile vengono combinati con la stringa unregistered attraverso una serie di istruzioni come add, sub e xor che come sapete possono essere tranquillamente reversate, poichè non comportano perdite di bit (e quindi di informazione), ed il nostro compito è proprio questo, dobbiamo \notate all'uscita della call a 0040208Dh i valori contenuti nei vari registri rimangono invariati, e la routine (escluse appunto le chiamate a 0040208Dh) fa qualcos'altro..come avrete intuito, la seconda funzione di tutte queste call è confonderci le idee! proviamo infatti a riscrivere l'intera routine, eliminando tutte queste call:

Proviamo a riscrivere in C questo pezzetto di codice:

}

Come per magia scopriamo, che si tratta semplicemente della procedura di Encryption del TEA, solo che riscritto in istruzioni MMX e con il delta cambiato :) Quello che dobbiamo fare è semplicemente reversare questo algoritmo, scrivendo cioè la routine di Decryption.

Piccola nota sul TEA:

TEA Il TEA (Tiny Encryption Alorithm) e' stato creato da David Wheeler e Roger Needham. Questo algoritmo ha il pregio di essere abbastanza veloce e di offrire una "sicurezza-media", si basa principalmente su un'architettura di tipo Feistel Network, perciò la cifratura/decifratura di dati avviene "a blocchi" solitamente di 64 bits. E' un sistema di cifratura simmetrica quindi se invertiamo l'intero algoritmo ed usiamo la stessa chiave utilizzata per crittare, ed applichiamo in entrata il CipherText, in uscita otterremo il PlainText.

Un ultimo piccolo reverse ed abbiamo finalmente finito, se ricordate all'uscita della call 00401F33h, viene controllato se MM7 è uguale a zero, se non lo è, l'esecuzione salta ad Unregistered. La routine responsabile del valore di MM7 in uscita è contenuta all'interno della procedura del TEA, ben nascosta in modo da essere confusa con l'intero altro codice, eccola:

Anche qui si tratta di un banalissimo reverse, che vi riporto qui sotto:

E con questo abbiamo finalmente finito il reverse di Kwasek6! :)

Note per un eventuale keygen

Un imbocca al lupo per chi volesse cimentarsi nel keygenning di questo crackme, non perchè sia eccessivamente difficile, ma necessita sicuramente di un buon ordine di coding ed una gran pazienza :), credo che possa aiutarvi, suddividere il crackme in fasi successive:

Ci vediamo al prossimo tute!!! :))