Enhanced Contactless Polling (ECP) is a proprietary extension to the ISO/IEC 14443 (A/B) standard developed by Apple.

It defines a custom data frame that a reader transmits during the polling sequence, giving an end device contextual info about the reader field, allowing it to select an appropriate applet even before any communication starts.

This extension:

• Helps to make sure that end device will only start communication with the reader if it has something useful to do with it, avoiding error beeps and card clashing;
• Increases privacy and security as it complicates brute force scanning for available passes on the device in a single tap.
• Allows automatic usage of non ISO7816-compliant passes:
  • DESFire in native mode and on card-level instead of app-level;
  • Passes without application id: Mifare Plus, Ultralight, Classic etc.
• Helps with conflict resolution when there are multiple passes with the same ISO7816 AID:
  • Allows to differentiate between Gymkit and ISO18013 even though both use NDEF AID for BLE handover.
  • Resolves routing issues between access credentials from same system manufacturer (HID, AssaAbloy, WaveLynx, Brio etc) even if they use the same AIDs.
• May serve as a form of NFC DRM, requiring reader manufacturers to pay licensing fees in order to be able to use this feature and provide better experience for Apple users.

_{ECP is also sometimes referred to as Enhanced Contactless Protocol. For explanation, look into extras section}

Express mode for most passes (apart from NFC-F and CATHAY) is implemented using ECP. That includes:

• Credit cards (For transit fallback);
• Transit cards;
• Access passes:
  • University;
  • Office badges;
  • Venue (Theme parks);
  • Apartment;
  • Hotel.
• Keys:
  • Car;
  • Home.

Other features use ECP as well:

• Value Added Services (VAS):
  Allows reader to select the VAS applet and try to get pass in advance (although failing to do so), causing pass to appear on a screen for authentication or under a payment card if one is selected.
  
• GymKit:
  Makes apple watch act as an NDEF tag for BLE handover in order to connect to supported gym equipment.
  
• Identity:
  Makes apple device act as an NDEF tag for BLE handover in order to connect to a ISO18013 verfier.

  

• CarKey Setup:
  Tells the device what car brand it is, causing a car key setup popup to appear on a screen.

  

• Field ignore:
  Makes apple devices not react (by react meaning displaying a default payment card) to a field generated by other apple devices.
• AirDrop:
  Replaces field ignore in IOS17 for background reading, used to negotiate an AirDrop session. NameDrop is a special case of AirDrop. Triggers a warp animation.

  

• HomeKit:
  Allows appliances with an NFC reader that lack card emulation mode to convey pairing info and bring up a pairing prompt when a user device is brought near to it.

Reader side:

• Can be implemented in software on most devices, provided that a low-level access to NFC hardware is available. In some cases it is required to reimplement parts of the protocol stack in software when doing so.
  HALs/Libraries for most popular chips contain separate confidential versions that include ECP support and are given to approved partners only, but homebrew solution is easy to implement.
  Proof of concept was successfuly tested using PN532, PN5180, ST25R3916(B), MFRC552 chips;
  For information about those chips and how it can be implemented, visit the Chips page;
• IOS has special reader APIs that make the device emit specific ECP frames:
  • NFCVASReaderSession, PaymentCardReaderSession for VAS;
  • MobileDocumentReaderSession for Identity;
  • When using other derivatives of NFCReaderSession, device emits Ignore frame so that other apple devices don't react to it.
• Android does not have an API for ECP, although some android-based handheld reader manufacturers have implemented this feature in their software.

Device side:

• Implemented using a customized CRS applet.
• Can be implemented on chips that allow reading raw frames in emulation mode even before selection.

Upon entering a loop, device does not answer to the first polling frame it sees, instead opting to wait and see what other technologies does the field poll for, allowing it to make a fully informed decision on what applet to select later.

When device makes a decision, it is mostly, although not in all cases (excluding keys) signified by a card image appearing along with a spinner.

Even though ECP is sent during the polling loop, device does not answer to it directly. Instead it responds to a polling frame related to technology of the pass that the device had decided to use.

When device enters the loop initially:

• In case of a full polling loop (A,B,F) it waits through one full iteration before making a decision on what applet to select:

(ENTRY) -> A -> ECP_A -> B -> ECP_B -> F -> (DECISION) -> A -> (RESPONSE)

A -> ECP_A -> (ENTRY) -> B -> ECP_B -> F -> A -> ECP_A -> (DECISION) -> B -> (RESPONSE)

• In case of partial or wierdly-ordered polling loop, behavior is different. For example:

