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