Four Workflows, Four Kinds of Consequence

The Android RW weakness becomes concrete only when the handler’s next decision is examined. This chapter applies the origin-versus-routing test to four documented workflows: Alipay payment, Huawei AI Life provisioning, Samsung Galaxy Wearable pairing, and YouTube Studio VR configuration. The comparison shows why one platform-level entry flaw can have very different consequences—and why none of the cases should be enlarged into a universal claim about every release, device, or user.

Payment and network attachment: when entry crosses into a sensitive environment

Alipay: a payment path with explicit experimental limits

The Alipay case begins with an exported Reader/Writer handler used for the app’s NFC tap-to-pay flow. In the intended experience, a point-of-sale terminal supplies an order through a physical NFC interaction, the phone reads that order, and Alipay enters its payment workflow. The physical contact is doing more than transporting bytes. It is the user’s apparent signal that a particular payment interaction is beginning.

The researchers showed that the entry into this flow could be reached by a software-constructed, routing-matching discovery request even though no terminal or tag was in proximity at trigger time. That is the platform-level observation. It demonstrates that the Activity launch itself does not require a contemporaneous physical tap when the handler is exposed and the request satisfies its routing conditions.

Payment completion required additional conditions. In the controlled setup, the researchers used their own equipment and accounts to obtain terminal-generated order content and transferred that content to the test device through an auxiliary channel. They also used a password-free NFC-payment configuration. Under those stated conditions, the flow proceeded to a transaction-visible completion, subject to a reported ¥1,000 per-transaction cap.

Those details change how the result should be understood. The finding is not that any local application can make every Alipay account pay without authentication. It is not that the forged entry bypasses all server-side risk controls. The paper reports that Alipay acknowledged the issue and said additional risk-control measures protect the affected functionality. The demonstrated result is narrower but still important: a local app without NFC hardware access could satisfy the condition that Alipay’s NFC entry treated as evidence of a physical tap, and the researchers could drive the configured flow to completion in controlled accounts.

This case separates two kinds of payment security. The first is protection at the platform entry boundary: should the payment Activity be allowed to believe that an NFC discovery occurred? The second is protection in the payment system: is the order valid, is the account permitted to pay, is the transaction within policy, and is further authentication required? The second layer can limit the consequence without repairing the first. A payment service may catch or reject a forged attempt, but the app still has an origin assumption that should not have been silently promoted from a route match to proof of proximity.

The case also shows why “handler reached” and “money moved” must remain separate claims. A study that stopped after observing the Activity launch would still have demonstrated the core platform weakness.