Craquer Winzip 8.1 SR-2 fr par Pifoman

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

Nom du prog	Winzip 8.1 SR-2
Disponible sur	http://www.absoft.fr
Téléchargeable	http://download.winzip.com/wz81fr.exe
Date du prog	Lundi 10 mai 2004
Date du crack	Dimanche19 septembre 2004
Réalisé par	Pifoman
Url site	http://tresordeguerre.free.fr
Url redirection	http://www.geocities.com/mitonnes

Ce compresseur/décompresseur n'est plus à présenter.En voici la version 8.1. Bien utile pour décompresser les fichiers téléchargés. Il prend en compte de nombreux formats : zip, arj, lzh, tar… Les nouveautés de cette version sont :

-> zipper un document et l'envoyer par e-mail en fichier joint.

-> L'interface a été sensiblement améliorée, maintenant Winzip possède un installateur d'écran de veille et de thème de bureau.

Winzip8.1 SR-2:

    1 - nag-screen avec temporisateur au lancement.
    2- "non enregistré" dans le titrede la fenêtre principale.
    3 - "nonenregistré" dans le menu aide -> A proposde winzip.

Winzip self-extractor:

1 - nag-screenau lancement..
2 - nag-screenquand on décompresse un auto-extractible.

w32dasm 8.9