(ENTRY) -> A -> ECP_A -> A -> ECP_A -> (DECISION) -> A -> (RESPONSE)

(ENTRY) -> F -> B -> ECP_B -> A -> F -> B -> (DECISION) -> ECP_B -> A -> (RESPONSE)

(ENTRY) -> A -> ECP_B -> F -> A -> ECP_B -> (DECISION) -> F -> A -> (RESPONSE)

(ENTRY) -> F -> F -> F -> (DECISION) -> F -> (RESPONSE)

(ENTRY) -> A -> A -> A -> (DECISION)

(ENTRY) -> A -> ECP_A -> F -> A -> ECP_A -> F -> (DECISION) -> A -> (RESPONSE)

_{Characters A, B, and F were used in examples as a shorthand for full polling frame names: WUPA, WUPB, SENSF_REQ respectively. ECP frame has different values depending on a use case _A/B suffix refers to modulation used.}

In conclusion, it seems that if reader is polling for:

• 1 technology, decision is made after third poll, response is given on the fourth;
• 2 technologies, decision is made after the second polling loop, while the response is given on the third.
• 3 technologies, decision is made after the first loop, response is given on the second.

Tests were conducted using very big intervals between polling frames. IRL if polling is faster device might respond after more frames than shown, presumably because of internal processing delay.

Although not possible during normal operation, if a reader is polling for multiple cards using express mode that use different technology qualifiers for selection, following technology priority will be applied:

1. ECP (ecp):
   1. Primary (ecp.2.tci);
   2. EMV Fallback (ecp.2.open_loop);
2. NFC-F (felica.*);
3. CATHAY (generic.type_a).

(BUG) If polling for both ECP and NFC-F, device will display NFC-F card in animation while actually selecting and emulating NFC-A/NFC-B applet.

(NOTE) In IOS17 new NameDrop frame does not follow the beforementioned rules, as device reacts to it with an animation on first iteration.

Each ECP frame consists of a header, version, payload and CRC:

     6A         XX          XX...     XX XX
  [Header]  [Version]  [Payload (n)]  [CRC]

• Header byte has a constant value of (HEX) 6A;
• Version number can be either 0x01 or 0x02;
• Payload: Version-dependant;
• CRC (Calculated via ISO14443A/B algorithm, according to the modulation used).

For V1 payload consists only of a single TCI:

  XX XX XX
   [TCI]  

• TCI is a 3 byte long identifier. More info below.

For V2 payload contains terminal configuration, terminal type, terminal subtype, and data:

     XX       XX        XX         XX...
  [Config]  [Type]  [Subtype]  [Data (n)]

• Configuration byte. Responsible for feature flags and data length. More info below;
• Type contains terminal type:
  • 0x01: Transit;
  • 0x02: Access;
  • 0x03: Identity (Handoff);
  • 0x05: AirDrop.
• Subtype depends on type. In most cases it has a value of 0x00;
• Data. Its content and availability depend on terminal type and subtype. Detailed description below.

Configuration byte is a mandatory part of a V2 ECP payload. It consists of 4 flag bits and a length nibble:

• Bit 07. Exact meaning unknown. Default value is 1. Express mode stops working if value is 0. ECP frames with this value being 0 not found IRL.
• Bit 06. Authentication not required. Default value is 1. Disables express mode if value is 0, device will bring up a matching pass for manual authentication instead. Access readers may set it when auth is required. Also set to 0 for Identity and AirDrop/NameDrop.
• Bit 05-04. Meaning unknown. Default value is 0;
• Bits 03-00. Defines length of the data part (0-15 bytes). If length does not match, device will ignore this ECP frame.

Data is a part of payload in V2, it contains TCIs and extra data:

  XX XX XX...        XX..
  [TCIs (n)]   [Extra data (n)]

• TCIs define an array of 3 byte long indentifiers. Standard allows for 0-n long TCI arrays to be conveyed depending on terminal type and subtype;
• Extra data contents depend on terminal type, subtype, and TCIs:
  • For transit it contains a mask of supported EMV payment networks for fallback;
  • For access/key readers it may contain a 8 byte long unique reader group identifier, which allows to differentiate between them for passes of the same type;
  • For HomeKit it contains pairing information;
  • For NameDrop it carries a 6 byte long BLE MAC address;
  • For AirDrop it carries a 6 byte long zeroed out value.

TCI, also referred to as Terminal Capabilities Identifier, is an arbitrary three-byte-long value that establishes reader relation to a particular pass type (Home key, Car key, Transit) or system feature (Ignore, GymKit, AirDrop, NameDrop).

