Craquer FlashGet 1.70 fr par Pifoman

Ce cours est un reflet fidèle du cours intégré au crack de ma création de FlashGet 1.70 fr.

Nom du prog	FlashGet 1.70
Editeur	http://www.amazesoft.com/
Téléchargeable	http://www.flashget.com/fgf170.exe
Date du prog	Mercredi 10 août 2005
Date du crack	Samedi 17 septembre 2005
Réalisé par	Pifoman
Url site	http://pifoman.free.fr/pif.php
Url redirection	http://www.geocities.com/mitonnes/pif.htm

FlashGet est spécialement conçu pour gérer deux des plus gros problèmes survenant lorsque vous téléchargez des fichiers : la vitesse et la gestion des fichiers téléchargés. FlashGet est capable de diviser des fichiers téléchargés en sections, de télécharger chaque section simultanément pour un accroissement de la vitesse de téléchargement. Ces caractéristiques, couplées avec des fonctions de gestion puissantes et faciles à utiliser, vous aideront à contrôler vos téléchargements.

w32dasm 8.9
Pour désassembler le progamme (transformation en langage d'assemblage)
Pour trouver les string data references nécessaires pour élaborer le crack.

WinHex 10.2
Pour éditer l'exécutable et modifier certains octets dans le but de la cracker.
On cherche l'offset impliqué en regardant la barre de statut de w32dasm 8.9.
On utilise ce même offset dans WinHex pour effectuer physiquement la modification.

Offset
Déplacement depuis le début de la zone de code d'un programme.

EB
Code hexadécimal correspondant en assembleur à un saut inconditionnel (jmp).
On saute tout le temps vers l'adresse écrite sous forme hexadécimale qui suit le EB

90
Code hexadécimal qui se traduit en assembleur par "ne rien faire" (= nop = No OPeration).

LE CRACK

Octet	Adresse	Offset	Original	Cracké	Effet
1	0041DB10	1DB10	8B	C3	Enregistrement au nom inscrit dans la base de registre

Aujourd'hui on s'attaque à un logiciel très connu dans le monde des gestionnaires de téléchargement.

Comme d'habitude lorsque l'on commence le craquage d'un programme on commence par le désassembler et ensuite le débugguer pour y repérer les failles qui nous serviront à élaborer par la suite le crack. Le désassembleur / débuggueur que j'ai l'habitude d'utiliser et dont on va se servir c'est w32dasm. Cette introduction faite nous pouvons commencer.

On ouvre flashget.exe dans le désassembleur w32dasm par la commande Disassembler -> Open File to disassemble -> flashget.exe. Après quelques instants le listing de désassemblage s'affiche dans w32dasm.

Avant de commencer notre étude du programme nous allons mettre systématiquement le logiciel en version anglaise (afficher -> language -> english). Cela présente en effet de nombreux avantages puisque le logiciel comme beaucoup d'autres a été conçu en langue anglaise (menus, interfaces, boîte de dialogue). La version française n'est qu'une traduction du code écrit en anglais.

Si vous lancez le logiciel vous voyez apparaître dans le dernier menu (le menu help) l'élément "Register...". En cliquant dessus une fenêtre d'enregistrement apparaît avec 3 champs "Name", "E-Mail" et "Registration Code". Mettons les valeurs suivantes

Appuyez ensuite sur le bouton OK. Une fenêtre apparaît ensuite en affichant "Thank you for registering FlashGet. Please restart the program. If you have typed your registration data correctly, the banners will be removed.". Cela signifie en français que le programme a besoin d'être redémarré pour prendre en compte les modications et que si les informations d'enregistrement sont correctes le logiciel sera enregistré à votre nom (les bannières publicitaires n'apparaisant plus dans cette version de FlashGet).

Notons le message et allons dans w32dasm pour voir où est appelé ce message. Faîtes CTRL S pour vous placer au début de la zone de code de FlashGet puis Search -> Find Text -> Thank you for registering FlashGet. Vous arrivez alors à cet endroit.

* Possible StringData Ref from Data Obj ->"RegName"

`:0041D996`	`6850C55000`	`push 0050C550`

* Possible StringData Ref from Data Obj ->"General"

`:0041D99B`	`68FCA45000`	`push 0050A4FC`
`:0041D9A0`	`8BCE`	`mov ecx, esi`
`:0041D9A2`	`E8BB470A00`	`call 004C2162`
...

* Possible StringData Ref from Data Obj ->"RegPass"

`:0041D9B1`	`6848C55000`	`push 0050C548`

* Possible StringData Ref from Data Obj ->"General"

`:0041D9B6`	`68FCA45000`	`push 0050A4FC`
`:0041D9BB`	`E8A2470A00`	`call 004C2162`
...

* Possible StringData Ref from Data Obj ->"RegDisp"

`:0041D9CA`	`6840C55000`	`push 0050C540`

* Possible StringData Ref from Data Obj ->"General"

`:0041D9CF`	`68FCA45000`	`push 0050A4FC`
`:0041D9D4`	`E889470A00`	`call 004C2162`
...

* Possible Reference to String Resource ID=61314: "Thank you for registering FlashGet. Please restart the prog"

`:0041D9DD`	`6882EF0000`	`push 0000EF82`
`:0041D9E2`	`E839140000`	`call 0041EE20`

Le message "Thank you for registering FlashGet. Please restart the program. If you have typed your registration data correctly, the banners will be removed." est donc appelé en 0041D9DD. Si vous remontez dans le code vous voyez 3 appels à des chaînes RegName, RegPass et RegDisp suivis à chaque fois d'un appel à General. 3 ça ne vous rappelle rien ? Il y avait 3 champs dans la fenêtre d'enregistrement ! Le problème maintenant est de savoir la correspondance entre ces 3 variables qui seront intégrées au registre et les champs de la boîte d'enregistrement.

La question se pose alors comment retouver ces 4 informations (RegName, RegPass, RegDisp et General) dans le registre ; informations qui seront examinées par flashget.exe pour savoir s'il doit démarrer en mode enregistré ou non. Pour cela il suffit d'utiliser un petit utilitaire gratuit qui s'appelle Regmon.exe (Regmon = Registry monitoring -> en français surveillance du registre). Il est disponible an anglais sur http://www.sysinternals.com . Il est très petit (seulement 188 ko pour la version 6.06).

Comment allons nous l'utiliser ? En fait c'est assez simple. Je suppose d'abord que flashget.exe est toujours ouvert et que vous êtes à nouveau dans la boîte d'enregistrement de flashget.exe avec les 3 valeurs suivantes remplies

Ensuite vous lancez Regmon.exe et comme on veut surveiller l'activité du processus flashget.exe avec le registre vous tapez flashget.exe dans la case include puis OK.Vous cliquez ensuite sur le bouton OK de la boîte d'enregistrement et dès que le message "Thank you for registering FlashGet. Please restart the program. If you have typed your registration data correctly, the banners will be removed." apparaît faîtes File -> Save As ... -> Regmon.LOG dans Regmon.exe. Ouvrez ensuite Regmon.LOG. Vous voyez apparaître les informations recherchées.

8 2.27 flashget.exe:3704 SetValue HKCU\software\JetCar\JetCar\General\RegName SUCCESS "pifoman@yahoo.com"
17 2.27 flashget.exe:3704 SetValue HKCU\software\JetCar\JetCar\General\RegPass SUCCESS "123456"
26 2.27 flashget.exe:3704 SetValue HKCU\software\JetCar\JetCar\General\RegDisp SUCCESS "Pifoman"

On en déduit que FlashGet sauvegarde dans le registre nos 3 champs d'enregistrement sous la clé General qui se trouve dans le chemin HKEY_CURRENT_USER\software\JetCar\JetCar.

Elle consiste à trouver et forcer la variable d'enregistrement en étudiant le menu Help -> About FlashGet...

En parcourant les menus de flashget.exe on voit le menu Help -> About FlashGet... qui nous affiche une fenêtre à l'intérieur de laquelle on peut lire : This copy of FlashGet is licensed to : Unregistered. Juste en dessous de cette phrase on lit Our thanks to:. Ce que l'on va faire maintenant c'est voir où le programme fait sa vérification d'enregistrement parcequ'il nous affiche Unregistered. On va pour cela dans le listing de désassemblage de flashget.exe (dans w32dasm) et on cherche la chaîne Our thanks to:.On arrive à cet endroit

* Possible StringData Ref from Data Obj ->"Our thanks to:"

`:00419D20`	`6874BD5000`	`push 0050BD74`
...

* Possible Reference to Dialog: DialogID_0064, CONTROL_ID:04B9, ""

`:00419D8C`	`68B9040000`	`push 000004B9`
`:00419D91`	`8BCE`	`mov ecx, esi`
`:00419D93`	`E870F90900`	`call 004B9708`
`:00419D98`	`E8739EFFFF`	`call 00413C10`
`:00419D9D`	`8BF8`	`mov edi, eax`
`:00419D9F`	`8BCF`	`mov ecx, edi`
`:00419DA1`	`E86A3D0000`	`call 0041DB10`
`:00419DA6`	`85C0`	`test eax, eax`
`:00419DA8`	`0F84EE000000`	`je 00419E9C`
...

* Possible StringData Ref from Data Obj ->"RegisteredOwner"

`:00419E59`	`6808BD5000`	`push 0050BD08`
...

* Referenced by a (U)nconditional or (C)onditional Jump at Addresses: \|:00419DA8(C), :00419DEE(U)

`:00419E9C`	`8D4C240C`	`lea ecx, dword ptr [esp+0C]`
...
`:00419EC0`	`C3`	`ret`

On va maintenant débugguer flashget.exe à partir de l'adresse 00419D20 (adresse du premier byte de Our thanks to:) pour localiser la variable dans le code de flashget.exe qui est impliquée dans l'enregistrement de flashget.exe. Pour cela on commence par charger le programme en mémoire par la commande CTRL L de w32dasm. Ensuite on lance le programme via le debugger avec F9. On pose alors un breakpoint sur l'adresse 00419D20 qui appelle le Our thanks to: (SHIFT F12 -> 00419D20 -> OK -> F2) et direction le menu Help -> About FlashGet. A ce moment là w32dasm resurgit. Il a breaké (s'est arrêté) sur l'adresse 00419D20 (vous avez entendu un bing). Faîtes ensuite des F8 successifs (F8 = exécution ligne de code par ligne de code du programme sans entrer dans les calls mais en les exécutant quand même).

Si vous faîtes F8 arrivé en 00419DA8 vous constatez que le programme saute par dessus le RegisteredOwner appelé en 00419E59. Nous on veut s'enregistrer donc il nous faut absolument annuler ce saut en 00419DA8. Comment faire ? En 00419DA6 flashget.exe fait un test eax, eax qui équivaut à un and eax, eax. Si eax est différent de 00000000 le test rend un résultat non nul ce qui implique que le je 00419E9C (jump if equal to zéro dans le dernier test) ne saute pas (on n'a pas obtenu zéro). Il faut donc sorti du call 0041DB10 en 00419DA1 que eax soit différent de 00000000.Voyons ce qui se passe à l'adresse 0041DB10 (faîtes F7 dès que vous êtes arrivé avec le debugger sur l'adresse 00419DA1).

