git:20260909.90b22a8 to git:20260913.ae72a69

- description: Classify game-cheating threats across client memory, code injection, rendering, input, engines, kernels, DMA and remote transports. Use for repository-backed attack-surface maps, attacker prerequisites, state exposure, legitimate comparison baselines, and observable artifacts. Select engine source, capture or diagnostic resources that fit the evidence; separate source, transport, processing and server authority, and report benign counterexamples and limits without inferring a product or enforcement policy.

- ---

-

- # Game Hacking Techniques

-

- ## Overview

-

- This skill maps the offensive side of game-security threat models: what an attacker seeks to observe or control, which capability is required, and where defenses have visibility or authority. User-mode, kernel, hypervisor, device, visual, and network threats are alternative or combined paths, not a universal escalation sequence.

-

- ## Attacker Capability and Defensive Coverage

-

- For threats beyond local runtime access, use

- [game-server-security](../game-server-security/SKILL.md) for backend authority

- and transactional correctness, and

- [game-supply-chain-security](../game-supply-chain-security/SKILL.md) for build,

- release and mod trust. Each extends the attack taxonomy with its own prerequisites.

-

- Read the [attack surface map](references/attack-surface-map.md) when comparing

- attack families or building a defense coverage matrix. It includes client-state

- exposure, manipulation, injection, privileged acquisition, visual/input

- automation, and abuse of server trust, with prerequisites and counterexamples.

-

- For each relevant family, explain the attack objective and boundary before

- naming tools. Identify what the defender can actually observe, what control

- prevents or limits the behavior, and what remains uncertain. Distinguish

- read-only information abuse from state modification, and synthetic input from

- evidence of human intent. Avoid presenting a missing artifact as proof that an

- attack is undetectable.

-

- Cross-reference [DMA acquisition](../dma-attack/references/acquisition-and-transport.md)

- for host-driver versus device access, and

- [network evidence](../anti-cheat/references/network-environment-evidence.md)

- for account/device association and reported restrictions.

-

- Treat implementations, performance numbers, stealth rankings, and detection

- claims as versioned threat-model examples rather than guarantees. Use

- [`research-rigor`](../research-rigor/SKILL.md) when converting them into a

- factual claim or defensive decision.

-

- ## Repository Resource Selection

-

- Select evidence for the proposed capability: owned engine source, retained

- packet data, rendering baselines, or legitimate diagnostic UI. Read

- [repository resources](references/repository-resources.md) for exact README

- families, project choices, capability limits and expected evidence.

-

- ## Escalation Model

-

- ### User-Mode

- - Read and write process memory

- - Inject DLLs or shellcode

- - Hook graphics or input APIs

-

- ### Kernel-Mode

- - Use signed or vulnerable drivers for direct memory access

- - Bypass handle-based protections and inspect protected processes

- - Interact with callbacks, page tables, or kernel objects directly

-

- ### Below the OS

- - Virtualize the system with a hypervisor

- - Read memory through PCIe DMA hardware

- - Move logic to external devices or secondary machines

-

- ## Core Concepts

-

- ### Memory Manipulation

- - Read Process Memory (RPM)

- - Write Process Memory (WPM)

- - Pattern scanning

- - Pointer chains

- - Structure reconstruction

-

- ### Process Injection

- - DLL injection methods

- - Manual mapping

- - Shellcode injection

- - Thread hijacking

- - APC injection

-

- ### Hooking Techniques

- - Inline hooking (detours)

- - IAT/EAT hooking

- - VTable hooking

- - Hardware breakpoint hooks

- - Syscall hooking

-

- ## Cheat Categories

-

- ### Visual Cheats (ESP)

- ```

- - World-to-Screen transformation

- - Player/entity rendering

- - Box ESP, skeleton ESP

- - Item highlighting

- - Radar/minimap hacks

- ```

-

- ### Aim Assistance

- ```

- - Aimbot algorithms (memory-based and AI visual)

- - Triggerbot (auto-fire on crosshair detection)

- - No recoil/no spread

- - Bullet prediction and lead calculation

- - Silent aim (server-side angle manipulation)

- - AI visual aimbot (YOLO-based, no memory access required)

- ```

-

- ### AI Visual Cheats (Computer Vision Aimbot)

