18 Comments

  • 1. marc  |  juillet 15th, 2008 at 20:11

    Même pour un ignare de mon calibre, cette escalade de subtile perversité entre l’auteur du code et le désassembleur est jubilatoire et époustouflante.

    Ca vaut bien une tomme pour accompagner les mojito du Falstaff.

  • 2. ollep  |  juillet 15th, 2008 at 21:53

    Dommage qu’il y ait pas de easter egg pour killer la fenêtre quand même :)

  • 3. Sha  |  juillet 16th, 2008 at 06:34

    Ils sont quand même forts ces chinois :]
    Superbe article dude, ça change de la musique trash et des picz gores héhé ;)

  • 4. Neitsa  |  juillet 16th, 2008 at 10:54

    Salut Ivan :D

    Chouette post et joli reverse ! Ha, ils sont forts ces chinois quand même…

    En regardant les symbols on peut voir que ce champ fait 2 bytes

    Oui sous 2k3 (pas regardé pour Vista), mais pas sous XP et O.S précédents (où le champ fait 4 octets).
    Les offsets sont différents aussi (0×70 sous 2k3, mais 0×40 sous XP), alors attention, il y a un gros risque de bugcheck sous un autre O.S que sous XP !

    Si on voulait être « portable », il faudrait faire quelque chose comme ça – il me semble – pour changer la valeur de KernelDisableApc :

    //decrement KernelDisableApc until it is == 0
    while( !KeAreApcsDisabled() ) //check if KernelDisableApc is 0
    {
         KeEnterCriticalRegion(); //KernelDisableApc --;
    }
    
    //now, set KernelDisableApc to its maximum value
    KeEnterCriticalRegion();
    

    après je n’arrive pas à comprendre pourquoi ce dernier compte à l’envers

    Parce que KiDeliverApc() vérifiera si le champ vaut 0 ou non (donc n’importe qu’elle autre valeur fait l’affaire si != 0). Si la valeur est != de 0 alors on ne délivre pas d’APC. Je vois pas d’autre raison…

    Ceci dit, autant la méthode est chouette et bien pensée, autant je me demande ce qu’on faire avec un process planqué de la sorte (plus du tout d’APC délivrées, des threads à Terminated, un PID fantôme, etc.).

    Le système laisse t’il un liberté d’action à un process et des threads dans un tel état (possible d’ouvrir un fichier par exemple ?) ou faut-il tout « réparer » , faire une action (ex. : ouverture de fichier) et revenir à un état « zombie » ?

  • 5. admin  |  juillet 16th, 2008 at 11:02

    @Marc
    Tu peux me mailler ta tomme ?

    @Ollep
    Nan la DialogFunc de CreateDialogParam ne support pas les messages de type WM_DESTROY donc c’est mort :)

    @Sha
    Merci jeune folle.

    @Neitsa
    Oups erreur de ma part, le champ KernelApcDisable fait bien 4 bytes sous XP. Pour les APCs je ne suis pas d’accord avec ton code, la valeur max est tout simplement 1 ! Il ne pas oublier que KeLeaveCriticalRegion incrémente le compteur donc l’écart le plus grand avec 0 en incrémentant est égal à 0-0xFFFFFF=1 (en unsigned). Sinon le POC ne faisait aucune action après l’envoie des IOCTLs je ne sais pas comment se comporte l’OS avec un thread dans un tel état, pour être sur le mieux serait de tester.

  • 6. ITI  |  juillet 16th, 2008 at 16:23

    Coooool….. J’avais jamais lu un truc sympa comme ça, bien éclairci/traduit pour un noob du code comme moi (QB4, où est-tu ????) :o) merci.

    A quand le kit de codage dans lequel on injecte les exploits et qui maintient les failles ouvertes tant qu’on a pas pu tuer ce super-loader ? :o] gruntz…

  • 7. ollep  |  juillet 16th, 2008 at 16:51

    @ITI, si on reloge le code dans un process « vitale » de windows, ça revient plus ou moins au même en pratique ;)

    Je vois qu’il y a des fans de gorilla.bas

  • 8. CyberPunk  |  juillet 17th, 2008 at 01:11

    Les PID sont des multis de 4, a ce que j’ai compris la le PID fait 7.
    J’ai déja vu un POC qui permetait bypassé les FW en changent le PID de la sorte…

  • 9. sudami  |  juillet 17th, 2008 at 05:07

    Had inadvertently intruded into your treasure land, see this article


    I was the author of this process, I am glad that you patronize my blog,

    and the conduct of this procedure.
    In fact, the method 3, KernelApcDidable, did not play a role in this

    process.
    there not too many tests and improved, so it can not compatible with

    many platforms. Just run under XP SP2.
    The most important point is: This procedure is released just for fun,

    can not be used in the formal products, so the writing is very rough.

    In addition, the author of this article analysis « drv.sys » very well,

    but I had already share the source code http://www.debugman.com. add some jump

    code in the drv.sys is juest for test,the source Code in fact is so

    poor, so I’s not necessary to prevent others to reverse. Oh~~~

    - –
    French football,in this year’s European Cup, performance not well. ah,

    the lack of a central figure such as Zidane; Henry is old …
    and sad about that~

    sorry for my pool English. ~

  • 10. newsoft  |  juillet 18th, 2008 at 13:11

    * Le pb de PsGetVersion() c’est que tu dois faire la table de switch toi-même … donc avoir toutes les versions de Windows et/ou les symboles sous la main …

    * IDAPython et IDARuby ça existe déjà depuis un certain temps :)

    * nibbles.bas forever

  • 11. Taron  |  juillet 18th, 2008 at 15:21

    Sympa ce killme…, c’est vrai qu’il utilise des trucs assez simples, ,et ça marche pas mal, beau reverse !

  • 12. SSTA  |  juillet 20th, 2008 at 16:19

    Une autre perversion du même genre signé par MJ une camarade de Sudami, posté sur son blog ( http://hi.baidu.com/mj0011/blog/item/90adc462293510d9e7113a11.html) et discuté en anglais sur les forums Sysinternals ( http://forum.sysinternals.com/forum_posts.asp?TID=14328 ).

    D’autres codes intéressants sur Debugman/http://www.debugman.com/ (se familiariser avec un bon dico français/chinois est indispensable, et après quelques mois de pratique, il devient facile de naviguer sur n’importe quel site chinois. Si besoin est, les codes sont disponibles à toute personne intéressée); un peu moins sur Antiprotect (http://www.antiprotect.com/ ).

    Bonne continuation.

  • 13. sloshy  |  juillet 21st, 2008 at 17:01

    Hello,
    Une question me turlupine, en modifiant le processus de la manière que tu décris, celui n’est plus actif, si?

    çàd qu’il executera une action (afficher une fenêtre à l’écran pour le cas présent) mais ne sera pas réactif.
    Dans le cas d’une application concrète, notepad par exemple, il ne sera plus utilisable après l’avoir rendu « invincible » n’est ce pas? ce qui avouons le, limite le PoC en question (il me semble).

    Ou peut être suis-je passé à coté d’une énormité?

  • 14. admin  |  juillet 21st, 2008 at 17:06

    @sloshy
    Tu as ta réponse là http://0vercl0k.blogspot.com/2008/07/sudami-killme.html

  • 15. sloshy  |  juillet 21st, 2008 at 19:00

    merci, me voici donc avec un blog de plus à lire :D

  • 16. Nameless  |  juillet 28th, 2008 at 15:33

    C’est HS mais j’ai pas trouvé comment te contacter:
    Une chose interessante pour detecter les process hidden :
    http://forum.sysinternals.com/forum_posts.asp?TID=15457

    a+

  • 17. admin  |  juillet 28th, 2008 at 15:35

    Merci Nameless, très intéressant j’avais déjà vu cette tech, pour me contact, ivanlef0u@security-labs.org.

  • 18. none  |  décembre 15th, 2008 at 00:59

    Juste pour info, l’outils Antirootkit GMER kill très bien sudami, sans broncher.

Trackback this post