git:20260909.90b22a8 to git:20260913.ae72a69

- description: Assess Android and iOS game-security trust boundaries and select repository resources for APK/AAB/IPA inspection, DEX/native or IL2CPP analysis, device-kernel provenance, authorized network observations and signing review. Use for controlled instrumentation, root/jailbreak or emulator evidence, SELinux, Play Integrity and App Attest. Separate package, runtime, platform integrity and server authorization; record device/build/ABI, signer, entitlements, required privilege and collection limits before drawing conclusions.

- ---

-

- # Mobile Game Security

-

- ## Overview

-

- This skill covers Android and iOS game-security analysis across package provenance, runtime integrity, local data, platform policy, attestation, and backend trust. Describe attacker capabilities and defense limits separately at each boundary.

-

- Mobile behavior is strongly version-, OEM-, entitlement-, signing-, kernel-,

- and policy-dependent. Verify the exact device/build and use

- [`research-rigor`](../research-rigor/SKILL.md) before treating a root, hook,

- emulator, or integrity signal as attribution.

-

- ## Mobile Trust Boundaries and Integrity Evidence

-

- Use [game-server-security](../game-server-security/SKILL.md) for verified

- purchases, entitlement transitions, account authorization and retries. Use

- [game-supply-chain-security](../game-supply-chain-security/SKILL.md) when the

- question concerns build provenance, updates or third-party content.

-

- Separate app package/signing, process isolation, platform/device integrity,

- and server authorization/game rules. Repackaging, privileged instrumentation,

- local-data exposure, request replay, and reliance on client assertions affect

- different boundaries. State whether the scenario requires ordinary app access,

- a developer build, privileged runtime access, kernel control, or server access.

-

- Keep local indicators, verified attestation, backend decisions, and sanctions

- separate. A root indicator is not proof of cheating; a valid integrity response

- does not validate arbitrary game logic. Record the exact build and signing

- identity with the observation source and available counterevidence.

-

- - Android SELinux mandatory access control also applies to root processes.

- Record enforcement state, domain, build, and relevant policy denials instead

- of assigning universal trust or stealth ratings to framework names.

