Reverse Msnmsgr.exe

Bon aujourd'hui on va s'attaquer à ce cher petit msnmsgr.exe, ce petit outil utilisé par le monde entier et qui connait un succès grandissant.

On va voir comment arriver à lancer plusieurs fois MSN alors qu'à vu d'œil il refuse de se lancer plusieurs fois, à la place il donne le focus à la fenêtre déjà lancé.

Bien pour tout vous dire je me suis longtemps demander comment faisait beaucoup de programme pour détecter si ils sont déjà lancés ou pas.

Ils auraient pût lister la liste des processus et vérifier si le nom du prog ni figurait pas mais non ce n'est pas assez flexible, il suffit de renommer l'exe pour pouvoir le lancer plusieurs fois et la solution n'est donc pas très bonne au final.
Et puis je me suis demander si ce n'était pas une sorte de variable globale qui était déclaré lors du lancement de l'exe et qui été détruit en même tant que l'exe, comme ça lorsque l'exe été relancé il lui suffisait de vérifier si la variable existait et si tel était le cas bim on lui balance un MessageBox comme c'est le cas pour CodeBlocks ou alors on donne le focus au premier exe.

Et puis la ça fait bingo parce que justement Windows a une API qui nous permet de déclarer des variables globales enfin c'est pas tout à fait des variables globales c'est plutôt des events grâce à CreateEvent.

Reverse de MsnMsgr

Bon alors c'est parti pour le Reverse de MsnMsgr, maintenant qu'on sait ( on suppose en fait ) quelle fonction MsnMsgr va utilisé pour y parvenir ça va être très simple.

Alors on lance notre cher olly ( moi j'utilise olly parce que c'est le seul que j'utilise mais vous pouvez bien entendu utiliser votre debogueur préférer ) et on ouvre MsnMsgr ( chez moi il se trouve dans C:\Program Files\MSN Messenger\ ).

Et on laisse olly analyser le code parce que MsnMsgr c'est un sacré morceau ... 5 min plus tard olly à fini ^^

Donc comme on suppose que MsnMsgr va utiliser l'API CreateEvent() on va faire un clic droit -> Search For -> Name (label) in current module et on va rechercher CreateEvent(), il n'y a pas de symbole CreateEvent() mais il y a CreateEventA() et CreateEventW() d'après la msdn la seule différence entre ces deux fonctions est que CreateEventA() utilise un encodage ANSI alors que CreateEventW() utilise un encodage Unicode ( http://msdn2.microsoft.com/en-us/library/ms682396(VS.85).aspx Section Requirements -> Unicode).
On va donc poser des breakpoints sur les deux API à coup de clic droit -> Set breakpoint on every reference.

Maintenant un petit coup de F9 pour lancer le prog, on reconnait bien la lenteur de microsoft ... 5 min après boum break sur CreateEventW()

On regarde l'argument EventName, il est à NULL donc ça ne nous intéresse pas aller re F9, encore un appel qui ne nous concerne pas re F9 et puis la un CreateEventW qui pourrait nous servir sauf qu'après analyse aucune vérification n'est faite et donc ça ne nous intéresse pas non plus.
Après avoir relancer encore une fois à coup de F9, on tombe sur un CreateEventA avec comme EventName "MSNMSGR".
On va analyser un peu ce code pour voir de quoi il retourne.

...

00543CCB   > 68 78D75500    PUSH msnmsgr.0055D778                                  ; /EventName = "MSNMSGR"
00543CD0   . 57             PUSH EDI                                               ; |InitiallySignaled
00543CD1   . 6A 01          PUSH 1                                                 ; |ManualReset = TRUE
00543CD3   . 57             PUSH EDI                                               ; |pSecurity
00543CD4   . FF15 3C144000  CALL DWORD PTR DS:[<&KERNEL32.CreateEventA>]           ; \CreateEventA
00543CDA   . 3BC7           CMP EAX,EDI
00543CDC   . 8B5D E8        MOV EBX,DWORD PTR SS:[EBP-18]
00543CDF   . 8943 24        MOV DWORD PTR DS:[EBX+24],EAX
00543CE2   . 0F84 EA4B0000  JE msnmsgr.005488D2
00543CE8   . FF15 8C154000  CALL DWORD PTR DS:[<&KERNEL32.GetLastError>]           ; [GetLastError
00543CEE   . 3D B7000000    CMP EAX,0B7
00543CF3   . 0F84 2F4B0000  JE msnmsgr.00548828

...

Donc il appelle CreateEventA avec comme EventName MSNMSGR puis il compare EAX avec EDI or on peut remarquer que EDI est à 0 comme le témoigne le InitiallySignaled et pSecurity à FALSE donc il va tester si la fonction renvoie 0 donc hop un coup de msdn sur CreateEvent et on nous dis que CreateEvent renvoie un handle si la fonction est un succès sinon elle renvoie NULL donc il ne fait que tester si la fonction à bien marcher.
Si la fonction échoue on sort sinon on continue avec un appel à GetLastError().
Comme nous le dis la msdn GetLastError retourne ERROR_ALREADY_EXISTS si jamais l'event existe déjà, on peut donc supposer que le CMP EAX, 0B7 va vérifier si GetLAstError() renvoie ERROR_ALREADY_EXISTS.
Donc on fait un petit coup de msdn sur GetLastError pour trouver à quoi correspond ERROR_ALREADY_EXISTS, elle nous indique une page avec tout les codes d'erreur ( http://msdn2.microsoft.com/en-us/library/ms681381(VS.85).aspx )

On va donc chercher à quoi correspond 0B7h soit 183 et on tombe sur

ERROR_ALREADY_EXISTS         Cannot create a file when that file already exists.
183
0xB7

Tiens on ne s'en serait jamais douté ^^

Donc il vérifie si l'event existe déjà et si il existe il jmp en 00548828

On regarde ce qu'il fait en 00548828 et on s'aperçoit qu'il va chercher la fenêtre de MsnMsgr grâce à FindWindowA() et va lui envoyer un message pour qu'il prenne le focus avec PostMessageW().

Patch MsnMsgr

Donc pour finir cet article, il vous suffit de changer le 0B7 ( ERROR_ALREADY_EXISTS ) de "CMP EAX, 0B7" en 00543CEE par autre chose comme 0B6 ( ERROR_INVALID_ORDINAL ), ça fera très bien l'affaire.

Et bien j'espère que vous avez appris quelque chose aujourd'hui ( en tout cas moi oui ) d'intéressant et puis au moins ça m'aura permis de patcher mon msn pour ouvrir plusieurs compte en même temps ( plus besoin de aMsn )

Have fun :)