- ```

- Architecture overview:

- Screen-capture paradigm — uses frame capture, object detection, and input

- injection. Some implementations can avoid process attachment, a cheat driver,

- and direct game-memory reads; that does not make the full pipeline artifact-free.

-

- Typical setup:

- ┌─────────────────┐ screen capture ┌──────────────────┐

- │ Gaming PC │ ───────────────────────▶ │ AI Pipeline │

- │ Game + OBS │ │ (same PC, or │

- │ │ ◀─────────────────────── │ second PC) │

- └─────────────────┘ hardware input │ YOLO model │

- (KMBox / Logitech) │ TensorRT/CUDA │

- └──────────────────┘

-

- Dual-machine variant (separate processing location):

- - Machine A (game): only runs game + OBS, sends frames via NDI/capture card

- - Machine B (cheat): runs AI model, sends mouse commands via USB/network

- to hardware input device on Machine A

- - Game machine need not run the model or decision logic, though capture,

- transport, and input-device artifacts can remain

-

- Single-machine variant:

- - OBS + AI model run on the same PC

- - AI implemented as OBS filter plugin (looks like "OBS is running")

- - Mouse output via hardware device or driver-level injection

-

- Pipeline stages:

-

- 1. Frame Source Evidence:

- - Identify the actual source/backend and retained frame stage; a source label

- does not establish hook use, display coverage or a fixed frame rate

- - Treat capture plugins and external capture devices as separate provenance

- questions, and compare against legitimate recording configurations

- - Evaluate capture semantics using the graphics-api skill before interpreting

- a missing image or a process/module observation

-

- 2. AI Object Detection:

- - Model: YOLOv5 / YOLOv8 / YOLOv10 / YOLO11 (lightweight variants)

- - Training: fine-tuned on game-specific screenshots

- (enemy bodies, heads, torsos as labeled bounding boxes)

- - Input: cropped region around crosshair (320x320 or 640x640)

- to reduce inference cost

- - Output: bounding boxes with class (head/body/enemy) + confidence score

- - Acceleration: TensorRT (NVIDIA), CUDA, DirectML, OpenVINO

- - Set and measure the latency budget on the target capture path, model,

- hardware, frame rate, and input transport

-

- 3. Coordinate Transform and Aiming Logic:

- - Convert pixel coordinates to mouse movement delta:

- delta_x = (target_x - screen_center_x) * sensitivity

- delta_y = (target_y - screen_center_y) * sensitivity

- - Target selection: closest to crosshair, highest confidence,

- head priority, or combined scoring

- - FOV (Field of View) lock: only engage targets within

- configurable pixel radius from crosshair center

-

- 4. Attempts to mask automated trajectories:

- - Gradual movement with an acceleration curve instead of an instant snap

- - Synthetic jitter

- - Bézier curve or cubic interpolation for path

- - End-point correction (overshoot then settle)

- - Configurable engagement probability

- - Slight intentional offset (not pixel-perfect center-mass)

- - Variable reaction delay

- These transformations do not establish human equivalence; repeated

- parametric behavior can itself become a feature.

-

- 5. Mouse Movement Execution:

- - Hardware input devices (see Input Simulation section below)

- - Movement commands sent as physical HID reports

- - The host receives protocol-conformant HID input rather than a user-mode

- injection API call; device provenance and behavior may still be observable

-

- Why OBS specifically:

- - Legitimate streaming software, used by millions of streamers

- - Blanket action against OBS-related processes would create substantial

- collateral impact; process presence alone is not attribution

- - Game Capture provides fast, low-latency frame access

- - Plugin system can host filters inside OBS, but loaded plugins, behavior, and

- surrounding telemetry may still be inspected

- - Supports D3D11, D3D12, Vulkan, OpenGL capture paths

- ```

-

- ### YOLO Model Training Pipeline (for Game AI Aimbot)

