Commit Graph

3 Commits

Author SHA1 Message Date
catarrh a37266f865 v3.25.0 review: the DF-tree ARR resolution walk-up
The live card references 6F06 from MF-tree files (MF/7F20/6F07 ->
8B 03 6F06 14), but the resolver compared only the path's first
segment: the reference fell back to the ADF.USIM copy instead of the
file's own DF copy (ISO 7816-4 5.4.3.3 / TS 102 221 9.2.7 walk-up) -
masked on this card only because all four copies are byte-identical.

- The server reads the DF.TELECOM and DF.GSM copies too (MF/7F10/6F06,
  MF/7F20/6F06 - TS 51.011), best effort.
- fcpArrRules resolves by the file's DF chain (own DF first, then
  walking up to MF); a reference with no copy in the chain resolves
  only when a single candidate exists, otherwise it stays silent.
- The implicit form prefers the file's DF copy (6F06), walking up to
  the MF copy (2F06).

Tests: the DF copy wins over the ADF copy; two candidates outside the
chain stay unresolved; a single one resolves; the implicit walk-up;
the server reads the DF-tree paths.  879 frontend + 858 Python;
sw cache simple-v424.
2026-10-10 23:26:16 +03:00
catarrh 4d87094a98 v3.24.0 review: the ARR cache on the startup init path
A card present when the server starts is initialized by the startup
path in __main__.py, which reads EF.ICCID and the network-state files
directly and never runs _apply_equipped_card - the only place the ARR
cache was read.  The cache therefore stayed empty for the whole
session (/api/arr {ok: false}) and the file manager showed no access
rules until an explicit Equip.

The startup init now reads the ARR copies in the same CAT-free window
(best effort, right after the netstate read, skipped without a readable
ICCID like the other reads) and stores them as server.arr, with an
INIT: EF.ARR log line.  A later equip still refreshes the cache through
_apply_equipped_card.

Test: the startup wiring (the read, the assignment and the import).
869 frontend + 857 Python; sw cache simple-v423.
2026-10-10 22:36:02 +03:00
catarrh b6537bd54b v3.24.0: the EF.ARR access rules in the FCP view
The file manager's decoded FCI shows the '8B' security attribute
reference (EF_ARR 2F06, record 23).  The referenced record's access
rules are now rendered as indented muted lines under that row, decoded
with the existing EF.ARR record decoder (AM_DO/SC_DO conditions).

The server reads the card's ARR copies (MF/2F06 and ADF.USIM/6F06,
best effort) once per card session in _apply_equipped_card and keeps
them as server.arr; GET /api/arr serves the cache without the card
lock, a disconnect clears it, and a write to an ARR copy through
/api/write refreshes it.  The PWA fetches it lazily per card session
(pysimArrEnsure, keyed by card_session) and resolves the reference with
the selected file's DF context: an ADF.USIM file uses the ADF's 6F06
copy, the implicit reference form too (ISO 7816-4 5.4.3.3 lookup
order).  Unresolvable references stay silent.

The '8B' decode now covers all three ISO 7816-4 Table 25 forms:
implicit ARR byte / FID + record / FID + (SEID, ARR) pairs - the pairs
form was mis-decoded as a record before.  A snapshot resolves the same
references offline from its own captured EF.ARR copy.

Tests: the three forms, the resolution (DF preference, out-of-range
silence), the snapshot path, the server read/cache/route/write-refresh.
868 frontend + 856 Python; sw cache simple-v423.
2026-10-10 00:30:45 +03:00