ATR Decoder — Answer to Reset Parser

ATR Structure Explained

The Answer To Reset (ATR) is defined in ISO/IEC 7816-3. After card power-up, the card sends the ATR byte sequence to the terminal, which uses it to configure communication parameters. Understanding ATR is essential for smart card development and debugging reader-card interoperability issues. A typical ATR is 15-33 bytes long and encodes the card's communication capabilities, supported protocols, and optional manufacturer-specific historical bytes.

ATR Byte Layout

The ATR begins with TS (Initial Character): 3B for direct convention or 3F for inverse convention. Direct convention means bit 0 is transmitted first (least significant bit) and a logic 1 is represented by a high voltage level. Inverse convention reverses both. Almost all modern cards use direct convention (3B). T0 (Format Character) follows, with its high nibble (Y1) indicating which interface characters (TA1/TB1/TC1/TD1) are present, and its low nibble (K) specifying the number of historical bytes.

Interface characters provide communication parameters: TA1 sets clock rate conversion (FI) and baud rate adjustment (DI) factors. For example, TA1=0x65 means FI=6 (F=1860) and DI=5 (D=16), yielding a baud rate of approximately 30,720 bps at 3.5712 MHz. TB1 specifies programming voltage (P, I) and erasure timing — most modern cards do not use external VPP and set TB1=0x00. TC1 sets extra guard time (N) between consecutive characters — 0xFF is a special value meaning minimum interval. TD1 indicates the transmission protocol (T=0, T=1, T=14) and whether subsequent interface characters follow. Each TDi byte may point to the next set of TA(i+1)/TB(i+1)/TC(i+1)/TD(i+1).

T=0 vs T=1: Protocol Differences

T=0 is the asynchronous half-duplex character transmission protocol — data is sent byte by byte. It is simpler and older, used in most GSM SIM cards and some banking cards. In T=0, the command APDU is sent, and the card responds with a status word (SW1/SW2). If the response data is longer than expected, the card returns 61 XX (data available, XX bytes), and the terminal must issue GET RESPONSE to retrieve it.

T=1 is the asynchronous half-duplex block transmission protocol — data is sent in blocks (IBlock, RBlock, SBlock). It supports error detection via LRC/CRC and is more robust for longer data exchanges. T=1 is used in most EMV payment cards, ID cards, and complex smart cards. T=1 requires additional parameters defined in TA(i>1): IFSC (information field size), IFSD (maximum terminal block size), and BWT (block waiting time).

Protocol Negotiation

After the ATR, the terminal and card negotiate communication parameters. In Negotiable Mode (TA2 absent or bit7=0), the terminal sends PPS (Protocol and Parameters Selection) to propose specific FI/DI values. If the card accepts, both sides switch to the agreed parameters. In Specific Mode (TA2 present, bit7=1), the card has already chosen its preferred parameters and the terminal must use them without negotiation. Most modern cards operate in Negotiable Mode and accept the terminal's PPS request.

Historical Bytes and Status

The K historical bytes (specified in T0) typically contain manufacturer info, chip model, OS version, and a status indicator. For example, a card with historical bytes 31 50 41 59 2E 53 59 53 2E 76 31 2E 30 contains the ASCII string "1PAY.SYS.v1.0" — identifying it as a Visa payWave card. For T=1 protocol cards, a TCK (check byte) follows as the XOR of all preceding bytes. T=0 protocol ATRs do not include TCK. PC/SC readers return the ATR as a byte array, which you can paste directly into this tool.

Common ATR Patterns

EMV contact bank cards often start with 3B and declare T=0 or T=1, with historical bytes containing "PAY.SYS" or the card scheme name. GSM SIM cards have compact ATRs around 15-20 bytes with T=0 only. ID cards (eID, ePassport) typically support T=1 and have longer ATRs with multiple interface byte sets. Java Card applets return the ATR of the underlying OS, not the applet. If you see an unexpected ATR, try cold-resetting the card — some cards return different ATRs depending on the reset type (warm vs cold).

Debugging ATR Issues

If a card returns an invalid or truncated ATR, the most common causes are: wrong clock frequency — some cards require 3.5712 MHz, others 4.9152 MHz; electrical contact issues — dirty or worn contacts produce garbage bytes; protocol mismatch — the terminal defaults to T=0 but the card only supports T=1; ATR too long — some readers truncate ATRs longer than 33 bytes. Always cross-reference the decoded ATR with the card's specification datasheet. Use the PC/SC function SCardGetAttrib(SCARD_ATTR_ATR_STRING, ...) to retrieve the ATR programmatically.