The following restrictions apply to the use of TCI:

• Some TCIs are bound to a reader with particular type and subtype (which requires V2), while others trigger for all types (support V1). It is not known if this behavior is a bug or was intentional;
• TCIs intended for V1 cannot be used with V2.

TCI format is arbitrary, although several patterns related to grouping of similar functionality can be established:

• VAS: grouped with the last byte having a value of 0x00, 0x01, 0x02, 0x03 depending on mode;
• Access (Car/Home/University/Office/Venue): First byte is always 0x02, other two link to a particular pass provider;
• Transit: First byte is always 0x03, other two link to a particular transit agency (and their pass);
• CarKey: First byte is always 0x01. Next three nibbles serve as manufacturer identifier. Last nibble serves as reader location index. Can be seen in wallet configuration json hosted at smp-device-content.apple.com.

Note that CRC A/B, ECP Header, Configuration bytes are omitted from this table.

_{NA - not applicable; XX - any; ?? - unknown}

_{Source: Bruteforce - found by going over all config combinations; Sniffing - sniffed from a real reader;
Frames found via brute force may be working but not actually used. In case you have a real samle - let us know if it is different or the same}

Examples contain frames without CRC, which needs to be calculated according to the modulation used;

• VAS or payment:
  6a01000000

       6a         01      000000 
    [Header]  [Version]   [TCI]  
  

• GymKit:
  6a01c30000

       6a         01      c30000 
    [Header]  [Version]   [TCI]  
  

• Ignore
  6a01cf0000

       6a         01      cf0000   
    [Header]  [Version]   [TCI]  
  

• Access: Hotel: Hilton:
  6a02c3020002ffff

       6a         02        c3       02      00      02ffff  
    [Header]  [Version]  [Config]  [Type] [Subtype]  [TCI]     
  

• NameDrop:
  6a02890500010001deadbeef6969

       6a         02        89       05      00      010001  deadbeef6969 
    [Header]  [Version]  [Config]  [Type] [Subtype]  [TCI]     [Data]     
  
    1000        1001
    [NA]  [Payload length]
  

• Access: Car Pairing: Mercedes:
  6a02c30209010201

       6a         02        c3       02      09      010201 
    [Header]  [Version]  [Config]  [Type] [Subtype]  [TCI]  
  

  _{Replace TCI for any car TCI given in the table to get pairing prompt for other brand}

Note that for examples to work 8-bit byte setting should be set in case of NFC-A, 2-byte CRC has to be appended beforehand.

If you have a Proxmark3, you can test those frames using commands hf 14a raw -akc for NFC-A and hf 14b raw -kc -d for NFC-B. After sending the frame try polling the device using the hf 14a reader -sk or hf 14b reader command.

Express mode for EMV is triggered as a fallback in case a pass for a particular transit TCI has not been found in a system. EMV brand support mask is contained in the last 5 bytes of the frame's data. At the current moment only first byte is known to be used IRL.

Following table presents an encoding scheme for the first byte (bit 00 is the rightmost), with 1 (true) in a particular position signifying support:

To find a bit responsible for your card network, you can modify a particular bit inside the mask. Afterwards, having activated a specific card brand for express mode on your device, observe if express mode will activate when brought near to a test reader.

Unlike other applet types, when EMV is used with express mode, it modifies the default applet behavior, in this case it influences what transaction parameters need to be used for a device to produce a successful transaction + checkmark.

Requirements regarding the transaction seem to be dependant on a payment network brand (as each has a separate applet implementation):

• Mastercard/Maestro:
  • MCC is in a transit category
  • TC/ARQC + CDA
• Visa:
  • Offline data authentication for online authorizations enabled
  • TC/ARQC + CDA

Other card brands may have different success conditions. If you have any info, feel free to create a PR.

When first researching the topic of ECP, in some rare situations I noticed that some brochures refer to ECP as "Enhanced Contactless Protocol". The first assumption was either that it was a gaslight to put potential researchers off the track, or that it was a simple mistake when creating the material.

When looking into some promotional documents, "Enhanced Contactless Protocol" arose once again, this time in a context of "DESFire ECP compatability mode", which rang a bell.
After a bit of brute force analysis, it turned out that DESFire protocol indeed has a special command, created only for iPhones, the sole purpose of which is to notify a device that a transaction was done successfully.
This makes me think that ECP (Polling) and ECP (Protocol) are indeed two different terms when used by Apple or their partners. In conlusion, a new explanation for ECP (Protocol) has been formulated.

