Crack in France
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

 

INFOS SUR LE CRACK

 

Nom du progWinzip 8.1 SR-2
Disponible surhttp://www.absoft.fr
Téléchargeable

http://download.winzip.com/wz81fr.exe

Date du progLundi 10 mai 2004
Date du crackDimanche19 septembre 2004
Réalisé parPifoman
Url site

http://tresordeguerre.free.fr

Url redirectionhttp://www.geocities.com/mitonnes

 

COMMENTAIRES SUR LE PROGRAMME

 

    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. 

 

LIMITATIONS

 

    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.

 

LES OUTILS

 

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.

 

ASSEMBLEUR

 

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

OctetAdresse OffsetOriginalCrackéEffet
1004BD6A4

BD6A4

0100On met le logiciel au statutd'utilisateur enregistré.

 

         Détail des modifications wzsepe32.exe

OctetAdresse OffsetOriginalCrackéEffet
1

00409599

9599

1C00On met le logiciel au statut d'utilisateur enregistré.

 

ANALYSE  DU  PROGRAMME

 

        Winzip.exe

 

        On va s'attaquer aujourd'huiau programme de compression winzip 8.1 SR-2.

        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

:004602A2E8763CFAFFcall 00403F1D
:004602A784C0test al, al
:004602A97417je 004602C2
:004602AB803D70BF4C0000cmp byte ptr [004CBF70], 00
:004602B27407je 004602BB
 
* Possible Reference to String Resource ID=09036: "Merci d'avoir installé cette mise à jour."
 
:004602B4684C230000push 0000234C
:004602B9EB0Cjmp 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."
 
:004602BB684D230000push 0000234D
:004602C0EB05jmp 004602C7
 
* Referenced by a (U)nconditional or (C)onditional Jump at Address:
:004602A9(C)
 
* Possible Reference to String Resource ID=09038: "Installation terminée."
:004602C2684E230000push 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

:00403F1DA0A4D64B00mov al, byte ptr [004BD6A4]
:00403F22C3ret

        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:
 

:004BD69885 C0 75 0A 30 10 40 00..u.0.@.
:004BD6A054 12 40 00 01 6E 6D 63T.@..nmc
:004BD6A800 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.

        Si on remplace la valeur 01 de l'adresse 004BD6A4 par 00 le test à l'adresse 004602A7 rendra 0 (car test al, al <=> and 00000000,00000000 => ça met le flag ZF à 0 => le je jump if equal to 0 en 004602A9 s'exécute et on saute en 004602C2 vers "Installation terminée.").

        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.

 

 

         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 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).

      Solution 1   :

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

      Solution 2   (meilleure) :

      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).

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

      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

:00403CD1E89B580000call 00409571
:00403CD60FB6C0movzx eax, al
:00403CD985C0test eax, eax
:00403CDB7505jne 00403CE2
:00403CDDE8A8260000call 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

:0040958FE830000000call 004095C4
:004095940FB6C0movzx eax, al
:0040959785C0test eax, eax
:00409599741Cje 004095B7
:0040959B68CCC04200push 0042C0CC
:004095A0687CF74500push 0045F77C
:004095A5E806E60000call 00417BB0
:004095AA59pop ecx
:004095AB59pop ecx
:004095ACC60580F8450001mov byte ptr [0045F880], 01
:004095B3B001mov al, 01
:004095B5EB09jmp 004095C0
 
* Referenced by a (U)nconditional or (C)onditional Jump at Address:
:00409599(C)
 
:004095B780257CF7450000and 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).

       On teste et on voit que toutes les protections sont enlevées. Bon on réfléchit encore une fois. On est maintenant enregistré. L'octet patché en 0040638A (Solution 1) devient donc superflu donc on ne le patche pas (ça serait redondant) puisque étant enregistré on va systématiquement sauter quand on arrive à l'adresse 00403CDB.
 

       Voila terminé !

 

        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.

 

Voila c'est fini !
Bonne nuit

 



pifoman




Nombre de visites depuis le 14/10/2004