면책 조항 ( disclaimer )

I strongly inform you that this is not for game hacking purposes (the title is just to attract attention (for publicity)), but for research purposes. You are solely responsible for its use.

이는 게임 해킹 목적(제목은 단지 관심을 끌기 위한 목적(홍보용))이 아닌 연구 목적임을 강력히 알려드립니다. 그 사용에 대한 책임은 전적으로 귀하에게 있습니다.

---

I'm going to officially release a stable distribution version. Please wait a little bit !!

Also, provide instructions with API usage (with Python).

---

🖥 64Bit Windows Kernel-Based GAMEHACKING Season 2

---

Game Hacking Season 2 is now released!
This version aims to implement the maximum functionality possible with Windows kernel drivers and Hypervisor, while using JSON to make it easier for 'IOCTL' requesters (user programs) to send commands to the kernel and Hypervisor.

---

📌 Welcome

---

⚙ How It Works?

Previously, MFC was used, but now it has been replaced with an API server approach for a more user-friendly experience.
For example, a WebSocket-based API is provided, allowing access to the Windows kernel directly from Python.

Goal: Enable high-level control over the Windows kernel and Hypervisor.

In addition, the features built a year ago have been reinforced and further developed so that the kernel can interact more aggressively with user space.

---

⚙ so How can I use it?

Tip

Before running the target process, you must run driver and API server_program .

Important

1. Disabled HVCI
2. Load KernelDriver and Hypervisor(Optional) with KDUMapper
3. Execute the API_server
4. and then, you should be made a query tool (query to API SERVER in JSON format) ( Python ,, etc,, ) enjoy!
5. if you have some bug ( BSOD ), call me !

query tool ---> API SERVER ---> Windows Kernel Driver ---> Target Game EXE

Warning

The kernel driver for this project did not consider Unload. (Reboot is required.)

Disabled HVCI

A. Turn off the HVCI options

B. Using the KDU Mapper

---

🚀 Features

🔹 In Kernel

1. Kernel-Based DLL Injection
2. Memory Scan
3. Memory Write (with Force Mode)
4. Memory Dump (with Memory PAGE dump(optional) )
5. Kernel-Based Hardware Breakpoint (The VEH handler must implement the EXCEPTION_SINGLE_STEP handler.)
6. Memory ALL Scan -> value to return all datas in gave that size
7. Pointer Scan

Internal_Func_1. Get Real User_Process CR3

Internal_Func_2. APC based Async datas transfer to UserMode

---

🔹 In Hypervisor (Optional)

1. Kernel API Hooking ( AMD - NPF( NPT table Fault ) based )

---

🔹 In API Server (IOCTL Requester)

1. WebSocket API Server
2. JSON Support
3. WebServer on API Server (coming soon)

---

💡 Force Mode: Forces the memory page protection property to PAGE_EXECUTE_READWRITE.

---

📅 Updates

Note

(2025-08-29 - 13:00(UTC +09:00) ) — * "Hypervisor Level has been started!"*

Now I'm out of the kernel level, and I've written an Hypervisor level beta that works on Ring-1.

How to share data across different levels ??

There are so many different ways of doing this, but I introduce the following logic.

[ KERNEL <-> HYPERVISOR ] Using a Interrupt

When a VM-EXIT handler that supports virtualization returns a task, it deliberately generates an interrupt through the "Interrupt Vector ID" value obtained during initialization from the kernel.

"The Hypervisor must then convert the physical address that the kernel already knows to the physical address of the Hypervisor and then the virtual address of the Hypervisor to update the value."

The preregistered Interrupt handler in the kernel is then asynchronously invoked by Hypervisor.

Because it supports multi-core, the number of cores can be used as an index to refer to valid data, which can then be transmitted to Usermode via APC.'

[ KERNEL <==(1:1 mapped physical memory area)==> HYPERVISOR ] Using the Kernel Allocated Physical Addresses Area

I implemented the Host Physical Address of the hypervisor with 1:1 mapping of the Guest Physical Address of the kernel in a form that the hypervisor can refer to and write. The hypervisor is implemented to allocate no memory, and the kernel does not understand the space allocated by the hypervisor. This situation complicates the logic of releasing memory somewhat.

