User-reported: the decoded CNTR (0x1830A44E41 ≈ 104 billion) cannot
be the real counter — the OTA platform shows ~200 for that card.
Root cause: per TS 102 225 Table 2 note 1, when SPI indicates
ciphering the whole block from CNTR through the secured data
(CNTR, PCNTR, RC/CC/DS, secured data) is ENCRYPTED. Only CPI, CPL,
CHI/CHL, SPI, KIc, KID and TAR travel in the clear. Our decoder
parsed the ciphertext bytes as if they were the real CNTR/PCNTR/RC
and presented them as such — misleading (the true values are only
recoverable after 3DES decryption with the card's keys).
Fix:
- _decode_secured_packet: emit 'ciphered': True when SPI1.b3 is set
(wire hex values kept for reference); docstring documents the
ciphered block.
- _decode_response_packet: accepts ciphered (command SPI2.b5, PoR
ciphering) and flags the response likewise; database context now
carries por_ciphered from the ENVELOPE so the GET RESPONSE PoR
inherits it. Standalone SMS-SUBMIT PoRs carry no SPI — state
unknowable, defaults to False (documented).
- Frontend: CNTR/PCNTR/RC-CC-DS labels get "(encrypted)" when the
respective packet is ciphered (command, response, and ENVELOPE
response renderings).
Tests: +4 TestSecuredCiphering (ciphered flagged, unciphered plain
CNTR e.g. 200, response flag, PoR-via-context). 348 total. Version
1.18.0, SW cache simtrace-analyser-v26.
catarrh
840e233baf