Ce cours est un reflet fidèle du cours intégré au crack de ma création de winzip 9.0 SR-1 fr

        winzip32.exe

        On va s'attaquer aujourd'hui au programme de compression winzip 9.0 SR-1. La méthode pour craquer ce programme est exactement la même que pour winzip 8.1 SR-2 sur laquelle j'ai fait un cours très complet. Je remet donc le même cours en changeant les adresses qui ont bougé. La méthode reste la même (c'est aussi valable pour wzsepe32.exe).
 

        Limitations   : si on lance le programme on voit 1 nag au démarrage qui nous fait patienter 10 secondes en nous rappelant le statut non enregistré du logiciel.Lorsque l'on passe cet écran d'attente on arrive dans l'application qui nous affiche un "non enregistré" dans la barre de titre et dans le menu aide -> A propos de winzip.

        On va enlever ces 3 protections en cherchant à obtenir le statut d'utilisateur enregistré. Pour cela on désassemble winzip 9.0 SR-1 avec w32dasm et on regarde comme d'habitude les string data reférences (menu refs -> string data references dans w32dasm). On ne voit pas de chaîne comme "enregistré" mais par contre une chaîne nommée "Merci d'avoir installé cette version d'évaluation". Pourquoi cette chaîne me direz-vous ? Parceque si le programme affiche ce message c'est qu'au préalable il a fait un test pour savoir si on était enregistré ou non. C'est ce test qu'on cherche à craquer.

        On effectue une recherche dans w32dasm sur la chaîne "Merci d'avoir installé cette version d'évaluation" (par search->find text->Merci d'avoir installé cette version d'évaluation. Il n'y a qu'une seule occurence (ça va être rapide). On tombe alors au dessus de l'adresse 0046EE05. Voici le listing de désassemblage

:0046EDEC	E8552FF9FF	call 00401D46
:0046EDF1	84C0	test al, al
:0046EDF3	7417	je 0046EE0C
:0046EDF5	803DD4654E0000	cmp byte ptr [004E65D4], 00
:0046EDFC	7407	je 0046EE05
* Possible Reference to String Resource ID=09036: "Merci d'avoir installé cette mise à jour."
:0046EDFE	684C230000	push 0000234C
:0046EE03	EB0C	jmp 0046EE11
* Referenced by a (U)nconditional or (C)onditional Jump at Address: :0046EDFC(C)
* Possible Reference to String Resource ID=09037: "Merci d'avoir installé cette version d'évaluation."
:0046EE05	684D230000	push 0000234D

        On remonte alors dans le code pour voir comment on est arrivé ici. C'est le saut (je 0046EE05) en 0046EDFC qui provoque ce saut. Quelques lignes plus haut on a un call 00401D46 à la suite duquel on fait un test. Ca c'est intéressant : c'est le schéma classique de vérification de statut enregistré ou non (un call suivi d'un test ou d'un comp et terminé par un je ou un jne qui saute vers une zone enregistrée). En effet en 0046EE0C on n'a pas d'expression contenant "version d'évaluation".On va donc descendre dans le call à l'adresse 0046EDEC (sélectionnez la ligne d'adresse 0046EDEC et flèche droite). On arrive ici

:00401D46	A0C4F64D00	mov al, byte ptr [004DF6C4]
:00401D4B	C3	ret

        On voit bien que le programme passe ici la valeur enregistrée ou non enregistrée dans le registre al en lisant le contenu de l'adresse 004DF6C4. Les crochets en asm ça veut dire contenu de. Cette adresse qui est à l'ofset 1D46 contient 01 en hexa décimal (01 pour non enregistré). L'adresse 004DF6C4 ne se trouve pas dans la zone de code du programme (vous ne trouverez donc pas avec search->find text).Elle se trouve dans la zone de données du programme (tout exe a une zone de code et une zone de données; la zone de code utilise les données qui sont écrites dans sa zone de données).Cliquez sur le bouton hex display of data object /segment de w32dasm pour la retrouver cette adresse . Vous devez voir ça dans la petite fenêtre qui s'ouvre (c'est une partie du contenu de la zone de données:
 

:004DF6B8	85 C0 75 0A 00 10 40 00	..u...@.
:004DF6C0	AD 11 40 00 01 6E 6D 63	..@..nmc
:004DF6C8	00 00 00 00 E2 B8 CC CD	........

        Remarque   : les caractères écrits en blanc dans le tableau du dessus ne sont plus des instructions asm mais du code ascii correspondant à chacun des octets de la partie écrite en hexadécimal au centre en rouge.

        Ce saut en 0046EDF3 permet de sauter par dessus le "Merci d'avoir installé cette version d'évaluation" et nous donne le statut d'utilisateur enregistré puisque si on installe le logiciel en étant enregistré on n'aura pas de message contenant "version d'évaluation".

        Voila on démarre le programme une fois la valeur 00 posée en 004DF6C4 (offset DF6C4 pour l'éditeur hexadécimal winhex). Ok ça marche l'octet en 004DF6C4 détermine si on était enregistré (valeur 00) ou non enregistré (valeur 01). Il déverrouille ou non toutes les limitations citées plus haut.

         Wzsepe32.exe 

        Limitations   : si on lance le programme on voit 2 nags un quand on veut créer un auto extractible et un quand on décompresse un auto-extractible.On va enlever ces 2 protections.

        On désassemble le programme wzsepe32.exe dans w32dasm et on regarde d'abord les string data references. On ne voit rien d'interessant : pas de "version d'évaluation" comme dans winzip ou de "registered" ou encore de "registered to". Quand on ne sait pas par où commencer ou peut faire un traçage de l'exécution du programme depuis le point d'entrée du programme : en anglais : entry point.

       On va donc débugguer pas à pas winzip self extractor (CTRL L une fois que wzsepe32.exe chargé dans w32dasm) depuis l'entry point sur laquelle on se positionne avec la touche F10.L'entry point est à l'adresse 00417625.Le but de la procédure : on va chercher à se rapprocher le plus possible de l'adresse à partir de laquelle est appelée le nag.

    ->On met un bp en 00417625 (c'est l'entry point) avec F2 sur cette ligne que vous devez selectionner au préalable (pour pouvoir mettre le bp).

    ->Ensuite on fait F9 pour démarrer le debugging suivi de plusieurs F8 (exécuter chaque ligne de code une par une les unes à la suite des autres sans descendre dans les call mais en les exécutant quand même) et au bout d'un moment le nag apparaît.L'adresse qui a appelée le nag est un call en 004177A8
       :004177A8 E8C7C3FEFF call 00403B74

    -> On termine le debugging par CTRL T et on relance le debugging en mettant un bp sur 004177A8.
    -> Dès que w32dasm break sur 004177A8 on fait F7 pour descendre dans le call qui est en 004177A8 suivi de plusieurs fois F8 et on arrive à cette adresse ou le nag est appelé (on se rapproche du but).
      :00403BD2 E827010000 call 00403CFE

    -> On note l'adresse 00403BD2 et on relance une nouvelle session de debugging comme au dessus en mettant un bp sur 00403BD2.W32dasm break.On fait F7 suivide plusieurs F8 et on arrive là ou le nag est appelé (on se rapproche du but).
      :00404193 E802270000 call 0040689A

    -> On note l'adresse 00404193 et on relance une nouvelle session de debugging comme au dessus en mettant un bp sur 00404193.W32dasm break.On fait F7 on arrive là
      :0040689A 55 push ebp

    -> On continue avec F8.On arrive sur un call sur lequel on fait F8
      :004068C5 FF1524634200 Call dword ptr [00426324]

    Avant d'arriver sur ce call vous voyez que le programme est passé surla ligne * Possible StringData Ref from DataObj ->"Merci d'essayer WinZip(R) Self-Extractor " pour appeler notre nag ensuite en 004068C5

      Conclusion   :c'est bon on sait où est appelé le nag. C'est en 004068C5. La solution est donc d'éviter d'entrer dans ce call en 00404193 qui nous a fait venir ici en 004068C5. Pour cela on va nopper le call 0040689A ie l'annuler avec l'instruction asm nop qui veut dire ne rien faire (nop = no operation = 90 en hexa décimal).

      Solution1   :

      On remplace
      :00404193 E802270000 call 0040689A
      par
      :00404193 9090909090 nopnopnopnopnop

      Solution2   (meilleure) :

      On a plus élégant que d'écrire cette suite de 90. On laisse ce call appeler son adresse 0040689A et dès qu'on arrive en 0040689A on termine l'exécution du call avec un ret en assembleur (ret = return = retour).

      On remplace
      :0040689A 55 push ebp
      par
      :0040689A C3 ret

      C'est quand même mieux que la suite de 90 ? Non. L'offset correspondant à l'adresse 0040689A est 689A.On va dans winhex avec une copie de wzsepe32.exe chargée dedans et on fait (ALT G) et on tape 689A et on écrit C3 au lieu de 55. On enregistre la modification par CTRL S.On ferme w32dasm et on renomme la copie de wzsepe32.exe en wzsepe32.exe.

      On lance wzsepe32.exe et là ça marche c'est cool : plus de nag.Mais c'est pas fini malheureusement !

      En effet si on crée un auto extractible avec wzsepe32.exe et qu'on le décompresse il nous met encore un nag. Un nouveau cette fois-ci. On réfléchit. Si le nag apparaît dans l'archive auto-extractible c'est que le programme a vérifié avant de créer cette archive si on etait enregistré ou non. En effet l'exe généré nous dit que la version enregistrée n'affiche pas ce message. Bon on revient sur ce qu'on a fait : on va chercher le statut enregistré puisqu'il existe. On le savait déja dans le 1 ier nag puisque wzsepe32.exe affichait la version enregistrée n'affiche pas cette notice.

      Comme je pensais qu'il n'y avait qu'un nag à enlever je n'ai pas été plus loin que la suppression du nag.En fait il faut qu'on aille plus loin c'est à dire au statut enregistré. On réfléchit à nouveau en utilisant ce que l'on a fait. Le 1 ier nag est appelé en 00404193.Donc quand on arrive en 00404193 le programme sait déja qu'on est pas enregistré.Donc le statut enregistré est entre l'entry point et l'adresse 00404193. Ca réduit le domaine d'investigation.On va en 00404193 et on regarde ce qu'on a au dessus

:00404187	E8345B0000	call 00409CC0
:0040418C	0FB6C0	movzx eax, al
:0040418F	85C0	test eax, eax
:00404191	7505	jne 00404198
:00404193	E802270000	call 0040689A

      Tiens tiens un call 00409CC0 en 00404187 suivi d'un test sur le registre eax et d'un saut conditionnel jne 00404198 (jne = jump if not equal : saut si pas egal à 0 sur le test eax,eax qui positionne le flag 0F à 0 ou 1). Ca ressemble à un schéma classique de test d'enregistrement avec les string data reference en moins puisque en 00404198 on n'a pas une chaîne du style "registered to" ou "registred". Mais bon ca ressemble beaucoup à test d'enregistrement quand même. J'ai 2 remarques à formuler vu le code asm du listing du dessus.

      ->Pour eviter le premier nag en 00404193 on aurait pû forcer le saut en 00404193 en remplacant
          :00404191 7505 jne 00404198
          en
          :00404191 EB05 jmp 00404198
         Ca aurait aussi très bien marché.

      -> On sait aussi en voyant ce listing que dans notre programme comme le premier nag s'affiche qu'il ne saute pas en 00404198 puisque qu'il passe en 00404193 pour appeler notre premier nag.

       Je voulais faire ces 2 parenthèses pour vous faire comprendre la logique du programme.Bon revenons à notre statut enregistré (qui annulera tous nos nags).On va entrer le call en 00404187 pour voir comment se fait l'enregistrement.On arrive ici

:00409CDE	E855000000	call 00409D38
:00409CE3	0FB6C0	movzx eax, al
:00409CE6	85C0	test eax, eax
:00409CE8	7441	je 00409D2B
...
* Referenced by a (U)nconditional or (C)onditional Jump at Address: 00409CE8(C)
:00409D2B	8025A811460000	and byte ptr [004611A8], 00
:00409D32	32C0	xor al, al

       En 00409CE8 si on lance le debugger on voit que le programme saute vers l'adresse 00409D2B. Bon essayons d'annuler le saut en 00409CE8.Pourquoi ça ? Eh bien parceque en 00409D2B on a une instruction asm qui met 00 (état non enregistré) dans l'adresse 004611A8. L'offset correspondant à l'adresse 00409CE8 est 9CE8 (voir la barre de statut de w32dasm quand vous avez sélectionné la ligne avec l'adresse00409CE8). On va remplacer 7441 par 7400 ie je 00409D2B devient je 00409CEA (c'est l'annulation du saut).On va dans winhex faire la modification grâce à l'offset 9CE8+1=9CE9.Dans winhex on fait ALT G->9CE9 puis on remplace 41 par 00 suivi de CTRL S (si winhex refuse d'enregistrer fermer w32dasm qui verrouille le fichier wzsepe32.exe en écriture).

        Remarque finale: pour trouver où était situé l'appel au premier nag on aurait pû débugger le programme en mettant un bp sur toutes le références à l'API user32.MessageBoxA qui crée des fenêtres de message. Pour faire ça

        ->On aurait chargé le debugger de w32dasm avec CTRL L (wzsepe32.exe préalablement ouvert dans w32dasm) en nous positionnant au début de la zone de code avec CTRL S).
        ->Ensuite nous aurions fait une recherche de la chaîne MessageBoxA en mettant un bp (breakpoint) avec F2 sur la ligne qui précède chaque occurence de MessageBoxA (le premier bp par exemple nous l'aurions mis sur l'adresse 004014F1).
        ->Nous aurions ensuite alterné les F2 (poser un bp) avec les F3 (poursuivre la recherche).
        ->On aurait terminé avec F9 pour démarrer le debugging une fois tous ces bp posés.

         Là w32dasm aurait breaké et nous aurions trouvé l'adresse qui appelle le nag et nous serions remonté dans le code pour trouver le call qui nous amène à cet appel de nag : nous aurions trouvé la même adresse 00404193.

      Conclusion   : pour réaliser le crack de wzsepe32.exe on a qu'un seul octet à patcher en 9CE9 on remplace 41 par 00.

Voila c'est fini !
Bon après-midi
 

Nombre de visites depuis le 14/10/2004