Overview
This series examines Android’s NFC Reader/Writer dispatch: an NFC-shaped request can reach an exposed handler without the app being able to verify a fresh physical discovery. It separates discovery, routing, entry, visibility, and downstream effect; measures presence, manifest exposure, and confirmed delivery; compares four workflows; and weighs OS origin binding against developer hardening. The evidence supports a conditional local-app reachability finding, not universal payment compromise or harm across devices and releases.
Learning outcomes
- An Android RW handler launch establishes routed delivery, not a fresh physical tap, user intent, visibility, or completed business effect.
- TDFA can reach an exposed Reader/Writer handler through a software-created NFC-shaped request when matching and component-start conditions allow it.
- The four case studies connect the same entry weakness to controlled payment completion, Wi-Fi change, user-mediated pairing, and persistent VR configuration under stated conditions.
- In a Google-Play-scoped snapshot of 76,333 popular apps, 928 declared RW handlers; 498 of 597 installable, testable RW apps had confirmed delivery.
- An OS origin-binding rule could restore provenance; app restrictions and downstream gates mainly reduce exposure or consequences.
Keywords
Preview every chapter · Unlock full text, audio, and video from chapter 4
PlansFAQ
Does an Android NFC handler launch prove a physical tap?
No. Under the analyzed Android Reader/Writer design, a handler launch establishes routed delivery but not a fresh tag discovery or user intent.
What does the Tag-Dispatch Forgery Attack (TDFA) do?
TDFA is a local-app attack that can reach an externally startable Android Reader/Writer handler with a software-created NFC-shaped request, without NFC hardware interaction at trigger time. It does not guarantee that every workflow completes.
How widespread is confirmed Android NFC handler delivery?
In the paper’s Google-Play-scoped snapshot, 498 of 597 installable and testable RW apps had confirmed delivery to at least one handler. The result measures reachability in that environment, not harm or behavior across every release.
What can a forged Android NFC entry do?
Its consequence depends on app logic and later gates: under the reported conditions, cases included controlled payment completion, Wi-Fi network change, pairing that still required user confirmation, and persistent viewer-parameter changes.
How should developers protect Android NFC Reader/Writer handlers?
Developers should avoid exporting RW handlers unless needed and add explicit confirmation, freshness or state checks, identity validation, and safe unsolicited-entry handling before sensitive effects. These controls reduce exposure or consequences; only an OS origin guarantee can restore provenance.