none
Injecting a DLL into a Target Process VB.NET RRS feed

  • Question

  • Hey All,

    I recently wrote a quick VB.NET app that injects a DLL into a running process. To test it I was creating my own vb.net Class Library project which simply spawns a "Hello World" message box in hopes of it showing up in the target process once I injected my HelloWorld.DLL.

    My problem is that the message box never shows up after I inject the HelloWorld.DLL. I'm pretty sure the reason for this is because once my HelloWorld.DLL is injected (since it's a VB.NET DLL) it does not have a DllMain and hence has no idea what to execute and nothing happens.

    Do I have to make my injection DLL in C++ so it has a DllMain? Is there a way to make a VB/C# .NET DLL behave like a DLL with a DllMain? Or am I completely wrong about everything.

    Any insight would be greatly appreciated. Thanks.

    Tuesday, February 22, 2011 3:01 AM

Answers

  • It's a VERY bad idea to try to do anything complicated in DLLMain. Running managed code is a real no-no - see here: http://msdn.microsoft.com/en-us/library/aa290048(v=vs.71).aspx

    Instead, it's probably best to create your own entry point in the DLL which takes an LPCWSTR and returns an int, much like LoadLibrary() does, note that you can get away with any int returning function that takes a single pointer as this is valid as a thread start function and that's the important thing. You then inject your dll in the normal way, by creating a remote thread and calling load library, etc, and you do absolutely nothing clever in the injected DLL's DllMain(). You then use the same steps (create a memory buffer in the target process, load it with something useful if necessary and then call create remote thread) to call your own entry point.

    Your entry point is then responsible for running your injected DLL's start up code. This ensures that the start up code is called after the loader lock has been released and it's therefore safe to do anything you want.

    IMHO doing it any other way is asking for trouble.

    I go into a little more detail about this here: http://stackoverflow.com/questions/1162050/createremotethread-loadlibrary-and-postthreadmessage-whats-the-proper-ipc-met/1163681#1163681 

    • Marked as answer by Paul Zhou Tuesday, March 1, 2011 2:51 AM
    Tuesday, February 22, 2011 8:34 AM

All replies

  • What do you mean by injecting DLL into a running process? Which API did you call?

    It is a very bad idea to do complex things in your DllMain - for example do not run managed code in there.

    -Karel

    Tuesday, February 22, 2011 6:51 AM
    Moderator
  • It's a VERY bad idea to try to do anything complicated in DLLMain. Running managed code is a real no-no - see here: http://msdn.microsoft.com/en-us/library/aa290048(v=vs.71).aspx

    Instead, it's probably best to create your own entry point in the DLL which takes an LPCWSTR and returns an int, much like LoadLibrary() does, note that you can get away with any int returning function that takes a single pointer as this is valid as a thread start function and that's the important thing. You then inject your dll in the normal way, by creating a remote thread and calling load library, etc, and you do absolutely nothing clever in the injected DLL's DllMain(). You then use the same steps (create a memory buffer in the target process, load it with something useful if necessary and then call create remote thread) to call your own entry point.

    Your entry point is then responsible for running your injected DLL's start up code. This ensures that the start up code is called after the loader lock has been released and it's therefore safe to do anything you want.

    IMHO doing it any other way is asking for trouble.

    I go into a little more detail about this here: http://stackoverflow.com/questions/1162050/createremotethread-loadlibrary-and-postthreadmessage-whats-the-proper-ipc-met/1163681#1163681 

    • Marked as answer by Paul Zhou Tuesday, March 1, 2011 2:51 AM
    Tuesday, February 22, 2011 8:34 AM