2

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 anything I can do as a work around? Or am I completely wrong about everything.

Any insight would be greatly appreciated. Thanks.

Improve this question
6
  • .net dlls aren't even PE files, they are dlls in file-extension only. Commented Feb 21, 2011 at 22:12
  • Where did you put your Hello World message box code in the dll? Commented Feb 21, 2011 at 22:12
  • and you probably shouldn't inject .NET assemblies into other processes either, you're relying on that other process not hosting a different version of the runtime. Commented Feb 21, 2011 at 22:13
  • 2
    @Blogbeard: That is not correct. .NET assemblies are in fact an extended form of PE files, see en.wikipedia.org/wiki/… Commented Feb 21, 2011 at 22:17
  • @dthorpe - i tried putting it in the Public Sub New() as well as a shared method, neither worked. Since .NET assemblies ARE infact PE files, then shouldn't there be some way to specifiy the entry point into my DLL? Commented Feb 21, 2011 at 22:21

1 Answer 1

Reset to default
3

While the .NET DLL is technically an extension of the PE format it is that extension that makes it intrinsically different to a DLL that contains pure compiled, native code. In order for the .NET code (managed code) to be run is will need to be executed by the .NET interpreter and withing the context of an AppDomain.

Essentially there is a load of stuff that .NET will do to get that code up and running.

Microsoft (bless 'em!) have written and article outlining what you need to do here http://support.microsoft.com/kb/828736

Another option is to not write pure C++ code, but instead to create a managed C++ project which will be much easier in getting the two to play nicely together. BTW having a managed C++ project doesn't mean all the code has to be managed either AFAIK

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

This didn't seem to do anything. The issue is I don't have any control over how my DLL is getting called (aka I don't have the ability to import the .tlb etc). I called LoadLibrary and loaded my .dll into the target applications memory, but the entry point is unknown to the target process.
Hi crunchy, I still stand by my first posting. You will need to understand much more about AppDomain (and a whole load of other stuff that will simply not make it worth your while to persue this - IMHO). For what it's worth check this out msdn.microsoft.com/en-us/library/….

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.