* Referenced by a CALL at Addresses: \|:00419DA1 , :00424D26 , :00426B7F , :00426DFD , :0042CB24 :00451AD4 , :00462783 , :00464B70 , :00475AC8

`:0041DB10`	`8B8188020000`	`mov eax, dword ptr [ecx+00000288]`
`:0041DB16`	`C3`	`ret`

Vous arrivez en 0041DB10. Notez la valeur de eax en haut à gauche dans la grande fenêtre du debugger (celle qui s'était ouverte quand vous aviez fait CTRL L dans w32dasm). Vous voyez eax = 00513940. Ensuite si vous faîtes F8 le contenu sur 4 bytes (c'est le dword ptr) de l'adresse ecx + 00000288 est mis dans le registre eax (eax passe alors à 00000000).Et bien il suffit de teminer prématurément l'exécution du call 0041DB10 en mettant un ret en 0041DB10. Comme ça eax gardera la valeur non nulle qu'il avait avant de passer dans le call 0041DB10.

Avant d'effectuer physiquement la modification il faut s'assurer que notre patch ne perturbe pas l'exécution du programme (par exemple un crash). En effet on a modifié l'instruction en 0041DB10. Le problème c'est que cette instruction est appelée par 9 adresses au total qui sont 00419DA1 (celle de notre patch), 00424D26, 00426B7F, 00426DFD, 0042CB24, 00451AD4, 00462783, 00464B70, 00475AC8. On va en vérifier une (les autres on supposera que c'est OK en lançant le programme modifié et en constatant qu'il ne crashe pas et qu'il fait ce qu'on attend de lui c'est à dire démarrer en mode enregistré). Laquelle choisir ? Réponse : 00424D26. Pourquoi ? Pour la raison suivante. Le menu "A propos de" de flashget.exe fait appel à cette adresse 0041DB10 par la ligne de code d'adresse 00419DB5 :

