How a locked iPhone could be tricked into paying any amount, to any reader

In this blog, we are going to break down how a hidden signal in Apple Pay’s transit feature allows anyone to turn a locked iPhone into an unlimited, unauthenticated payment method without any fingerprint, Face ID or PIN.

Background: Express Transit and CDCVM

Standard EMV (Europay, Mastercard and Visa) contactless payments requires Cardholder Verification such as Face ID, fingerprint, or a passcode before Apple Pay will authorize a transaction. In EMV terms, this is called CDCVM (Consumer Device Cardholder Verification Method), and its status is meant to be sent back in the cryptographic data the phone sends back to the card reader.

IOS 12.3 released May 2019 [1] introduced an exception to this: Express Transit. This feature, when utilized on an iPhone, allows the device to tap through transit ticket barriers (Transport for London (TfL) being the flagship deployment), without any CDCVM steps and while being locked. It basically lets you use your transit card, pass, or credit card to ride public transport with just a tap. You do not need to wake or unlock your phone, use Face ID or Touch ID, or open an app.

The security question this raises is straightforward: if a locked iPhone can authorize payment with zero user interaction, what mechanism prevents that exception from being triggered by something other than a geniune transit gate?

First som important terms

Before delving into details regarding the attack, it helps to know what is actually being communicated between your phone and a card reader during a tap. It is not just ”here is my card number”, instead it is a small conversation and a few specific pieces of that conversation are what this whole attack revolves arround:

• TTQ (Terminal Transaction Qualifiers): A short message the reader sends to the card at the very start of a tap. Think of it as the reader introducing itself: ”here is what kind of reader I am, and here is what I need from you”. One part of this message can say ”I am okay processing this transaction while offline” which is useful for things like subway gates that don’t always have live internet. Another part says ”I support standard EMV payments”.
• CTQ (Card Transaction Qualifiers): The reverse of TTQ, which is a short message the card or phone sends back to the reader, describing what is already been verfied. The important part of this one is a single yes/no flag: ”has the user already confirmed their identity (fingerprint, Face ID, PIN, doesn’t matter which)”. If this says ”yes”, the reader is allowed to skip asking for further verification, even on a large payment.
• IAD (Issuer Application Data): Unlike the two fields above, the IAD is not simply a plain message passed between parties. It contains issuer specific information that is included within the card’s cryptographically generated transaction data, meaning its contents are authenticated by the Application Cryptogram and cannot be modified without invalidating the transaction. The IAD can contain information about whether the user successfully performed device based cardholder verification (such as fingerprint or Face ID authentication). In other words, while the CTQ makes an unprotected claim that verification occurred, the IAD provides the cryptographically authenticated record that can be used to verify whether that claim is genuine.
• MCC (Merchant Category Code): A standard code identifying what kind of business a card reader belongs to (a code for ”electronics store”, a different one for ”public transit”, and so on). It’s reported to the bank when the transaction is settled [4].

Of course there are other parameters and messages that are communicated between the card and the reader but we will only focus on the ones utilized for the attack so keep these four in mind. The whole vulnerability comes down to two of these (TTQ, CTQ) which are easy to fake, and two of these (IAD, MCC) exist specifically to catch that kind of tampering but one major payment network wasn’t actually checking them.

Reverse Engineering the trigger condition

Researchers at the University of Birmingham [2] captured transaction traces between locked iPhones and live TfL gate readers at several London Undergound stations by utilizing a Proxmark RDV4 fitted with an HF antenna. Analysis of the traces revealed a static, non-standard 15-byte message transmitted by the TfL readers immediately before the normal ”hello” signal every contactless reader sends.

This sequence, referred to as the ”magic bytes” turned out to be the entire mechanism by which Apple Pay distinguishes a transit reader from any other card terminal. Replaying it at a locked iPhone by utilizing a Proxmark for example was sufficient to unlock Apple Pay’s transaction flow for both Visa and Mastercard cards, with no biometric or passcode attempt.

(The exact bytes were kept private for ethical reasons)

From trigger to fraud

Unfortunately, triggering the unlock alone by sending the magic bytes to an iPhone did not yield a completed transaction with a normal shop terminal, a plain replay would stall mid transaction. Byte level analysis [2] of the Visa traces identified two flags that had to be set for the transaction to proceed, both inside the TTQ field. Again, TTQ is a byte of data sent by the reader to the card at the very start of the transaction, before any payment amount is exchanged. The two bits in question were:

