| |
Kaleidoscope 95.1 est un zoli Θconomiseur d'Θcran. Mais il affiche pleins de phrases qui gachent toute la beautΘ des courbes. Il y aurait-il un moyen de passer outre ??? ;-)Have Phun...
Allez, c'est parti, on commence evidemment par installer le programme.
On remarque que le programme nous informe que dans 30 jours il serait conseillΘ de s'enregistrer.
Ceci consiste en une premiΦre piste: Que se passe t-il lorsque la date est dΘpassΘe..?
Bon, on lance propriΘtΘs / Θcran de veille / on choisit KALEID95 et enfin paramΦtres.
Lα, il y a un boutton REGISTER. On clique dessus, puis un nom est demandΘ ainsi qu'un munΘro de sΘrie.
On rentre n'importe quoi, puis on clique sut OK. Lα il ne se passe rien.
DEDUCTIONS: Ceci est important, car le programme ne nous donne pas d'indice/de piste pour chercher (en utilisant un Dead Listing) ce qui se passe quand on rentre un mauvais code. En effet, quand il y a un message du genre:'Votre nom/numΘro de sΘrie n'est pas bon', avec un listing complet (grΓce α WDASM) on pourrait rechercher cette prhase, ce qui nous donnerait un point de dΘpart.
Bon, au tout dΘbut, j'ai dit qu'il y avait un petit indice au niveau de la date.
Pour vΘrifier cela, on avance tout simplement la date du systΦme, puis on relance l'application. Il ne se passe rien. Attention, ceci n'est pas une preuve absolue, car certains prog ont leur propre "compteur de jours", mais cela permet d'avoir une petite vΘrification.
En effet, il se peut que le programme malgrΘs qu'il soit enregistrΘ puisse continuer de vΘrifier la date.
Mais bon, nous avons vΘrifiΘ en avanτant la date du systΦme, et puis quelques petites recherches dans le fichier texte fourni par WDASM avec des mots comme 'Days', 'Date' ne nous indique aucune correspondance. On peut alors supposer qu'il n'y a pas de vΘrification du nombre de jours.
Bon, continuons....
Pour un prg il y a diffΘrents moyens de rΘcupΘrer les donnΘes entrΘes par un utilisateur, en gΘnΘral les fonctions: GetDlgItemTexta et GetWindowTexta sont assez utilisΘes.
On pose donc un BreakPpoint sur ces deux API. Il se trouve que seule Getdlgitemtexta est utilisΘe. On appuie sur F11 afin de retomber sur l'adresse qui suit le call.
Voici le code:
On relance le programme en tapant G, F5 ou X...
:0040208D FF15ACE44100 Call GetDlgItemTextA :00402093 6A0F push 0000000F <-on arrive ici :00402095 8D4DF0 lea ecx, dword ptr [ebp-10] :00402098 51 push ecx
Puis, Soft-Ice rΘapparait...On rappuie sur F11 et voilα, le prg a rΘcupΘrΘ les deux champs d'informations remplis.
On peut mΩme dire que de maniΦre gΘnΘrale :
NOMBRE DE CHAMPS = NOMBRE D'APPELS DE LA FONCTION Code aprΦs le deuxiΦme CALL :
:004020A1 FF15ACE44100 Call GetDlgItemTextA :004020A7 8D4DE0 lea ecx, dword ptr [ebp-20] <-On arrive ici...
Bon, le programme doit stockΘ les valeurs qu'il vient de rΘcupΘrer quelque part.
Si vous faites une vΘrification des adresses mΘmoires [ebp-10] vous remarquerez qu'il s'agit de l'endroit o∙ est stockΘ le SERIAL que l'on a rentrΘ.
De mΩme avec [ebp-60] qui reprΘsente l'endroit o∙ est stockΘ le NOM que l'on a rentrΘ.
Bon, un petit peu de logique maintenant α propos des diffΘrents call qui suivent...
:004020A7 8D4DE0 lea ecx, dword ptr [ebp-20] :004020AA 8D55F0 lea edx, dword ptr [ebp-10] SERIAL :004020AD 51 push ecx :004020AE 8D45A0 lea eax, dword ptr [ebp-60] NOM :004020B1 52 push edx :004020B2 50 push eax :004020B3 E89AFDFFFF call 00401E52 <-Premier Call :004020B8 83C40C add esp, 0000000C :004020BB 8D4DE0 lea ecx, dword ptr [ebp-20] :004020BE 8D55A0 lea edx, dword ptr [ebp-60] NOM :004020C1 51 push ecx :004020C2 52 push edx :004020C3 E885080000 call 0040294D <-DeuxiΦme Call
Donc, on peut en conclure qu'il y a des chances pour que le deuxiΦme call soit necessaire α la vΘrification du NOM/SERIAL
En effet, il y a deux paramΦtres passΘs pour le deuxiΦme call, dont celui du NOM...
Il y a donc de fortes raisons de penser que c'est ce call qu'il va falloir analyser de plus prΦs.
De plus, si vous regardez ce qui se passe pour le premier call, en fait le programme calcul un premier rΘsultat α partir du SERIAL. Ce rΘsultat est placΘ dans [ebp-20].
Puis comme illustrΘ ci-dessus ce premier rΘsultat ainsi que le NOM sont passΘs en paramΦtres pour le deuxiΦme CALL.
Bon, il y a autre chose...Regardez la suite...
:004020C8 83C408 add esp, 00000008 :004020CB 8BC8 mov ecx, eax :004020CD 83E103 and ecx, 00000003 :004020D0 A378814100 mov dword ptr [00418178], eax :004020D5 3BC8 cmp ecx, eax :004020D7 754A jne 00402123 :004020D9 85C0 test eax, eax :004020DB 7446 je 00402123
On peut remarquer que EAX est manipulΘ, et cela juste aprΦs le call...Tiens Tiens...
Si vous tracez, vous remarquerez que le prog ne saute pas en 00402123, en revanche le deuxiΦme saut conditionnel lui saute en 00402123.
Bon, on regarde un petit peu en dessous et on trouve des API TRES interessantes...
On va donc tester de changer le cours du programme en changeant ce JE en JNE...Juste pour voir ce qui se passe....Cela veut donc dire que tout ce qui suit est exΘcutΘ...
:004020DD 8D45F0 lea eax, dword ptr [ebp-10] :004020E0 BF58844100 mov edi, 00418458 :004020E5 50 push eax :004020E6 BE18844100 mov esi, 00418418 :004020EB 57 push edi :004020EC BBA0B94100 mov ebx, 0041B9A0 :004020F1 FF159CE34100 Call dword ptr lstrcpyA :004020F7 8D4DA0 lea ecx, dword ptr [ebp-60] :004020FA 51 push ecx :004020FB 56 push esi :004020FC FF159CE34100 Call dword ptr lstrcpyA :00402102 53 push ebx :00402103 56 push esi :00402104 6814864100 push 00418614 :00402109 BEB8824100 mov esi, 004182B8 :0040210E 56 push esi :0040210F FF15A0E34100 Call dword ptr WritePrivateProfileStringA :00402115 53 push ebx :00402116 57 push edi :00402117 6808864100 push 00418608 :0040211C 56 push esi :0040211D FF15A0E34100 Call dword ptr WritePrivateProfileStringA
Bon, vous devriez vous douter que les API ci-dessus sont assez sympathiques... En effet, si vous regardez les registres qui sont manipulΘs, vous trouverez:
-Le nom
-Le sΘrial
-Kaleidoscope 95.1
-control.ini
Cela ne fonctionne pas car le programme n'est pas enregistrΘ. Car le boutton REGISTER est toujours actif, et la case "EDIT MESSAGES" est toujours inactive...
On jette un petit coup d'oeil sur ce fichier control.ini, et comme par magie on trouve une section USERNAME et PASSWORD avec en face les donnΘes que l'on a rentrΘ.
DEDUCTION: le passage dans cette partie de programme est obligatoire...Puisque c'est elle qui va se charger d'Θcrire dans le fichier CONTROL.INI notre USERNAME ainsi que notre PASSWORD.
D'ailleurs, en relancant le prg pour essayer α nouveau de s'enregistrer, vous remarquerez que ce que vous aviez Θcrit s'y trouve dΘjα...Plus besoin de retaper le NOM et le SERIAL.
On sait que cela n'a pas fonctionnΘ mΩme si le programme a Θcrit dans le fichier control.ini le USERNAME et le PASSWORD. Cela veut donc dire que le programme vΘrifie α chaque fois si ces deux champs suivent bien le schΘma de protection, en d'autres mots que le SERIAL correspond bien au NOM....
Revenons en au code qui se trouvaient si dessus...
:004020C3 E885080000 call 0040294D <-deuxiΦme call :004020C8 83C408 add esp, 00000008 :004020CB 8BC8 mov ecx, eax :004020CD 83E103 and ecx, 00000003 :004020D0 A378814100 mov dword ptr [00418178], eax :004020D5 3BC8 cmp ecx, eax :004020D7 754A jne 00402123 :004020D9 85C0 test eax, eax :004020DB 7446 je 00402123
Inutile de vous dire que le contenu de EAX semble dΘcisif...il est placΘ dans ECX et c'est lui qui dΘtermine ou non si le PASSWORD et le USERNAME doivent Ωtre Θcrit dans control.ini, c'est donc qu'il a un role important...
On va donc tracer dans ce call...puis voir ce qui se passe pour ce registre (EAX) en particulier...
Voici le code du deuxiΦme call....
On remarquera que cette partie de programme est appelΘe 4 fois...
Si vous placez un bpx sur cette adresse vous verrez Soft-Ice quand vous passez d'un autre Θcran
de veille α K95, quand vous cliquez sur ParamΦtres, quand vous cliquez sur REGISTER et enfin quand vous sortez en cliquant sur OK du menu de K95.
Je n'ai pas mis tous le code du call, car ce qui nous interesse se trouve α la fin.
On cherche les derniΦres modifications de EAX, celles qui seront encore valides quand le RET sera exΘcutΘ.
Et ce sont ces opΘrations lα qui sont interessantes, car ce sont elles qui
conditionnent apparement le reste du prg, du moins l'Θcriture dans control.ini
Voici le code source fourni grace α WDASM...J'ai ΘcourtΘ le listing of course...
.....
:0040294D 55 push ebp :0040294E 8BEC mov ebp, esp
:00402BF0 8BC6 mov eax, esi :00402BF2 F7D0 not eax :00402BF4 2345EC and eax, dword ptr [ebp-14] :00402BF7 5F pop edi :00402BF8 5E pop esi :00402BF9 5B pop ebx :00402BFA 8BE5 mov esp, ebp :00402BFC 5D pop ebp :00402BFD C3 ret
Bon, alors voici la fin du call.... Ce qui nous interresse c'est EAX...Donc la derniΦre instruction qui apparait traitant de ce registre c'est :
:00402BF4 2345EC and eax, dword ptr [ebp-14]
On peut donc en dΘduire qu'il y a un lien entre EAX et la valeur qui se trouve en [ebp-14]...
On va donc regarder ce lien qui unit ces deux entitΘs....
On va donc remonter le programme (avec WDASM ou encore le descendre avec Soft-Ice) pour savoir ou se trouve la partie de code qui commence α traiter entre [ebp-14] et EAX...
Voici ce que l'on trouve....
:00402BC6 FF1590E34100 Call dword ptr [0041E390] :00402BCC 85C0 test eax, eax :00402BCE 7507 jne 00402BD7 :00402BD0 C745EC02000000 mov [ebp-14], 00000002
Tiens un call suivi d'un cmp sur EAX !!!!
Et en plus un saut conditionnel qui dΘtermine la valeur de [ebp-14] !!!!
Cela fait bcp de choses tout α coup....
:00402BD7 8D45D4 lea eax, dword ptr [ebp-2C] :00402BDA 8D4DF8 lea ecx, dword ptr [ebp-08] :00402BDD 50 push eax :00402BDE 51 push ecx :00402BDF FF1590E34100 Call dword ptr [0041E390] :00402BE5 85C0 test eax, eax :00402BE7 7507 jne 00402BF0 :00402BE9 C745EC01000000 mov [ebp-14], 00000001
Idem pour ici...un CALL, un cmp et un saut conditionnel qui dΘtermine la valeur de [ebp-14]... Bon...mais quelle est la diffΘrence entre 1 et 2 ???
Qu'est que cela change pour le programme??? Est qu'une de ces deux valeurs veut dire 'OK, le SERIAL est bon' ????
Bon...si vous tracez le programme, vous vous rendrez compte qu'aucune de ces deux valeurs n'est placΘ dans [ebp-14]....
Tiens...Mais alors qu'est-ce qu'il y a dans cet emplacement mΘmoire??
Un petit D ebp-14 pour en avoir le coeur net...Il y a 0
Mais si vous regardez les parties de code qui concerne [ebp-14] dans le code qui correspond au call ΘtudiΘ, vous ne trouverez que 4 rΘponses:
ainsi que
:00402BD0 C745EC02000000 mov [ebp-14], 00000002 ainsi que
:00402BE9 C745EC01000000 mov [ebp-14], 00000001 et enfin....
:00402BF4 2345EC and eax, dword ptr [ebp-14]
:00402953 C745EC00000000 mov [ebp-14], 00000000
Cette derniΦre correspondance de code se trouve au tout dΘbut du call...
Donc [ebp-14] est initialisΘ au tout dΘbut puis modifiΘ si besoin est....
Il ne reste plus qu'α tester avec [ebp-14]=02 pour voir ce que cela fait...
Pour cela on change JNE 00402BD7 en JE 00402bd7 puis on relance le prog....
Et oh!!! cela fonctionne...Votre petit nom apparait en bas α droite de l'Θcran, on peut taper des messages...et mΩme avoir acces aux options AUDIO...
Bon...mais alors...la valeur [ebp-14]=01 c'est pourquoi????
Pour en avoir le coeur net, on ressort du panneau d'affichage, puis on relance propriΘtΘs puis on modifie JNE 00402BF0 en JE 00402bf0...
On relance le prog...Mais lα aussi cela fonctionne....Hum...on peut aussi Θcrire des messages... Ah...Mais quand on appuie sur le boutton AUDIO un petit message nous indique gentillement que le SERIAL que l'on vient de rentrer n'est pas valide pour avoir accΦs aux fonctions Audio...
C'est EXCELLENT!!!
On sait donc maintenant que lorsque [ebp-14]=01 cela veut dont dire que le programme pense que le SERIAL tapΘ n'est pas valide pour les options Audio, alors que lorsque [ebp-14]= 02 le SERIAL est valide pour toutes les options....
Voilα, voilα....il ne vous reste plus qu'α faire un patch pour que [ebp-14] soit tout le temps Θgal α 02...Pour cela, il suffit de s'occuper du fichier Kaleid95.Scr....
Plusieurs mΘthodes s'offrent α vous:
-Modifiez le dΘbut du call du style:
Mov EAX,2
ret / jmp fin
-modifiez pour que [ebp-14]=2 tout le temps en modifiant JNE en JE
-Pour les autres α vous de voir...