name: mobile-platform-vulnerability-research description: "Use when hunting new vulnerabilities in the latest stable Android or iOS platform and widely deployed OEM components, including zero/one-click parsers, messaging and media services, Binder/XPC IPC, application sandboxes, system services, baseband/connectivity, kernels/drivers, secure services, and mobile browser-to-OS chains." version: 1.0.0 license: MIT metadata: package: unleash-skills author: NetVar1337/unleash category: re upstream: C:\Users\Admin\.agents\skills\mobile-platform-vulnerability-research\SKILL.md

Bundled with Unleash skills pack. Source: C:\Users\Admin\.agents\skills\mobile-platform-vulnerability-research\SKILL.md

Mobile Platform Vulnerability Research

Priority Model

Prefer:

1. zero-click network/message/media processing;
2. one-click browser, document, link, or attachment RCE;
3. application/renderer sandbox escape to system service or kernel;
4. cross-app or cross-profile data/authority compromise;
5. baseband, Wi-Fi, Bluetooth, NFC, or nearby-service compromise;
6. pervasive OEM system components with privileged parsers;
7. secure-world/TEE boundary bugs with practical reachability.

Ordinary app-local bugs and WebView XSS do not qualify without a platform boundary.

Phase 1: Pin a Current Device Matrix

Record:

• device model/SKU/region and hardware revision;
• latest stable OS build and security patch level;
• bootloader/baseband/modem, Wi-Fi/Bluetooth firmware;
• kernel build/config and vendor modules;
• system component/APEX/Mainline or equivalent independently updated package versions;
• browser/WebView engine version;
• OEM framework and carrier package versions;
• lock state, user/profile setup, enabled radios, and default apps;
• clean reset/flash procedure and image hashes.

Android/AOSP latest is not enough for an OEM-only bug; iOS version alone may not identify modem or WebKit component state. Prove exact shipped bytes.

Completion criterion: target can be reflashed/reset to a hash-identified current stable state.

Phase 2: Map Automatic and Low-Interaction Inputs

Remote/ambient

• SMS/MMS/RCS/iMessage-like messaging;
• push notification payloads and attachment previews;
• voice/video calls and signaling;
• image/audio/video/font/document thumbnailing and indexing;
• email/calendar/contact/vCard parsing;
• Wi-Fi management/action frames and provisioning;
• Bluetooth advertisements/profiles, NFC, UWB, nearby sharing;
• baseband control/data messages;
• captive portal and network discovery.

App-to-system

• Android Binder/AIDL/HIDL and content/provider intents;
• iOS XPC/Mach services, extensions, URL/document handlers;
• media, graphics, camera, codec, accessibility, clipboard, keystore, package/install, backup/restore services;
• shared memory, file descriptors, surfaces, handles, and capability tokens;
• OEM services exposed to ordinary or isolated apps.

For each input record interaction, lock-screen reachability, network proximity, parser process, sandbox, and final privilege.

Phase 3: Build the Boundary Graph

Trace:

remote bytes or app request
 -> framework decoder/binding
 -> native parser/service
 -> IPC hop/shared object
 -> privileged system/driver/secure service

Record:

• caller identity: UID, package, entitlement, sandbox/profile;
• service permission/SELinux/seatbelt checks;
• object/handle ownership and lifecycle;
• deserialization, lengths, offsets, counts, and types;
• async callback/cancellation and process death;
• user/profile/device-unlock state;
• kernel or firmware interface reached.

Completion criterion: every trust transition has an enforcing component and expected invariant.

Phase 4: Harness by Surface

• parser library harness for media/document/message formats;
• Binder/XPC client generated from interface metadata or runtime introspection;
• compromised-app/isolated-process harness for sandbox boundaries;
• radio protocol simulator or shielded test setup for connectivity;
• emulator/simulator for early triage, then physical current hardware;
• snapshot/reflash automation and tombstone/panic collection;
• differential tests across OEMs or OS releases.

Use sanitizers in source builds where meaningful, but confirm on release binaries. Preserve complete request sequences and device state.

Phase 5: High-Yield Campaigns

Zero-click parsers

• incremental/streaming decode and truncation;
• metadata/thumbnail/preview paths differing from full open;
• nested containers and parser handoff;
• huge dimensions/counts and integer conversion;
• hardware codec/GPU driver buffers;
• attachment cleanup and indexing races;
• processing while locked or before first unlock.

IPC and sandbox escape

• missing caller/entitlement/permission checks;
• identity checked before async work and lost later;
• stale Binder/XPC object after client death;
• shared-memory size/offset mutation;
• file descriptor/handle rights and object-type confusion;
• confused deputy across work/personal profiles;
• isolated process reaching methods intended for trusted system apps;
• service restart and generation-ID reuse.

Kernel/driver

• ioctl lengths and nested pointers;
• graphics/media/camera/DSP command buffers;
• async completion after close/free;
• mapping and cache coherency;
• integer overflow in allocation versus DMA;
• race across suspend/resume and process death.

Connectivity/baseband

• negotiation/state downgrade;
• fragment/reassembly and timer state;
• duplicate/reordered control messages;
• malformed capability lists;
• cross-layer length disagreement;
• host/modem shared-memory and diagnostic channels.

Phase 6: Impact and Chain Analysis

Separate:

• parser process code execution;
• app/renderer sandbox escape;
• system/root/kernel code execution;
• secure-world/key compromise;
• cross-profile/tenant data access;
• persistence and lock-screen/first-unlock implications.

Record mitigations: PAC, MTE, CFI, pointer hardening, hardened allocators, SELinux/seatbelt, seccomp, entitlement checks, kernel isolation, and reboot persistence.

A crash in a privileged media process may still be contained; identify the remaining boundary.

Phase 7: Stable and Deployment Validation

• retest after monthly patch/Mainline/APEX/WebView updates;
• test clean device, upgraded device, and relevant lock/profile states;
• verify OEM/carrier variants using the affected code;
• establish widespread deployment for OEM-only components;
• compare emulator and physical hardware behavior;
• search advisories, fuzz trackers, OEM bulletins, and upstream commits for novelty;
• avoid pre-release-only conclusions.

Variant Hunting

Search:

• preview/indexer versus full application parser;
• app framework and baseband/firmware copies of codecs;
• AOSP versus OEM service forks;
• work-profile, guest-user, lock-screen, and pre-unlock paths;
• same AIDL/XPC interface implemented by sibling services;
• hardware and software codec paths;
• fixes applied upstream but absent from current OEM branch;
• independently updated modules lagging the platform fix.

Common Pitfalls

1. Recording OS version but not patch level and modular components.
2. Calling emulator-only behavior a device vulnerability.
3. Claiming zero-click without proving default automatic processing.
4. Treating app crash as sandbox escape.
5. Ignoring lock, profile, and first-unlock state.
6. Testing an OEM component without deployment evidence.
7. Losing full IPC/radio sequence needed for replay.
8. Using beta OS findings without stable reproduction.

Verification Checklist

• [ ] Device/SKU/hardware and every relevant component version recorded
• [ ] Latest stable and current patch level proven
• [ ] Automatic/interaction reachability established
• [ ] Boundary graph and enforcing identities complete
• [ ] Harness reproduces on physical release device where required
• [ ] Root cause and process/privilege level established
• [ ] Remaining sandbox/kernel/secure boundary identified
• [ ] Lock/profile/first-unlock states tested
• [ ] OEM/deployment relevance proven
• [ ] Monthly/component update and novelty gates pass