Unreal

Les petits batards de russkoff aux doux noms de MP_ART et EP_X0FF qui ont codé le rootkit POC unreal.a ont filé les sources certes, mais ils ont oublié de donné les définitions des structures utilisées et pire encore le code ne comporte aucun commentaire (et c’est moi qui ça :p), bref c’est un peu incompréhensible et surtout incompilable. Ayant la dernière fois parlé de l’ObpRootDirectoryObject mais sans donné un moyen pour pour y planquer notre driver je me rattrape cette fois-çi, et il y a même des commentaires

Alors je récapitule ce que j’ai dit la dans le post précédent. L’ObpRootDirectoryObject est un structure gérée par l’Object Manager de Win qui contient l’arborescence des objets maintenu par le noyau. Chaque structure OBJECT_DIRECTORY comporte une liste chaînée d’OBJECT_DIRECTORY_ENTRY qui se compose donc d’un champ pointant sur la structure suivant (null si il n’y en à pas) et un champ pointant sur l’object référencé. Lorsque qu’on load un driver, son objet associé est ajouté dans la directory portant de le nom de ‘\Driver’ de l’ObpRootDirectoryObject il est donc possible de parcourir cette liste afin de retrouver les drivers loadés, méthode employée par certains anti-rookits.

Nous comme on est des méchants on voudrait pas que notre driver n’apparaisse pas dans cette liste, pour faire cela le principe est simple, comme on à affaire à une liste chaînée simple d’OBJECT_DIRECTORY_ENTRY il suffit de retrouver l’élément qui référence notre DriverObject puis de dire à celui qui le précède de pointer sur le suivant, dans le cas ou notre driver est le dernier élément de la liste on ne change rien car le champ ChainLink est nul donc après modification le champ Chainlink de l’élément précédent sera nul, dans le cas ou notre driver est le premier élément on modifie le pointeur de l’OBJECT_DIRECTORY pour qu’il commence au second.

Plus précisément le programme fonctionne de la manière suivante :

1. On récupère un handle sur ObpRootDirectoryObject avec l’API ZwOpenDirectoryObject(), comme on veut manipuler l’objet que le handle référence on utilise ObReferenceObjectByHandle() pour obtenir un pointeur sur l’object.
2. On scan récursivement l’arborescence à la recherche de notre DriverObject, dès qu’on l’a trouvé on modifie la liste comme dit plus haut.

Une dernière chose, comme notre thread va parcourir et modifier la structure il serait intéressant de « locker » celle-ci pendant que notre thread l’inspecte, c’est à dire d’empêcher les autres threads d’y accéder. Imaginez le cas ou un autre thread modifie en même temps la liste chaînée que nous, celui ci peut très bien supprimer l’élément suivant à notre driver et si juste avant on modifie le pointeur de l’élément précédent vers celui qui vient d’être supprimé car on voulait delinker notre driver, celui-ci aura une valeur fausse et donc toute la suite de liste sera fausse. Hélas ce genre de problèmes de synchronisation m’échappe encore …

En attendant le code fonctionne quand même

http://ivanlef0u.fr/repo/HideInObjDir.rar
Enjoy

5 comments mars 1st, 2007