• Byte 1, bit 6 ”EMV mode supported”: Tells the card that the reader can process a standard EMV-style contactless transaction.
• Byte 1, bit 1 ”Offline Data Authentiction for Online Authorizations supported”: This flag exists because some readers, specifically transit gate readers, don’t always have a live network connection at the exact moment of the tap (a transit barrier undergound needs to open in well under a second, it can’t wait on a round trip to a payment network). This bit tells the card ”I might be offline right now, but process this transaction as though it will be settled online later”.

A locked iPhone, once tricked into transit mode by the magic bytes , expects the reader on the other end to look like a transit gate, i.e., to have this pair of bits set. Take for example a shop terminal, shop terminals don’t set these bits when they broadcast the TTQ field to the iPhone since they are not a transit reader. However, by intercepting the real shop reader’s TTQ and flipping these two bits before forwarding it on to the phone, the relay made an ordinary shop terminal look like a transit gate from the iPhone’s point of view.

The Setup

To actually pull this off in the real world, three seperate rolls needs to be filled, each played by a different piece of hardware, all working together in real time.

Role 1: The fake transit gate (tricking the iPhone)

This job goes to a Proxmark RDV4, a small device widely used for reading, recording, and emulating cards and readers. It is roughly the size of a deck of cards, connects to a laptop over USB, and can be reprogrammed at the firmware level to send custom radio signals.

Researchers at the University of Birmingham [2] modified the Proxmark’s firmware so that when acting as a fake reader it would:

1. Send the secret 15-byte ”magic bytes” signal first to a locked iPhone near it.
2. Wait some time.
3. Then send the standard wake up command (WUPA) that every contactless reader sends.

From there, the rest of the handshake proceeds like a normal tap, the iPhone has no way to tell, at this stage, that it isn’t talking to a real TfL gate.

Role 2: The fake card

A second device is utilized, such as an Android phone which played the opposite role of the iPhone’s, mainly pretending to be a payment card presented at a geniune real world shop terminal. This Android phone uses an existing open source ”card emulation” software which lets the phone broadcast itself over NFC the same way a contactless card would, so a normal terminal treats it just like someone tapping their card.

Role 3: The relay server (the middleman)

Sitting between the Proxmark (near the victim) and the Android phone (near the shop card reader) is a laptop running a Python script [2], connected to the Proxmark over USB and to the Android card-emulator over a network socket.

The server’s job is to:

• Pass EMV messages back and forth between the two ends in real time, so the iPhone, the Android phone and the terminal could complete a transaction as if they were talking directly.
• Rewrite specific bytes as they passed through, specifically the TTQ flas described earlier before forwarding them onward to the iPhone.

Why do we need both the iPhone and the Android phone?

The thing is that the iPhone is the only device that actually holds the victim’s real payment credentials, it’s the ”money source”. But the iPhone can only talk to whatever is physically near it (the Proxmark). Meanwhile, the shop card reader, is the only place that will actually ”take money”, but it can only talk to whatever’s physically near it (the Android phone). The laptop running the relay server is what stitches these two imposters together over the internet taking whatever the iPhone says and passing it along to the shop terminal via the Android phone and vice versa.

The attack

In summary, the attack plays out like this:

1. The Proxmark sends the magic bytes + wake up command to the locked iPhone.
2. Apple Pay unlocks and begins a transaction believing it is at a transit gate.
3. Once the EMV protocol begins, messages start getting relayed from the Android phone (which is near a shop’s terminal) and gets forwarded to the relay server then the iPhone, and then the iPhone’s replies get forwarded back to the terminal via the relay server in the middle.
4. When the terminal’s request which contains the TTQ is sent back and gets captured b the relay server, the server edits the TTQ flags in it, making the ordinary shop terminal look like a transit reader to the iPhone before passing it on to it.
5. The iPhone’s request is then forwarded back, and the transaction proceeds to completion. Everyone is happy.

Removing the spending limit

At this point, fraud has been already accomplished. By utlising the attack described, transactions with the locked iPhone can be initiated, however there is a catch. Every contactless terminal, whether it is reading a plastic card or a phone runs a standard rule. Small payments go through with no proof identity while larger payments require it. At the time of the research conducted at the University of Birmingham [2] (2021-2022), the UK’s threshold was £45, this has since risen to £100 [3] and the UK is moving toward letting individual banks set their own limits from March 2026. Sweden runs the same system at a lower threshold, 400 SEK per tap, with a PIN eventually required after either a few consecutive taps or a running total of 1500 SEK.

For a phone, the proof of identity means Face ID, a fingerprint or a passcode. This is CDCVM, and it is the mobile equivalent of typing a PIN into the terminal. Whether verification happened is reported back to the terminal in the field described before, called the CTQ. Recall how the attack got started, the locked iPhone was tricked into transit mode using the ”magic bytes”, and Express Transit is specifically designed to skip verification entirely. So once the phone is in this tricked state, it geniunely never checks Face ID for example, and thus honestly reports ”not verified” in the CTQ. Under standard rule, that alone still caps the payment at the normal threshold.

