Four Ways Configuration Becomes a Payload

The lifecycle exposure described so far is a location, not yet an attack explanation. PHANTOM asks what kinds of metadata can cross that boundary and still look acceptable until a privileged consumer must materialize it. This chapter turns the study’s method into a practical taxonomy: three conditions define an effective vector, and four primitives describe how values exceed downstream assumptions without requiring application code to run.

Finding the surface behind the documentation

A security review that reads only the public manifest or bundle reference sees an important but incomplete surface. Documentation tells developers how to declare ordinary application behavior. It does not necessarily enumerate every entry accepted by a build tool, every extension-specific value a system daemon reads, or every piece of signing information that a package manager later returns through an API.

PHANTOM addresses that gap in two phases. The first phase begins with documented fields. For Android, the researchers mapped documented manifest attributes across the documented tags. For iOS, they began with core Info.plist fields used for application identity and system integration. They then tested otherwise valid packages with values designed to cross relevant resource boundaries. The aim was not to make the package syntactically invalid. It was to ask whether a valid-looking field could be accepted at one stage and become too expensive at a later stage.

The second phase looks for surfaces that documentation alone may miss. On Android, the study compared the public manifest reference with the AOSP attrs_manifest.xml file used by the Android Asset Packaging Tool. That comparison exposed tags and attributes recognized by the toolchain but absent from the developer-facing reference. On iOS, the researchers tested metadata in documented App Extension families because an extension has its own bundle and its own system-facing consumers. They also examined Android signature metadata, including structures associated with multiple signers and key rotation, as a separate source of package information that can be serialized with application data.

This distinction between documented and implemented surface matters for a reason beyond counting fields. A documented field has usually been considered from the perspective of ordinary application construction. An undocumented or extension-specific field may still be accepted and propagated, but its downstream behavior may have received less attention. A signing structure may look even more trustworthy because it is associated with cryptographic identity. In all three cases, the relevant question is the same: can an external package control the value, and where does the platform later carry it?

The study reports 979 evaluated configuration fields: 498 in Android and 481 in iOS. The Android total combines documented manifest fields, undocumented entries found in the AOSP schema, and two signature structures. The iOS total includes core fields and extension-related coverage. Phase 2 contributed 33 of the 65 vectors reported in the study.