Hooking WMI (.NET Application)

[aldente]

ResumeThread() has to be called with pi.hThread, that was right. The process will stay suspended, if you call it with pi.hProcess.
But apart from that, I tried your suggestions.

I also tried to start the process non-suspended, which doesn't work either...

This injection stuff is a debugging nightmare, you can't debug it in the development environment, and debugging in IDA doesn't work neither because of all this .NET stuff... :-(

Don't you have somer loader, which is known working for .NET applications?

[Ember]

Originally Posted by aldente

ResumeThread() has to be called with pi.hThread...

Sorry yes that was a typo. Are you on a x64 system? If the .NET metadata in your target executable is not marked as 32bit required then it will spawn as a 64bit process. This will result in failure. You will need to compile the DLL as a 64bit DLL to inject.

I have successfully got the DLL working in your test app, spoofing processor ID with my hook + this loader: http://code.google.com/p/injector/

Command line: newloaderv4.1.exe --lib "E:\Downloads\WmiSpoof.dll" --launch Test.exe

http://i.imgur.com/2rqsj.png

[aldente]

Yes, I am on a x64 system...

I just tried the loader you mentioned in a virtual machine (x86), but without any success either...

newloaderv4.1.exe --lib WmiSpoof_x86_StaticRuntime.dll --launch Test.exe

The loader starts Test.exe, but the loader console window stays open (nothing is shown after "Email: [email protected]").
When I close Test.exe, the loader outputs:

Error: [@InjectLibraryW] Unknown Error (LoadLibraryW).
Error: [@SuspendResumeProcess] NtResumeProcess. [NtStatus: 0xC000010A] [LastErro
r: 6]
Error: [@InjectLibraryW] Could not resume process.
Error: [@commandline_parser] Injection failed.

How did you build your DLL?
I built it Non-Unicode with static runtime ('release' mode) with MSVC 2010.
I tried other options as well, neither worked (dynamic runtime, Unicode).

Does my attached DLL work for you?

(Thanks for your patience, by the way!)

[Ember]

Yes, it works when I run the injector from administrative cmd line and modify the exe to have 32bit required in the .NET metadata header.

[aldente]

So why doesn't it work for me?

I tried to run it on Windows XP x86, as the Administrator user... No luck!

What's your version of the .NET Framework? Maybe that's the difference...

[Ember]

You are hooking a non-framework native module. I do not know what to tell you if it does not work on XP (unless you are lacking runtimes for VS2010 or something, even though it does not import it). I am on Windows 7 Ultimate x64 SP1 with all updates and it works fine, and it worked when I was on XP SP3 as well.

When I compile modules like that I link against the latest WDK libs and headers to cut down on size and importing anything from the new runtimes. It will link against msvcrt.dll instead.

Perhaps you can PM me and tell me what you want to spoof your processor ID to and I can compile one in my environment and you can try it.

[aldente]

I tested the exact same binaries on a third machine, and these are the results:

Win7 SP1 x64: Does not work
WinXP SP3 x86: Does not work
Win7 SP1 x86: Works

Strange, but now I have at least one working system. I'll do some testing to find out why it doesn't work on the other ones.

Thanks for all your help!