But the relay server was already sitting in the middle of every message, editing them in transit, and the CTQ is not cryptographically protected, so it can be modified freely without breaking anything. By simply flipping the CTQ’s ”user already verified” flag from no to yes, the terminal just reads the flag and trusts it. With that single bit flipped, the normal spending threshold is bypassed.

Why this works on Visa but not Mastercard

The entire vulnerability comes down to one question, once the relay tells the phone a lie such as you are at a transit gate or the user already verified themselves, is there anything that can catch the lie before the bank approves the payment? Mastercard’s protocol has two separate answers to this. Visa’s at the time has none.

Firstly, the merchant type is cryptographically protected in Mastercard’s protocol. Unlike Visa, the reader sends the Merchant Category Code (MCC, which is the code identifying the type of business operating the terminal [4]) to the card during the EMV transaction. The card then includes this MCC in the Signed Dynamic Application Data (SDAD) [5], which is a cryptographic signature generated by the card that proves the authenticity and integrity of the transaction data. The SDAD digitally binds the MCC to the transaction alongside other critical fields, such as the amount, creating a tamper evident record of what information the card approved.

A relay attacker may attempt to alter the MCC before it reaches the card, causing the card to generate an SDAD containing a false merchant category. However, this does not allow the attacker to disguise the transaction without detection. The resulting SDAD contains a cryptographically authenticated claim about the MCC that the card was presented with, which can be compared against the merchant information associated with the acutal terminal. If the signed MCC does not match the registered merchant category of the terminal, the inconsistency reveals that the transaction has been manipulated and it can be rejected.

Visa’s protocol on the other hand never sends the MCC to the card at all. That means there’s no signed record the bank could use to catch a lie about the merchant type because the card was never involved in reporting it to begin with. This is why the Visa attack focuses on the TTQ as discussed before. The attacker does not need to convince the card that the merchant’s MCC is transit, they only need to make the card believe the terminal capabilities indicate a transit transacation.

Secondly, the ”user was verified” claim in the CTQ flag never gets checked against the truth either. Every card also generates a second piece of data, the IAD, which contains information about the card’s processing state, including whether CDCVM such as fingerprint or Face ID authentication was performed. The IAD is also included within the Application Crytpogram (AC) [2], meaning that its contents are cryptographically protected and cannot be altered without causing the transaction to fail.

Keep in mind that this IAD is separate from the CTQ, which is an unprotected field that also communicates whether user verification occured. Because the CTQ is not cryptographically protected, the attack described before modified its value. The way to detect such manipulation is to compare the claim made by the CTQ against the authenticated CDCVM status in the IAD.

Mastercard performs this check, Visa however, despite producing the same type of field containing the actual and geniune CDCVM status, did not use this information to validate the CTQ claim. As a result, a forged CTQ value could pass through unchecked because Visa’s backend was not comparing the unprotected claim against the authenticated data that could reveal the manipulation.

Severity and disclosure

The vulnerability was rated CVSS 7.1 (High) [2]. Apple said Visa should be validating the IAD and the MCC. Visa said this was an Apple lock-screen problem and that back-end fraud detection would catch abuse even though the researchers at the University of Birmingham repeatedly tested high value transactions on the same card and were never flagged.

As of the publication of this blog, neither company has shipped a fix, and the advice for iPhone users is to simply disable Express Transit in the settings for Visa cards. For readers interested in a deeper technical analysis of this attack and why only iPhones are vulnerable, I recommend exploring the original research conducted by the University of Birmingham [2]. Additionally, Veritasium’s youtube video offers a good explanation of the attack [6].

References

[1] How to set up Express Transit with Apple Pay for any card with iOS 12.3, https://9to5mac.com/2019/05/15/apple-pay-express-transit/

[2] Practical EMV Relay Protection, https://practical_emv.gitlab.io/assets/practical_emv_rp.pdf

[3] UK banks keep £100 limit for contactless card payments despite FCA scrapping it, https://www.theguardian.com/money/2026/mar/19/uk-banks-keep-100-limit-for-contactless-card-payments-despite-fca-scrapping-it

[4] Merchant Category Codes, https://www.citibank.com/tts/solutions/commercial-cards/assets/docs/govt/Merchant-Category-Codes.pdf

[5] The EMV Standard, https://scispace.com/pdf/the-emv-standard-break-fix-verify-3pued503e4.pdf

[6] How easy is it to steal $10,000 from a locked phone?, https://youtu.be/PPJ6NJkmDAo?si=tIMP-icSbRsoapdc