Hello, some bugs, really can't handle. Please consult me.

[GitHubHengheng]

I used airhv as Lib, and when I loaded hyperhide, I also ran airhv.

In the virtual machine win10-1703 test, running for a long time, there will be two problems:

Here's a scenario:

win32kfull! AllocateHidData+0xbd

nt! KiSystemServiceCopyEnd+0x13 (TrapFrame @ ffffae01`ec27bb00)

win32u! NtUserFindWindowEx+0x14

USER32! FindWindowW+0xb3

In this case, the location of AllocateHidData+db in windbg is int 3

win32kfull! AllocateHidData+0xb0:

fffff9637e40252e ebe3 jmp win32kfull! AllocateHidData+0x9f (fffff9637e402513)

fffff963`7e402530 cc int 3

fffff963`7e402531 cc int 3

fffff963`7e402532 cc int 3

My understanding is that you enter the kernel by calling NtUserFindWindowEx, and you jump through ept_hook to the address of int 3,

Another problem is:

nt! DbgBreakPointWithStatus

nt! KiBugCheckDebugBreak+0x12

nt! KeBugCheck2+0x922

nt! KeBugCheckEx+0x107

nt! KiBugCheckDispatch+0x69

nt! KiSystemServiceHandler+0x7c

nt! RtlpExecuteHandlerForException+0xd

nt! RtlDispatchException+0x404

nt! KiDispatchException+0x1f6

nt! KiExceptionDispatch+0xce

nt! KiPageFault+0x217 (TrapFrame @ ffffae01`f196d1e0)

win32kfull! GetWindowBordersWithDpiAwareness

win32kfull! xxxInitSendValidateMinMaxInfoEx+0xb2

win32kfull! xxxAdjustSize+0x64

win32kfull! xxxCreateWindowEx+0xf4e

win32kfull! NtUserCreateWindowEx+0x557

nt! KiSystemServiceCopyEnd+0x13 (TrapFrame @ ffffae01`f196db00)

win32u! NtUserCreateWindowEx+0x14

USER32! CreateWindowExW+0x9aa

Page exception blue screen appears, May I ask if these will appear when you test? In win7, hang up when quite normal.

[GitHubHengheng]

The problem is found, but there is no solution for the time being.

In the case of int 3, when the CodeCaves address is executed, the address property becomes executable (at the beginning of the hook page, the property is not executable), and then the ept is not produced, and int 3 is executed.

[GitHubHengheng]

After testing, it was found that in the case of multi-core cpus, bugs will appear. Single-core runs without bugs.

I am not very good at technology, after studying your code, describe the logic of your ept hook:

When the system executes NtUserFindWindowEx, the vmexit_ept_violation event is triggered, and then the system executes fake_page_contents, jmp to the CodeCaves address, The CodeCaves address then triggers the vmexit_ept_violation event, and the HookedNtContinue address is executed.

I was in a virtual machine, running on one cpu, without a hang up for 40 minutes, with no problems. But with multicore cpus, if you hang it up for a period of time (less than 40 minutes), this will happen:

When the system executes NtUserFindWindowEx, the vmexit_ept_violation event is triggered, and then the system executes fake_page_contents, jmp to the CodeCaves address, and then the CodeCaves address becomes executable, The int 3 instruction that executes the CodeCaves address appears.

The address of the hooked CodeCaves is as follows:

[HookNtSyscall] KernelCodeCaves[1] = fffff8031ec0686d

[HookNtSyscall] KernelCodeCaves[2] = fffff8031ec0760e

[HookNtSyscall] KernelCodeCaves[3] = fffff8031ec077c1

[HookNtSyscall] KernelCodeCaves[4] = fffff8031ec0830d

[HookNtSyscall] KernelCodeCaves[5] = fffff8031ec08931

[HookNtSyscall] KernelCodeCaves[6] = fffff8031ec097d0

[HookNtSyscall] KernelCodeCaves[7] = fffff8031ec098ef

[HookNtSyscall] KernelCodeCaves[8] = fffff8031ec0b512

[HookNtSyscall] KernelCodeCaves[9] = fffff8031ec0b63e

[HookNtSyscall] KernelCodeCaves[10] = fffff8031ec0cc3f

[HookNtSyscall] KernelCodeCaves[11] = fffff8031ec111ef

[HookNtSyscall] KernelCodeCaves[12] = fffff8031ec11af1

[HookNtSyscall] KernelCodeCaves[13] = fffff8031ec11c00

[HookNtSyscall] KernelCodeCaves[14] = fffff8031ec11db1

[HookNtSyscall] KernelCodeCaves[15] = fffff8031ec120be

[HookNtSyscall] KernelCodeCaves[16] = fffff8031ec12abd

[HookNtSyscall] KernelCodeCaves[17] = fffff8031ec12b5d

[HookNtSyscall] KernelCodeCaves[18] = fffff8031ec13380

[HookNtSyscall] KernelCodeCaves[19] = fffff8031ec13cbc

[HookNtSyscall] KernelCodeCaves[20] = fffff8031ec13f7c

[HookNtSyscall] KernelCodeCaves[21] = fffff8031ec14add

[HookNtSyscall] KernelCodeCaves[22] = fffff8031ec14c7e

[HookWin32kSyscall] Win32kCodeCaves[1] = fffff9637e401b2c

[HookWin32kSyscall] Win32kCodeCaves[2] = fffff9637e402531

[HookWin32kSyscall] Win32kCodeCaves[3] = fffff9637e4027de

[HookWin32kSyscall] Win32kCodeCaves[4] = fffff9637e4036ad

Most bugs appear in the Win32kCodeCaves address. If it appears in a KernelCodeCaves, a page exception blue screen appears.

hook Win32kCodeCaves address information at the beginning of execution

1: kd> ! pte fffff9637e4036ad

VA fffff9637e4036ad

PXE at FFFFBE5F2F97CF90 PPE at FFFFBE5F2F9F2C68 PDE at FFFFBE5F3E58DF90 PTE at FFFFBE7CB1BF2018

contains 0000000000000000

contains 0000000000000000

not valid

After a while

1: kd> ! pte fffff9637e4036ad

VA fffff9637e4036ad

PXE at FFFFBE5F2F97CF90 PPE at FFFFBE5F2F9F2C68 PDE at FFFFBE5F3E58DF90 PTE at FFFFBE7CB1BF2018

contains 0A0000000E8D2863 contains 0A00000003DDD863 contains 0A00000104D40863 contains 010000000F5DD001

pfn e8d2 ---DA--KWEV pfn 3ddd ---DA--KWEV pfn 104d40 ---DA--KWEV pfn f5dd -------KREV

And KernelCodeCaves always do,

1: kd> ! pte fffff8031ec0cc3f

VA fffff8031ec0cc3f

PXE at FFFFBE5F2F97CF80 PPE at FFFFBE5F2F9F0060 PDE at FFFFBE5F3E00C7B0 PTE at FFFFBE7C018F6060

contains 0000000000A09063 contains 0000000000A0A063 contains 000000013B4009E3 contains 0000000000000000

pfn a09 ---DA--KWEV pfn a0a ---DA--KWEV pfn 13b400 -GLDA--KWEV LARGE PAGE pfn 13b40c

I have some suspicion that it is the swap_pml1 problem in the function: vmexit_ept_violation_handler. I tried to deal with it, but it did not work.

Finally, for technical reasons, no more information can be analyzed at this time. If the author has time, please take a look at my message and give me a hint on where to analyze the bug, and, even better, the results of the fix.

[Air14]

Most likely, this is the same problem as in HyperDbg. I'll try changing the code so that each core has its own ept structure, and then see if that fixes the problem, but I'm betting it will.

[Air14]

Fixed in commit 31253da586b8b0f9de3f65d4c34e642f38d4dd5e

[GitHubHengheng]

Thank you, thank you very much to share.