Commit Graph

6 Commits

Author SHA1 Message Date
catarrh 6403fb9f29 feat: C9 + memory-quota inputs, STK rejection hint (v3.6.17)
The vendor's working install script (samples/uicc/applets/STK3) sends
`C9 22 <config> EF 08 C7 02 0000 C8 02 0000 EA 26 80 0A ... 81 18
<access>` - an applet config in C9 and memory quotas in EF.  The RAM install
form now composes that prefix:

- "Applet-specific parameters (C9, hex)" -> `C9 <len> <value>`;
- "C7 / C8 memory quotas (bytes)" -> `EF <len> C7/C8 <2-byte int>` (4-byte
  above 32767, GP 9.7);
- the prefix is prepended to the raw "Install parameters (hex)" field and
  the server appends the STK part, giving `C9 EF EA`;
- `ramParamsPrefix`/`ramQuotaValue` are pure and tested (incl. the vendor's
  `EF 08 C7 02 0000 C8 02 0000` form).

Also: `updateStkParamsHex` shows a hint naming the rejection reason (TAR not
a multiple of 3 bytes / menu ID > 7F / ADF AID not 5-16 bytes) instead of
silently emptying the field, and the UICC_SPECS.md install row notes that
`CA` sits inside `EF` and `CA`+`EA` together return 6A80.

647 frontend / 496 Python green; version 3.6.17; sw simple-v290.
2026-09-28 07:56:01 +03:00
catarrh 9a3174a324 feat: card-specific ADF AID helper + priority default (v3.6.16)
- the ADF AID field gains a "From card" button: it reads the ADF.USIM FCI
  via /api/select and extracts the DF name (tag 84) with the new
  adfAidFromFci() - the AID is card-specific (the live card's is
  A0000000871002FF49FF0589, 12 bytes; the base A0000000871002 is only a
  prefix, and a shorter AID makes the card reject the access entry with
  6A80).
- the priority field defaults to 255 (0xFF) and is labelled "(0 = RFU)":
  TS 102 226 8.2.1.3.2.6 makes '00' RFU, which can break the toolkit
  registration; the builder defaults an unset priority to 0xFF and the
  chain rows follow.
- stkParamsBuild's formatted payload fields are uppercase now (the rest of
  the tool's hex is; toString(16) emits lowercase).
- tests: adfAidFromFci pinned to the live FCI, the From-card wiring, the
  updated form expectations.

643 frontend / 496 Python green; version 3.6.16; sw simple-v289.
2026-09-28 03:32:13 +03:00
catarrh 7c683fcb0a fix: UICC file-access parameters use tag 81, not 82 (v3.6.14)
TS 102 226 8.2.1.3.2.2 defines the EA inner tags as 80 (toolkit params),
C3 (toolkit DAP), 81 (UICC Access Application specific parameters) and 82
(UICC *Administrative* Access) - the plain-text spec extract had shifted the
table columns, so the access list was emitted under 82.  With the list under
82 the card rejected the ADF.USIM entry with 6A80 and the applet never got
its uicc.access.FileView rights (live 2026-09-28).

- stkParamsBuild emits the access list under 81 (the structure is unchanged:
  the admin field is coded the same way per 8.2.1.3.2.2.4).
- tests updated (81 04 / 81 0F / 81 17 expectations).

641 frontend / 496 Python green; version 3.6.14; sw simple-v287.
2026-09-28 03:07:40 +03:00
catarrh daaddf21cb fix: install-form grant hygiene + correct 82 access coding (v3.6.12)
Live findings (2026-09-28): a browser-restored Receipt Generation privilege
bit (third byte, ISD-only per GP Table 6-2) was silently sent and produced
6985, and the '82' access entries were missing the mandatory "Length of
Access Domain DAP" byte, so the card rejected the ADF.USIM entry with 6A80.

- ramResetGrants() clears the privilege / toolkit-enable / file-access
  checkboxes and refreshes the aggregates on load; ramInstallCap re-derives
  the privileges from the checkboxes at send time - no stale or
  browser-restored grant can be sent.