- ```

- End-to-end workflow from raw game screenshots to deployed TensorRT model.

-

- 1. Data Collection:

- - Capture game screenshots during actual gameplay (OBS recording or replay)

- - Capture diverse scenarios: different maps, lighting, character skins,

- distances, poses, partial occlusion, smoke/flash effects

- - Determine dataset size from coverage and learning curves; image count alone

- does not guarantee robustness

- - Include negative samples (empty scenes, friendlies, environment objects)

-

- 2. Annotation / Labeling:

- - Tools: LabelImg (YOLO format), CVAT (collaborative), Roboflow (cloud),

- Label Studio, makesense.ai (browser-based)

- - YOLO format: one .txt per image, each line:

- <class_id> <center_x> <center_y> <width> <height>

- (all values normalized to 0-1 relative to image dimensions)

- - Class definitions (typical):

- 0: enemy_body (full body bounding box)

- 1: enemy_head (head-only bounding box, for headshot targeting)

- 2: friendly (to avoid shooting teammates)

- - Label head separately from body for head-priority targeting

- - Quality control: consistent label boundaries, no missed instances

-

- 3. Data Augmentation:

- - Built-in Ultralytics augmentations (mosaic, mixup, copy-paste)

- - Game-specific augmentations:

- - Brightness/contrast variation (simulate different map lighting)

- - Random crop around crosshair area (match inference ROI)

- - Motion blur (simulate fast movement)

- - Noise injection (simulate compression artifacts)

- - Avoid augmentations that distort aspect ratio

- (characters would look unnatural, hurting accuracy)

-

- 4. Training:

- - Framework: Ultralytics YOLOv8/v10/v11/YOLO11

- - Base model: yolov8n.pt or yolov8s.pt (nano/small for speed)

- or yolo11n.pt for latest architecture

- - Training command:

- yolo detect train data=game_dataset.yaml model=yolov8n.pt

- epochs=100 imgsz=640 batch=16 device=0

- - dataset.yaml structure:

- path: /path/to/dataset

- train: images/train

- val: images/val

- names: {0: enemy_body, 1: enemy_head, 2: friendly}

- - Key hyperparameters to tune include input size, learning rate, confidence

- threshold, NMS IoU threshold, batch size, and augmentation policy

- - Measure training and inference cost on the exact model, software stack,

- precision, and target hardware

-

- 5. Validation and Testing:

- - Evaluate mAP@0.5 and mAP@0.5:0.95 on validation set

- - Choose operating thresholds from precision/recall and downstream error

- costs; no single mAP cutoff establishes reliable deployment

- - Test inference speed on target hardware and evaluate held-out maps, skins,

- patches, capture paths, and hard negatives

-

- 6. Export to TensorRT (deployment):

- - Step 1: Export to ONNX

- yolo export model=best.pt format=onnx simplify=True opset=17

- - Step 2: Convert ONNX to TensorRT engine

- yolo export model=best.pt format=engine half=True device=0

- (half=True enables FP16 precision)

- - Or use trtexec directly:

- trtexec --onnx=best.onnx --saveEngine=best.engine

- --fp16 --workspace=4096

- - Benchmark FP16 against FP32 on the exported model; latency, throughput, and

- accuracy changes are hardware- and graph-specific

- - INT8 can improve throughput but requires representative calibration data

- and accuracy validation

-

- 7. Runtime Integration:

- - Load TensorRT engine in C++/Python inference loop

- - Input: preprocessed frame (resize, normalize, HWC→CHW, float32/16)

- - Decode the exporter/version-specific output tensor; shapes and NMS

- placement vary across model and runtime versions

- - Apply NMS (Non-Maximum Suppression) to deduplicate detections

- - Select target based on: closest to crosshair + highest confidence

- - Convert pixel coordinates to mouse delta

-

- Alternative acceleration backends:

- - DirectML (AMD GPUs, Windows native)

- - OpenVINO (Intel GPUs/CPUs)

- - ONNX Runtime with CUDA EP (cross-platform)

- - CoreML (macOS, less common for game cheats)

- ```

-

- ### Movement Cheats

- ```

- - Speed hacks

- - Fly hacks

- - No clip

- - Teleportation

- - Bunny hop automation

- ```

-

- ### Miscellaneous

- ```

- - Wallhacks

- - Skin changers

- - Unlock all

- - Economy manipulation

- ```

-

- ## Overlay & Rendering

-

- ### Overlay Methods

- - **DirectX Hook**: D3D9/11/12 Present hook

- - **Vulkan Hook**: vkQueuePresentKHR hook

- - **OpenGL Hook**: wglSwapBuffers hook

- - **DWM Overlay**: Desktop Window Manager

- - **External Window**: Transparent overlay window

- - **Steam Overlay**: Hijacking Steam's overlay

- - **NVIDIA Overlay**: GeForce Experience hijack

-

- ### Rendering Libraries

- - **Dear ImGui**: Immediate mode GUI

- - **GDI/GDI+**: Windows graphics

- - **Direct2D**: Hardware-accelerated 2D

-

- ## Memory Access Methods

-