- [AOSP SELinux](https://source.android.com/docs/security/features/selinux)

- - Validate Play Integrity request details, identity, binding, and freshness

- before interpreting app/device/account verdicts on the backend.

- [Android integrity verdicts](https://developer.android.com/google/play/integrity/verdicts)

- - App Attest requires server verification of attestations/assertions, including

- challenge and counter handling. Keep development and production context

- separate. [Apple server validation](https://developer.apple.com/documentation/devicecheck/validating-apps-that-connect-to-your-server)

- - For owned-app transport tests, distinguish debug-only trust anchors from

- release configuration and verify the packaged result.

- [Android network security configuration](https://developer.android.com/privacy-and-security/security-config)

-

- Include supported emulators, stock devices, developer builds, OS updates, and

- service/attestation errors as controls. Record unavailable evidence separately

- from a verified negative result. Report the boundary, prerequisite, artifact,

- backend interpretation, false-positive alternatives, and unresolved limits.

- Sources above were reviewed on 2026-09-09.

-

- ## README Coverage

-

- - `Cheat > Magisk`

- - `Cheat > Xposed`

- - `Cheat > Frida`

- - `Cheat > Hook ART(android)`

- - `Cheat > Hook syscall(android)`

- - `Cheat > Android Terminal Emulator`

- - `Cheat > Android File Explorer`

- - `Cheat > Android Memory Explorer`

- - `Cheat > Android Application CVE`

- - `Cheat > Android Kernel CVE`

- - `Cheat > Android Bootloader Bypass`

- - `Cheat > IoT / Smart devices`

- - `Cheat > Android ROM`

- - `Cheat > Android Device Trees`

- - `Cheat > Android Kernel Source`

- - `Cheat > Android Root`

- - `Cheat > Android Kernel driver development`

- - `Cheat > Android Kernel Explorer`

- - `Cheat > Android Kernel Driver`

- - `Cheat > Android Network Explorer`

- - `Cheat > Android memory loading`

- - `Cheat > IOS jailbreak`

- - `Cheat > IOS Memory Explorer`

- - `Cheat > IOS File Explorer`

- - `Cheat > IOS App Packaging`

- - `Cheat > Injection:Android`

- - `Cheat > Injection:IOS`

- - `Anti Cheat > Detection:Android root`

- - `Anti Cheat > Detection:Magisk`

- - `Anti Cheat > Detection:Frida`

- - `Some Tricks > Android`

- - `Android Emulator`

- - `IOS Emulator`

-

- ## Android Security

-

- ### APK Analysis

-

- #### Tools

- - **apktool**: Decompile/recompile APKs

- - **jadx**: DEX to Java decompiler

- - **APKiD**: Identify packers/protectors

- - **Frida**: Dynamic instrumentation

- - **APKLab**: VS Code integration

-

- #### Workflow

- ```bash

- # Decompile APK

- apktool d game.apk

-

- # Analyze DEX files

- jadx -d output game.apk

-

- # Identify protection

- apkid game.apk

- ```

-

- ### Native Library Analysis

-

- #### IL2CPP Games (Unity)

- ```

- 1. Extract libil2cpp.so from APK

- 2. Use IL2CPP Dumper to generate headers

- 3. Analyze with IDA/Ghidra

- 4. Hook using Frida or native hooks

- ```

-

- #### Native Games

- ```

- 1. Identify target libraries (.so files)

- 2. Analyze with reverse engineering tools

- 3. Pattern scan for functions

- 4. Apply hooks/patches

- ```

-

- ### Memory Manipulation

-

- #### Tools

- - **GameGuardian**: Memory editor

- - **Cheat Engine (ceserver)**: Remote debugging

- - **Custom memory tools**: Direct /proc/pid/mem access

-

- #### Access Methods

- ```c

- // Via /proc filesystem

- int fd = open("/proc/pid/mem", O_RDWR);

- pread64(fd, buffer, size, address);

- pwrite64(fd, buffer, size, address);

- ```

-

- ### Hooking Frameworks

-

- #### Frida

- ```javascript

- // Basic function hook

- Interceptor.attach(Module.findExportByName("libgame.so", "function_name"), {

- onEnter: function(args) {

- console.log("Called with: " + args[0]);

- },

- onLeave: function(retval) {

- retval.replace(0);

- }

- });

- ```

-

- #### Native Hooks

- - **Substrate**: Inline hooking framework

- - **And64InlineHook**: ARM64 inline hooks

- - **xHook**: PLT hook library

- - **Dobby**: Multi-platform hook framework

-

- ### Root Mechanisms and Privilege Boundaries

-

- KernelSU implements a kernel component that grants root privileges to user-space

- applications. APatch describes kernel patching through KernelPatch and separately

- identifies kernel-space modules. A root-enabled application does not thereby

- execute all its code in kernel mode: distinguish user-space credentials,

- privileged services, kernel components and their interfaces.

- [KernelSU architecture](https://kernelsu.org/guide/what-is-kernelsu.html),

- [APatch architecture FAQ](https://apatch.dev/faq.html).

-

- Compare an exact release, kernel/device, boot-image provenance and module

- configuration. Do not infer universal stock-kernel compatibility, interchangeable

- module APIs, filesystem cleanliness or detectability from a framework name.

- Android SELinux normally constrains even root processes; for a modified kernel,

- record the observed enforcement and collection trust assumptions rather than

- assuming either normal policy behavior or its total absence.

- [AOSP SELinux](https://source.android.com/docs/security/features/selinux)

-

- ### Dynamic Instrumentation and Observation Limits

-

- Frida distinguishes injected, embedded and preloaded operation. These are

- integration modes, not universal stealth levels or guarantees of early-execution

- coverage. Bind a report to the exact tool revision, target build, entry point,

- required privilege and actual evidence source.

- [Frida modes](https://frida.re/docs/modes/)

-

- | Question | Evidence to preserve |

- |---|---|

- | What boundary was crossed? | Owned debug integration, user-space process access or a privileged/kernel component; avoid treating them as equivalent |

- | What changed in the observation? | Available module/memory provenance, process lifecycle, control-channel exposure and instrumentation logs |

- | What could be missed? | Uncovered startup periods, native versus managed execution, unloaded components, unavailable logs and effects of the observer itself |

- | Is a detector conclusion justified? | Defined observable signal, exact tested configuration, benign/debug-build comparison and false-positive/false-negative limits |

-

- Packing components into one binary, moving work to a different layer or changing

- an instrumentation mode does not establish fewer observable artifacts, universal

- compatibility or guaranteed nondetection. Evaluate the complete privileged path

- and its management interface; do not infer a clean device from one absent signal.

-

- ### Local Root Indicators and Attribution

-

- Filesystem/package indicators, build properties and runtime observations may

- support a device-state hypothesis. Record how each was obtained, the observer's

- privilege and whether the observation source is trustworthy. A developer build,

- custom ROM, stale artifact or unavailable visibility can explain an indicator or

- its absence. Keep root-state assessment separate from verified attestation,

- server authorization and evidence of cheating.

-

- Review how a privileged component could affect the trustworthiness of local

- observations at the mechanism level. Do not treat a list of framework names or

- local checks as proof of a specific hiding method, or rank systems by a fixed

- stealth tier. Sources for these privilege/instrumentation corrections reviewed:

- 2026-09-09.

-

- ### Zygisk Modules

-

- ```cpp

- // Zygisk module structure

- class Module : public zygisk::ModuleBase {

- void onLoad(zygisk::Api *api, JNIEnv *env) override {

- this->api = api;

- this->env = env;

- }

-

- void preAppSpecialize(zygisk::AppSpecializeArgs *args) override {

- // Before app loads

- }

-

- void postAppSpecialize(const zygisk::AppSpecializeArgs *args) override {

- // After app loads - inject here

- }

- };

- ```

-

- ### Android Protections

-

- #### Common Protectors

- - **Tencent ACE**: Chinese market protection

- - **AppSealing**: Commercial protection

- - **DexGuard/ProGuard**: Obfuscation

- - **Arxan**: Enterprise protection

-

- ## iOS Security

-

- ### Analysis Tools

- - **Hopper**: Disassembler

- - **IDA Pro**: Industry standard

- - **class-dump**: Objective-C header extraction

- - **Frida**: Dynamic instrumentation

- - **Clutch/dumpdecrypted**: App decryption

-

- ### Jailbreak Tools

- - **H5GG**: iOS cheat engine

- - **Flex**: Runtime patching

- - **Cycript**: Runtime manipulation

- - **ceserver-ios**: Cheat Engine for iOS

-

- ### Hooking (Jailbroken)

- ```objc

- // Using Logos (Theos)

- %hook TargetClass

- - (int)targetMethod:(int)arg {

- int result = %orig;

- return result * 2; // Modify return

- }

- %end

- ```

-

- ### Non-Jailbreak Techniques

- - **Sideloading**: Modified IPAs

- - **Enterprise certificates**: Custom signing

- - **AltStore**: Self-signing tool

-

- ## Unity Mobile Games

-

- ### IL2CPP Analysis

- ```

- 1. Locate libil2cpp.so (Android) or UnityFramework (iOS)

- 2. Find global-metadata.dat

- 3. Run IL2CPPDumper

- 4. Generate SDK/headers

- 5. Hook target functions

- ```

-

- ### Mono Analysis

- ```

- 1. Extract managed DLLs

- 2. Decompile with dnSpy/ILSpy

- 3. Modify and repackage

- 4. Or hook at runtime

- ```

-

- ### Common Targets

- ```

- - Currency/coins values

- - Player stats (health, damage)

- - Inventory manipulation

- - Premium unlocks

- - Ad removal

- ```

-

- ## Unreal Mobile Games

-

- ### Analysis Approach

- ```

- 1. Identify UE version

- 2. Dump SDK using appropriate tool

- 3. Locate GObjects, GNames

- 4. Find target functionality

- 5. Apply memory patches or hooks

- ```

-

- ## Overlay Rendering (Android)

-

- ### Surface-Based

- ```cpp

- // Native surface overlay

- ANativeWindow* window = ANativeWindow_fromSurface(env, surface);

- // Render using OpenGL ES or Vulkan

- ```

-

- ### ImGui Integration

- - Zygisk + ImGui modules

- - Surface hijacking

- - Direct framebuffer access

-

- ## Network Analysis

-

- ### Authorized Transport Observation

-

- Use existing captures or an owned test build to distinguish connection metadata,

- TLS validation and decrypted application content. A proxy or packet record only

- covers traffic visible at that observation point; it does not establish that

- all networking libraries or the release build use the same trust configuration.

-

- ### Trust Configuration and Pinning Evidence

-

- For Android, inspect the actual networking stack, target SDK, manifest-linked

- Network Security Configuration, domain policy and build variant. Android's

- documented default CA trust changes with the target SDK; debug-only trust anchors

- apply when the application is debuggable. A successful debug capture cannot

- establish release-build trust or pinning behavior.

-

- A replacement Java trust manager is not a universal TLS or certificate-pinning

- analysis method: custom/native stacks and independently configured checks require

- their own contracts and evidence. Preserve the test configuration, relevant

- validation result and unobserved paths. Review authorized debug configuration

- and release checks without weakening production trust or publishing a bypass

- recipe. Consult iOS-specific trust contracts separately.

- [Android Network Security Configuration](https://developer.android.com/privacy-and-security/security-config),

- [unsafe trust-manager guidance](https://developer.android.com/privacy-and-security/risks/unsafe-trustmanager).

-

- Source reviewed: 2026-09-09.

-

- ## Anti-Cheat on Mobile

-

- ### Common Systems

- - **Tencent ACE**: Chinese games

- - **NetEase Protection**: NetEase games

- - **Custom solutions**: Per-game implementations

-

- ### Detection Methods

- ```

- - Root/jailbreak detection

- - Frida detection

- - Emulator detection

- - Integrity checks

- - Debugger detection

- - Hook detection

- ```

-

- ### Detection Finding Review

-

- For a claimed integrity failure, identify the signal, observer, required attacker

- capability and the boundary affected. Correlate available package, process,

- platform and server evidence with legitimate debug/development use. Missing

- instrumentation telemetry or one passed local check does not establish an

- unmodified device or a successful concealment technique. Retain collection

- limits and uncertain attribution in the final finding.

-

- ## eBPF-Based Tools

-

- ### Tracing & Hooking

- ```

- - stackplz: eBPF-based stack trace tool for Android

- - eDBG: eBPF-powered debugger for Android processes

- - tracee: Aqua Security's eBPF runtime security tool (Linux/Android)

- - eBPF hooking: attach to tracepoints, kprobes, uprobes without kernel module

- ```

-

- ### Advantages Over Traditional Approaches

- ```

- - No kernel module compilation required (runs in eBPF VM)

- - May work on compatible GKI kernels when BPF features, BTF, privileges,

- SELinux policy, lockdown state, and required attach points permit it

- - Can avoid a custom kernel module, but programs, maps, links, helpers, and

- privileged loader activity still create an observable surface

- - CO-RE improves portability across kernels with compatible BTF/type changes;

- it does not guarantee run-everywhere behavior

- - The verifier rejects many unsafe programs and reduces risk, but verifier,

- helper, JIT, driver, and kernel bugs can still cause failures

- ```

-

- ## Android Kernel Driver Development

-

- ### Development Patterns

- ```

- - Loadable kernel module (LKM) for older kernels

- - GKI-compatible modules via vendor_dlkm partition

- - Kernel build scripts: build from AOSP source or vendor BSP

- - Device Trees: hardware description for board-specific drivers

- ```

-

- ### Common Use Cases in Game Security

- ```

- - Process memory access: /dev/custom_mem → read/write target process

- - Syscall hooking: __NR_read, __NR_write interception

- - Binder hooking: intercept IPC transactions

- - GPU memory inspection: access GPU buffers directly

- ```

-

- ### Android Kernel Source

- ```

- - AOSP Common Kernel (ACK): google/common branch

- - GKI: versioned Generic Kernel Image model; capabilities and module rules vary

- across Android releases and OEM implementations

- - Vendor-specific: Qualcomm (CodeAurora), MediaTek, Samsung Exynos

- - Build system: build/build.sh or Bazel-based (newer)

- ```

-

- ## HarmonyOS / OpenHarmony

-

- ```

- - HarmonyOS (Huawei): abc file format for compiled apps

- - arkdecompiler: decompile HarmonyOS abc bytecode

- - OpenHarmony: open-source base, growing ecosystem

- - Security model differs from Android: distributed capabilities

- - Reverse engineering challenges: new bytecode VM, different IPC

- ```

-

- ## Android CVE Research

-

- ### Application-Level CVEs

- ```

- - WebView RCE (CVE-based exploit chains)

- - Intent redirection / deep link abuse

- - Content provider data leaks

- - Serialization vulnerabilities (Parcel, Bundle)

- ```

-

- ### Kernel-Level CVEs

- ```

- - Use-after-free in Binder driver

- - Privilege escalation via ion/DMA-BUF

- - GPU driver vulnerabilities (Adreno, Mali, PowerVR)

- - SELinux policy bypass chains

- - Reference: Android Security Bulletins (monthly)

- ```

-

- ## Emulator Considerations

-

- ### Android Emulators

- - **LDPlayer**: Gaming focused

- - **BlueStacks**: Popular emulator

- - **NoxPlayer**: Game optimization

- - **MEmu**: Android gaming

-

- ### Emulator Detection

- ```

- - Build.FINGERPRINT checks

- - Hardware sensor verification

- - File system characteristics

- - Performance timing

- ```

-

- ## Resource Organization

-

- The README contains:

- - Android hooking frameworks

- - iOS jailbreak tools

- - Memory manipulation utilities

- - Root/jailbreak bypass tools

- - Mobile anti-cheat research

- - Emulator resources

-

- ## Repository Navigation

-

- For project selection, load [repository resource selection](references/repository-resources.md) on demand. Use the shared [repository navigation](../overview/references/repository-navigation.md) for local discovery layers, filename case, missing snapshots and currentness. Generated descriptions and wiki pages are discovery aids, not independent evidence.

-

- For topic discovery, see the [compiled mobile-security overview](../../../wiki/overviews/mobile-security.md). Verify its technical claims against primary sources and the actual target context.

-

- ## 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/mobile-security.md](../../../wiki/overviews/mobile-security.md).

- Raw URL: [mobile-security overview](https://raw.githubusercontent.com/gmh5225/awesome-game-security/refs/heads/main/wiki/overviews/mobile-security.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.