|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ce cours est un reflet fidèle du cours intégré au crack de ma création de Readiris pro 9 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 readiris.exe
Readiris.exe
Avant propos Le logiciel comporte une limitation au niveau du temps d'utilisation qui est fixé à 30 jours. Si vous avancez d'un an la date du système en utilisant l'horloge en bas à droite de votre écran le logiciel ne se lancera plus.Normal vous me direz le logiciel est limité à 30 jours d'utilisation ! On se dit alors qu'en le ramenant à la date d'aujourd'hui le programme va à nouveau se lancer (c'est le cas par exemple pour certains logiciels comme paint shop pro). Le problème c'est que le logiciel est définitivement verrouillé (en apparence du moins parceque nous on va passer par là :)). On réfléchit. Si le logiciel sait que la date d'utilisation a expiré c'est que cette information il l'a enregistrée au préalable quelque part. Ce quelque part dans une grosse majorité des cas c'est le registre (la registry pour les anglophones). Pour ceux qui ne connaissent pas le registre c'est la table de paramétrages des systèmes windows et des applications qui y sont installées.On y accède via l'utilitaire regedit.exe à partir de démarrer->exécuter->regedit.exe. La question se pose alors comment retouver cette information dans le registre ; information qui est examinée par readiris.exe pour savoir s'il doit se lancer ou se fermer (passé les 30 jours d'utilisation il se ferme). Pour cela il suffit d'utiliser un petit utilitaire gratuit qui s'appelle Regmon.exe (Regmon = Registry monitoring -> en français surveillance du registre). Il est disponible an anglais sur http://www.sysinternals.com . Il est très petit (seulement 188 ko pour la version 6.06). Comment allons nous l'utiliser ? En fait c'est assez simple. Vous le lancez et comme on veut surveiller l'activité du processus readiris.exe avec le registre vous tapez dans la case include readiris.exe.Vous avancez la date du système de 1 an (après avoir ouvert readiris une première fois pour initialiser le repère de temps) et vous lancez ensuite readiris.exe. Là le logiciel readiris.exe cherche à se fermer : laissez le faire. Ensuite revenez à Regmon.exe.Vous avez alors à l'écran une colonne process avec explorer.exe et readiris.exe. Sur les lignes où apparaissent readiris.exe vous en avez plusieurs qui font référence à la clé HKCR\CLSID\{772B7777-2D11-4af5-A72B-E48B7E1AC759}\ClassData\ru_d8x Sur cette même ligne vous avez les paramètres result=success et other= un nombre (chez moi 0400115068). Ca c'est très intéressant.Quand un programme interroge la clé HKCR\CLSID (HKCR pour HKEY_CLASSES_ROOT et CLSID pour Class Identifier) vous pouvez être sûr que dans beaucoup de cas l'identifiant de classe qui succède le CLSID (ici {772B7777-2D11-4af5-A72B-E48B7E1AC759}) est impliqué dans la protection temporelle. C'est le cas ici. De plus le nombre dans la colonne other ça ressemble à un timestamp c'est à dire un nombre qui après calcul donne une date (date d'expiration sûrement). Allons dans le registre et effaçons cette clé de nom ru_d8x et relençons readiris.exe .Eh là bien que nous ayons fait un saut dans le temps de 1 an le logiciel se lance comme si c'était la première utilisation ! Bon voila la protection est découverte.On pourrait s'arrêter là mais nous ce qu'on veut c'est que le logiciel à chaque lancement croit que c'est la première utilisation.On va donc le craquer (en supprimant pendant qu'on y est le nag à chaque démarrage).
Analyse du programme
Octet 1 Notre but : retirer les nags screen (écrans de harcèlement en français). On désassemble readiris.exe dans w32dasm par la commande Disassembler->Open File to Disassemble. On inspecte ensuite les string data référence dans w32dasm comme d'habitude. On clique pour cela sur le bouton dans la barre de boutons nommé Strn Ref et ensuite on clique sur le bouton Copy All. On colle le tout avec CTRL V dans l'éditeur de texte wordpad.exe (accessible par démarrer->exécuter->wordpad). On cherche une chaîne que nous parle de register (par exmple regist). L'avantage de cherche regist c'est que vous trouvez à la fois registered et enregistré (si les messages sont en français). On cherche mais on ne trouve rien d'intéressant. On va donc utiliser une de mes techniques préférées celle du point d'arrêt (et pas celle du point d'arrête comme j'ai souvent l'habitude d'écrire en tapant trop vite au clavier) sur la fonction MessageBox de l'API user32.dll (c'est cette fonction qui appelle les nag screen en général). On y va. On charge readiris.exe en mémoire depuis w32dasm par CTRL L (L pour load en anglais).Ensuite on se met au début de la zone de code de readiris.exe par CTRL S et on met un point d'arrêt sur chaque ligne ou apparaît MessageBox. Pour mettre le point d'arrêt vous faites search->find text->MessageBox ,vous sélectionnez la ligne de code qui précède le MessageBox et vous faites F2. Le premier bp (breakpoint ou encore point d'arrêt) par exemple est mis sur la ligne de code d'adresse 00434E68 :00434E68 50 push eax Un carré jaune apparaît alors à gauche du bp posé.Vous faites F3 pour passer à l'occurence suivante et vous alternez ainsi les F2 et les F3.Vous avez à poser au total 7 bp.Cette liste de bp apparaît dans la grande fenêtre du debuggeur à droite où c'est marqué Bpts (Bpts = breakpoints). Rappel : la grande fenêtre du debuggeur c'est la fenêtre qui est apparue quand on avait fait CTRL D.Une fois tous ces bp posés on lance le programme avec F9. Attention je me place dans la configuration du programme où il est encore évaluable (regardez plus haut comment revenir au premier jour d'utilisation si vous avez avancé la pendule de plus d'un mois). w32dasm break alors sur la ligne de code d'adresse 00434E68 :00434E68 50 push eaxSi vous faites F9 le programme est lancé. Il n'y a donc qu'un seul appel à la fonction MessageBox sur les 7 potentiels dans le listing de désassemblage qui est impliqué dans le nag à l'ouverture de programme (c'est normal vous me direz puisqu'il n'y a qu'un seul nag-screen à apparaître).Terminons la session de debugging par CTRL T (T pour terminate) et regardons comment on est arrivé à exécuter cette fonction.
Je crois que c'est clair : la seule manière d'arriver ici en 00434E68 c'est par l'adresse 00434E09 (le C indique que le saut depuis 00434E09 s'est fait de façon conditionnelle ie c'est un je ou un jne qui nous a amené en 00434E59).Allons en 00434E09 par shift F12 -> 00434E09. On voit alors ça :00434E07 85C0 test eax, eax:00434E09 744E je 00434E59 :00434E0B 8B4D10 mov ecx, dword ptr [ebp+10] On va donc annuler le saut en 00434E09 en remplaçant le code hexadécimal 744E par 7400, comme ça le programme sautera en 00434E0B au lieu de sauter en 00434E59 et évitera de nous afficher le nag-screen. Pour faire physiquement la modification dans l'éditeur hexadécimal winhex.exe il nous faut l'offset correspondant à l'adresse 00434E09. w32dasm nous le donne dans la barre de statut en bas en sélectionnant la ligne d'adresse 00434E09. Vous voyez @Offset 00034E09h. L'offset est donc 34E09. Vous allez dans winhex vous ouvrez une copie de readiris.exe et vous faites ALT G -> 34E09 et vous remplacez 744E par 7400. Enregistrez et lancer cette copie. Le nag-screen " Cette version ne fonctionnera que pendant 30 jours" a disparu. Si vous avancez d'un an la pendule de windows le nag disant que " la période d'évaluation de 30 jours est terminée" est aussi retiré. On a donc supprimé les 2 nags en patchant un seul appel à MessageBox. En fait appel gère les 2 nags. Le problème c'est que le programme passé les 30 jours se ferme. On va donc maintenant s'attaquer au time limit.
Octet 2 Notre but : retirer le time limit Quand on lance le programme il nous affiche le nag et ensuite il reste ouvert ou se ferme si on a dépassé les 30 jours. Nous ce que l'on va chercher à faire maintenant c'est maintenir la fenêtre ouverte tout le temps (avant et après les 30 jours). Pour cela il faut un peu de connaissances sur les API windows en particulier sur la fonction ShowWindow de l'API USER32.dll. Comme son nom l'indique ShowWindow est la fonction qui est appelée dans de nombreux cas pour afficher une fenêtre. Les paramètres de cette même fenêtre comme ses dimensions (position du coin supérieur gauche, largeur, hauteur) sont positionnés au préalable avec par exemple la fonction CreateWindow.Je vous invite à ce sujet à regarder mon article sur le code source de mes cracks en C++ disponible sur mon site dans la rubrique /cours_cracking/cours_pif_source_C2.htm. Vous verrez à la fin du code un appel à la fonction ShowWindow. C'est une fonction indispensable au programme sinon rien ne s'affiche même si vous avez fait votre CreateWindow au préalable. Cette règle on va l'appliquer dans le cas de readiris.exe. Ce que l'on va faire c'est d'abord avancer la pendule de 1 an et mettre un point d'arrêt sur tous les appels à cette fonction ShowWindow.Pour cela faites CTRL T (pour terminer la session courante de debugging) CTRL L puis CTRL S (début de la zone de code du programme) et mettez avec F2 un breakpoint (bp) sur toutes les occurences de ShowWindow trouvées avec search->find text->ShowWindow (F3 pour passer aux occurences suivantes). J'en ai posé 67. Les 4 premiers bp sont sur les adresses 00408145, 00408156, 00408458, 00408588 et ainsi de suite jusqu'à la fin. Le dernier est mis sur l'adresse 00536CC9. Ensuite on démarre avec F9 le programme avec le debugger. Et là w32dasm break et est arrêté sur l'adresse 00481A06. Faites F9 pour continuer l'exécution et w32dasm break à nouveau en 0048B868. Faites encore F9 et là le programme est lancé. On a donc l'adresse de l'appel du ShowWindow qui va afficher la fenêtre au démarrage c'est celle de dernier break à savoir 0048B868. On fait CTRL T et on relance une nouvelle session de debugging avec CTRL L en posant un bp sur l'adresse 0048B868 (SHIFT F12->0048B868->F2). On démarre ensuite le programme avec F9 et dès que w32dasm break sur 0048B868 on fait des step over avec F8 (F8 exécute le programme ligne de code par ligne de code en ne rentrant pas dans les call mais en les exécutant quand même). Vous avez alors des fenêtres dont le titre est W32dasm API details qui apparaissent à l'écran. Regardez ce qui apparaît dedans ça va nous aider. On a le listing de désassemblage suivant
Les W32dasm API details qui apparaissent successivement à l'écran nous indiquent que -> En 0048B8DF la chaîne "Période d'évaluation de %i jours terminée.Veuillez contacter votre revendeur" est chargée via la fonction USER32.wsprintfA. On réfléchit à la vue de ces éléments et on se dit qu'il nous faut absolument éviter ces messages d'erreurs et le saut vers KERNEL32.FindClose. Comment faire ? Remontons dans le code pour voir si on peut éviter de passer sur cette zone qui provoque la fermeture de la fenêtre. On voit que cette zone peut être évitée grâce à :0048B8B2 7558 jne 0048B90C En fait il suffit de forcer ce saut en 0048B8B2 et le programme croira que l'on est encore dans la période d'évaluation.Comment est ce que je sais ça ? Eh bien il suffit de redémarrer la période d'évaluation au premier jour en effaçant dans le registre la clé HKCR\CLSID\{772B7777-2D11-4af5-A72B-E48B7E1AC759}\ClassData\ru_d8x Ensuite faites CTRL T pour terminer la session courante de débugging et relancez en une nouvelle avec CTRL L. Vous mettez un bp sur 0048B8B2 et démarrez le programme avec F9.Vous voyez ensuite que le w32dasm break en 0048B8B2. Si vous faites F8 en 0048B8B2 le programme saute en 0048B90C. Conclusion : l'idée de forcer le saut vers 0048B90C quand on avait dépassé la période d'évaluation était bonne.Ce saut donne à présent au programme l'illusion qu'il est dans la période d'évaluation ad vitam aeternam. Pour effectuer physiquement la modification allez dans winhex et faites ALT G -> 8B8B2. Remplacez 75 par EB. Enregistrez avancez la pendule d'un an et lancez le programme. Il tourne correctement au dela des 30 jours.Voila le cours est terminé et le programme est complètement craqué.
Conclusion : Dans ce cours vous pouvez constater qu'un programme n'a pas besoin d'être important en taille pour avoir une protection dure à craquer. Ce programme fait 22.3 Mo. Serait-il 18 fois plus dur à craquer que winrar 3.41 qui ne fait seulement que 1.18 Mo. J'en doute. Je serais même tenté de dire que winrar est plus dur à craquer que ce programme pour autant qu'on ait l'idée de penser à mettre un bp sur la fonction ShowWindow. Ce cours c'est l'occasion aussi de voir la fonction ShowWindow et de faire une trace des messages d'erreur renvoyés dans les nags-screen du programme pour pouvoir ensuite retirer ces mêmes nags-screen.
![]()
|