Cheat Engine

[lcineyes]

​​Should IF be set to 1 immediately after entering ring 0 via VMCALL_KERNELMODE?​

[Dark Byte]

Feel free to set IF to 1 afterwards. You're in ring0, so go ahead

This is just to protect you from unexpected interrupts that detect kernelmode running in usermode execution regions

[lcineyes]

[lcineyes]

​​Issue​​: After entering kernel mode via VMCALL_KERNELMODE, enabling interrupts (STI) leads to memory corruption (e.g., recently accessed files overwritten with zeros). Despite IRQL being 0 (PASSIVE_LEVEL), page faults are unhandled.

[Dark Byte]

[lcineyes]

1.Currently, my approach to handling Ring-3 memory access exceptions is to return to user mode via VMCALL_USERMODE, access the target memory in user space, and then re-enter kernel mode.

2.The above method cannot handle code running in kernel space.

3.I've tried using VMCALL_DISABLE_DATAPAGEFAULTS and VMCALL_ENABLE_DATAPAGEFAULTS, but they fail to prevent page faults from occurring, still resulting in BSODs.

4.When I use VMCALL_KERNELMODE to operate in kernel address space and execute KeStackAttach before returning, after several runs it causes BSODs due to page faults. Additionally, I've observed that content from some recently accessed files gets completely overwritten with zeros while the file sizes remain unchanged.

5.When a page fault triggers a blue screen, Windbg can successfully query the target memory, which leads me to suspect CR3 corruption. I'll conduct two tests and report back here:

5.1 Test without KeStackAttach​​:
Verify whether CR3 corruption still occurs when avoiding process attachment.
5.2 ​​Continuous Process Memory Access Test​​:
Check if accessing memory within the same process triggers page faults
Validate whether such faults can be handled
(Given that Ring-3 faults couldn't be handled previously, this will likely fail too)

The testing environment is VMware 17 with an i7 CPU running Windows 10.

[lcineyes]

Root Cause Identified​​:
The Windows thread scheduler doesn't preserve CR4 during context switches. Many kernel APIs trigger thread scheduling, and enabling interrupts (STI) makes the thread susceptible to preemption. When the thread resumes execution:

1.It may land on a different CPU core
2.The new core's CR4 has SMEP/SMAP enabled (not disabled like the original context)
3.This causes page faults at DISPATCH_LEVEL
4.Paradoxically, the target data pages remain resident in memory


Thank you for taking the time to answer my questions.

[Dark Byte]

Maybe you can edit the pagetable entrys your code runs in and mark it as a supervisor page before you enable interrupts