[C#] Managed Dll Injection

[Xarg0]

Btw it's way easier to just create a new thread in DllMain then to call your dlls exports using another remote thread, and it is saving you from using a special injector.
I don't get who came up with the idea of calling exports of an injected module using remote threads, but doing something like this is completly retarded if you can just setup threads in DllMain, and ofcourse don't wait for the threads to return in DllMain, that would cause yet another deadlock.

[Cypher]

Btw it's way easier to just create a new thread in DllMain then to call your dlls exports using another remote thread, and it is saving you from using a special injector.
I don't get who came up with the idea of calling exports of an injected module using remote threads, but doing something like this is completly retarded if you can just setup threads in DllMain, and ofcourse don't wait for the threads to return in DllMain, that would cause yet another deadlock.

You seem to be missing the fact that you're not supposed to create threads in DllMain...

DLL Dynamic Link Library Best Practices

You should never perform the following tasks from within DllMain:
Call LoadLibrary or LoadLibraryEx (either directly or indirectly). This can cause a deadlock or a crash.
Synchronize with other threads. This can cause a deadlock.
Acquire a synchronization object that is owned by code that is waiting to acquire the loader lock. This can cause a deadlock.
Initialize COM threads by using CoInitializeEx. Under certain conditions, this function can call LoadLibraryEx.
Call the registry functions. These functions are implemented in Advapi32.dll. If Advapi32.dll is not initialized before your DLL, the DLL can access uninitialized memory and cause the process to crash.
Call CreateProces. Creating a process can load another DLL.
Call ExitThread. Exiting a thread during DLL detach can cause the loader lock to be acquired again, causing a deadlock or a crash.
Call CreateThread. Creating a thread can work if you do not synchronize with other threads, but it is risky.
Create a named pipe or other named object (Windows 2000 only). In Windows 2000, named objects are provided by the Terminal Services DLL. If this DLL is not initialized, calls to the DLL can cause the process to crash.
Use the memory management function from the dynamic C Run-Time (CRT). If the CRT DLL is not initialized, calls to these functions can cause the process to crash.
Call functions in User32.dll or Gdi32.dll. Some functions load another DLL, which may not be initialized.
Use managed code.

Yes, most of the time it will work, but it's still dangerous (for obvious reasons -- think: race condition on unmap because of pe loader 'failure').

[streppel]

thanks again for your answers. now the only problem left would be, that it does not start the "StartUp" method as it it intended to.
how would i get around this?
that the dll looks for the managed dll in the application folder makes sense when thinking that it runs as part of the game right after is has been injected, but i'll get some way around this.(The example was good btw,thx again )

EDIT: did it with the injector mentioned in this thread before. calling an exported function with an argument(the argument here is the path+dll name like Directory.GetCurrentDirectory() + "\\MyHook.dll"; as the c# program knows where it is and in the same folder the other files are,so this is the perfekt solution for me )

only thing still left now is to make it run the StartUp method

[Cypher]

You need to call your export yourself.

If your injector does not support calling remote exports then you'll need to add that or use one that does.

Basically you just need to load the DLL locally (as data, so no code is run), get the address of the export, subtract the base address, take that offset, find the module in the remote process, add the offset, and call the function with a remote thread. May sound complicated but it's actually very easy.

[streppel]

You need to call your export yourself.

If your injector does not support calling remote exports then you'll need to add that or use one that does.

Basically you just need to load the DLL locally (as data, so no code is run), get the address of the export, subtract the base address, take that offset, find the module in the remote process, add the offset, and call the function with a remote thread. May sound complicated but it's actually very easy.

what you wrote actually doesn't sound too complicated(getting the difference in my own process,using it in the other process,makes sense )

but now i don't understand what

hr = pClrHost->ExecuteInDefaultAppDomain(L"MyDll.dll",L"Class1.MyHook", L"StartUp", L"param", &dwRet);

is supposed to do. ofc it loads the dll, but what does it do with the namespace/class/method information then?

[Cypher]

what you wrote actually doesn't sound too complicated(getting the difference in my own process,using it in the other process,makes sense )

but now i don't understand what

hr = pClrHost->ExecuteInDefaultAppDomain(L"MyDll.dll",L"Class1.MyHook", L"StartUp", L"param", &dwRet);

is supposed to do. ofc it loads the dll, but what does it do with the namespace/class/method information then?

Cool, it actually shouldn't sound complicated at all, but you'd be surprised how much some people struggle to grasp the basics around here.

And ****, my bad, I thought 'Startup' was the export in your DLL that you were injecting to bootstrap the CLR. Sorry, I was skim-reading the thread because I was leaving to go for a swim.

I'm about to have lunch, but if nobody has helped you by the time I get back and have some spare time to answer then I'll sort it out.

[Xarg0]

and you're not supposed to inject dlls into a running process, well anyways I still don't understand why calling an exported function by injecting a code stub and creating a remotethread should be more safe to do then to create a thread from within dll main, I mean if DllMain is executed the dll is already loaded, so I don't quite understand what you mean by pe loader failure.
So could you please elaborate in detail why calling a dlls export from a remote thread is more secure then doing your stuff in a thread created from dllmain?

[Cypher]

and you're not supposed to inject dlls into a running process, well anyways I still don't understand why calling an exported function by injecting a code stub and creating a remotethread should be more safe to do then to create a thread from within dll main, I mean if DllMain is executed the dll is already loaded, so I don't quite understand what you mean by pe loader failure.
So could you please elaborate in detail why calling a dlls export from a remote thread is more secure then doing your stuff in a thread created from dllmain?

Bzzt. Wrong. DLL injection is required for quite a few legitimate things. The most obvious/common being windows hooks and window subclassing. DLL injection is part of programming for Windows, it is NOT some 'low level hacker tool' or w/e you seem to be implying it is.

As for why calling an export is safer than using DllMain. First off, it's documented as dangerous, isn't that enough for you? However, to elaborate on my previous point, it's been a while since I've looked at that portion of the PE loader, but last time I checked I'm pretty sure there are some conditions that can cause the DLL to be unloaded by the PE loader after DllMain returns, if this is the case, then you'll have a nasty race condition on your hands. However, as I can't confirm that right now I'll withdraw it.

The fact that Microsoft say "don't create threads in DLLMain" should be more than enough justification for the use of exports.

EDIT:

Heck, there's an entire chapter on DLL injection in the book 'Programming Windows via C/C++'.

[adaephon]

@streppel at work ATM and can't check this or your code that well (eww iPhone). But it looks like you might not be using fully qualified class name ie L"Class1.MyHook" should be L"Namespace1.Class1.MyHook".

Also if you're intending to use .NET 4.0 you are using outdated hosting Apis and will have to update your code to use the new ones

[streppel]

i switched back to .NET 3.5 for this reason,so it's not because of this

i'll try what you said

edit: i'm doing it the way you said. Class1 is my namespace, MyHook is my class and StartUp is my method

[caytchen]

i switched back to .NET 3.5 for this reason,so it's not because of this

i'll try what you said

edit: i'm doing it the way you said. Class1 is my namespace, MyHook is my class and StartUp is my method

Not quite sure what step you're at right now. Is it loading the CLR but not calling StartUp from your assembly?
Make sure StartUp has the signature given on the MSDN "static int pwzMethodName (String pwzArgument)" and check the HRESULT.

If you're still looking to call your exported function that is supposed to load the CLR, find the module and GetProcAddress will lead your way from there.

[streppel]

Not quite sure what step you're at right now. Is it loading the CLR but not calling StartUp from your assembly?
Make sure StartUp has the signature given on the MSDN "static int pwzMethodName (String pwzArgument)" and check the HRESULT.

If you're still looking to call your exported function that is supposed to load the CLR, find the module and GetProcAddress will lead your way from there.

i love you,it works...i had the function be a void....as an int it works just fine
you will get the rep as soon as i can give some again