18 Comments

  • 1. Taron  |  septembre 2nd, 2007 at 16:13

    sympa, je connaissais pas les rookits ;-)

    jai laché l’affaire vers la fin de l’article pour raisons médicales (la fin des vacances :-), sinon sympa, on voit de plus de plus de nouveautés !

    espérons que les chinois auront encore le temps de créer à la rentrée :-)

  • 2. Nono  |  septembre 2nd, 2007 at 20:30

    Fan de joanna ? :p

  • 3. admin  |  septembre 2nd, 2007 at 20:38

    Je ne suis pas PD ! :p

  • 4. Anonyme  |  septembre 3rd, 2007 at 00:29

    pas mal ton article. Merci

  • 5. Christophe  |  septembre 4th, 2007 at 13:50

    Ho, plutot que de reverser du rootkit chinois fais moi donc un rapport de stage ;-)

  • 6. Nono  |  septembre 4th, 2007 at 18:13

    ca taille

  • 7. Socrate  |  septembre 5th, 2007 at 06:57

    Plutot que de troller sur ce blog, fini ton TI !

  • 8. Christophe  |  septembre 5th, 2007 at 10:07

    argg

  • 9. Azy  |  septembre 6th, 2007 at 02:54

    hi, i didnot handle the FileFullDirectoryInformation and FileNamesInformation indeed. In fact i found a detector using the same method as yours days ago(yep, by FileNamesInformation), i will add some codes to bypass that if there’s time, i think =)

  • 10. TheShade  |  septembre 6th, 2007 at 21:22

    C’est pas plus simple de detecter le hook de KeRaiseIrqlToDpcLevel ?

  • 11. admin  |  septembre 6th, 2007 at 21:30

    Ouais et comment tu fais ca avec un soft userland ? (mis a part le kd bien sur et sans \device\physicalmemory)

  • 12. TheShade  |  septembre 6th, 2007 at 22:15

    Je me disais que les detecteurs de rootkit travaillaient en ring0 en verifiant que les fonctions principales ne sont pas hookées (comparaison des premiers octets par exemple)

  • 13. admin  |  septembre 7th, 2007 at 00:19

    Ouais les anti-rk use bien des drivers pour détecter les hooks. Mais généralement il ne check que les fonctions de la SSDT à la fois dans la KiServiceTable et les inlinehook. Après si il faut tout vérifier, l’intégralité du binaire par rapport à l’image disque, c’est possible mais c’est long et pas forcément pratique …

    Même si là, j’avoue, la fonction est exportée par hal.dll. On pourrait réduire le champ d’action uniquement aux fonctions exportées des principaux modules.

  • 14. TheShade  |  septembre 7th, 2007 at 08:23

    « Le hook de KeRaiseIrqlToDpcLevel sert juste à faire appel à la fonction qui va hooker IofCompleteRequest »

    Ce que je veux dire c’est que l’idée du hook qui se repete sns cesse est intéressante mais pour moi elle ne fait que reporter le pb de la detection de IofCompleteRequest sur celle de KeRaiseIrqlToDpcLevel.

  • 15. b0l0k  |  septembre 7th, 2007 at 17:17

    D’accord avec TheShade :) C’est fun comme technique mais au niveau de la détection je ne vois pas l’amélioration sachant qu’une API reste hooker. Ca peut être intéressant si avec cette API hooké, on rehook a chaque fois plusieurs APIs, oui là la détection est divisée.

  • 16. newsoft  |  septembre 7th, 2007 at 21:28

    J’arrive pas à ouvrir le .IDB …
    Y a comme qui dirait un petit pb de licence !

  • 17. Michel  |  septembre 21st, 2007 at 19:50

    Un test complet sur la problématique rootkit et leur detection (face à Kav 6):http://kavtest.over-blog.com/article-6656073.html

    La 1ere version d’Oddysee est pas mal non plus pour contourner les detecteurs:
    http://security.over-blog.com/article-4066034-6.html

    Bonne continuation.

  • 18. Ivanlef0u’s Blog &r&hellip  |  mars 27th, 2008 at 14:09

    [...] AK922, contient le code de plusieurs version du rootkit AK922, celui même que j’avais reversé … Le lien sur la page renvoie sur un fichier .sys mais il s’agit bien d’une [...]

Trackback this post