KeygenMe #02 de JuLio eL NeGRo - Solution par Bigbang

I. Unpacking de l'exe

On ouvre l'exe dans stud_PE, dans "Signature", on voit :

Donc ici l'exe est packé avec UPX. Pas de problèmes, on fais upx -d sur l'exe. Arrive une erreurUPX ne peux pas décompresser.
Ce qui se passe, c'est l'exe est protégé et compressé. Il faut donc le dé-protéger pour pouvoir ensuite le dé-compresser. Merci à Netix pour m'avoir présenté son outil : Anti-UPX Scramble.

"Open File" > Retore. On obtient un exe compressé avec UPX et cette fois le upx -d marche très bien.

II. Analyse du KeygenMe

Un anti-sice est là. Ici on utilise Olly, donc sice n'est pas chargé (dsl pour les sice-ad :)
On pose un bpx sur le premier appel à GetWindowTextA, en 00401476. On lance avec F9, je rentre "bigbang" pour nom et "123456" comme serial. On click sur Register et ça break.

Le buffer en 004031B1 recupère le nom (ici "bigbang"). L'exe vérifie que le nom fais plus ou 6 caractères.
Si OK, appel d'une fonction qui empile trois paramètres : un buffer en 00403278, le nombre de caractères du nom et un pointeur sur le nom.
Après le call, le buffer en 00403278 est occupé par 128 bits et le nom a été remplacé par une chaine ASCII :

L'idée d'un hash 128 bits me vient tout de suite pour le buffer en 00403278. On remarque que le buffer en 004031B1 est la représentation ASCII de ce hash.
On vérifie notre hypothèse avec PC Hash Calculator en demandant tous les hash sur 128 bits sur la chaine "bigbang" :

Il s'agit donc ici d'un hash MD5 sur le nom. Et en effet, le buffer en 004031B1 est la représentation ASCII du MD5(nom).

On rentre ensuite dans une boucle qui passe tous les caractères ASCII du hash (buffer en 004031B1).
Si le caractère est une lettre (A, B, C, D, E ou F), il la copie dans un nouveau buffer (en 004031ED).
Sinon il ne fait rien.
Donc extraction des lettres du hash ASCII.
Pour "bigbang", on a "fdfaddffb" en 004031ED.

Ensuite, 2e appel à GetWindowTextA en 004014C3 qui récupère le serial en 00403229.

Ensuite, il y a une comparaison entre la longueur du serial et entre la chaine représentant les lettres extraites du hash.
Si le longueur sont égales, ca continue. Donc dans notre cas, la longueur de "fdfaddffb" et celle de "123456" ne sont pas les memes, donc on quitte.
On va virer tous les bpx posés précédemment, en poser un sur la comparaison en 004014D4 et relancer le debbuging.
On fais F9, et on rentre "bigbang" comme nom, et "123456789" comme serial.

Arrivé à la comparaison, les deux longueurs sont égales à 9, donc ca passe.

On arrive à une nouvelle boucle.

En l'analysant un peu, on s'aperçoit qu'elle vérifie que le sérial est uniquement constitué de chiffres.
Par chance, c'est notre cas, donc on passe cette boucle sans problèmes.
Ensuite, nous avons encore une boucle.

Cette boucle récupère le reste de la division euclidienne d'un caractère du serial par 30h ('0').
Elle vérifie que la somme de ce reste et du caractère correspondant dans les lettres extraites du hash est égale à 66h ('F').

Finalement, chaque caractère du serial est le complément à F de la lettre extraite du hash.
Exemple dans notre cas :

FDFADDFFB ; hash modifié (1)
020522004 ; serial=distance de (1) à FFFFFFFFF

Cette nouvelle chaine est donc le sérial de ce keygenme.

III. Codage du keygen

Je l'ai codé en ASM.
Il utilise la DLL de PC Hash Calculator : lucyhash.dll et la fonction MD5_Compute qu'elle contient.
J'ai utilisé une routine rippée dans un autre keygenme pour convertir le hash en chaine ASCII.
J'ai codé une routine pour extraire les lettres du hash.
Et une petite boucle dont voici le code pour récupérer le serial à partir des lettres extraites :

mov esi, offset szletterinhash
mov edi, offset szSerial
@1:
mov al, BYTE PTR [esi]

test al, al
je short @2

and al, 0Fh
sub eax, 6
neg eax
or al, 30h

mov BYTE PTR [edi], al

inc esi
inc edi

jmp short @1
@2:

mov BYTE PTR [edi], 0

Sources et DLL : _source_keygen.zip

bigbang / 020522004

Ciao...