samueltulach / lighthook Goto Github PK

Hey, while overall a great and simple library, it seem to break if a target function has a nearcall (E8 ? ? ? ?) in the first 14 bytes.
Possibly also will break on jmp and cmp if relative displacement is used.
Reason being this:

The JUMP_CODE trashes the r15 register, thus causing undefined behaviour.

I would suggest using any other volatile register that is expected to be trashed anyway, such as RAX

GetInstructionSize returns wrong value for
48 81 ec d0 00 00 00 sub rsp,0xd0
returns 11, should return 7.

First off, let me say that of all the hooking libraries I tried recently LightHook is first one I got completely working. 😄

A couple issues regarding compiling, but I may file separate issues for those.
(Mainly in regard to -Wall -Werror and could not get around those with clang++)
Also, no arm, arm64 or risc-v support, but I may have a friend help me get LightHook working with those architectures.

I was able to compile with g++ -Wall -Werror -Os -std=gnu++17 -Wno-pointer-arith -Wno-error=parentheses -Wno-parentheses -Wno-error=sign-compare -Wno-sign-compare and that is how I noticed that PlatformFree was never being called (as I got an error about that, and was not going to disable that warning/error).

I'm using this with Free Pascal (FPC) and there was no way it could import LightHook.h (without major surgery) so I did not bother, I just wrote a wrapper C unit and created a much smaller header file that FPC could import.

In my wrapper I'm calling PlatformFree immediately after DisableHook.

Despite functions I tried hooking not being C compatible as far as calling, LightHook had no problem hooking them.

So, should I be calling PlatformFree immediately after DisableHook each time? I noticed I could enable and disable more than once and it performed as expected.

Hey, When using LightHook on MSVC and WindowsSDK source cannot be compiled because your implementation of CopyMemory conflicts with Windows SDK CopyMemory, This can simply be fixed by renaming it to something else like LHCopyMemory.

Regards

Use case: Running WinARM (from MAC using Parallels for example, or a native MSFT ARM based notebook)

Module = KERNELBASE.sys
Function = CreateFileW

pseudo code: HMODULE mod=(HMODULE)LoadLibraryA("kernelbase.sys")
void * origPtr = GetProcAddress("CreateFileW")

... use LH to "hook" and make a call to anything that gets to CreateFileW (fopen is fine, or use CreateFileW)

calling the ORIGINAL hook will crash/fault... along the lines of:

typedef HANDLE (*pfnCFW)( ...the..args...to...CFW);

HANDLE myCreateFileW( ..args ..)
{
pfnCFW orig = (pfwCFW)LH.trampoline;
return orig( .. args ..); <-- CRASH
}