How to inject my dll into all user processes [Win]?

if you are looking for process injection on all of win32, then some level of 'trickery' is involved.
The shortcut are the APIs CreateRemoteThread() and VirtualAllocEx(), allowing you to allocate a thread and memory in another process. the remotely executed code *should* be relocation-independent (meaning the API addresses AND code would have to be passed down through a structure ...) but that's another thing. The remotely injected code (in this case) would then call LoadLibrary() to actually load the dll

under 9x, there are various well-docummented hacks to inject, or at least emulate, the injection of a thread. VirtualAllocEx is absent, however, there are several workarounds. First of all, look up matt pietrek's trick, the 8000000h flag trick, that, when passed on to VirtualAlloc(), will return a block of memory >0x80000000, or >2gig, therefore in shared memory region. An alternative way, but the same method, is to simply create a empty file mapping under 9x, and the address will be >2gig as well.

There are several other hacks for allocation of memory into a remote process under 9x, including some secret ordinals (which i can't quite recall right now)...

as for the actual injection part, there is a secret kernel routine under 9x, which handles the creation of a new thread under any process, which is internally called by DebugActiveProcess(). it's just a hint, hunt around, it's easy.

Likewise, there are other undocummented APIs like CreateKernelThread(), which is sorta similar to process injection..

anyways, another way completely would be to enumerate the processes and their threads, suspend a thread, alter eip, and inject your code that way. the method involves using SetThreadContext, and the debug apis are found on all of win32. HOWEVER, OpenThread() isn't present in 9x, but there are various hacks to easily unobfuscate the address anyways. But this whole mumbo is too long to write in a post...


oh well enough rambling.

[MaRKuS-DJM]

what i think about this AppInit_DLLs:
this would make us crackers possible to write a DLL which accesses a configuration file (maybe crack.txt) with all neccessary information to inline-patch nearly every packed program (thread instantly checking on loading-time of DLL for neccessary bytes). a configuration file like this one from ASLoad:

Exe:file.exe
Mod:1
Crash:0
Patch:
Offsetriginal byteatched byte

what do you think of this? a universal inline-patcher... you don't need cracks anymore, only the neccessary bytes

[britedream]

Originally Posted by MaRKuS-DJM

what i think about this AppInit_DLLs:
this would make us crackers possible to write a DLL which accesses a configuration file (maybe crack.txt) with all neccessary information to inline-patch nearly every packed program (thread instantly checking on loading-time of DLL for neccessary bytes). a configuration file like this one from ASLoad:

Exe:file.exe
Mod:1
Crash:0
Patch:
Offsetriginal byteatched byte

what do you think of this? a universal inline-patcher... you don't need cracks anymore, only the neccessary bytes

The problem I see with that,if I understoond your idea correctly, is you need to know when to patch, many targets use the same address for different flags, while others reset flags , and set them few times.so targets are not the same.

[niom]

what about DllMain/global-var initializiation code?

i mean, if an exe is linked to a dll that contains antidebugging/whatever code in its dllmain (or global ctor-like), this code would be executed through the windows loader *before* own dlls are injected, so this could be a problem.

or i'm wrong?

and how could this be solved?

[MaRKuS-DJM]

Originally Posted by britedream

The problem I see with that,if I understoond your idea correctly, is you need to know when to patch, many targets use the same address for different flags, while others reset flags , and set them few times.so targets are not the same.

that's true. maybe it could be done through some waiting-values (for example the Module Handle dword) like it is done in diablos dUP for ASProtected apps.
the other problem your mentioned also exists for every type of loader or crack... i think it could be handled.
i got the idea of such a patcher one year before, but through the idea of patching kernel. i didn't know there's a registry value that can inject such dlls.