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