Enhanced Contactless Protocol is a protocol that implements commands that allow to explicitly notify an end device about the state of a transaction, without resorting to making any assumptions about a particular command sequence or operations that need to be done in order for a transaction to be deemed successful (or not).

An NFC transaction is deemed successful when a device produces a checkmark on a screen, following with a notification in special cases.
Failure condition is displayed with an exclamation mark, and an optional error popup/device vibration.

NFC protocols can be divided into two categories, depending on how a UX success condition is determinted:

• Explicit (Enhanced Contactless Protocol).
• Implicit;

Following protocols are considered "enhanced" as they implement an explicit status commands.

_{DESFire command name was made up by me as it's newely discovered, no info about it online.}

Following protocols have implicit transaction status detection:

There are other protocols, but those were left untested as I have no access to them:

• iCLASS SE;
• SEOS.

It is not known to me if those protocols have dedicated status commands or their status is inferred implicitly. If you have access to any of them (on a device), feel free to add info in a PR.

Service mode is a feature that is available on some contactless passes. It is intended to be used when you need to give a device to someone to conduct service/help operations with the card.

After some experimentation, following changes to the behavior have been noticed:

• Device increases the grace period before it ends the NFC authorization;
• TRESET/DESELECT, implicit, explicit transaction end conditions do not end the NFC session;
• Device generates a transaction notification/receipt after the service mode period ends (No SE notifications to the SEP?).

Judging from this information, it is safe to assume that what this mode does is that it disables regular transaction status tracking and end condition fulfillment, allowing even an incompatible/slow/uniqe reader to conduct any NFC transaction sequences imaginable, with DESELECTs/TRESETs and so on. Extra time in comparison to regular NFC auth is also given in order to accomodate for all possible service proccesses and communication delays.

Best way to help is to provide more samples of ECP frames and TCIs.
Especially interesting (missing) are the following:

• TCIs of transit agencies that use EMV only (transit agency list at smp-device-content):
  • United Britain:
    • London (Possibly different for buses?);
  • United States:
    • New York (MTA);
  • Australia:
    • Sydney (NSW Transport);
  • France:
    • Dreux;
    • Lyon;
    • Montargis;
    • Nevers;
    • Tarbes-Lourdes.
  • Estonia:
    • Tartu.
  • Finland:
    • Turku.
  • Sweeden:
    • Malmo.
  • Belarus:
    • Minsk.
  • Ukraine:
    • Kyiv.
• Access (There might be many unknown variations, so any samples would be welcome):
  • University;
  • Office;
  • Venues;
  • Hotels;
  • Multi-family housing;
  • Keys:
    • Car (Real device);
• HomeKit pairing;
• Identity (Real device).

_{Frames missing from the example table but not mentioned above were collected but not yet analyzed and publicized.}

Also some unanswered questions remain, which require further analysis and testing, such as:

• If more than one TCI can be sent by a reader;
• If TCI has format, at least in some situations;
• If a TCI is 3 bytes long, or it could have a variable length (such as for transit), this question arose after seeing an "Identity" frame;
• If data part is actually considered a second TCI;
• If terminal subtype has some special encoding rules;
• What the unknown configuration byte bits are responsible for (pairing? other flags?).

If you have any findings or thoughts on this manner, feel free to discuss them in issues section.

One way to collect information about ECP is via a sniffing functionality of a device like Proxmark (Easy or RDV2/4) connected to a Proxmark client inside of Termux running on an Android phone. A couple of tidbits encountered:

• First time using the app I've encountered an issue connecting to Proxmark3 directly as Termux did not connect a device, TCPUART app had to be installed to forward serial connection over the local network to be used in Proxmark client inside of Termux;
• Some Android phones won't power Proxmark properly through direct connection. Connecting via a USB-C to USB-A dongle can help to overcome this issue.

More info on installing and running Proxmark client on your Android device here.

The command needed to collect traces is hf 14a sniff, after activating the command hold the Proxmark near a reader for a couple of seconds. In some cases it is needed to tap/touch the reader in order to wake it up as it might not poll to save energy.

After that, press a button on a device, traces will be downloaded and can be viewed with a hf 14a list command. You'll know which ones are the ones.

Some other devices might also be able to sniff the frames, but due to a lack of personal experience I cannot recommend any.

The second way of retreiving useful information could be pkpass file analysis. It can be done in the following way:

1. Extract pass files:
   1. On MacOS, from "~/Library/Passes/Cards/";
   2. On jailbroken iPhone from "~/Library/Passes/Cards/";
   3. On a non-jailbroken iPhone, via an encrypted backup extracted at path "HomeDomain/Library/Passes/Cards, extracted with an app such as iMazing, iOSBackup or similar tools.
2. Enter the folder with passes;
3. Click on any .pkpass, select "Show Package Contents"
4. Open the "pass.json" file.
5. Inside the file, search for keywords tci, openloop, ecp, transit, automatic, selection, express, as in example:

   {
     "formatVersion":1,
     "passTypeIdentifier":"paymentpass.com.apple",
     "teamIdentifier":"Apple Inc.",
     "paymentApplications":[
       {
           "secureElementIdentifier":"133713371337",
           "applicationIdentifier":"69696969696969696969",
           "applicationDescription":"Mastercard",
           "defaultPaymentApplication":true,
           "supportsOptionalAuthentication":1,
           "automaticSelectionCriteria":[
               {
                   "type":"ecp.2.open_loop",
                   "supportsExpress":true,
                   "openLoopExpressMask":"0800000000"
               }
           ],
           "supportedTransitNetworkIdentifiers":[],
       }
     ]
   }
   

   _{Other fields removed to reduce space taken}
   Here we see that a Mastercard has automatic selection creteria 0800000000 which corresponds to 00001000 in binary for the first byte of transit data mask.
   All cards can be analysed the same way.

For the most dedicated people, there is a third method of finding useful information.

It is possible to find ECP frames using sheer brute force.

To do that, you have to program an NFC reader that does the following in a loop:

1. Turn off the RF field;
2. Wait 5-10 seconds;
3. Turn on RF field;
4. Attempt to increment/modify one of the values in a ECP frame;
5. Send the ECP frame 3 times in 0.5 second intervals;
6. Attempt the ANTICOLL; If successfull continue, otherwise return to 1);
7. Observe results, save useful info (uid, ats, sak etc) try doing PPSE, DESFire functions, selecting basic AIDs.