`:00419D9D`	`8BF8`	`mov edi, eax`
`:00419D9F`	`8BCF`	`mov ecx, edi`
`:00419DA1`	`E86A3D0000`	`call 0041DB10`
`:00419DA6`	`85C0`	`test eax, eax`
`:00419DA8`	`0F84EE000000`	`je 00419E9C`
`:00419DAE`	`8D542414`	`lea edx, dword ptr [esp+14]`
`:00419DB2`	`8BCF`	`mov ecx, edi`
`:00419DB4`	`52`	`push edx`
`:00419DB5`	`E836AF0000`	`call 00424CF0`

Pour vous en convaincre terminez la session de debugging courante par CTRL T puis positionnez vous sur l'adresse 00419DB5 (SHIFT F12 -> 00419DB5 -> OK) puis appuyez sur la flèche droite du clavier. Vous arrivez ici

* Referenced by a CALL at Address: \|:00419DB5

`:00424CF0`	`6AFF`	`push FFFFFFFF`
...
`:00424D26`	`E8E58DFFFF`	`call 0041DB10`
`:00424D2B`	`85C0`	`test eax, eax`
`:00424D2D`	`7479`	`je 00424DA8`
`:00424D2F`	`6838395100`	`push 00513938`

* Possible StringData Ref from Data Obj ->"RegDisp"

