[C#] Managed Dll Injection

[streppel]

Heya,

currently i'm working on the injection part of my bot, but i just ran into some troubles i can't fix.

void StartTheDotNetRuntime()
{
ICLRRuntimeHost *pClrHost = NULL;
HRESULT hr = CorBindToRuntimeEx(NULL, L"wks", 0, CLSID_CLRRuntimeHost,IID_ICLRRuntimeHost, (PVOID*)&pClrHost);
hr = pClrHost->Start();
DWORD dwRet = 0;
hr = pClrHost->ExecuteInDefaultAppDomain(L"MyDll.dll",L"Class1.MyHook", L"StartUp", L"param", &dwRet);   
}

So this is my c++ dll,it injects just fine and starts the function, but does not load the MyDll.dll at all.(it's not in the module list) The MyDll.dll hast a strong name and is in the same folder as the injector and the c++ dll.

Am i missing any step to make this work? Do i have to inject the managed dll before doing it with the c++ one?

Thank you really much

Streppel

[Cromon]

Where do you run the StartTheDotNetRuntime function? In DllMain? What about checking the HRESULT's?

[streppel]

yes in DllMain when attached to the process. i'll check the HRESULT now(why didn't i already do this? cO)

[Cromon]

You shouldnt do anything complex in the DllMain as its in the loaderlock. You will most likely get a deadlock. Loading the CLR makes a deadlock 100%. See here:

Does creating a thread from DllMain deadlock or doesn't it? - The Old New Thing - Site Home - MSDN Blogs
Another reason not to do anything scary in your DllMain: Inadvertent deadlock - The Old New Thing - Site Home - MSDN Blogs
Some reasons not to do anything scary in your DllMain - The Old New Thing - Site Home - MSDN Blogs
How you might be loading a DLL during DLL_PROCESS_DETACH without even realizing it - The Old New Thing - Site Home - MSDN Blogs

[streppel]

Thanks for the links,i'll have a look at them.
a question about the deadlock: i'm injecting the dll via createremotethread. if i'd run into the deadlock, would it just be the thread locking then or the whole application?

AND: how would i do it better? My c++ is not very good(that's why i'm wanting to use the language i know aka c#) and currently i wouldn't know about any way to go around this problem.

thanks again
Streppel

[adaephon]

One way to do it is to provide your StartTheDotNetRuntime method as an exported method. You then inject your C/C++ dll (doing pretty much nothing in DllMain) and then create a second remote thread after you have successfully injected to call the export.

A while ago I released an injector for .NET and it allowed you to call exports in the injected DLL. Check it out here if you're interested: http://www.mmowned.com/forums/world-...-injector.html. I haven't updated it in a while but it should still work. Feel free to ask any questions about it.

Alternatively, Cypher's Hades library is great for this sort of stuff, but it's in C++ so if you're not familiar with it it might be a bit of a learning curve.

[Bananenbrot]

I'm currently working on a 'clean' injector too.
In my first attempt I hardly failed at hosting the CLR inside DllMain just like you, which is a little tedious and requires us to spawn a second remotethread.
I found it a little awkward to spawn 2 remotethreads only for injecting the CLR assembly, so now I'm going with SetWindowsHookEx to inject the bootstrap dll.
As I'm only beginning injection I really don't have a clue regarding warden and API hook detection, but getting the work done without even have to spawn a remotethread and risk concurrency issues sounds good to me.
Windows via C/C++ is your reference for injecting native dll's and for dll's in general.

adaephon's injector should really well do the job for you if you don't want to dig deeper into that stuff. Otherwise I would suggest to look at Cypher's HadesMem injector.

[streppel]

One way to do it is to provide your StartTheDotNetRuntime method as an exported method. You then inject your C/C++ dll (doing pretty much nothing in DllMain) and then create a second remote thread after you have successfully injected to call the export.

A while ago I released an injector for .NET and it allowed you to call exports in the injected DLL. Check it out here if you're interested: http://www.mmowned.com/forums/world-...-injector.html. I haven't updated it in a while but it should still work. Feel free to ask any questions about it.

Alternatively, Cypher's Hades library is great for this sort of stuff, but it's in C++ so if you're not familiar with it it might be a bit of a learning curve.

thanks for your answer
i tested your injector but it doesn't seem to change anything.

seems like i'd have to go the way for a 2nd thread that then start the CLR

[adaephon]

Look at the example included dll (Stub) and the Tester project. Injectnyour dll and make sure it does nothing in dll main (or at least doesn't start runtime). Create an exported function that calls your start runtime method (or export that). Use the injector to call that exported function. Can't show code from phone ATM but it's all there in tester program

[streppel]

Look at the example included dll (Stub) and the Tester project. Injectnyour dll and make sure it does nothing in dll main (or at least doesn't start runtime). Create an exported function that calls your start runtime method (or export that). Use the injector to call that exported function. Can't show code from phone ATM but it's all there in tester program

Ok so i just did another try:
the dll gets injected(the c++),the exported function gets called correctly, and then nothing happens.... so it's about the CLR not starting correctly or the dll not being loaded correctly...

[Cromon]

What are the HRESULTs saying?

[streppel]

is there any better way then

::MessageBox(NULL, (LPCWSTR)hr, (LPCWSTR)hr, MB_OK);

to get the hr value?

[mnbvc]

write it to a file

[streppel]

write it to a file

great idea,wasn't too hard either

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

it executes until this line,not further
anything behind this was not executed... :/

EDIT:
i got good and bad news:
good news: the dll gets injected now, but has to be placed in the programs application folder.(in the folder of the game) how would i get around this?
bad news: the method doesn't get executed(StartUp in this case). why would this be?

thanks again

[Cypher]

It's because you're using a relative path and the working dir of the game is obviously it's app folder.

You need to use an absolute path.

e.g. Rather than Inject("MyHax.dll") you need Inject("C:/Foo/MyHax.dll").

Alternatively, you could modify the current working directory, but that's nasty because it opens up a whole bunch of potential race condition bugs. Just use absolute paths.

Easiest way to do that is to have your injector get the path to itself, then go up one level (removing the name of the injector) and append the name of your DLL.

Here's a C++ example, probably not much help to you, but I'm sure you get the idea:

    // Get path to self (directory)
    inline boost::filesystem::wpath GetSelfDirPath()
    {
      // Get self
      HMODULE const ModMe(reinterpret_cast<HMODULE>(&__ImageBase));

      // Get path to self
      DWORD const SelfPathSize = MAX_PATH;
      std::wstring SelfFullPath;
      if (!GetModuleFileName(ModMe, Util::MakeStringBuffer(SelfFullPath, 
        SelfPathSize), SelfPathSize))
      {
        DWORD LastError = GetLastError();
        BOOST_THROW_EXCEPTION(HadesError() << 
          ErrorFunction("GetSelfDirPath") << 
          ErrorString("Could not get path to self.") << 
          ErrorCodeWin(LastError));
      }

      // Path to self dir
      auto const SelfDirPath(boost::filesystem::wpath(SelfFullPath).
        parent_path());
      return SelfDirPath;
    }