---

( 2025-08-27 - 08:55(UTC +09:00)) - "AMD (SVM) Hypervisor Based Kernel API Hooking"

Based on the hypervisor sample code running on AMD-based CPUs, I release the code that implements kernel API hooking using NPT's page fault.

At the end of the test process, I will further implement and complete the main kernel driver and communication process.

Because I created a hypervisor based on that sample code, the GPL-3.0 license is enforced, so it exists independently in the Hypervisor/AMD folder as a "separate kernel driver" folder.

---

(2025-08-28 - 05:06(UTC +09:00) ) — * "APC-Based Asynchronous User Mode Callback Implementation !"*

I used APC to allow the kernel to pass data transfer events to the user mode (IOCTL requester) asynchronously.

This is a medium that can deliver asynchronous events, such as hooking signals from the kernel or hypervisor, to the user mode!!!!

---

(2025-08-22 - 03:40(UTC +09:00) ) — * "Kernel Based Pointer Scanner is opened !"*

I have implemented a "pointer scanner" that works on a kernel basis in version 2 of this season

Additionally, the .data and .rdata areas are implemented to simply extract paths in JSON-type APIs with a "fixed offset" for one variable address found in EXE and dll (except Windows System dll) loaded into target process memory.

---

(2025-08-22 - 22:20(UTC +09:00) ) — * "(Physical Memory Page Based) Kernel logic has been changed to connect to the User Mode stack by referring to a valid CR3 register !"*

In addition, the user mode was always accessed through a valid CR3 and changed to Copy form.

These measures are intended to prevent CR3 modulation of anti-cheats.

Basic

CR3 Brute-Force Processing

1. Acquire PEPROCESS

   • Obtain the PEPROCESS of the target process.

2. Extract ImageBaseAddress from PEPROCESS

   • Retrieve the ImageBaseAddress from the PEPROCESS structure.

3. Split Base Virtual Address into Bits

   • Split the ImageBaseAddress extracted in step (2) into individual bits.

4. Obtain Full Physical Page Map and Calculate PFN Upper Limit

   • Use the MmGetPhysicalMemoryRanges() API to get the full physical page map.
   • Pre-calculate the upper limit of PFN (Page Frame Number).

5. Traverse the Physical Page Map

   • Traverse the physical page map from start to end using index-based iteration.

6. CR3 Candidate Brute-Forcing

   • Assume each PFN as CR3 and reference the page tables.

     PML4 -> PDP -> PD -> PT
     

   • Use the PFN upper limit from step (4) and the MmCopyMemory() API to verify validity.

7. Verify EXE File and Check PEB

   • If step (6) is successful, convert to a DOS header and verify the signature to confirm the process EXE.
   • Since collisions with other processes are possible, assume the CR3 is correct and retrieve the PEB using the same method (PML4 -> PDP -> PD -> PT).
   • Finally, confirm that the PEB's ImageBaseAddress matches the address extracted in step (2).

8. Final CR3 Determination

   • If step (7) is successful, the CR3 can be obtained with 100% certainty.

Code is Here

---

(2025-08-10 - 16:00(UTC +09:00) ) — * "Highly stable hardware breakpoint"*

NMore reliably than previous methods, you can import and modify thread contexts without conflict at the kernel end. There is a 98.13 percent chance that you no longer experience conflict issues with Thread Context.

if want to use Hardware Breakpoint, you can see this VEH_HANDLER in DLL sample Preview) Kernel returns a path based on a "Linked list" to the user mode process, which converts it to JSON to give you results.

---

(2025-08-09 - 19:00(UTC +09:00) ) — Added "Memory ALL Scan"

When it provides a size, by default, copy data from the PAGE_READWRITE area and import it to the node.

---

(2025-08-09 - 15:00(UTC +09:00) ) — Improved "Hardware Breakpoint"

Now more stable than the first-generation implementation.
The kernel driver now pauses the target process’s threads before modifying the debug register.

---