A couple of tips:

• If you plan on running the brute force while not nearby, you can record a video of your device.
• Before brute forcing, decide what is your goal, what feature or pass you might want to activate, this will define which values you'll have to try changing.
• Do not try to bruteforce all values mindlessly. From the info available we see that most combinations are done using changing terminal type, subtype, and first and last bytes of TCI.

• This document is based on reverse-engineering efforts done without any access to original documentation. Consider all information provided here as an educated guess that is not officially cofirmed.
• If you find any mistakes/typos or have extra information to add, feel free to raise an issue or create a pull request.
• Refer to resources directory to access json database of ECP frames. This info will also be pushed to Proxmark3 repository from time to time;
• For information on implementation for particular chips or modules, refer to Chips page.

• Resources that helped with research:
  • Code analysis:
    • IOS16 Runtime Headers;
  • Apple resources:
    • Apple Developer Documentation;
    • Apple Wallet configuration json;
    • Apple mention of ECP as Enhanced Contactless Protocol;
  • Other:
    • Arduino Octopus Card Reader - sparked interest in researching Express Mode, which led to ECP;
    • Practical EMV: Express Tranit exploit - sparked initial interest in ECP research. ECP info there was redacted;
    • TFL ECP frame found by Payment Village;
  • Forums:
    • NXP mention that ECP HALs or docs are only given to licensed partners;
    • ST mention that ECP docs can be provided only after certification;
  • Device operation manuals:
    • HID mention of TCI for reader configuration (Archive);
  • Chip brochures (with ECP mentions):
    • PN7150X (Archive);
    • ST25 (Archive).
    • SM-4XXX.
  • Chip datasheets:
    • PN532 (Archive);
    • PN5180 (Archive);
    • ST25R3916 (Archive);
    • MFRC522 (Archive) - ECP support confirmed by @kupa22.
• Devices and software used for analysis:
  • Proxmark3 Easy - used to sniff ECP frames out. Proxmark3 RDV2/4 can also be used;
  • Proxmark3 Iceman Fork - firmware for Proxmark3;
  • RFID Tools app - app that can used to control OFW Proxmark RDV4 from an Android device while in field;
  • Termux - can be used to run Iceman Fork Proxmark client in field;
  • TCPUART transparent Bridge - used to connect Proxmark to a client running in Termux;
  • iOSBackup - used to extract data from an encrypted iOS backup;
  • PN532, PN5180, ST25R3916 - chips used to test homebrew ECP reader implementation.