HookLib icon indicating copy to clipboard operation
HookLib copied to clipboard

hook failed with DbgkpCloseObject

Open LYingSiMon opened this issue 2 years ago • 1 comments

nt!DbgkpCloseObject:
fffff804`566493f0 4983f901        cmp     r9,1
fffff804`566493f4 0f87fb000000    ja      nt!DbgkpCloseObject+0x105 (fffff804`566494f5)
fffff804`566493fa 488bc4          mov     rax,rsp
fffff804`566493fd 48895808        mov     qword ptr [rax+8],rbx
fffff804`56649401 48896810        mov     qword ptr [rax+10h],rbp
fffff804`56649405 48897018        mov     qword ptr [rax+18h],rsi
fffff804`56649409 48897820        mov     qword ptr [rax+20h],rdi
fffff804`5664940d 4156            push    r14

because of relocateBeginning() return false.

RH} $2IZ%)7{Y6WI9~JHY image

You cannot directly copy the bytecode of the jump instruction, This caused the redirect address to be incorrect

LYingSiMon avatar Nov 24 '23 12:11 LYingSiMon

The code in this repository doesn't handle assembly code with relative jumps very well. In fact, it can easily encounter problems in the kernel because you simply can't request an address that's only 2GB away from the hooked position in the kernel . So once there is a four-byte relative jump like 0x0f 0x8x xx xx xx xx, it can't relocate. image I've written a toy before that can solve this problem, https://github.com/smallzhong/kernelhook. I specifically adapted the code to handle relative jumps like 0xex xx, 0x0f 0x8x xx xx xx xx, 0xe8(0xe9) xx xx xx xx, etc., which can solve this problem. image However, my code is a toy, and it can't be used in a real production environment. In fact, the reason I wrote this toy is because I couldn't find a complete open-source repo that could adapt to these relative jumps in the kernel.

smallzhong avatar Mar 13 '24 13:03 smallzhong