- the privileges aggregate emits 1 or 3 bytes, never the invalid 2-byte
  form (GP Table 11-43), in both updateRcPriv and the chain's computePriv.
- '82' entries carry the DAP-length byte: '00 01 00 00' (shared FS) and
  '<len> <ADF AID> 01 00 00' (ADF); the ADF AID is editable
  (rc-tk-adfaid, default A0000000871002 = ADF.USIM, 5..16 bytes enforced).
- tests: ram_grants.test.js (aggregate forms, the send-time derivation, the
  load-time reset) and the updated access-parameter shapes in
  stk_params.test.js.

638 frontend / 496 Python green; version 3.6.12; sw simple-v285.
2026-09-28 02:56:11 +03:00
catarrh 05c14b42dd feat: UICC file-access parameters in the install form (v3.6.11)
SIM toolkit applets installed while UICC-library applets failed at INSTALL
[for install] with 6F00 - including with the reference tool's exact install
parameters.  The asymmetry: the SIM (CA) path grants file access via the
Access Domain field (default 00 = full access), while the UICC (EA) path
sent no '82' (UICC Access Application specific parameters) at all, and the
reference's '82 00' is empty.  An applet importing uicc.access (the failing
CAP has 2 refs) can then fail inside its install().

- EA mode gains two checkboxes (RAM install form + the chain rows' toolkit
  block): "File system access (full)" appends '82 03 00 01 00' (shared file
  system + Access Domain Parameter 00 = full access, TS 102 226
  8.2.1.3.2.2.2/8.2.1.3.2.5); "ADF.USIM access (full)" adds
  '07 A0000000871002 01 00' to it.  Both default off.
- tests: the access TLV shapes (with/without the ADF entry), the form -> hex
  path with the checkbox, and the toolkit-field wiring count (16 fields).

635 frontend / 496 Python green; version 3.6.11; sw simple-v284.
2026-09-28 02:24:12 +03:00
catarrh 9fb2ad5d2b fix: send the STK install parameters as entered (v3.6.9)
The RAM install form sent the `STK parameters (hex)` field, which was only
regenerated when the toolkit checkbox or the mode select changed - editing
the TAR (or any other toolkit field) afterwards was silently dropped.  The
live install therefore carried the form defaults (TAR B00001, textLen 0,
menus 0, MSL 16, channels 0) instead of the entered AF4D01 / MSL 12 /
channels 1, and the card rejected the install parameters with 6A80
(TS 102 226 8.2.1.3.2.7: a TAR already assigned on the card).

- every `rc-tk-*` field regenerates the hex on input/change; the install
  recomputes it at send time unless the user hand-edited the hex
  (`dataset.manual`), so the edit order can no longer drop values;
- one pure `stkParamsBuild` serves the RAM form (`buildRcToolkitParams`) and
  the RAM/GP chain rows (`buildTkParams`) - no drift between them (the chain
  row also gains the menu-ID <= 7F check);
- applet TAR field: empty by default, no placeholder - B0 00 01 is the
  allocated ADF RFM TAR (TS 101 220 Annex D), not an applet TAR; an empty
  field is coded as TAR length 00 (the card may take a TAR from the AID only
  when the AID carries one, PIX hex digits 15-20);
- the chain builder's INSTALL/LOAD rows drop the trailing Le (the v3.6.8
  server form; a trailing Le made the card execute a phantom command);
- tests: stk_params.test.js (the decrypted live parameters, empty-TAR
  coding, CA wrapper, long-form lengths, rejection cases, form wiring, and
  the form -> hex path with the real builders) and ram_counter_flow.test.js
  (the Explore delete persists the consumed counter through the real
  ramSaveCntr); STK fixtures no longer use B00001.

631 frontend / 496 Python green; version 3.6.9; sw simple-v282.
2026-09-28 01:49:35 +03:00