I am attempting to hook a 32bit test process with a 32bit dll and injector, just like in the native c++ beep tutorial, but i am getting the error code -1073741582 with the error Unable to find the required native entry point in the given 32-bit library.
I have followed the tutorial exactly and clearly have the entry point defined in the dll:
extern "C" void __declspec(dllexport) __stdcall NativeInjectionEntryPoint(REMOTE_ENTRY_INFO * inRemoteInfo);
void __stdcall NativeInjectionEntryPoint(REMOTE_ENTRY_INFO *inRemoteInfo)
{
...etc
}
If i compile everything to 64 bit instead, and move the dll path to the 64bit library path argument in
RhInjectLibrary, it is capable of injecting into a 64bit process
I dont see the reason why it is unable to find the entry point in the 32bit version since i followed the tutorial exactly, and the exact same code works for 64bit
With EasyHook, can i hook keys on a specific keyboard?
I'm using C#
@Acidical are you using latest NuGet? The issue is probably related to what the export name ends up in 32-bit e.g. _NativeInjectionEntryPoint@4 . Check the export name using one of many dll export tools out there
@ronsig_gitlab are you certain that the code you have written in Target.cpp actually results in calling those underlying APIs?
@ronsig_gitlab have you attempted debugging and setting break points in the hook handler?
@Acidical to clarify, in 32-bit mode the native export is assumed to be _NativeInjectionEntryPoint@4 . I'm adding support for this to be changed in a .def EXPORTS section to NativeInjectionEntryPoint just in case.
I have checked the 32bit dlls export and it seems to be correct
And i am using a version i built myself from the github develop branch, ill try rebuilding with your new commit and see if it fixes the issue
Just read your commit and it does seem that would fix it, ill build it now
@ronsig_gitlab not sure sorry. My approach to dealing with needing to have reliable notification or IO is to write a file system filter driver. You could try hooking if you can get the address and know the calling convention, otherwise you could look at using something like API monitor to see if there is another API being used there somewhere that is suitable.
@Qibbi The only incompatibility that I have identified so far is no .NET remoting. My plan is to remove any inbuilt IPC (use MMF or names pipes if something is still required internally), and provide examples using other ipc solutions. Removing reliance on .net remoting actually won’t be that hard. I just have to find the time :)
why
anyone here?
sometimes there is down time so maybe in your region? https://www.githubstatus.com/
@spazzarama , FYI, i'm back to the grind and re-looking at formatting C#/C++ and this issue: EasyHook/EasyHook#275
impressive to see one 5 years old still getting updates
@rasta-mouse not really sorry, the driver is intended for kernel mode hooking, so probably not quite what you are after in that instance. People have certainly got it workjng but i dont support it as it is a fairly advanced topic within an already advanced topic. If you need a driver for the create process notify i would look at how to create a file system filter driver - this should give you the low level access you are after.
@spacehamster no pull request, this is the related issue: EasyHook/EasyHook#8
and. show me dbgheap error
if it was my fault?
Call Stack:
EasyHook32.dll!542a3be6() 未知
[下面的框架可能不正确和/或缺失，没有为 EasyHook32.dll 加载符号]
EasyHook32.dll!542a440d() 未知
EasyHook32.dll!542a43aa() 未知
EasyHook32.dll!542a6299() 未知
EasyHook32.dll!5429e567() 未知
EasyHook32.dll!5428dea9() 未知
EasyHook32.dll!54290d32() 未知
EasyHook32.dll!54291451() 未知
KPHookDll.dll!doHook() 行 49 C++
KPHookDll.dll!DllMain(HINSTANCE__ * hModule=0x544e0000, unsigned long ul_reason_for_call=1, void * lpReserved=0x00000000) 行 21 C++