Trying to inject dll causes Win32Exception on AnyCpu or x86 configurations about bleak HOT 9 CLOSED

I am unable to replicate any of the issues you described on two computers both running the latest version of Windows 10. Furthermore, it also seems to work fine on the remote server that does my continuous integration built under AnyCpu.

I also have several people that are using this library for their own tools and they have also confirmed it is working fine for them.

I'm gonna go out on a limb here and say that ManualMapping is failing because it can't find a windows dependency (it looks in System32 for x64 and SysWow64 for x86.) As for the other injection methods, its pretty self explanatory whats happening - The library is looking for the exported method "LoadLibraryW" but failing to find it. This means one of two things - Your process for some reason doesn't have kernel32.dll loaded into it or (the most likely) your process hasn't started up fully and you are trying to inject before kernel32.dll has been loaded into it.

It may also be worth mentioning that this was all tested using the latest version of .net core (2.2)

Here is the code I used to test

var injector = new Injector();

var dllBytesX64 = File.ReadAllBytes(@"x64DllPath");

var dllBytesX86 = File.ReadAllBytes(@"x86DllPath");

// Inject into x64 process
            
injector.ManualMap("notepad", dllBytesX64);

 // Inject into x86 process
            
injector.ManualMap("Discord", dllBytesX86);

from bleak.

I'm using Windows 7
I think I found the problem but i'm not sure

ManualMap assumes all the dlls are stored in the system folder, and when it fails to get proc address via GetRemoteProcAddress, it tries to load those dlls (and when it is wrong about dll location, we get FileNotFoundException).
(the process I was injecting to was a java process and jvm.dll has a different location)
https://imgur.com/zmsoNDZ

But the reason it fails to GetRemoteProcAddress is a different problem. For some reason, calling Module32First on a x64 java process from x86 or AnyCpu program always returns false (on my machine at least), so GetRemoteProcAddress fails and ManualMap tries NtCreateThreadEx (probably with wrong dll path), when other injection methods just throw Win32Exception.

from bleak.

Those functions are looking for dependencies of the DLL you are trying to inject. The language that the process was written in shouldn't affect the ability to inject into it. Can't say I've ever seen a native DLL being dependent on jvm.dll though.

Also you are correct about it looking for the DLL in the wrong location - Since this library is specifically for native DLL injection only, dependencies for DLL's would be found in the system folder and I'm guessing that jvm.dll is part of the Java runtime, hence, it obviously isn't a system DLL and isn't present in the folder.

You haven't by any chance written your DLL that you are trying to inject using Java? As stated before, this library is specifically for injecting native DLL's (C, C++ etc) and won't work with DLL's written in managed languages.

from bleak.

Dll is written in C++. I also tried injecting the following dll to java process and get the same thing (kernel32.dll not found). As I said It seems that GetProcessModules returns empty list (Module32First returns false) when injecting to x64 java process from injector program that is compilled with x86 or AnyCpu configuration

#include <Windows.h>
#include <process.h>
void ThreadEntry(PVOID)
{
	while(true) Sleep(10000);
}

BOOL WINAPI DllMain(HINSTANCE hinst, DWORD reason, LPVOID reserved)
{
	switch (reason)
	{
		case DLL_PROCESS_ATTACH:
		{
			_beginthread(ThreadEntry, NULL, NULL);
		}
	}
	return TRUE;
}```

from bleak.

Is it possible for you to get the error code that it is failing with?

Just do this and add a breakpoint at the end of the condition.

if (!Native.Module32First(snapshotHandle, moduleEntryBuffer))
{
    var error = Marshal.GetLastWin32Error();
}

Also if you could get the value of snapShotHandle (passed into Module32First) for me it would be very useful. I have a feeling CreateToolhelp32Snapshot is failing to create a snapshot for some reason. If that's the case it should be a small fix.

from bleak.

snapShotHandle is 0xffffffff
error after CreateToolhelp32Snapshot is 299
error after Module32First is 6

from bleak.

Oh, i found
https://docs.microsoft.com/en-us/windows/desktop/api/tlhelp32/nf-tlhelp32-createtoolhelp32snapshot
it says

If the specified process is a 64-bit process and the caller is a 32-bit process, this function fails and the last error code is ERROR_PARTIAL_COPY (299).

from bleak.

If there is no other method to get modules of 64-bit process from 32-bit caller, then
I think that ValidateArchitecture.Validate should have this:
if (Environment.Is64BitOperatingSystem && !Environment.Is64BitProcess && !isWow64)
instead of this:
if (!Environment.Is64BitProcess && isWow64)
i'v opened pull request

from bleak.

Thanks for spotting this, stupid mistake on my part. Should of been !isWow64.

from bleak.