APDU Builder / Decoder
Compose and dissect ISO 7816-4 command APDUs with a SIM/UICC command layer (ETSI TS 102 221 + 3GPP TS 31.102) — Case 1–4 classification, CLA/INS decoding and status-word interpretation.
Command APDU structure
A command APDU is a 4-byte header — CLA INS P1 P2 — optionally followed by a length byte
Lc and command data, and/or an expected-length byte Le. The
class byte distinguishes classic GSM (A0) from UICC (00/80)
and carries the logical-channel and secure-messaging bits; the instruction byte selects the
operation (SELECT, READ BINARY, UPDATE RECORD, VERIFY, RUN GSM ALGORITHM, ENVELOPE, FETCH…).
Status words
Paste the response SW1 SW2 and the decoder interprets it: 9000 success,
6A82 file not found, 6982 security status not satisfied (PIN/ADM not verified),
63Cx PIN retries remaining, and the 61xx/6Cxx conventions on T=0.
FAQ
How does this differ from a generic APDU parser?
Most online APDU parsers are EMV/payments-flavoured. This one is SIM/UICC-native: it knows A0A40000023F00 selects the MF on a classic SIM, recognises the USIM/ISIM AIDs, decodes SIM-specific status words (63Cx PIN retries, 6982 security status), and labels files by FID.
What are Case 1–4?
ISO 7816-4 classifies command APDUs by whether they carry command data (Lc/Data) and expect response data (Le): Case 1 (neither), Case 2 (Le only), Case 3 (data only), Case 4 (both). The decoder classifies your APDU and explains the fields accordingly.
What's the 61xx / 6Cxx convention?
On T=0, 61xx means the card has xx bytes ready — issue GET RESPONSE with Le = xx. 6Cxx means your Le was wrong and the correct length is xx — re-issue with that Le. The status-word decoder spells both out.
Related tools
Need this at production scale?
Senior SIM/USIM/OTA consulting, applet development and operator advisory — EN/PT.