18 Comments

  • 1. Eloo  |  mai 26th, 2010 at 21:24

    Petite question : malgré l’ASLR, LoadLibrary a la même adresse dans le processus injecteur et dans le processus injecté ? Je vois que tu utilises cette hypothèse pour définir l’adresse de départ du thread créé.

  • 2. mxatone  |  mai 27th, 2010 at 09:27

    L’ASLR est defini au boot ce qui fait que ntdll et la plus part des dll systems auront la meme base addresse dans tous les process. (Le reste depend des dlls loader et leur ordre)

    Ca facilite la vie des devs (user ou kernel) et ca ne reduit que des tres peu la couverture de la protection car remotely tu ne connais pas la base addresse choisi au boot.

    Nice post Ivan :)

  • 3. admin  |  mai 27th, 2010 at 10:29

    Merci mx je n’aurais pas mieux répondu :]

    Pour savoir pourquoi les DLLs ne sont pas remappées aléatoirement à chaque nouveaux process je cite Windows Internals 5h:

    For DLLs, computing the load offset begins with a per-boot, systemwide value called the image bias, which is computed by MiInitializeRelocations and stored in MiImageBias. This value corresponds to the time stamp counter (TSC) of the current CPU when this function was called during the boot cycle, shifted and masked into an 8-bit value, which provides 256 possible values. Unlike executables, this value is computed only once per boot and shared across the system to allow DLLs to remain shared in physical memory and relocated only once. Otherwise, if every DLL was loaded at a different location inside different processes, each DLL would have a private copy loaded in physical memory.

  • 4. Geo  |  mai 27th, 2010 at 20:30

    Encore un bon article de notre Ivanlef0u national.

    Merci beaucoup ! En plus j’ai bien compris le code. Continue comme ça. :)

    Geo

  • 5. falken  |  mai 28th, 2010 at 02:36

    @Ivan : Ça s’appelle le prelinking sur Linux.

    Sinon article sympa :-)
    Bonne continuation

  • 6. nameless  |  mai 28th, 2010 at 15:42

    @Ivan : Tu dis : « En fait rien ne nous oblige à notifier le subsystem lorsqu’on crée un nouveau thread. »

    Ma question est : Si on ne notifie pas le subsystem lors de la création d’un thread, esque le thread

  • 7. nameless  |  mai 28th, 2010 at 15:45

    // Oups, j’ai appuyer sur entrer :(

    Ma question est : Si on ne notifie pas le subsystem lors de la création d’un thread, esque le thread peut être hidden avec certain tools ?

    Sympa ton article :)

  • 8. admin  |  mai 30th, 2010 at 11:35

    @geo Merci dude :]

    @nameless
    En fait si ce tool se base uniquement sur la liste CsrRootProces pour scanner les processes et threads (comme le csrwalker), dans ce cas oui tu pourras te cacher de cet outil.

  • 9. ninjax  |  juin 29th, 2010 at 21:45

    Ty pour cet article fort intéressant :)

    Btw ayant migré sous win7 j’ai casé windbg et les symbols, cependant pour ta commande :

    !list -x « dt nt!_CLIENT_ID @$extret-8  » poi(CsrRootProcess)+8

    Il me retourne :
    Invalid expression in poi(CsrRootProcess)+8 .

    WTF?! Problème de symboles? (j’ai choppé les retails Win7 RTM).

  • 10. admin  |  juin 30th, 2010 at 13:01

    Yo,
    Une fois que t’es dans le context de csrss, fais un ‘.reload’ ensuite ‘x /v csrss!*’ puis : ? csrss!CsrRootProcess si tout ca est bon, retente.

  • 11. bla-bla-bla-blaker  |  mars 14th, 2011 at 15:12

    Bonjour,

    Bon article comme toujours.

    Je sais bien que je suis en retard de plusieurs mois, que l’eau a coulé sous les ponts, mais c’est aujourd’hui que j’ai mon soucis.

    J’ai étudié le code, la doc msdn… mais je n’arrive pas à injecter mon bout de code sous Windows7 x64.

    Je compile évidement tout en 64bits.

    J’ai un code d’erreur retourné par VirtualProtect(…) – 487L (ERROR_INVALID_ADDRESS).

    Y’a-t-il d’autres gens confrontés au même soucis ? Ou alors ça vient de moi, j’ai loupé le « truc » du magicien….

    Cordialement.

    Blabla.

  • 12. admin  |  mars 14th, 2011 at 23:49

    Yo,
    @bla-bla-bla-blaker on voit ca par mail :)

  • 13. User-space API monitor, P&hellip  |  décembre 25th, 2012 at 23:57

    [...] http://www.codeproject.com/Articles/2082/API-hooking-revealedhttp://www.ivanlef0u.tuxfamily.org/?p=395http://0x191unauthorized.blogspot.it/2011/08/reverse-shell-through-dll-injection.html – [...]

  • 14. clique  |  avril 26th, 2013 at 06:31

    i can’t download your file, it need password what’s it????!!!

  • 15. mekhalleh  |  mai 21st, 2013 at 11:03

    Salut Ivan On a plus accès au repository ?
    J’ai testé mais il semble avoir un bug quand on liste les fonctions de ntdll.dll !

    :)

  • 16. BB  |  novembre 13th, 2013 at 21:01

    I’m getting the following error Unhandled exception at 0x000000013f2013cc in InjectDll7.exe: 0xC0000005: Access violation reading location 0x00000000fd5db1e8.

    The error is thrown on the line OriginalCsrClientCallServer = *(PDWORD)ImportAddress;

    I’m running Win7x64. Any ideas why it’s crashing there?

  • 17. BB  |  novembre 13th, 2013 at 21:06

    After a little more looking, I see I’m getting the same error as the previous poster. The failure is actually on the previous line of VirtualProtect. The GetLastError() shows 487…which is invalid address.

  • 18. BB  |  novembre 13th, 2013 at 21:16

    By the way…this is very nice. I’ve never seen this technique before. Great job!

Trackback this post