`:00424D34`	`6840C55000`	`push 0050C540`
...

* Possible StringData Ref from Data Obj ->"General"

`:00424D3D`	`68FCA45000`	`push 0050A4FC`
...

* Possible StringData Ref from Data Obj ->"RegName"

`:00424D76`	`6850C55000`	`push 0050C550`
...

* Possible StringData Ref from Data Obj ->"General"

`:00424D7F`	`68FCA45000`	`push 0050A4FC`
...

* Referenced by a (U)nconditional or (C)onditional Jump at Addresses: \|:00424D2D(C), :00424D6F(C)

`:00424DA8`	`8B742424`	`mov esi, dword ptr [esp+24]`
...
`:00424DDC`	`C20400`	`ret 0004`

En 00424D2B le programme refait un test eax, eax après avoir appelé notre fameux call 0041DB10. On voit que si le call 0041DB10 n'a pas été modifié on a encore une remise à zéro de eax. Cela provoque alors un saut par dessus une instruction intéressante : le push 0050C540 en 00424D34 qui est chargée de récupérer la chaîne RegDisp = "Pifoman" dans le registre pour l'afficher ensuite à la place du Unregistered dans le menu Help -> About FlashGet... de flashget.exe.

On a donc bien la confirmation encore une fois qu'il faut empêcher la remise à zéro de eax dans le call 0041DB10.

Ce que nous allons faire c'est annuler physiquement ma mise à zéro de eax en 0041DB10. Pour cela on ouvre une copie vierge de flashget.exe dans winhex et on remplace par la commande ALT G -> 1DB10 (1DB10 c'est l'offset donné dans w32dasm dans la barre de statut de w32dasm quand vous sélectionnez l'adresse 0041DB10) le code hexadécimal suivant en blanc et rouge (le blanc c'est ce qui est effectivement à changer) :

  :0041DB10   8B8188020000 mov eax, dword ptr [ecx+00000288]
  :0041DB16   C3    ret
  :0041DB17 90    nop
  :0041DB18 90    nop
  :0041DB19 90    nop
  :0041DB1A 90    nop
   remplacé par
  :0041DB10   C3 ret
  :0041DB11   8188020000C390909090   or dword ptr [eax+C3000002], 90909090

Le fait de mettre C3 sans changer le code qui le suit est ici sans influence sur l'exécution du programme grâce aux nop d'origine qui suivent le C3 à partir de l'adresse 0041DB17. En effet si vous modifiez l'offset 1DB10 dans une copie de flashget.exe en y mettant C3, que vous enregistrer la modification et que vous désassemblez cette copie modifiée dans w32dasm vous voyez dans les 2 listings de désassemblage (flashget.exe non modifié et flashget.exe modifié) que la prochaine ligne de code est située en 0041DB20 :

Cela est effectué par le crack qui met à jour le contenu de la valeur RegDisp présente sous la clé HKEY_CURRENT_USER\software\JetCar\JetCar\General (c'est la commande /nom=pifoman dans la zone de texte du crack).Vous pouvez faire manuellement cette opération (une fois le programme patché) en adaptant ce code qui doit être collé dans un fichier texte nommé enregistrer_flashget.reg :

  [HKEY_CURRENT_USER\software\JetCar\JetCar\General]
   "RegName" = pifoman@yahoo.com
   "RegPass"   = 123456
  "RegDisp"   = Pifoman

Dans ce cours vous avez appris dans un premier temps à localiser les variables d'enregistrement du programme flashget.exe en exploitant un message d'erreur dans w32dasm et en utilisant l'utilitaire Regmon. Par la suite je vous ai présenté une méthode pour craquer FlashGet en étudiant le menu Aide -> "A propos de". Il s'agit en particulier de retouver l'endroit dans w32dasm où le programme appelle le message Our thanks to: .C'est en effet à la suite de cette expression que le nom du propriétaire du logiciel est affiché. Unregistered par défaut ou une autre valeur notamment celle de la variable RegDisp stockée dans le registre lors de la tentative d'enregistrement par le menu aide -> "Register...".