diff --git a/docs/api.md b/docs/api.md index a8c0e16..25fb2db 100644 --- a/docs/api.md +++ b/docs/api.md @@ -36,6 +36,7 @@ a 3.x PWA). | `/api/presets/update` | POST | Update a preset (`{id, fields}`; the counter may be raised) | | `/api/presets/delete` | POST | Delete a preset (`{id}`) | | `/api/presets/import` | POST | Import presets (`{presets: [...], mode: merge\|replace}`) | +| `/api/tar-probe` | POST | Probe the card's registered OTA applications (one secured packet per TAR, TS 101 220 Annex D) | | `/api/esim/chip` | GET | eUICC chip details (EID, EUICCInfo1/2, configured addresses) | | `/api/esim/profiles` | GET | Installed eSIM profiles with their metadata | | `/api/esim/notifications` | GET | Pending eSIM notifications (read-only) | @@ -245,6 +246,35 @@ import also accepts presets exported by the older localStorage-based builds. `"replace"`) → `{"ok": true, "added": N, "skipped": M, "errors": […]}`; invalid entries and duplicates are skipped and reported, never fatal. +### `POST /api/tar-probe` + +Probe which OTA applications the card has registered: one **secured packet per +TAR** (the standard allocations of TS 101 220 V18.3.0 Annex D, Table D.1 unless +a `tars` list is given), each carrying a harmless C-APDU (`SELECT MF` by +default), with the preset's keyset and SPI `16/01` (counter check + PoR). +Every accepted packet consumes a counter, which is persisted into the keyset +like any other operation, so the probe is refused when the SPI1 has no counter +check (b5b4 = 00) or the named preset does not define the key version. + +```json +{"preset_id": "…", "kic": "25", "kid": "25", "kicKey": "…", "kidKey": "…", + "cntr": "0000000187", "apdu": "00A40000023F00", "tars": ["000000", "B00000"]} +``` + +**Response:** `{"success": true, "registered": N, "total": M, + "final_cntr": "…", "kvn": 2, "spi1": "16", "spi2": "01", + "results": [{"tar": "000000", "label": "Issuer Security Domain (compact)", + "verdict": "registered", "sw": "9000", "por_status": "por_ok", + "por_sw": "6D00", "por_data": ""}], "steps": [...]}` + +Verdicts: `registered` (ENVELOPE 9000 + a PoR carrying the application's own +status word/data), `no_answer` (accepted, PoR without an R-APDU), `no_por` +(accepted, no PoR at all — the packet was silently dropped), `refused` (a +non-9000 ENVELOPE, typically `6200` for a TAR without a registered +application). Observed on a live card: `000000`, `B00000` and `B00001` +registered (compact-format applications), the expanded-format TARs, USAT, +multiplexing and CASD refused. + ### eSIM / LPA (local ES10 operations) These endpoints work only when the equipped card is an eUICC (SGP.22/32); @@ -388,6 +418,16 @@ presets*), so a lost response or a closed tab cannot lose the increment; the request is refused when KIc/KID carry different key versions (TS 102 225 A.2) or a non-zero key version the preset does not define. +**Counter tracking follows SPI1.b5b4** (TS 102 225 §5.1.1): with `00` the +counter field is "present, ignored, never updated", so a packet whose SPI1 has +no counter check (the keyless `SPI1 00` form) reports **no** `final_cntr` and +persists nothing — a keyless send must leave every preset counter untouched. +The spec's no-security KIc/KID values `00/00` are accepted when the SPI says +no ciphering / no RC-CC-DS (A.2), so `{apdu, spi1: "00", kic: "00", kid: "00"}` +builds a keyless packet (the card accepted exactly that form; a fake `15/15` +was refused with `6200`). When a PoR was requested and the card did not +answer, the response carries `por_missing: true`. + **Request body:** ```json { diff --git a/frontend/help-ru.html b/frontend/help-ru.html index caa229c..ab44e20 100644 --- a/frontend/help-ru.html +++ b/frontend/help-ru.html @@ -323,6 +323,7 @@ Обзор карты (все данные GP)Запрос GET STATUS для ISD, приложений, ELF и модулей ELF, а также GET DATA FF21 (расширенные ресурсы карты: число установленных приложений и свободная энергонезависимая/энергозависимая память). Компактный листинг содержит только AID, состояние жизненного цикла и привилегии (версии в устаревшем формате нет); если карта отвергает его (P2.b2=0, устаревший по GP), запросы повторяются в расширенном формате E3, а флажок Запрашивать расширенные данные реестра (связи load-файла и SD) дополнительно запрашивает их и объединяет расширенные поля: версию исполняемого load-файла, AID load-файла, AID Security Domain, списки модулей, пункты меню STK апплета (SCP Registry Data, TS 102 226 8.2.1.6) и любые другие объекты реестра, которые вернула карта (показываются как есть, без потерь) — он стоит несколько дополнительных защищённых пакетов на каждый обзор и включён по умолчанию (запоминается в браузере; снимите флажок, чтобы пропустить). Карты различаются в том, что принимают, поэтому расширенный запрос пробуется в трёх формах — эталонный список тегов (с EA по TS 102 226), тот же список без EA и вовсе без списка тегов (форма GlobalPlatformPro) — а обзор сообщает, какая форма сработала и где выполнен откат к компактному списку (версии пакетов тогда недоступны). Результаты отображаются в обзоре (строка успеха минимальна, счётчики — в заголовках разделов) с кнопками Удалить для каждого элемента и определённым форматом команд RAM (подсказка при наведении объясняет compact и expanded). Установка пакета (.cap файл)Отправка .cap файла на карту через сервер: INSTALL[for load] → LOAD ×N → INSTALL[for install (+make selectable)]. Load-файл делится на LOAD APDU размера размер блока LOAD (1–240 байт полезной нагрузки, по умолчанию 240); каждый защищённый пакет доставляется одним SMS или, если он больше, конкатенированной SMS-PP загрузкой до 5 сегментов, так что большой .cap просто занимает несколько SMS. Сразу после выбора файл проверяется и в форме показывается оценка требований к памяти: требование NVRAM (образ кода + постоянные данные, сумма в стиле C6+C8 из GP Card Spec) и оценка RAM. Там же показаны библиотеки, с которыми слинкован CAP (его компонент Import: имя библиотеки, AID и минимальная версия ≥ x.y — имена стандартных библиотек и семейства подставляются, а где известно, даётся подсказка о версии Java Card), идентификаторы пакета и апплетов и разбивка по компонентам (размеры и доли в порядке load-файла) — всё сгруппировано по разделам Package, Requires, Memory и Components. Строка Platform показывает минимальный уровень Java Card, который должна предоставить карта (выводится из импорта javacard.framework; флаг int в заголовке дополнительно требует поддержки int — Java Card 2.2+), и релиз ETSI, из которого пришли импорты UICC API (версия uicc.toolkit → REL-N по корпусу sim-tools в рабочем каталоге; основание показано в скобках): JCRE проверяет каждый импорт по своим пакетам при верификации load-файла (JC VM spec 4.5.2), поэтому карта со старой платформой отклоняет LOAD сразу после завершения компонента Import (в строке шага виден remote SW карты и компонент, который завершил блок, например завершает Import) — меньший размер блока LOAD помогает только если блок превышает буфер карты. Повреждённый файл не проходит анализ, и Execute остаётся недоступной до успешного анализа. Оценка носит справочный характер и никогда не используется при установке: NVRAM — это образ кода плюс постоянные данные (сумма в стиле C6+C8 по GP Table 11-48; управление памятью карты, округление и запись в реестре не учитываются, а образ статических полей входит в обе части); рекомендуемый C6 следует за load-файлом, а рекомендуемые квоты — это десятичные значения в байтах (шестнадцатеричное значение в скобках — это кодирование параметров установки C7/C8: C6 — энергонезависимый код, C7 — энергозависимая RAM, C8 — энергонезависимые данные). Проверка совместимости CAPОтвечает на один вопрос, ничего не устанавливая: может ли эта карта удовлетворить список импортов CAP? Сервер выполняет проверку формата, INSTALL[for load] и блоки LOAD только до блока, завершающего компонент Import — именно там JCRE проверяет список импортов — и останавливается: без флага последнего блока и без INSTALL[for install], поэтому ничего не фиксируется и удалять после этого ничего не нужно. Список «Версии импортов для проверки» предзаполняется из анализа CAP: AID=version переписывает запрошенную версию импорта, +AID=version добавляет синтетический импорт (запрос возможностей карты: LOAD проходит, только если карта экспортирует этот пакет версии ≥ указанной), а «Все 0.0» снимает все требования. Использование в два шага: нажмите «Все 0.0» — если проверка проходит, причиной был список импортов; затем возвращайте по одной строке, чтобы найти пакет и версию, которых не хватает карте. Вердикт явно указывает, что проверяется только этап LOAD/импортов: этап связывания (наличие реально вызываемых API) проверяет настоящая установка на INSTALL[for install]. Запуск и результат показываются в окне (как при установке): строки шагов, вердикт и блок деталей по каждому AID — при отказе он называет раздел CAP, который покрывает неудачный блок (диапазон байтов load-файла и компоненты, и завершает ли этот блок Import), SW команды с его значением, список импортов ровно в том виде, в каком он проверялся (версии CAP, правки пробы, добавленные синтетические записи, строки без совпадений) и что означает состояние пробы; при успехе — список импортов, который прошёл проверку. + Проба TAR (зарегистрированные OTA-приложения)Отправляет по одному защищённому пакету на каждый TAR — стандартные значения из TS 101 220 Annex D, Table D.1, если список TAR не задан — с безобидной C-APDU (по умолчанию SELECT MF), набором ключей предустановки и SPI 16/01 (проверка счётчика + PoR), и классифицирует ответ карты: зарегистрировано (ENVELOPE 9000 + PoR со SW/данными приложения), принято, нет PoR (пакет молча отброшен), отклонено (обычно 6200). Полезно для картирования OTA-приложений карты. Каждый принятый пакет расходует счётчик, который сохраняется в набор ключей — проба отклоняется, если в SPI1 нет проверки счётчика. diff --git a/frontend/help.html b/frontend/help.html index 0f5e190..0eb243e 100644 --- a/frontend/help.html +++ b/frontend/help.html @@ -321,6 +321,7 @@ Explore Card (all GP data)Queries GET STATUS for ISD, Applications, ELFs, and ELF Modules, plus GET DATA FF21 (Extended Card Resources: the number of installed applications and the free non-volatile/volatile memory). The compact listing carries the AID, life cycle and privileges (the legacy format has no version); if a card rejects it (P2.b2=0, deprecated by GP) the queries are retried in the expanded E3 form, and the Fetch expanded registry details (load-file / SD associations) checkbox also requests it as an extra pass and merges the expanded-only fields: the Executable Load File version, Load File AID, Security Domain AID, module lists, the applet STK menu entries (SCP Registry Data, TS 102 226 8.2.1.6) and any other registry data objects the card returns (shown raw, never dropped) — it costs a few extra secured packets per Explore and is on by default (remembered per browser; untick to skip). Cards differ in what they accept, so the expanded query is tried in three forms — the reference tag list (with the TS 102 226 EA), the same list without EA, and no tag list at all (the GlobalPlatformPro form) — and the explorer reports which form worked and where the run fell back to the compact listing (package versions are then unavailable). Results appear in an explorer view (the success line stays minimal; the counts are in the section headings) with per-item Delete buttons and the detected RAM command format (hover for what compact vs expanded means). Install Package (.cap file)Sends a .cap file to the card via the server: INSTALL[for load] → LOAD ×N → INSTALL[for install (+make selectable)]. The load file is split into LOAD APDUs of the LOAD block size (1–240 bytes of payload, 240 by default); each secured packet is delivered as a single SMS or, when larger, as a concatenated SMS-PP download of up to 5 segments, so a large .cap simply takes several SMS. As soon as the file is selected it is validated and its memory requirements are estimated in the form: the NVRAM requirement (the code image + persistent data, the GlobalPlatform Card Spec C6+C8 style total) and the RAM estimate. The same box reports the libraries the CAP is linked against (its Import component: library name, AID and the minimum version ≥ x.y, with standard names and families resolved and a Java Card SDK hint where known), the package/applet identity and the component breakdown (sizes and shares in load-file order) — grouped under the Package, Requires, Memory and Components headings. The Platform line names the minimum Java Card level the card must provide (derived from the javacard.framework import; the header int flag additionally requires int support, Java Card 2.2+) and the ETSI release the UICC API imports come from (uicc.toolkit version → REL-N, per the workspace sim-tools corpus; shown with its basis in brackets): the JCRE checks every import against its own packages when it verifies the load file (JC VM spec 4.5.2), so a card whose platform is older rejects the LOAD as soon as the Import component is complete (the step line carries the card's remote SW and names the component the block completed, e.g. completes Import) — a smaller LOAD block only helps when the block exceeds the card's buffer. A corrupt or wrong-format file fails the analysis, and Execute stays disabled until a successful analysis. The estimate is informational only and is never used for installation: NVRAM is the code image plus the persistent data (the GlobalPlatform C6+C8 style total, Table 11-48 — card memory management, rounding and the registry entry are not included, and the static field image is counted in both parts); the suggested C6 follows the load file, and the suggested quotas are decimal byte counts (the hex in parentheses is how the C7/C8 install parameters encode them: C6 = non-volatile code, C7 = volatile RAM, C8 = non-volatile data). + Probe TARs (registered OTA applications)Sends one secured packet per TAR — the standard allocations of TS 101 220 Annex D, Table D.1, unless a TAR list is given — each carrying a harmless C-APDU (default SELECT MF) with the preset's keyset and SPI 16/01 (counter check + PoR), and classifies the card's answer: registered (ENVELOPE 9000 + a PoR with the application's own status word/data), accepted, no PoR (the packet was silently dropped), refused (typically 6200). Useful to map which OTA applications a card carries. Every accepted packet consumes a counter, which is saved into the keyset — the probe is refused when the SPI1 has no counter check. CAP compatibility testAnswers one question without installing anything: can this card satisfy the CAP's import list? The server runs the format check, INSTALL[for load] and the LOAD blocks only up to the block that completes the Import component — the point where the JCRE verifies the import list — then stops: no last-block flag and no INSTALL[for install], so nothing is committed and nothing has to be deleted afterwards. The Import versions to test list is pre-filled from the CAP analysis: AID=version rewrites an import's requested version, +AID=version appends a synthetic import (a card-capability query: the LOAD passes only if the card exports that package at ≥ that version), and Set all 0.0 drops every requirement. Two-step use: press Set all 0.0 — if the test passes, the import list was the blocker; then restore one line at a time to find the package and version the card lacks. The verdict states it covers the LOAD/import gate only: the link gate (whether the applet's actual API calls exist) is what a real install checks at INSTALL[for install]. The run and its result appear in a popup (like the install): the step lines, the verdict and a per-AID detail block — on a rejection it names the CAP section the failing block covers (load-file byte range and components, and whether that block completes Import), the remote status word with its meaning, the import list exactly as tested (CAP versions, probe rewrites, appended synthetic entries, unmatched lines) and what the probe state implies; on success it lists the import list that passed. diff --git a/frontend/index.html b/frontend/index.html index 81dba91..b5ea111 100644 --- a/frontend/index.html +++ b/frontend/index.html @@ -705,6 +705,7 @@ + @@ -721,6 +722,13 @@
+