Hook execution is different when using Qdb

[HackingFrogWithSunglasses]

*Describe the bug When using Qdb the execution of function hooks are completely different. For example, here's a trace of a IoCreateFileEx when not using Qdb:

[=] 	1406eb79c [drv.sys              + 0x6eb79c]  ret                  
[=] 	140e45a30 [ntoskrnl.exe         + 0x615a30]  mov                  rax, rsp

[+] 	(CORE) Calling API: IoCreateFileEx with FUNC: <function hookIoCreateFileEx at 0x00000247ABE64790>
[+] 	(CORE) Calling API: IoCreateFileEx at ADDR: 140e45a30
[+] 	(CORE) RIP: 140e45a30 with: {'FileHandle': 18446734659141496464, 'DesiredAccess': 3221225472, 'ObjectAttributes': 18446734659141496512, 'IoStatusBlock': 18446734659141496472, 'AllocationSize': 0, 'FileAttributes': 0, 'ShareAccess': 3, 'Disposition': 2, 'CreateOptions': 33, 'EaBuffer': 0, 'CreateFileType': 0, 'InternalParameters': 0, 'Options': 0, 'DriverContext': 4294967304}
[+] 	Hooking: IoCreateFileEx!
[=] 	Len of buffer: 40
[+] 	(CORE) Returning at: 1407b148e with: 0
[+] 	0x140e45a30: hookIoCreateFileEx(FileHandle = 0xfffff7700003ee90, DesiredAccess = 0xc0000000, ObjectAttributes = 0xfffff7700003eec0, IoStatusBlock = 0xfffff7700003ee98, AllocationSize = 0, FileAttributes = 0, ShareAccess = 0x3, Disposition = 0x2, CreateOptions = 0x21, EaBuffer = 0, CreateFileType = 0, InternalParameters = 0, Options = 0, DriverContext = 0x100000008) = 0x0

[=] 	1407b148e [drv.sys              + 0x7b148e]  push                 0x36503b65

As you can see, when the hook is entered at 140e45a30 the hook is executed successfully and then the program returns execution to the correct address at 1407b148e.

If we observe the same trace with Qdb enabled we can see that when the hook is entered, the program continues to step through ntoskrnl.exe which subsequently crashes the emulator because of missing Windows structures.

[=] 	1406eb79c [drv.sys              + 0x6eb79c]  ret                  
[=] 	140e45a30 [ntoskrnl.exe         + 0x615a30]  mov                  rax, rsp

[+] 	(CORE) Calling API: IoCreateFileEx with FUNC: <function hookIoCreateFileEx at 0x0000027996D20940>
[+] 	(CORE) Calling API: IoCreateFileEx at ADDR: 140e45a30
[+] 	(CORE) RIP: 140e45a30 with: {'FileHandle': 18446734659141496464, 'DesiredAccess': 3221225472, 'ObjectAttributes': 18446734659141496512, 'IoStatusBlock': 18446734659141496472, 'AllocationSize': 0, 'FileAttributes': 0, 'ShareAccess': 3, 'Disposition': 2, 'CreateOptions': 33, 'EaBuffer': 0, 'CreateFileType': 0, 'InternalParameters': 0, 'Options': 0, 'DriverContext': 4294967304}
[+] 	Hooking: IoCreateFileEx!
[=] 	Len of buffer: 40
[+] 	(CORE) Returning at: 1407b148e with: 0
[+] 	0x140e45a30: hookIoCreateFileEx(FileHandle = 0xfffff7700003ee90, DesiredAccess = 0xc0000000, ObjectAttributes = 0xfffff7700003eec0, IoStatusBlock = 0xfffff7700003ee98, AllocationSize = 0, FileAttributes = 0, ShareAccess = 0x3, Disposition = 0x2, CreateOptions = 0x21, EaBuffer = 0, CreateFileType = 0, InternalParameters = 0, Options = 0, DriverContext = 0x100000008) = 0x0

[=] 	140e45a33 [ntoskrnl.exe         + 0x615a33]  mov                  qword ptr [rax + 8], rbx
[=] 	140e45a37 [ntoskrnl.exe         + 0x615a37]  mov                  qword ptr [rax + 0x10], rbp
[=] 	140e45a3b [ntoskrnl.exe         + 0x615a3b]  mov                  qword ptr [rax + 0x18], rsi
[=] 	140e45a3f [ntoskrnl.exe         + 0x615a3f]  mov  

Sample Code None.

Expected behavior When using Qdb the hooks should execute in the same way, the hooks should not enter ntoskrnl execution and should instead return straight away in the same way that they do when Qdb is not enabled.

Screenshots None.

Additional context None.

[ucgJhe]

Hmmm this is weird, Qdb normally doesn't change anything on the fly. Maybe the register context got changed accidentally. Could you trace it down and throw a PR or provide a minimal PoC to reproduce it so I can fix this.

[HackingFrogWithSunglasses]

Sure, will produce a POC and update when I can.

[ucgJhe]

Hi @HackingFrogWithSunglasses, I noticed you may runing qdb with PE format, it will be crashed due to we need to do something more when running Windows. This issue should be fixed by #1295 .