5

So, I have an executable file that was made with C#, I don't have its source code but I have disassembled it with IDA, and it gave me a lot of object oriented assembly.

I've made an .exe file that injects a .dll into another .exe, and I've injected this new C++ DLL into the C# .exe, with no problems, the DLLMain is called and so...

But when I inject this DLL into a normal .exe file made with C++, I can call a function in the .exe with its memory address which I can take on IDA.

The problem is, that object oriented assembly doesn't have addresses on its function, even with the function names being disassembled.

So, is there any way I can call this function with my injected DLL on the C# .exe file?

If possible, is there a way I can use the namespace declared in the C# .exe file and all its functions and variables, even being private?

Sample disassembled code:

.namespace MyCSharpApp
{
.class public auto ansi Test extends [mscorlib]System.Object
{
  .field public value class [Microsoft.Xna.Framework]Microsoft.Xna.Framework.Vector2 pos

  .field public int32 foo
....
Toribio
  • 3,963
  • 3
  • 34
  • 48
  • It wouldn't make much sense even if it were possible to get an address -- the code is MSIL, not native. Need to spin up the CLR (and I have no idea how this would even happen). –  May 23 '11 at 20:22
  • @pst: Since the application is .NET, the CLR will be up and running. However, the particular function to be called might not be JITted yet, so your concern is valid. – Ben Voigt May 23 '11 at 21:13

2 Answers2

3

You are trying to do something tricky and I'm not perfectly clear on what it is. From your description you have at least four things:

  • Managed EXE
  • Managed DLL
  • Unmanaged EXE
  • Unmanaged DLL

some of which you have control over (i.e. source code for), and some of which don't.

You want to use a process you call "injecting" to change a module you don't have control over to call a module you do have control over. In order to do this you are using a tool that requires you to have an unmanaged entry point in the address space of the process.

If you are getting what you want with unmanaged modules, then all you need to do is write a new mixed-mode module (over which you obviously have control) to call the managed DLL that you don't control. Now you effective have an unmanaged DLL (for export purposes) and the problem of it being managed has gone away.

To call managed code from your new unmanaged wrapper module, you can use the techniques described in this introductory article:

Basically you need a C++/CLI project that references your black-box managed DLL and calls it and exports an unmanaged entry point that you can "take the address of" for your injection. Searching will find you a whole lot more ideas.

Finally, can you call private methods in the managed DLL (over which you have no control) using this method? No, not directly. However, its a managed DLL so it must have some public entry points to have ever been useful to anybody and you can call those. If that's not enough, you can use reflection from C++/CLI to call private methods and access private members.

Rick Sladkey
  • 33,988
  • 6
  • 71
  • 95
1

You'll need to use the unmanaged hosting/debugging APIs. If you could inject a managed DLL, this would be much easier, you could just use Reflection.

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
  • I've tried to inject a managed DLL, it compiled well, but, I just can't start my threads on the DllMain, because it gives me an error at runtime: `"Attempt to use MSIL code from this assembly during native code initialization"` (even though I'm not using MSIL code at initialization), but I have to use DllMain, because the target .exe doesn't call any methods in my DLL, that means I can't to anything until the .exe is entirely loaded. – Toribio May 23 '11 at 22:29
  • @Flavio: Put DllMain in a file compiled without `/clr`, and link everything together. – Ben Voigt May 23 '11 at 23:45