Free tool · TS 102 225 / TS 31.115
OTA secured packet decoder
Paste an OTA command or response packet and read the header: lengths, SPI security settings, KIc and KID algorithms and key versions, TAR, counter, and where the checksum and payload start.
Paste a packet, or load one of the examples above.
Checks
What the decoder checks
Decoding the bytes is the easy half. These are the conditions that make a well-formed packet fail anyway, and the decoder flags each one:
- Length consistency. CHL must count from the SPI to the end of the checksum, which is 13 octets plus the checksum length; CPL must count from the CHL octet to the end of the secured data. A mismatch is a leading cause of status 06.
- Key version equality. If the KIc and KID key versions differ and neither is zero, the card is required to reject the message with status 06.
- PoR rules. The PoR checksum type must match the command checksum type, and a ciphered PoR is only allowed when the command was both authenticated and ciphered.
- AES counter requirement. AES must be used with counter setting 10 or 11. A stale counter setting after a DES to AES migration fails here.
- Zero counter with counter checking enabled, which no card can accept as higher than its stored value.
- No security at all — no integrity and no counter, which is trivially replayable and is worth knowing before it reaches production.
If the card returned a status code, the response status decoder explains what it means, what normally causes it, and whether retrying can possibly help.
Questions
- Is anything sent to a server?
- No. The decoder runs entirely in your browser and there is no analytics call on submit. You can load this page, disconnect, and it still works.
- Does it decrypt the secured data?
- No, and it never asks for a key. It decodes the header — SPI, KIc, KID, TAR, counter, padding counter and lengths — and tells you what the security settings mean. Deciphering the payload requires the operator key material, which should not be pasted into a web page.
- Which bearer does it assume?
- SMS-PP, the SMS dialect in 3GPP TS 31.115, which is what almost all SIM OTA traffic uses. It detects the User Data Header (02 70 00 for a command, 02 71 00 for a response) and strips it. CAT_TP and TCP/IP place a CPI or RPI octet at the front instead; those are not handled yet.
- Why does my TAR show as unknown?
- Only a few TAR values are published in a form worth repeating. Card Manager is 000000, and B00010 and B00011 are widely used for RFM. Everything else is application or vendor specific, and the card vendor manual is the authority — TS 101 220 annex D allocates the ranges but not every value in use.
- The decoder flags a length mismatch. Does that matter?
- Usually yes. A wrong CPL or CHL is one of the most common causes of a card rejecting a packet with status 06, and because the length octets can be inside the checksum calculation for SMS, a wrong length can also present as a checksum failure with status 01 instead.
Why this exists
A header tells you what you sent
It does not tell you why part of a campaign failed, which cards to retry, and which are permanently stuck. That is the campaign engine and the engineering around it.