|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ce cours est un reflet fidèle du cours intégré au crack de ma création de winzip 8.1 SR-2 fr
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
Offset Déplacement depuis le début de la zone de code d'un programme. EB 90
Détail des modifications winzip.exe
Détail des modifications wzsepe32.exe
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
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
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:
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). -> 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à -> On continue avec F8.On arrive sur un call sur lequel on fait F8 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
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 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 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
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 -> 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
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). 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 ! ![]()
|