15 Comments

  • 1. dora  |  mars 2nd, 2008 at 16:00

    Comme les chocapics !

  • 2. SynApsus  |  mars 3rd, 2008 at 07:12

    J’adooore ce genre de tites analyses :) pour une fois g pas besoin de doliprane en plus.
    Continue à ecrire ivan, ça me permet de continuer à rever que je referai des trucs dans le genre bientot !

  • 3. Orkblutt  |  mars 3rd, 2008 at 09:52

    On peut retrouver l’utilisation de QueryObject dans un vieux src ecrit par Zoltan Csizmadia en 2000. Sa classe SystemHandleInformation peut être trés utile pour ceux qui veulent ecrire un programme à la unlocker…
    Une petite mise à jour par Shub-Nigurrath from ARTeam: http://arteam.accessroot.com/releases.html?fid=17

  • 4. x  |  mars 10th, 2008 at 00:41

    « Par contre dans le cas d’un fichier, l’utilisation d’un driver un peu lourde, il est possible de faire beaucoup plus simple, en effet pour obtenir le nom de l’objet référencé par un handle après l’avoir dupliqué il suffit d’utiliser l’API ZwQueryObject »

    ok mais dans ton exemple (http://ivanlef0u.free.fr/repo/Handle.rar) tu utilises NtQueryInformationFile(FileNameInformation) et pas ZwQueryObject(ObjectNameInformation) (ni NtQueryObject) : pourquoi ? samarchpa?
    je demande paske NtQueryInformationFile(FileNameInformation) ne donne pas le volume du fichier…pas cool
    on fait comment pour avoir le volume sur lequel est le fichier sans driver (et proprement) ?

  • 5. marylune  |  mars 10th, 2008 at 16:02

    écoute avec tes « je trouve un peu con » et tes « il suffirait » qu’estce que tu fais de ta Vie?
    moi je comprends rien a ce que tu expliques parceque tu ne donnes rien en échange

    cordiale salutations IvanleFou

    Marylune

  • 6. Cedrick  |  mars 10th, 2008 at 17:55

    “Par contre dans le cas d’un fichier, l’utilisation d’un driver un peu lourde, il est possible de faire beaucoup plus simple, en effet pour obtenir le nom de l’objet référencé par un handle après l’avoir dupliqué il suffit d’utiliser l’API ZwQueryObject”

    Typique Fanfaronade Francaise :D Quelle meilleure solution avez vous?

    « Bon jusqu’ici c’est simple, le problème c’est que je suis tomber sur un bug lorsqu’on esssaye d’obtenir le nom sur un NamedPipe ouvert en mode synchrone (gnifulol?) la fonction NtQueryObject devient blocante oO. J’ai donc implémenté un thread qui effectue cette opération pour ce type (de type File en fait), au moins il peut bloqué puisqu’on le kill si il fait le malin ;) »

    C’est vraiment pas terrible ca, mais je comprends que vous ayez eu cette idee puisque c’est la plus facile a mettre en place. Cependant hormis son inelegance, terminer les threads bloques ne nettoie pas les requetes bloquees, mais aussi car en user space beaucoup de handle ne trouvent pas de nom.

    Le driver est malheureusement la meilleure solution. Si vous trouvez mieux tennez moi au courrant :D

  • 7. Cedrick  |  mars 10th, 2008 at 18:03

    Zut j’ai clique « Submit » trop tot.

    Felicitation pour la tres bonne reversion de Unlocker, ca donne en effet les grandes lignes correctes.

  • 8. admin  |  mars 10th, 2008 at 20:15

    @x
    Tu peux récupérer le full path d’un fichier à partir de son handle avec GetFullPathName

    @Cedrick
    Nan je n’ai pas mieux en effet, je voulais juste dire que je trouvais cela lourd et non que c’était mal implémenté, au contraire même. Process explorer fonctionne de la même manière à ce niveau, il utilise aussi un driver. Si jamais je vois mieux je vous mail :]

    @Marylune
    Dans ma vie je bois du brawndo, ça déchire ta soif et ça contient des electrolytes !

  • 9. marylune  |  mars 10th, 2008 at 23:53

    http://sendtofriend.blogspot.com/2007/12/brawndo-du-film-idiocracy.html ?

  • 10. admin  |  mars 11th, 2008 at 00:02

    Wai le brawndo de idiotcracy :)
    http://www.mirror-mondenocturne.com/films-idiocracy-dvdrip-vf-1-103

  • 11. x  |  mars 11th, 2008 at 00:46

    @ivanlef0u : j’ai trouve (un truc bien crade), mais merci quant meme pour la blague.

    sinon…
    « Il commence par récup un handle sur la DLL avec GetModuleHandle puis entre dans une boucle de 16 itérations, qui va appeler FreeLibray et CloseHandle. Si le développeur à choisit d’utiliser une boucle c’est parce que chaque DLL possède un compteur référençant le nombre de chargements effectués avec LoadLibrary »
    et pis apres
    « je pense que pour décharger un DLL, unlocker fait bien le boulot, c’est la méthode la plus simple »
    ok : ya 1 compteur (maybe OBJECT_BASIC_INFORMATION.ReferenceCount ?), on le lit pa, on fait 16 tours mem si le compteur est a 17 et sa s’appel sa bien faire le boulot ? au bou de 16 win devine kon veut unloader la DLL cé sa et le 17 cé cado ?

  • 12. admin  |  mars 11th, 2008 at 00:59

    Mais nan, la boucle sert uniquement au compteur qui référence le nombre de fois que la DLL a été loadée. Il se situe dans le champ LoadCount de la structure LDR_MODULE unique à cahque DLL accessible depuis une double listé chainée depuis le PEB :

    typedef struct _LDR_MODULE {
    
      LIST_ENTRY              InLoadOrderModuleList;
      LIST_ENTRY              InMemoryOrderModuleList;
      LIST_ENTRY              InInitializationOrderModuleList;
      PVOID                   BaseAddress;
      PVOID                   EntryPoint;
      ULONG                   SizeOfImage;
      UNICODE_STRING          FullDllName;
      UNICODE_STRING          BaseDllName;
      ULONG                   Flags;
      SHORT                   LoadCount;
      SHORT                   TlsIndex;
      LIST_ENTRY              HashTableEntry;
      ULONG                   TimeDateStamp;
    
    } LDR_MODULE, *PLDR_MODULE;
    

    A chaque fois que tu appels FreeLibray sur une dll, ce compteur est décrémenté, quand il ateint 0 la dll est déchargée.

  • 13. martin  |  mars 13th, 2008 at 08:02

    Salut,
    Ca fonctionne aussi pour les oplocks?

  • 14. admin  |  mars 13th, 2008 at 13:25

    Je sais pas.

  • 15. 0xtceb  |  mai 23rd, 2011 at 08:27

    Supa reverse comme d’hab

Trackback this post