Pour désassembler le progamme (transformation en langage d'assemblage) et 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 le cracker. On cherche l'offset dans w32dasm 8.9 qui est impliqué dans la protection (en sélectionnant la ligne et en regardant la barre de statut où c'est marqué @offset) et on utilise ce même offset dans WinHex (avecle raccourci ALT G) pour effectuer physiquement la modification à l'endroit repéré par l'offset trouvé dans w32dasm.

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 un endroit du code.

90
Code hexadécimal correspondant en assembleur à une instruction à rien (= nop = No OPeration).

LE CRACK

Détail des modifications winzip.exe

Octet	Adresse	Offset	Original	Cracké	Effet
1	004BD6A4	BD6A4	01	00	On met le logiciel au statutd'utilisateur enregistré.

Détail des modifications wzsepe32.exe

Octet	Adresse	Offset	Original	Cracké	Effet
1	00409599	9599	1C	00	On met le logiciel au statut d'utilisateur enregistré.

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 8.1 SR-2 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 004602BB. Voici le listing de désassemblage

`:004602A2`	`E8763CFAFF`	`call 00403F1D`
`:004602A7`	`84C0`	`test al, al`
`:004602A9`	`7417`	`je 004602C2`
`:004602AB`	`803D70BF4C0000`	`cmp byte ptr [004CBF70], 00`
`:004602B2`	`7407`	`je 004602BB`

* Possible Reference to String Resource ID=09036: "Merci d'avoir installé cette mise à jour."

`:004602B4`	`684C230000`	`push 0000234C`
`:004602B9`	`EB0C`	`jmp 004602C7`

* Referenced by a (U)nconditional or (C)onditional Jump at Address: :004602B2(C)

* Possible Reference to String Resource ID=09037: "Merci d'avoir installé cette version d'évaluation."

`:004602BB`	`684D230000`	`push 0000234D`
`:004602C0`	`EB05`	`jmp 004602C7`

* Referenced by a (U)nconditional or (C)onditional Jump at Address: :004602A9(C)

* Possible Reference to String Resource ID=09038: "Installation terminée."
`:004602C2`	`684E230000`	`push 0000234E`

On remonte alors dans le code pour voir comment on est arrivé ici. C'est le saut (je 004602BB) en 004602B2 qui provoque ce saut. Quelques lignes plus haut on a un call 00403F1D à 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 004602C2 on n'a pas d'expression contenant "version d'évaluation".On va donc descendre dans le call à l'adresse 004602A2 (sélectionnez la ligne d'adresse 004602A2 et flèche droite). On arrive ici

`:00403F1D`	`A0A4D64B00`	`mov al, byte ptr [004BD6A4]`
`:00403F22`	`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 004BD6A4. Les crochets en asm ça veut dire contenu de. Cette adresse qui est à l'ofset BD6A4 contient 01 en hexa décimal (01 pour non enregistré). L'adresse 004BD6A4 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:

`:004BD698`	`85 C0 75 0A 30 10 40 00`	`..u.0.@.`
`:004BD6A0`	`54 12 40 00 01 6E 6D 63`	`T.@..nmc`
`:004BD6A8`	`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 004602C2 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 004BD6A4 (offset BD6A4 pour l'éditeur hexadécimal winhex). Ok ça marche l'octet en 004BD6A4 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.

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 encorede "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 004173E9.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 004173E9 (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 004174b2
       :004174B2 E88EC2FEFF call 00403745

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

    -> On note l'adresse 004037A3 et on relance une nouvelle session de debugging comme au dessus en mettant un bp sur 004037A3.W32dasm break.On fait F7 et on arrive là
      :00403897 E810410100 call 004179AC

    -> On continue avec F8; le nag appelé ici
      :00403CDD E8A8260000 call 0040638A

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

-> On continue avec F8.On arrive sur un call sur lequel on fait F8
:0040639F FF15C8524200 Call dword ptr [004252C8]

Et là le debugger affiche une fenêtre dans laquelle on voit que le programme charge "Merci d'essayer WinZip(R) Self-Extractor Edition Personnelle!WinZip Self-Extractor Editi".Cette fenêtre a pour titre "W32dasm API details" -> très intéressant.

->On continue avec F8. Le call suivant charge le même message avec le titre "winzip générateur d'autoextractibles" et lance effectivementle nag en
:004063B5 FF15FC524200 Call dword ptr [004252FC]

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

      On remplace
      :00403CDD E8A8260000 call 0040638A
      par
      :00403CDD 9090909090 nopnopnopnopnop

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

C'est quand même mieux que la suite de 90 ? Non. L'offset correspondant à l'adresse 0040638A est 638A.On va dans winhex avec une copie de wzsepe32.exe chargée dedans et on fait (ALT G) et on tape 638A 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 00403CDD.Donc quand on arrive en 00403CDD le programme sait déja qu'on est pas enregistré.Donc le statut enregistré est entre l'entry point et l'adresse 00403CDD. Ca réduit le domaine d'investigation.On va en 00403CDD et on regarde ce qu'on a au dessus

`:00403CD1`	`E89B580000`	`call 00409571`
`:00403CD6`	`0FB6C0`	`movzx eax, al`
`:00403CD9`	`85C0`	`test eax, eax`
`:00403CDB`	`7505`	`jne 00403CE2`
`:00403CDD`	`E8A8260000`	`call 0040638A`

Tiens tiens un call 00409571 en 00403CD1 suivi d'un test sur le registre eax et d'un saut conditionnel jne 00403CE2 (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 00403CE2 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 00403CDD on aurait pû forcer le saut en 00403CDB en remplacant
          :00403CDB 7505 jne 00403CE2
          en
          :00403CDB EB05 jmp 00403CE2
         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 00403CE2 puisque qu'il passe en 0040638A pour appeler notre permier 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 00403CD1 pour voir en comment se fait l'enregistrement.On arrive ici

`:0040958F`	`E830000000`	`call 004095C4`
`:00409594`	`0FB6C0`	`movzx eax, al`
`:00409597`	`85C0`	`test eax, eax`
`:00409599`	`741C`	`je 004095B7`
`:0040959B`	`68CCC04200`	`push 0042C0CC`
`:004095A0`	`687CF74500`	`push 0045F77C`
`:004095A5`	`E806E60000`	`call 00417BB0`
`:004095AA`	`59`	`pop ecx`
`:004095AB`	`59`	`pop ecx`
`:004095AC`	`C60580F8450001`	`mov byte ptr [0045F880], 01`
`:004095B3`	`B001`	`mov al, 01`
`:004095B5`	`EB09`	`jmp 004095C0`

* Referenced by a (U)nconditional or (C)onditional Jump at Address: :00409599(C)

`:004095B7`	`80257CF7450000`	`and byte ptr [0045F77C], 00`

En 00409599 si on lance le debugger on voit que le programme saute en 004095B7. Bon essayons d'annuler le saut en 00409599.Pourquoi ça ? Eh bien parceque en 004095AC on a une instruction asm qui met 01 (état enregistré en général) dans l'adresse 0045F880. L'offset correspondant à l'adresse 00409599 est 9599 (voir la barre de statut de w32dasm quand vous avez sélectionné la ligne avec l'adresse 00409599). On va remplacer 741C par 7400 ie je 004095B7 devient je 0040959B (c'est l'annulation du saut).On va dans winhex faire la modification grâce à l'offset 9599+1=959A.Dans winhex on fait ALT G->959A puis on remplace 1C 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 004013EF).
        ->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 00403CDD.

Conclusion : pour réaliser le crack de wzsepe32.exe on a qu'un seul octet à patcher en 959A on remplace 1C par 00.