- ### User-Mode

- ```

- - OpenProcess + ReadProcessMemory

- - NtReadVirtualMemory

- - Memory-mapped files

- - Shared memory sections

- ```

-

- ### Kernel-Mode

- ```

- - Driver-based access

- - Physical memory access

- - MDL-based copying

- - KeStackAttachProcess

- ```

-

- ### Advanced Methods

- ```

- - DMA (Direct Memory Access)

- - EFI runtime services

- - Hypervisor-based access

- - Hardware-based (FPGA)

- ```

-

- ## EFI/UEFI Threat Boundaries

-

- Classify boot-component tampering, runtime firmware behavior and device-originated

- memory access as separate capabilities. Record the boot stage, affected component,

- necessary privilege or trust failure, persistence evidence and observation point.

- Runtime residency does not by itself demonstrate persistence across a reboot.

-

- Secure Boot, Windows startup integrity and measured-boot assessment address

- different parts of the trust chain. An assertion that code runs before the OS,

- is test-signed, or uses a firmware interface does not demonstrate acceptance by

- the actual configured policy. Preserve firmware/build identity, active trust and

- revocation policy, and available measurement evidence.

- [Microsoft boot security](https://learn.microsoft.com/en-us/windows/security/operating-system-security/system-security/secure-the-windows-10-boot-process)

-

- Combining firmware and DMA claims establishes no general stealth advantage.

- Identify the memory accessor and its trust boundary independently. Microsoft

- separates post-OS Kernel DMA Protection from firmware responsibility during boot;

- evaluate both stages rather than extending a runtime policy conclusion backwards

- through the boot process.

- [Kernel DMA Protection](https://learn.microsoft.com/en-us/windows/security/hardware-security/kernel-dma-protection-for-thunderbolt)

-

- Missing OS image-load or driver-bookkeeping evidence must be scoped to the

- collector and lifecycle it covers. Corroborate with available boot, firmware,

- device and runtime evidence; a quiet channel is not proof that execution was

- invisible. Use [windows-kernel](../windows-kernel/SKILL.md) for callback contracts

- and [dma-attack](../dma-attack/SKILL.md) for acquisition boundaries.

- Sources reviewed: 2026-09-09.

-

- ## HWID Spoofing

-

- ### Targets

- ```

- - Disk serial: IOCTL_STORAGE_QUERY_PROPERTY, SMART data

- - NIC MAC address: NDIS OID_802_3_PERMANENT_ADDRESS

- - SMBIOS: motherboard serial, system UUID, BIOS vendor

- - GPU serial: registry-based or NVAPI/ADL queries

- - Monitor EDID: display serial number

- - Volume serial: NtQueryVolumeInformationFile

- - TPM EK: Endorsement Key fingerprint

- ```

-

- ### Techniques

- ```

- - Disk filter driver: intercept IOCTL and replace serial in response

- - Registry value spoofing: modify cached hardware IDs

- - SMBIOS table patching: modify raw SMBIOS memory region

- - NIC driver hook: replace MAC in NDIS miniport response

- - Full HWID spoofer: coordinated spoofing across all identifiers

- ```

-

- ## Stack Spoofing

-

- ### Return Address Spoofing

- ```

- - Replace return address on stack before API call

- - Restore original after call returns

- - Evades stack-walk-based detection (RtlWalkFrameChain)

- - Techniques: JMP RBX gadget, synthetic frames, fiber-based

- ```

-

- ### Call Stack Reconstruction

- ```

- - Build fake but plausible call stack frames

- - Match expected module return addresses (ntdll, kernel32)

- - Evade NtQueryInformationThread stack inspection

- - Tools: SpoofCallStack, Vulcan, CallStackSpoofer

- ```

-

- ### Detection & Evasion

- ```

- - Anti-cheat walks thread stacks looking for non-module returns

- - Stack unwinding via .pdata / UNWIND_INFO validation

- - Spoofed stacks must pass RtlVirtualUnwind consistency checks

- ```

-

- ## Driver Communication

-

- ### Full Taxonomy (40+ methods in README)

- ```

- IOCTL-based:

- - Standard DeviceIoControl with custom control codes

- - Buffered I/O, Direct I/O, METHOD_NEITHER

-

- Data pointer swaps (abusing legitimate syscalls):

- - NtUserGetObjectInformation

- - NtConvertBetweenAuxiliaryCounterAndPerformanceCounter

- - NtUserRegisterRawInputDevices

- - NtGdiGetCOPPCompatibleOPMInformation

- - NtDxgkGetTrackedWorkloadStatistics

- - NtUserGetPointerInfoList

- - NtUserSetInformationThread

- - NtDCompositionSetChildRootVisual

- - Win32k syscall hooks

-

- Shared memory:

- - Named shared sections (ZwCreateSection + ZwMapViewOfSection)

- - Physical memory mapping

- - Shared event objects for signaling

-

- Callback-based:

- - Registry callbacks (CmRegisterCallbackEx)

- - Minifilter communication ports (FltCreateCommunicationPort)

- - Object callbacks with embedded data

-

- Unconventional channels:

- - Named pipes from kernel

- - Window messages (NtUserPostMessage)

- - ETW provider channels

- - Socket from kernel (Winsock Kernel / WSK)

- - File system filter callbacks

- - Debugging APIs (DbgPrint interception)

- ```

-

- ## World-to-Screen Calculation

-

- ### Basic Formula

- ```cpp

- Vector2 WorldToScreen(Vector3 worldPos, Matrix viewMatrix) {

- Vector4 clipCoords;

- clipCoords.x = worldPos.x * viewMatrix[0] + worldPos.y * viewMatrix[4] +

- worldPos.z * viewMatrix[8] + viewMatrix[12];

- clipCoords.y = worldPos.x * viewMatrix[1] + worldPos.y * viewMatrix[5] +

- worldPos.z * viewMatrix[9] + viewMatrix[13];

- clipCoords.w = worldPos.x * viewMatrix[3] + worldPos.y * viewMatrix[7] +

- worldPos.z * viewMatrix[11] + viewMatrix[15];

-

- if (clipCoords.w < 0.1f) return invalid;

-

- Vector2 NDC;

- NDC.x = clipCoords.x / clipCoords.w;

- NDC.y = clipCoords.y / clipCoords.w;

-

- Vector2 screen;

- screen.x = (screenWidth / 2) * (NDC.x + 1);

- screen.y = (screenHeight / 2) * (1 - NDC.y);

-

- return screen;

- }

- ```

-

- ## Engine-Specific Techniques

-

- ### Unity (Mono)

- - Assembly-CSharp.dll analysis

- - Mono JIT hooking

- - Il2CppDumper for IL2CPP builds

- - Method address resolution

-

- ### Unity (IL2CPP)

- - GameAssembly.dll analysis

- - Metadata recovery

- - Type reconstruction

- - Native hooking

-

- ### Unreal Engine

- - GObjects/GNames enumeration

- - UWorld traversal

- - SDK generation (Dumper-7)

- - Blueprint hooking

-

- ### Source Engine

- - Entity list enumeration

- - NetVars parsing

- - ConVar manipulation

- - Signature scanning

-

- ## Input Simulation

-

- ### Software Methods

- - SendInput API

- - mouse_event/keybd_event

- - DirectInput hooking

- - Raw input injection

- - Driver-based input (mouclass)

-

- ### Kernel-Level

- - Mouse class service callback

- - Keyboard filter drivers

- - HID manipulation

-

- ### Input Sources and Observation Scope

-

- Protocol-conformant input does not authenticate human intent. Raw Input can

- identify different source devices, while API-generated input has its own

- platform contract; neither observation alone establishes a cheating decision.

- [Microsoft Raw Input](https://learn.microsoft.com/en-us/windows/win32/inputdev/about-raw-input),

- [Microsoft SendInput](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-sendinput)

-

- Use this comparison as a collection plan, with no concealment ordering:

-

- | Source class | Evidence potentially available | Benign controls and limits |

- |---|---|---|

- | External HID or input bridge | Device identity/topology, reported input and relevant host associations | Ordinary peripherals, KVMs, remappers and accessibility devices; device names alone do not establish behavior |

- | Vendor or other input driver | Exact image/version, service/device ownership and observed operations | Legitimate vendor software; a familiar publisher does not demonstrate a game-specific exemption |

- | Input filter component | Driver provenance, configured role and available input-path observations | Authorized filters and accessibility software; presence alone is not a verdict |

- | User-mode input API | Caller/path evidence where available, integrity-level context and observed events | UI testing and accessibility; API visibility and collection coverage vary |

-

- Record actual observer access, provider health, sampling, input transformation

- and gameplay context. A remote decision process or additional device changes

- which components need examination; it does not make the entire pipeline less

- observable in every deployment. The table's review criteria are a synthesis,

- not a documented guarantee that any one detector collects these fields.

-

- Use [input provenance](../anti-cheat/references/input-provenance-and-measurement.md)

- for units, client uploads and missing samples. Sources reviewed: 2026-09-09.

-

- ### KMBox Protocol Details

- ```

- KMBox Net (network variant) — UDP-based protocol:

-

- Packet header (16 bytes, Little-Endian):

- Offset Field Size Description

- 0x00 MAC 4 B Device UUID (unique per device, used for auth)

- 0x04 RAND 4 B Random value or parameter

- 0x08 INDEXPTS 4 B Incrementing sequence number (replay protection)

- 0x0C CMD 4 B Command code

-

- Key command codes:

- The values below are firmware/API-version examples; verify them against the

- exact device implementation before analysis.

- Code Command Description

- 0xAF3C2828 connect Establish connection with device

- 0xAEDE7345 mouse_move Direct mouse movement (dx, dy)

- 0xAEDE7346 mouse_automove Human-like movement with interpolation

- 0xA238455A mouse_beizer Bézier curve mouse movement

- 0x9823AE8D mouse_left Left button press/release

- 0x238D8212 mouse_right Right button press/release

- 0x97A3AE8D mouse_middle Middle button press/release

- 0xFFEEAD38 mouse_wheel Scroll wheel

- 0x123C2C2F keyboard_all Keyboard key event

-

- Mouse API functions:

- - move(x, y): Direct relative movement, no interpolation

- - move_auto(x, y, ms): Interpolated movement over ms milliseconds

- - move_beizer(x, y, ms, Second-order Bézier curve with custom

- x1, y1, x2, y2): control points for trajectory shaping

-

- Encrypted variants (enc_*): Same functions with packet-level encryption

- to resist network packet analysis

-

- Performance:

- - Measure command rate, latency distribution, loss, buffering, and jitter on

- the exact firmware, transport, host, and network; fixed figures do not

- transfer across setups

-

- KMBox B / B Pro (serial variant):

- - USB CDC serial communication (COM port)

- - Baud rate is firmware/configuration-specific (115200 is one common setting)

- - Simpler protocol: ASCII or binary command frames

- - Benchmark round-trip timing on the deployed serial stack

-

- Physical keyboard/mouse monitoring:

- - monitor() function reads real user input from the device

- - Enables "pass-through + inject" mode:

- real user input flows through normally,

- AI-calculated deltas are added on top

-

- Arduino / Teensy HID protocol:

- - Custom serial command format (typically simple ASCII):

- "M,dx,dy\n" — mouse move

- "C,button\n" — click (1=left, 2=right, 3=middle)

- "K,keycode\n" — keypress

- - USB HID report generated by ATmega32U4 (Leonardo)

- or ARM-based Teensy (3.2, 4.0, 4.1)

- - HID report descriptor mimics standard mouse:

- buttons (3 bits) + X delta (8-16 bits) + Y delta (8-16 bits)

- - No custom driver needed — OS uses generic HID driver

-

- Logitech driver API (exploitable versions):

- - G HUB versions prior to certain patches expose internal functions

- - Key DLLs: LGS (lcore.dll), G HUB (ghub_mouse.dll or internal APIs)

- - ghub_mouse_move(dx, dy) or equivalent internal symbol

- - Accessed via DLL injection into GHUB process

- or LoadLibrary + GetProcAddress

- - Movement appears as Logitech device input in the HID stack

- - Patched in newer G HUB versions; specific version numbers

- circulate in cheat communities

- ```

-

- ## Anti-Detection Techniques

-

- ### Code Protection

- - Polymorphic code

- - Code virtualization

- - Anti-dump techniques

- - String encryption

-

- ### Runtime Evasion

- - Stack spoofing

- - Return address manipulation

- - Thread context hiding

- - Module concealment

-

- ## Development Workflow

-

- ### External Cheat

- ```

- 1. Pattern scan for signatures

- 2. Read game memory externally

- 3. Process data in separate process

- 4. Render overlay or use input simulation

- ```

-

- ### Internal Cheat

- ```

- 1. Inject into game process

- 2. Hook rendering functions

- 3. Access game objects directly

- 4. Render through game's graphics context

- ```

-

- ## Learning Resources

-

- ### Communities

- - UnknownCheats

- - GuidedHacking

- - Game Hacking Academy

-

- ### Practice Targets

- - PWN Adventure (intentionally vulnerable)

- - CTF game challenges

- - Older/unsupported games

-

- ## Repository Navigation

-

- Load [repository resources](references/repository-resources.md) for this

- domain's resource choices and evidence outputs. Use

- [shared repository navigation](../overview/references/repository-navigation.md)

- for local discovery layers, case-sensitive paths, missing snapshots and current

- upstream verification. Generated summaries are discovery aids, not independent

- evidence.

-

- The compiled [game-hacking overview](../../../wiki/overviews/game-hacking.md)

- can help locate related material; trace consequential claims to their underlying

- source.

-

- ## Data Source

-

- Use the following repository sources directly when applying this skill. Prefer

- available local files for discovery and scoped historical inspection; use the

- raw URLs when the collection is not installed locally. These entrypoint details

- are retained here so source lookup does not depend on loading another skill.

-

- ### 0. Compiled Wiki

-

- Start with [wiki/index.md](../../../wiki/index.md) for topical synthesis and

- cross-project connections. [Wiki schema](../../../wiki/AGENTS.md) describes its

- structure. Generated wiki pages are discovery aids; follow their original

- citations before adopting technical claims.

-

- Raw catalog: [wiki/index.md](https://raw.githubusercontent.com/gmh5225/awesome-game-security/refs/heads/main/wiki/index.md).

- For this domain, read [wiki/overviews/game-hacking.md](../../../wiki/overviews/game-hacking.md).

- Raw URL: [game-hacking overview](https://raw.githubusercontent.com/gmh5225/awesome-game-security/refs/heads/main/wiki/overviews/game-hacking.md).

-

- A direct project question can start with its README entry or description below;

- reading the entire wiki is unnecessary.

-

- ### 1. Project Overview and Resource Index

-

- [README.md](../../../README.md) contains the collection's actual categories,

- subcategories, project URLs and short descriptions. Find the relevant category

- and retain the original URL, including any specific file or revision suffix.

-

- Raw index: [README.md](https://raw.githubusercontent.com/gmh5225/awesome-game-security/refs/heads/main/README.md).

-

- ### 2. Repository Descriptions

-

- For a concise project summary, look for the actual local path:

-

- ```text

- description/{owner}/{repo}/description_en.txt

- https://raw.githubusercontent.com/gmh5225/awesome-game-security/refs/heads/main/description/{owner}/{repo}/description_en.txt

- ```

-

- Example: [bgfx description](https://raw.githubusercontent.com/gmh5225/awesome-game-security/refs/heads/main/description/bkaradzic/bgfx/description_en.txt).

- Extract owner/repository from the original GitHub project URL, omitting a .git

- suffix. Resolve existing path casing before constructing a local/raw path.

- Descriptions are generated summaries, not independent verification. If absent

- or inaccessible, use the README entry, relevant archive or original project.

-

- ### 3. Repository Source Archives

-

- For deeper inspection of an available captured source tree, locate:

-

- ```text

- archive/{owner}/{repo}.txt

- https://raw.githubusercontent.com/gmh5225/awesome-game-security/refs/heads/main/archive/{owner}/{repo}.txt

- ```

- Example: [bgfx archive](https://raw.githubusercontent.com/gmh5225/awesome-game-security/refs/heads/main/archive/bkaradzic/bgfx.txt).

- Prefer inspecting the relevant portion of an existing archive over re-cloning

- merely to inspect the same captured material. Archives may exclude files, use

- fallback extraction or contain truncation; they are not guaranteed complete

- checkouts. Record any upstream revision evidence and included-file limits.

- If missing or insufficient, follow the README's original upstream URL.

- ### Choose and Verify the Source

- For a specific project, locate its README identity, use a description or wiki

- page for orientation when helpful, then inspect the relevant archive/source

- artifact for the question. For current compatibility or exact implementation,

- verify the matching upstream documentation, release or immutable source revision.

- Keep the collection revision and capture/generation dates separate from the

- upstream version. Multiple generated layers from one source are not independent

- corroboration, and missing archive content does not establish upstream absence.

- The per-domain resource guide above helps choose useful artifacts. Shared

- [repository navigation](../overview/references/repository-navigation.md) adds the optional read-only indexer,

- case-ambiguity handling and maintenance details; it supplements this Data Source

- section rather than replacing it.