Crack in France par pifoman

Ce cours est un reflet fidèle du cours intégré au crack de ma création de Acdsee 2.41 fr

Logiciel de nouveau disponible sur xtx grace à Taloche merci à lui. ;)

        Acdsee32.exe

        On va s'attaquer aujourd'hui à acdsee 2.41. Pourquoi cette version ? Parceque c'est la meilleure à mon avis de toutes celles faîtes par Acdsee et la moins brouillon jusqu'à la version 6.0.6.

        Donc allons-y pour le craquage de acdsee 2.41. On voit une boîte d'enregistrement dans acdsee 2.41 (menu outils -> inscrire). Le logiciel est donc passable du statut shareware au statut version complète. Nous on va essayer de forcer l'enregistrement en étudiant la protection mise en oeuvre quand on entre un nom / serial quelconque. Pourquoi allons nous étudier cette boîte d'enregistrement pour craquer acdsee 2.41 ? Parceque dans cette boîte d'enregistrement le programme fait appel à un calcul qui va lui dire si vous êtes enregistré ou non. Et nous on veut atteindre le statut d'utilisateur enregistré.

            a/ Recherche de l'adresse d'appel du message d'erreur

        Quand on entre le couple pifoman / 123456 dans la boîte d'enregistrement d'acdsee 2.41 nous voyons apparaître le message d'erreur suivant : "Votre nom et votre code d'enregistrement ne correspondent pas.Vérifiez votre nom et votre code, puis réessayez.".Ce que nous allons faire c'est rechercher où le programme acdsee 2.41 appelle ce message d'erreur.Pour cela ouvrons ACDSee32.exe dans le désassembleur w32dasm par la commande Disassembler -> Open file to disassemble -> ACDSee32.exe ; puis à l'aide du menu Search -> Find Text -> Votre nom et votre code d'enregistrement de w32dasm nous arrivons à l'adresse où le programme charge le message (1 seule occurrence trouvée).

        * Possible Reference to String Resource ID=00566: "Votre nom et votre code d'enregistrement ne correspondent pa"
        :00401FA8 C7057804500036020000    mov dword ptr [00500478], 00000236

        L'adresse dans laquelle est mise notre message d'erreur est l'adresse 00500478. Refaisons comme ci-dessus une recherche de l'endroit où est utilisée cette adresse (prenez la commande de w32dasm Search -> Find Text -> 00500478). Vous arrivez ici (1 seule occurrence trouvée).

        L'adresse 00500478 est donc appelée quand le programme exécute la ligne de code mov ecx, dword ptr [00500478] à l'adresse 0045919F. Comment est-on arrivé ici ? Il suffit de remonter dans le code en suivant les indications données par chaque mot-clef Referenced by jusqu'à arriver à un endroit intéressant (par exemple un call suivi d'une comparaison cmp puis d'un saut conditionnel type je ou jne). En regardant le code on voit que l'on est arrivé à exécuter l'adresse 0045919F en venant de l'adresse 00459171. Ensuite depuis 00459129 on arrive en 00459171 (regardez le Referenced by).

        En 00459129 on est à un endroit intéressant comme je l'ai mentionné juste au dessus.En 00459129 on a un saut conditionnel.On se dit alors naïvement qu'en annulant ce saut que l'on va enregistrer le logiciel.Ce raisonnement n'est pas bon car vous ne faîtes que remplacer le message "Votre nom et votre code d'enregistrement ne correspondent pas.Vérifiez votre nom et votre code, puis réessayez." par le message "Nous espérons que vous l'apprécierez et que vous continuerez à le supporter, ainsi que les autres logiciels à contribution volontaire.Merci d'avoir choisi notre produit ! " sans enregistrer le logiciel.

        Si vous voulez faire le test ouvrez dans winhex une copie de ACDSee32.exe et placez vous par la commande ALT G -> 59129 à l'offset 59129.Remplacez ensuite le code hexadécimal en rouge suivant :

        :00459129 7543 jne 0045916E
        remplacé par
        :00459129 7500 jne 0045912B

        Ensuite enregistrez et lancez copie de ACDSee32.exe.Vous n'êtes pas enregistré.

            b/ Analyse d'un saut

        On réfléchit.On a le code suivant

        Dans la fin du paragraphe précédent j'ai dit qu'annuler le saut était un raisonnement erroné si on se contente d'inverser le saut.En fait le bon raisonnement c'est de se dire que la fonction de vérification faux serial / vrai serial : le call 00458120 manipule le registre eax et qu'une fois arrivé en 00459126 le registre eax contient une valeur qui dit qu'on doit sauter ou non en 00459129 vers 0045916E (saut <=> non enregistré ;  pas de saut = enregistré).Quelle doit donc être la valeur de eax ? Ce qu'il faut savoir c'est que cmp eax, 00000001 <=> eax - 00000001. Si cette différence donne 00000000 le jne 0045916E (jump if not equal to zero dans la dernière instruction : le cmp eax, 00000001) ne provoque pas de saut vers 0045916E.Le jne saute si on a obtenu quelque chose de différent de 00000000 et ne saute pas si on a obtenu 00000000.

        Conclusion : il faut que eax = 00000001 car 00000001 - 00000001 = 00000000.

            c/ Débugging à l'intérieur d'un call

        Comme le test d'enregistrement se passe dans le call 00458120 on va débugger ce call avec le débugger de w32dasm.Pour cela vous chargez le programme ACDSee32.exe en mémoire avec la commande CTRL L de w32dasm puis vous posez un point d'arrêt sur l'adresse du call 00458120 qui est 00459121 (SHIFT F12 -> 00459121 -> F2) pour dire au débugger de w32dasm d'arrêter l'exécution de ACDSee32.exe dès qu'il rencontre l'instruction située à l'adresse 00459121.Ensuite lancez le programme avec F9 puis direction la boîte d'enregistrement.Saisissez le couple pifoman / 123456 puis OK.w32dasm resurgit alors aussitôt.Il est arrêté sur l'adresse 00459121.Si vous cliquez sur le bouton eax au milieu de la grande fenêtre du debugger (celle qui s'est ouverte quand vous aviez fait CTRL L) vous voyez que le registre eax représente l'adresse du premier byte du nom pifoman (qui est la lettre p) et que edx contient l'adresse du premier byte du faux serial 123456 (qui est le chiffre 1).

        Pour entrer dans le call 00458120 faîtes F7.Après une serie de F8 pour atteindre la fin du call toujours symbolisée par une instruction assembleur ret (ici c'est un ret 000C) on arrive à l'endroit où est mis à jour pour la dernière fois eax

        En suivant les traces rouges laissées par le debugger de w32dasm vous voyez que le programme arrivé 0045817C saute vers 0045818D en évitant en 00458181 le mov eax, 0000001 qui met eax à 0000001. Le programme continue jusqu'en 00458194 puis saute en 0045813E puis met eax à 0000000 avec le xor eax, eax en 00458141. Pour rappel nous on veut que eax = 00000001 avant d'arriver sur le ret 000C.

        Conclusion : il faut annuler le saut en 0045817C ie il faut que eax soit différent de 00000000 par exemple 00000001 sorti du call 00459DB0 en 00458172. En effet en 0045817A le test eax, eax qui est en fait un and eax, eax rendra comme résultat 00000001 si eax = 00000001 et donc on ne sautera pas 0045817C (car on a un jump if equal to zero).

            d/ Débugging à l'intérieur d'un autre call

        Terminez la session de debugging courante par la commande de w32dasm CTRL T (T pour Terminate). Rechargez une nouvelle session de debugging avec CTRL L puis effacez s'il est encore là le breakpoint (point d'arrêt) sur l'adresse 00459121 (cliquez sur le bouton Clear dans à la grande fenêtre du debugger à droite de BPts). Lancez le logiciel avec F9 puis direction la boîte d'enregistrement. Saisissez le couple pifoman / 123456 sans faire OK. Mettez dans w32dasm un point d'arrêt sur l'adresse 00458172 (le call 00459DB0) avec SHIFT F12 -> 00458172 -> F2. Faîtes OK dans ACDSee32.exe. w32dasm resurgit alors aussitôt. Il est arrêté sur l'adresse 00458172.

        Pour entrer dans le call 00459DB0 faîtes F7.Après une serie de F8 juste un peu avant d'atteindre le ret vous arrivez ici

            e/ Inverser un saut et utiliser le patcher dans w32dasm

        Pour rappel on veut que eax soit différent de 00000000 quand on arrive à la fin du call 00459DB0. En 00459E34 le programme ne saute pas en 00459E41 et met en 00459E37 eax à 00000000. Il faut donc forcer le saut en 00459E34 pour éviter de mettre eax à 00000000. Par exemple arrivé avec w32dasm sur l'adresse 00459E34 cliquez sur le bouton Modifiy Data en bas de la grande fenêtre du debugger puis dans la fenêtre qui s'ouvre cliquez sur le chiffre en dessous du Z en haut puis cliquez sur le bouton Modify puis sur le bouton Close. Le saut est maintenant inversé. En faisant F8 on saute vers 00459E41.

        Après plusieurs F8 arrivé en 00459E52 on voit que le programme saute en 00459E83.Si vous faîtes encore des F8 jusqu'à 00459E8B vous avez eax = 00000001 ce qui fait que le test eax, eax qui est en fait un and eax, eax <=> and 00000001, 00000001 rend 00000001. ZF est alors mis à 0 car on a pas obtenu 00000000 (le test modifie toujours ZF).Ensuite en 00459E8D l'instruction sete cl met cl à 00 car ZF = 0. Petit rappel si eax = MMNNOOPP (4 bytes MM, NN, OO, PP) alors cl = PP.ecx est donc mis à 00000000 en 00459E8D puis eax est mis à la valeur de ecx soit 00000000 en 00459E91.Il faut donc empêcher les 2 sauts vers l'adresse 00459E83 (celui en 00459E52 et celui en 00459E62) pour que eax vaille 00000001.Vous pouvez par exemple pour les deux utiliser le patcher de w32dasm.Par exemple arrivé sur l'adresse 00459E52 (avec des F8) cliquez sur le bouton Patch Code de la petite fenêtre du debugger de w32dasm et tapez en dessous de Entrer New Instruction Below jne 00459E54 -> Entrée -> Apply Patch -> Close -> Oui -> Oui. Recommencez la même chose sur l'adresse 00459E62 en entrant l'instruction jne 00459E64.

        Faîtes ensuite F9.Vous êtes enregistré. Le menu ?->A propos de d'acdsee le confirme.

            f/ Appliquer physiquement les modifications

        On vient dans la partie précédente de modifier des bytes dans la mémoire du processus ACDSee32.exe qui tourne en mémoire sous le contrôle du debugger de w32dasm.Si vous femez w32dasm et que vous lancez ACDSee32.exe il se relancera sans que nos modifications soient prises en compte (elles ont disparu de la mémoire en même temps que vous aurez fermé w32dasm). Ce qu'il faut c'est effectuer physiquement les modifications dans le code exécutable du fichier ACDSee32.exe. Pour cela on va utiliser un éditeur hexadécimal : winhex.Ouvrez une copie de ACDSee32.exe dans winhex et remplacez le code hexadécimal suivant en rouge à partir de l'offset considéré.

        Offset 59E34 -> forçage de saut

                :00459E34 740B   je 00459E41
                devient
                :00459E34 EB0B  jmp 00459E41

        Offset 59E52 -> annulation de saut

                :00459E52 752F   jne 00459E83
                devient
                :00459E52 7500   jne 00459E54

        Offset 59E62 -> annulation de saut

                :00459E62 751F   jne 00459E83
                devient
                :00459E62 7500   jne 00459E64

        NB : les offsets précédents ont été trouvés dans w32dasm en sélectionnant la ligne de code considéréée (par exemple :00459E34 740B   je 00459E41 puis en rcopiant le nombre hexadécimal dans la barre de statut de w32dasm à droite de @offset (sans prendre le h).

            a/ Breakpoints sur l'API User32.MessageBoxA

        Pour repérer l'endroit où est appelé le message d'erreur "Votre nom et votre code d'enregistrement ne correspondent pas.Vérifiez votre nom et votre code, puis réessayez." on peut utiliser une autre technique plus lourde mais qui marche très souvent.

        Démarrez le débugging de ACDSee32.exe par CTRL L suivi de F9 dans w32dasm (acdsee ouvert au prélable dans w32dasm).On se dirige ensuite vers la boîte d'enregistrement et on saisit le couple pifoman / 123456 sans faire OK. On met ensuite un point d'arrêt (bp) avec F2 sur tous les occurrences de la fonction messageboxA trouvées dans w32dasm.

        Pourquoi ? Parceque si avec une copie de acdsee vous saisissez  le couple pifoman / 123456 vous avez une fenêtre de message qui vous dit "Votre nom et votre code d'enregistrement ne correspondent pas.Vérifiez votre nom et votre code, puis réessayez.". Sous windows les messages affichés dans ce type de boîte sont en général gérés par la fonction messageboxA de l'API user32.dll. On fait donc une recherche dans w32dasm par search -> find text de messageboxA. Pour chaque occurence trouvée de messageboxA on fait F2 (poser un bp : un point d'arrêt) sur la ligne de code qui la précède. Ensuite on saisit le couple pifoman / 123456 dans la fenêtre d'enregistrement d'ACDSee32.exe. W32dasm break (vous entendez un bing) sur un bp posé celui posé en 0044A4FC.

        :0044A4FC 51 push ecx

        On continue avec F8 pour atteindre le ret et sortir de cette routine on arrive là :

        :004591B1 E8EA12FFFF   call 0044A4A0
        :004591B6 83C414            add esp, 00000014

        Voila.On était donc dans le call en 004591B1 puisque maintenant on est sur 004591B6. C'est ce call qui appelle le message.La suite est exactement pareille que la première méthode.

        On remarquera que cette méthode est plus fastidieuse que le première à mettre en œuvre (il y a beaucoup de breakpoints à poser).

            a/ 1 Breakpoint sur la fonction MessageBoxA dans User32.dll

        Au lieu de poser plein de breakpoints sur chaque occurrence de messageboxA dans le listing de désassemblage de ACDSee32.exe on va poser un seul breakpoint directement dans le fichier User32.dll. Pour cela on charge ACDSee32.exe en mémoire avec la commande CTRL L (après l'avoir désassemblé) puis dans la grande fenêtre du debugger qui est apparue vous double cliquez en bas à droite sur User32.dll dans la liste des Actives DLLs.A la question Disassembly Not Loaded, Load Now ? Répondez par oui. Quand le désassemblage de User32.dll est terminé faîtes F9 pour démarrer ACDSee32.exe. Allez dans la boîte d'enregistrement d'ACDSee32.exe et saisissez pifoman / 123456 sans faire OK.Revenez à w32dasm.Mettez un breakpoint sur l'adresse 77D3ADD7 (SHIFT F12 -> 77D3ADD7 -> F2) : c'est l'adresse du premier byte de la fonction messageboxA.

        Exported fn(): MessageBoxA - Ord:01DDh
        :77D3ADD7 833DC4D3D67700          cmp dword ptr [77D6D3C4], 00000000

       Cliquez sur le bouton OK dans ACDSee32.exe. De retour dans w32dasm faîtes des F8 jusqu'à obtenir l'affichage du message d'erreur dans ACDSee32.exe. Cliquez sur OK dans le message d'erreur dans ACDSee32.exe puis sur F8 dans w32dasm.Dans la grande fenêtre du debugger, bouton eip enfoncé vous voyez l'adresse de la prochaine instruction à exécuter qui est 0044A503 comme le montre la copie du registre eip suivante (eip = extra instruction pointer = adresse de la prochaine instruction à exécuter) :

       [0044A4EF] - 10248c8b ..$.
       [0044A4F3] - 8d000001 ....
       [0044A4F7] - 52082444 D$.R
       [0044A4FB] - 15ff5150 PQ..
       [0044A4FF] - 004df63c <.M.
       [0044A503] - 00c4815f _...
       [0044A507] - c3000001 ....
       [0044A50B] - 90909090 ....
       [0044A50F] - 00ec8190 ....
       [0044A513] - a0000001 ....
       [0044A517] - 00500080 ..P.

       L'appel de la fonction messageboxA dans ACDSee32.exe correspond donc à l'adresse qui précède l'adresse 0044A503 dans ACDSee32.exe soit l'adresse 0044A4FD comme le montre ce listing tiré du désassemblage de ACDSee32.exe. Pour voir ce listing redésassemblez ACDSee32.exe puis SHIFT F12 -> 0044A503)

       * Reference To: USER32.MessageBoxA, Ord:01BEh
       :0044A4FD   FF153CF64D00     Call dword ptr [004DF63C]
       :0044A503    5F                           pop edi

       La suite est exactement pareille que la première méthode à la différence qu'il faut alors redésassembler ACDSee32.exe.

      On remarquera que cette méthode est plus élégante et plus simple que la deuxième à mettre en œuvre (1 seul breakpoint à poser).Ici on débuggué une dll : la dll C:\windows\system32\user32.dll.

         Acdsee n'est pas de prime abord simple à craquer.Vous n'avez pas de string data reference qui vous aide (registered par exemple). La technique utilisée ici est l'étude d'une boîte d'enregistrement. Les mécanismes mis en jeu ici sont relativement complexes si vous n'êtes pas familier avec l'asm (l'assembleur), les breakpoints, et le debugging de façon générale mais n'oubliez pas que c'est en forgeant qu'on devient forgeron. Rien de tel que la pratique pour devenir un bon cracker.

Bonne nuit
Et à bientôt pour de nouveaux cours.
Pifoman
 

Nombre de visites depuis le 14/10/2004