Overview
PHANTOM examines how Android manifests and iOS Info.plist metadata can become operating-system inputs before application code runs. Across installation, persistence, enumeration, extension registration, and boot, the series traces how long strings, repeated elements, indirect resources, and Android signing structures can exceed downstream limits. It distinguishes package authenticity from resource safety, shows why Binder, persistence encoders, Jetsam, and recovery behavior produce different outcomes, and maps defenses to parser, serialization, enumeration, and boot boundaries. The study reports 65 vectors among 979 evaluated fields, with 25 classified as capable of complete system failure in tested paths; those figures describe its corpus rather than universal mobile risk or store-review bypass.
Learning outcomes
- PHANTOM reports 65 vectors among 979 evaluated Android and iOS configuration fields; the figures describe its tested corpus.
- A package signature authenticates origin and integrity but does not bound metadata’s later resource cost for every consumer.
- Long strings, repeated elements, indirect resources, and Android signer structures create distinct downstream growth paths.
- Privileged services can encounter metadata during installation, queries, extension registration, or boot before app code runs.
- Defenses must bound data at parsing, contain later failures, and make recovery change the triggering package state.
Keywords
Preview every chapter · Unlock full text, audio, and video from chapter 4
PlansFAQ
How can PHANTOM’s signed mobile package affect the OS before app code runs?
PHANTOM shows that a signed package can affect the OS when privileged services parse, store, or reuse its metadata before launch. Signing authenticates origin, not resource safety.
What kinds of mobile metadata can become a PHANTOM vector?
PHANTOM identifies long strings, repeated elements, indirect resource references, and Android signature-chain structures as four growth primitives. Each requires attacker control, a privileged path, and insufficient validation.
Why do Android and iOS produce different PHANTOM failures?
They use different processing and recovery boundaries: Android cases involve Binder or Modified UTF-8 persistence, while iOS cases involve Jetsam and boot-time daemon supervision.
How should platforms defend against PHANTOM-style metadata failures?
Platforms should bound values, repeated elements, aggregate size, and signer data at parsing, then isolate failures and quarantine packages that retrigger boot problems. Distribution scanning remains defense in depth.