3 ms·

It's been a while since I looked at this (or at Windows, for that matter), but back in the day one thing that consistently failed for these approaches were thre

It's been a while since I looked at this (or at Windows, for that matter), but back in the day one thing that consistently failed for these approaches were thread initialization - after you load a DLL, every new thread gets a call to DllMain with reason DLL_THREAD_ATTACH; You can hook CreateThread and friends, but some threads are not created through those but rather through native APIs. I don't remember the details, but ... I do remember failing to find a working solution (myself or in any of the projects I checked at the time).

metroholografix 7y ago
https://docs.microsoft.com/en-us/windows/desktop/api/libloaderapi/nf-libloaderapi-disablethreadlibrarycalls https://docs.microsoft.com/en-us/windows/desktop/api/libload...
- beagle3 7y ago
  This tells how to stop it from happening. But my problem was that I needed it to happen (e.g. if using msvcrt) and having no way to do so for DLLs “manually” loaded from memory.
  - metroholografix 7y ago
    One way is to use the Windows library loader and simply trick it to load a DLL from memory rather than disk. If you use a method that completely bypasses the OS loader, then you have to do a lot more work to have your DLL behave like a DLL loaded by the OS would.
    - beagle3 7y ago
      How do you trick the loader to load from memory?
      - metroholografix 7y ago
        There are many ways but the one I chose is in my presentation that I linked above. Roughly, first you get an idea of the system calls involved when a DLL is loaded. Then you hook the system calls that are responsible for mapping/reading in order to redirect them to a memory buffer. Conceptually, it's straightforward. The devil is in the implementation details as they say.
        beagle3 7y ago
        I see. Thanks. I was under the impression you needed to have some non-trivial tokens to patch NtDll in a way that kernel32 would use (which would make it unusable as a general technique), but it's been ages and I'm probably misremembering.

metroholografix 7y ago

https://docs.microsoft.com/en-us/windows/desktop/api/libloaderapi/nf-libloaderapi-disablethreadlibrarycalls https://docs.microsoft.com/en-us/windows/desktop/api/libload...

beagle3 7y ago
This tells how to stop it from happening. But my problem was that I needed it to happen (e.g. if using msvcrt) and having no way to do so for DLLs “manually” loaded from memory.
- metroholografix 7y ago
  One way is to use the Windows library loader and simply trick it to load a DLL from memory rather than disk. If you use a method that completely bypasses the OS loader, then you have to do a lot more work to have your DLL behave like a DLL loaded by the OS would.
  - beagle3 7y ago
    How do you trick the loader to load from memory?
    - metroholografix 7y ago
      There are many ways but the one I chose is in my presentation that I linked above. Roughly, first you get an idea of the system calls involved when a DLL is loaded. Then you hook the system calls that are responsible for mapping/reading in order to redirect them to a memory buffer. Conceptually, it's straightforward. The devil is in the implementation details as they say.
      - beagle3 7y ago
        I see. Thanks. I was under the impression you needed to have some non-trivial tokens to patch NtDll in a way that kernel32 would use (which would make it unusable as a general technique), but it's been ages and I'm probably misremembering.