Mobile Security

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 before treating a root, hook, emulator, or integrity signal as attribution.

Mobile Trust Boundaries and Integrity Evidence

Use game-server-security for verified purchases, entitlement transitions, account authorization and retries. Use game-supply-chain-security 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
• Validate Play Integrity request details, identity, binding, and freshness before interpreting app/device/account verdicts on the backend. Android integrity verdicts
• App Attest requires server verification of attestations/assertions, including challenge and counter handling. Keep development and production context separate. Apple server validation
• For owned-app transport tests, distinguish debug-only trust anchors from release configuration and verify the packaged result. Android network security configuration

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

# 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

// Via /proc filesystem
int fd = open("/proc/pid/mem", O_RDWR);
pread64(fd, buffer, size, address);
pwrite64(fd, buffer, size, address);

Hooking Frameworks

Frida

// 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, APatch architecture FAQ.

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

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

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

// 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)

// 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

// 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, unsafe trust-manager guidance.

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 on demand. Use the shared repository navigation 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. 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 for topical synthesis and cross-project connections. Wiki schema describes its structure. Generated wiki pages are discovery aids; follow their original citations before adopting technical claims.

Raw catalog: wiki/index.md. For this domain, read wiki/overviews/mobile-security.md. Raw URL: mobile-security overview.

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 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.

2. Repository Descriptions

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

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. 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:

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

Example: bgfx archive. 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 adds the optional read-only indexer, case-ambiguity handling and maintenance details; it supplements this Data Source section rather than replacing it.