HomeSite 4.0 Evaluation Version Infection Time Limit de 30 jours Ecran Shareware au lancement de l'application Bandeau d'écran: Evaluation Version Compacté par Shrinker 3.3 Méthode Mélange de Dead Listing et de Live Approach Décompactage de l'exécutable Outils W32dasm89 SoftIce 4.0 Deshrinker 1.4 Ultra Edit How to HomeSite 4.0 est un éditeur HTML en version complète, de 1.6 Mo, mais limité dans le temps à 30 jours. Sa particularité est surtout d'avoir été crypté par Shinker, une protection que vous n'avez certainement pas été sans rencontrer un jour ou l'autre. Après avoir fait tourner un peu le logiciel pour repérer les différentes infections Shareware, j'ai voulu désassembler HomeSite avec W32dasm. A peine lancé, celui ci m'a renvoyé un message: "PE File Not Standard", a quand même déssassemblé le programme, mais sans les Strings data références. Un petit coup d'œil, en faisant Goto Entry Point m'a donné comme point d'entré du programme 007C83DA. On est loin des 00401000, plus habituel. Bon! Probablement un programme Crypté/Packé. Oui! Mais par quoi? Pour le savoir, il peut y avoir différentes méthodes. L'une des plus simples, est de lancer un utilitaire du genre PE-Sniffer, qui va se charger de vous indiquer, si il le reconnaît, le type de Packer qui a été appliqué à l'exécutable. (Attention !, certains vicieux n'hésitent pas à utiliser plusieurs Packers les uns derrière les autres....). Dans le cas de Homesite, PE-Sniffer à reconnu Shrinker 3.3 Une autre méthode consiste à lancer ProcDump, qui va décompacter l'exécutable, et créer une copie utilisable (le résultat à été un fichier exécutable de 3.7 Mo). Shrinker à l'avantage d'être assez facile à repérer. En chargeant Homesite dans un éditeur hexadécimal, vous verrez même qu'il manque de discrétion: on retrouve des Shrink1, Shrink2, Shrink3 à plusieurs endroits... Puisqu'il s'agit de Shrinker, le mieux et quand même d'utiliser l'outil Ad Hoc dans ce genre de cas, à savoir le Deshrinker de JOB (Il me semble que la dernière version est la 1.5). J'ai obtenu cette fois un fichier de 3.9 Mo soit 200 ko de différences par rapport à ProcDump. Enregistrez ce nouvel exécutable en le baptisant Homesite5.exe, par exemple, ça ne posera aucun problème. Maintenant que vous avez une version décompactée de HomeSite, la suite ne va pas être très différente d'un crack classique. Prenons les infections dans leur ordre d'arrivée: L'écran Shareware: Pendant que Wdasm commence à désassembler le nouvel exécutable fraîchement décompacté, lançons le programme via le symbol loader de SoftIce. Pas de mauvaise surprise, ça marche: SoftIce prend la main. En traçant doucement avec F10, vous allez faire surgir l'écran shareware en 00640F23. Au dessus, vous verrez un test qui permet de s'en passer facilement: :00640EC4 E8DBF0FFFF call 0063FFA4 :00640EC9 84C0 test al, al :00640ECB 7411 je 00640EDE --> à changer en 7418 :00640ECD A100126600 mov eax, dword ptr [00661200] :00640ED2 8B00 mov eax, dword ptr [eax] :00640ED4 E83751DFFF call 00436010 :00640ED9 E931010000 jmp 0064100F * Referenced by a (U)nconditional or (C)onditional Jump at Address: |:00640ECB(C) | :00640EDE C605407F660001 mov byte ptr [00667F40], 01 :00640EE5 803D407F660000 cmp byte ptr [00667F40], 00 :00640EEC 7419 je 00640F07 :00640EEE 8B0D00126600 mov ecx, dword ptr [00661200] :00640EF4 8B09 mov ecx, dword ptr [ecx] :00640EF6 B201 mov dl, 01 :00640EF8 A150386000 mov eax, dword ptr [00603850] :00640EFD E89A00DFFF call 00430F9C :00640F02 A33C7F6600 mov dword ptr [00667F3C], eax * Referenced by a (U)nconditional or (C)onditional Jump at Address: |:00640EEC(C) | :00640F07 33C0 xor eax, eax :00640F09 55 push ebp :00640F0A 68F90F6400 push 00640FF9 :00640F0F 64FF30 push dword ptr fs:[eax] :00640F12 648920 mov dword ptr fs:[eax], esp :00640F15 803D407F660000 cmp byte ptr [00667F40], 00 :00640F1C 7416 je 00640F34 :00640F1E A13C7F6600 mov eax, dword ptr [00667F3C] :00640F23 E88C30DFFF call 00433FB4 => affichage écran Shareware Ce test est fonction du contenu d'une adresse mémoire [00667F40]. Quelques lignes plus haut, vous avez justement un mov byte ptr [00667F40], 01, suivi d'un cmp byte ptr [00667F40], 00. Ca paraît vraiment trop facile! La grande majorité des Trial Version sont des versions finales auxquelles les commerciaux ont fait rajouter une couche de vernis shareware. A partir d'une clé, ou d'une petite modification, les programmeurs se débarrassent ensuite de la protection pour livrer une Full Version sans avoir à réécrire un nouveau logiciel, et [00667F40] pourrait bien être la clé de débridage... Dans un cas comme celui la, vous avez généralement un test en amont qui va se éviter le mov [truc],01. Effectivement, en 006040ECB vous avez un JZ 00640EDE, qui se branche sur le mov byte ptr [00667F40], 01. Par contre, dans ce cas précis, le Jump if Egal que l'on a juste avant le call de l'écran shareware montre clairement que ce call ne sera évité que si l'adresse mémoire contient 0. En route pour notre premier breakpoint intelligent... Après avoir relancé HomeSite, Ouf! Pas de problème, break en 006040ECB, et pas de surprise, le saut se fait en 00640EDE. Tapez ensuite "d 00667F40" (sans les guillemets) sur la ligne de commande de SoftIce, et vous verrez le contenu de cette adresse mémoire dans la fenêtre des Data (à supposer que vous l'ayez activée => WD) Cliquez avec votre souris sur le 01, et remplacez le par 00, puis Echap pour sortir des Data. Appuyez sur F5, et Homesite va démarrer sans afficher l'écran en question. Pour pérenniser cette première bidouille, il faudra, un peu plus tard, soit placer 00 dans [00667F40], soit modifier le saut en 00640ECB pour l'obliger à aller en 00640EE5. On le ferra avec un éditeur hexadécimal. Evaluation Version: Wdasm ayant théoriquement fini de désassembler l'exécutable (il en met du temps, le Bougre!), vous aller avoir enfin accès à des Strings Data références. La seule qui sera vraiment intéressante est justement EVALUATION VERSION: :00616486 80BB980A000000 cmp byte ptr [ebx+00000A98], 00 :0061648D 7572 jne 00616501 :0061648F 8D45FC lea eax, dword ptr [ebp-04] * Possible StringData Ref from Code Obj ->"Allaire HomeSite 4.0" | :00616492 BA30656100 mov edx, 00616530 :00616497 E81CDADEFF call 00403EB8 :0061649C 8D45FC lea eax, dword ptr [ebp-04] * Possible StringData Ref from Code Obj ->" - EVALUATION VERSION" | :0061649F BA50656100 mov edx, 00616550 La routine qui va s'occuper d'afficher ce texte dans le bandeau d'écran, est appelée par un branchement en 006148D JNZ 00616501. Voilà de quoi poser un deuxième breakpoint. Après avoir lancé Homesite, vous allez retrouver votre premier point d'arrêt, et en profiter pour taper Bpx 006148D sur la ligne de commande de SoftIce, avant de refaire la manip de tout à l'heure, et d'enfoncer la touche F5 (pour relancer la bête). Au break suivant, si vous inverser le saut (soit en passant en mode assemblage, soit en tapant R FL Z sur la ligne de commande), vous aurez le plaisir de voir démarrer l'application sans bandeau pollué par de méchantes considérations pécuniaires. Bon vieux système d'économie de marché! Reste à comprendre ce qui se passe. Notre première modification n'a pas suffit à débrider le logiciel, cette fois ci la condition qui fera que le saut s'effectuera ou non est fonction d'une comparaison du contenu de [ebx+00000A98] avec 0. Placez un Bpm ebx+A98, et dans la foulée un Bpm 667F40, pour avoir une idée des sollicitations faitent sur ces deux adresses mémoires, et relancez HomeSite. Vous verrez qu'il y a de fréquentes comparaisons (avec 0) pour chacune d'elles. Où en sommes nous? · Si le programme est un shareware, 667F40 est égal à 1 (et ça n'est pas naturel, il a fallu que le programme place ce 1 dans la mémoire à un ou plusieurs endroits du programme), Toujours dans l'idée qu'il doit y avoir · Ebx+A98, lui doit être égal à 1 pour oublier son statut shareware, ce qui veut dire que quelque part il peut y a une mise à 00 de cette adresse. Plutôt que de continuer à l'aveuglette dans SoftIce, vous allez utiliser la fonction "Search" d'un bon éditeur de texte (genre Ultra Edit), et rechercher toutes les occurrences sur [00667F40], et A98. Pour cette dernière adresse mémoire, ne faites pas la recherche sur ebx+A98: ebx étant un registre, vous pourriez aussi bien avoir des eax+A98, et passer à coté d'eux. Résultat des courses: · Pour [00667F40], vous n'obtiendrez qu'une seule mise à 1 (celle que l'on avait trouvée pour l'écran shareware). · Pour [registre+00000A98], vous trouverez 6 occurrence, dont deux seulement qui vont nous intéresser: en 0060A0F5 mov byte ptr [EAX+00000A98], 00 et en 00619C19 mov byte ptr [ESI+00000A98], bl. Testons un peu ces deux adresses en y posant des Bpx dans softice: sur chacune d'elles, vous aurez un break. La première lors de la phase lancement de l'application, et la deuxième à la sortie. En remplaçant 00 par 01 en 0060A0F5, et en relançant le Soft, vous verrez que EVALUATION VERSION à disparu. Ne vous précipitez pas trop pour faire une modification définitive à ce niveau (on ne sait jamais), vous y reviendrez plus tard... Pour le break en 00619C19, bl est égal à 00. Je n'ai pas vu de différence en forçant le contenu de l'adresse mémoire à 01, si bien que je ne m'en suis plus occupé. La Time Limit: Avec un peu de chance, nos modifications vont suffire pour transformer ce Shareware en Full version. Pour s'assurer qu'il n'y a plus de contrôle sur le temps, vous allez faire un premier test en posant un bpx GetLocalTime. Au cas ou vous n'auriez pas de réponse sur ce breakpoint, il faudra aller éplucher les fonctions importées dans Wdasm pour chercher les Fonctions Windows que le programme appelle du genre GetFileTime, GetSystemTime et autre SetTimer... Et on relance HomeSite: 1er break en 00640EDE, plutôt bon signe ça! 2ème break en GetLocalTime, Aie! Apparemment il s'intéresse au temps... 3èmè break, GetLocal Time à nouveau! 4ème break en 0060A0F5 Puisqu'il s'intéresse au temps, nous aussi! Au premier break dans GetLocalTime, vous allez sortir des MSCVRT, et autres Kernels en appuyant sur F12, jusqu'à revenir à l'exécutable de HomeSite. Vous serez en 0040A410 call Kernel32!GetLocalTime: * Reference To: kernel32.GetLocalTime, Ord:0000h | :0040A410 E8A7C9FFFF Call 00406DBC :0040A415 668B0424 mov ax, word ptr [esp] :0040A419 83C410 add esp, 00000010 :0040A41C C3 ret Il y différentes façons d'exprimer une date: en JJ/MM/AA, en jours (le 30/08/99 est le 242ème jour de l'année 1999), en secondes (une période d'essai de 30 jours et aussi égale à 2592000 s), etc... Il reste que l'année est le plus difficile à camoufler. En gardant un œil sur la fenêtre des registres (WR pour l'activer dans SoftIce), vous allez tracer avec F10 en surveillant les valeurs qui passent dans ces registres, et en guettant tout particulièrement un 07FC (1999 en décimal). Vous ne chercherez pas longtemps: :0040B4F9 8B45F8 mov eax, dword ptr [ebp-08] :0040B4FC 50 push eax :0040B4FD 668B4DEC mov cx, word ptr [ebp-14] :0040B501 668B55EE mov dx, word ptr [ebp-12] :0040B505 8BC7 mov eax, edi :0040B507 E8F4EBFFFF call 0040A100 :0040B50C 8845F7 mov byte ptr [ebp-09], al Voilà pour notre premier GetLocalTime: en CX, DX et EDI, vous avez la date qui pour moi est celle d'aujourd'hui, et je viens d'installer HomeSite il y a peine 1 heure. A la sortie du deuxième break sur getLocalTime, en tracant avec F10, vous arriverez ici: * Reference To: kernel32.GetLocalTime, Ord:0000h | :0040A390 E827CAFFFF Call 00406DBC :0040A395 668B4C240E mov cx, word ptr [esp+0E] jour = 30 :0040A39A 668B54240A mov dx, word ptr [esp+0A] mois = 08 :0040A39F 668B442408 mov ax, word ptr [esp+08] an = 1999 :0040A3A4 E81FFEFFFF call 0040A1C8 :0040A3A9 DD1C24 fstp qword ptr [esp] :0040A3AC 9B wait :0040A3AD DD0424 fld qword ptr [esp] :0040A3B0 83C418 add esp, 00000018 :0040A3B3 C3 ret Pourquoi deux fois la même date à des endroits différents? Une fois pour la date d'installation ? Une fois pour le date du jour en cours ? Pour le savoir, le plus simple est d'avancer (un peu) l'horloge, mais pas au point de dépasser la durée de la période d'essai, disons de 15 jours. En relançant le programme, vous allez de nouveau interrogez le contenu des registres où se trouve stocké la date. En 0040B4FD, vous trouverez toujours 30, 08, 1999 (la date d'installation), mais en 0040A390, c'est la date de votre horloge qui va figurer dans les registres. Si vous avancez encore un peu l'horloge, de façon à vous retrouvez à 25 jours après la date théorique d'installation, vous verrez une message box annonçant " Your 30 day evaluation expire in 5 days", et si vous dépassez les 30 jours d'essai, la même boite affichera "... have expired". Si vous recalez votre horloge à une date comprise dans les 30 jours d'essai, le programme n'y verra que du feu: Pas de clé de mise en place dans votre dos et verrouillant HomeSite en cas de modifications de l'horloge. Bien! Qu'est ce qui va être le plus simple à faire ? Il peut y avoir différentes manières de contourner le contrôle du temps qui passe, mais ce qui me semble le plus simple, c'est de placer la date d'installation à la place de la date réelle saisie par GetLocalTime. Ainsi, HomeSite se croira toujours au 1er jour de la période d'essai, et ceci Ad Vitam Eternam. Voilà l'allure que ça va prendre: * Reference To: kernel32.GetLocalTime, Ord:0000h | :0040A390 E827CAFFFF Call 00406DBC :0040A395 66B91E00 mov cx, 001E :0040A399 90 nop :0040A39A 668BA0800 mov dx, 0008 :0040A39E 90 nop :0040A39F 668BCF07 mov ax, 07CF :0040A3A3E 90 nop :0040A3A4 E81FFEFFFF call 0040A1C8 Les Modifications: Il y a trois niveau de modifications à faire, avec un éditeur hexadécimal: · Modifier le saut en 00640ECB, en remplaçant 7411 par 7418 · Remplacer 00 par 01 en 0060A0F5, en changeant C68098A000000 en C68098A000001 · Modifier les lignes en 0040A390, suivant la proposition ci-dessus Reparlons un peu de Shrinker Shrinker, si je ne me trompe pas, décompresse l'exécutable partie par partie, et au moment ou il en a besoin. Si il est possible d'utiliser SoftIce sur un programme Shrinké, Wdasm et un éditeur hexadécimal ne donnerons rien (pas moyen de retrouver la correspondance entre les codes de softice et ceux de votre hexéditeur). Dans certain cas, pour compliquer les choses (et sans même penser à utiliser plusieurs décompresseur les uns derrière les autres: il faut bien payer les Licences!), vous ne pourrez pas utiliser une version déshrinké du programme (un simple contrôle de la taille de l'exécutable suffit pour le repérer). Il me semble que c'est le cas pour WINHACK 2, lui aussi compacté par Shrinker. Dans ce cas, il faudra (à supposer qu'il n'y a pas d'autre checksum), recompacter l'exécutable en réutilisant le Deshrinker. Si vous écrivez un patch pour HomeSite, il faudrait normalement le "deshrinquer" avant de pouvoir l'appliquer. Il existe un moyen pour l'éviter, mais c'est une autre histoire...