WTF

mars 18th, 2007 at 02:09 admin

2h du matin, annihilation mentale, après 4h de recherches infructeuses mon cerveau a laché. Incapable de comprendre, mêmes mes contacts IRC/IRL ont séché, désespoir il ne reste plus que toi. Ayant envie de partager ma douleur je vais vous conter ma tragédie. Samedi soir, une soirée calme, tout avait pourtant bien commencé, je décidais de connecter ma VM sur le kernel debugger, juste pour jouer maintenant que j’ai un new laptop avec de la vrai puissance. D’un coup, sans prévenir, me vient l’idée de suivre le déroulement du shellcode de mon dernier post « Kernel BOF » en live . Hop hop hop, je lance le driver dans la VM et là c’est l’halucination cognitive, ca ne marche pas ! Partant de cette simple constatation je décide de tracer le code. Après avoir passé 3h devant des lignes asm et des dump hexa j’arrive à la conclusion effrayante que le shellcode disparaît de la mémoire !! Pour vous en convaincre aller voir le lien suivant :
http://ivanlef0u.fr/repo/WTF.txt

J’ai remplacé le shellcode par une simple série de ‘A’, le saved EBP et le saved EIP sont bien overwrité par la fonction strcpy. Le souci est qu’au moment de faire le ret 4 de la fonction Mofo, le Buff qui est en 0xfbdf5ba0 est désintégrer ! WHAOU c’était pas prévu ça !
J’ai bien essayé de mettre des breakpoints en accès sur la zone mémoire mais rien n’y fait. La seule possibibitée que j’envisage est que dans mon nouveau processeur, AMD Turion Dual Core TL52, une protection hardware consiste à modifier la stack dépilée. J’avoue ca fait de la peur, après avoir googler je suis tomber sur cette page :
http://www.amd.com/us-en/Weblets/0,,7832_11104_11105,00.html

Après plus de recherche je suis tombé sur ces 2 papers :

http://www.virusbtn.com/pdf/conference_slides/2005/Costin_Raiu.pdf

http://www.amd.com/us-en/assets/content_type/DownloadableAssets/dwamd_AMD64_WinHEC04_pubfinal.pdf

Apparament le NX-bit (NX pour No Execute) permet d’empêcher l’exécution de code dans des zones mémoire non autorisées par le processeur. Ok c’est cool mais ca n’explique pas pourquoi mon Buff avec des 0×41 a disparu, alors si quelqu’un le sait qu’il me fasse signe.

Merci d’avance :)

Entry Filed under: Non classé

4 Comments

  • 1. kraal  |  mars 20th, 2007 at 11:31

    /GS ?


  • 2. admin  |  mars 20th, 2007 at 12:00

    Nion le flag /GS n’introduit qu’une protection avec un cookie qui a pour but de signaler au système qu’il y a eu un debordement. De plus si tu regarde bien le dump des fonctions dans le wtf.txt il n’y a aucune protection de ce genre intaurée (pas de call sur un __security_check_cookie) tout simplement parce que je l’ai désactivé.

    Enfin on m’a donné la solution ce n’était pas un problème hardware en fait. Il s’agit tout simplement (lol?) du fait qu’une interruption prioritaire peut débarquer à tout moment et comme celle-ci se place dans le contexte courant (notre thread dionc) elle utilise la stack libre, qui, avant le return est bien notre ancienne stack alloué qui contenait le buffer ayant debordé avec le shellcode. Cette interruption modifie donc mon ancien buffer mais cela est tout à fait normal et imprévisible.

    Merci à b0nd, ô mon grand maître vénéré pour m’avoir donner la réponse :]


  • 3. kraal  |  mars 20th, 2007 at 12:17

    Je n’ai pas pu regarder ton fichier txt effectivement, le link ne marche pas.
    Sinon c’est intéressant cette histoire d’interruption, c’est propre au mode noyau ?


  • 4. admin  |  mars 20th, 2007 at 12:52

    Dsl pour le txt, je l’ai remit. Autrement nion les interruptions ne sont pas uniquement spécifique au kernel, il ya bien des int XXh dans les process. Dans noyau tous les threads partage le même espace mémoire, lorsque qu’une interruption débarqué, si elle est prioritaire elle interrompt le thread courant et exécute sa routine après elle restaure le contexte et relance le thread. Si tu veux approndir va voir là :

    http://book.itzero.com/read/microsoft/0507/Microsoft.Press.Microsoft.Windows.Internals.Fourth.Edition.Dec.2004.internal.Fixed.eBook-DDU_html/0735619174/ch03lev1sec1.html


Trackback this post


Calendar

mars 2024
L Ma Me J V S D
« fév    
 123
45678910
11121314151617
18192021222324
25262728293031

Most Recent Posts