Reading a Polish passport produced an empty dump directory and the app
answered with "EF_DG1 is missing - no MRZ to render", which sent us after
one file when every file was absent. Chasing that turned up several
reasons a failed read did not explain itself, and one wrong label in the
SECURITY tab that the same document exposed.
Nothing was reported as a success. _read_finished treated any read the
classifier had not flagged as one: it set status to "success", loaded the
empty record and switched to the data page, leaving the DG1 line in the
log as the only clue. It now treats an empty record as a failure, and the
loader no longer names DG1 when nothing at all was read.
A failed read left no evidence, so pm3.log is kept beside the dump. The
key material is redacted out of it: result.command is the whole built
command line and the client echoes it back in its own output, so the MRZ,
the document number and the CAN all reach the log unless both are
scrubbed. The log does not count as a file when judging whether a read
produced anything - otherwise a failed read looks like it holds one and
the empty-dump prune, which uses rmdir, could never clear it again.
The classifier missed a lot. Fifteen of the client's failure messages
matched no rule and surfaced as the generic error; thirteen now classify,
each verified to end in a return false in the client. Two are deliberately
left alone with a comment saying why: "Secure select rejected" is answered
6A82 for an absent optional DG during a good read, and "PACE is not
available" precedes a normal BAC fallback.
It also contradicted itself twice. A superseded PACE attempt was reported
as the outcome, so a dump with every file in it announced itself as "PACE
authentication failed" - the client falls back to BAC, and
detect_mechanism already knew BAC had got in. And "Did you supply the
correct MRZ info?" is printed whenever external authentication fails,
whatever the cause, so a chip that had stopped answering was reported as a
bad MRZ; a missing APDU response now outranks it and says the key was
never tested.
EF_CardAccess was listed in the file table but never parsed, and DG14's
protocols were mislabelled: 0.4.0.127.0.7.2.2.1.2 was called "PACE (ECDH,
generic mapping)" when that arc is the Chip Authentication public key -
the client calls the same constant oid_pk_ecdh - and PACE lives under
0.4.0.127.0.7.2.2.4.x.y, as the comment above the client's own table says.
emrtd/securityinfos.py parses SecurityInfos for EF_CardAccess,
EF_CardSecurity and DG14, taking its names and domain parameters from the
client's pace_table and pacesdp_table so the two agree. Only the members
of the SET count: walking every nested SEQUENCE also collected the X9.62
identifiers inside the public key, which are not protocols the chip
supports. It uses the TLV reader already in the tree rather than
asn1crypto, an optional dependency the old OID scan silently needed.
Behaviour change: a read that writes no file reports failure and opens the
LOG tab instead of an empty data page; every dump gains a redacted
pm3.log, ignored when judging emptiness and removed with the directory;
failures that surfaced as one generic error now name themselves; DG14
lists four named protocols where it listed six raw OIDs.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Clicking a file that holds a picture - EF_DG2, EF_DG7 - showed nothing at
all: no image, no hex dump, and no error either.
Both panes drew their text into a single Kivy Label, and a Label is one
OpenGL texture, capped at commonly 16384px. A monospace line here is 13px,
so past roughly 1260 lines the texture fails to be created and the pane
draws nothing. A DG2 portrait is 15-25kB, which is 940-1560 dump lines at
16 bytes a row and four times that in a narrow pane, where the dump falls
back to 4 bytes a row. The LOG pane holds 4000 lines, so it blanked as
well once a dump got talkative. The 64kB cap already in the hex view
guarded the wrong bound: it was sized for how long a Label takes to lay
out, not for what the GPU will hold.
Split both over several Labels. split_blocks() chunks at 512 rows, and the
log at 256 because its lines wrap and so cover more rows than they hold.
The log reuses its Labels and only assigns the ones whose text changed, so
streaming output still re-renders just the tail.
The FILES tab now also shows the picture above the dump for the files that
carry one, which is what you actually want to see for a DG2. The PNG is
already decoded at load time for the data page, so image_for() only hands
over what is there.
Behaviour change: a file carrying an image shows it above the hex dump,
with the dump still underneath. Nothing is truncated that was not before.
Testing: 270 passed, 2 skipped (was 265). Checked on screen against a
generated sample - EF_DG2 shows the portrait, EF_DG7 the signature, EF_SOD
the dump at full height, and the LOG tab renders a full 4000-line buffer
as 16 Labels, tallest texture 3328px against the 16384px maximum. black
clean. Python only, so no client or firmware build matrix applies.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
