mirror of
https://github.com/RfidResearchGroup/proxmark3.git
synced 2026-10-06 18:37:52 +00:00
Paul KilarandClaude Opus 5
92a98b1e14
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>