"Personal number (from DG13)" renders 203px wide and the caption column is
dp(190), so it wrapped and left the source sitting on a line of its own.
Without the "from" it comes to 167px and fits, with room to spare over the
140px of the longest caption already in that tab.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Kivy's stock disabled button texture is pale at the edges and dark in the
middle. Stretched across a wide button the edges stay put and the middle
grows, so it reads as three vertical bands with the label sitting on the
dark one and disappearing - "Delete dump" is unreadable at startup, where
it is disabled because no dump is loaded yet.
Keep the normal background for the disabled state and let the dimmed label
carry it instead. The text goes to 45% rather than Kivy's 30%, which is
faint on that grey.
Applied as a Button rule because nine buttons across the app bind
disabled: Export, Open folder, the camera button, Samples, the bin button
and the rest all band the same way. The one button that sets its own
transparent background stays transparent, since background_color
multiplies the texture.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A Polish passport carries EF_DG13 and no EF_DG11, so the PERSONAL tab had
nothing to show and the data page fell back to "not on chip", even though
the document does carry a personal number.
DG13 is optional details and ICAO assigns it no meaning, so parse_dg13()
reads it as tagged values and names none of them. The 5C tag list is
skipped: it enumerates what follows rather than being a field itself.
Poland is the one case worth naming. It puts the PESEL, its national
identity number, in tag 5F70, and is_pesel() checks the length and the
check digit - DG13 being issuer-defined, the checksum is what separates a
PESEL from eleven digits that happen to share a tag. That is applied only
when the MRZ nationality is POL, so the same tag on another state's
document is carried but not claimed as a personal number.
It slots in behind the two sources personal_number already had, which its
docstring anticipated: DG11, then the MRZ optional-data field, then this.
personal_number_source reports DG13 so the PERSONAL tab and the data page
can say where the value came from rather than implying DG11.
Confirmed against a Polish passport: the 11 digits validate as a PESEL,
their first six match the MRZ date of birth under PESEL's century-offset
month encoding, and the gender digit agrees with the MRZ sex field. The
two US documents to hand are unaffected - they keep taking the number from
the MRZ - and a document with none of the three shows no row, as before.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
100 array declarations uint8_t x[PM3_CMD_DATA_SIZE]
21 receive sites — GetFromDevice, APDU/smartcard response buffers
All in a days work
Signed-off-by: Niel Nielsen <nieldk@gmail.com>
A card that needs longer than FWT to answer replies with S(WTX) carrying a
multiplier, and ISO 14443-4 has the timeout become FWT * WTXM for that
exchange. iso14443b_apdu() multiplied the shift instead:
uint32_t fwt_temp = (s_iso14b_fwt * wtxm);
iso14b_set_timeout((32 << fwt_temp));
(32 << fwi) is the FWT in ETUs - the form iso14b_set_fwt() uses, and the
one the client prints in hf 14b info - so this computed 32 << (fwi * wtxm).
With the fwi of 8 that a passport reports, wtxm 1 happens to come out
right, wtxm 2 is 256 times too long, and wtxm 4 shifts a uint32_t by 32.
That is undefined, and on ARM it leaves 0, so the read that follows gives
up before the card has answered and the client reports
APDU: no APDU response
Found on a Polish ePassport that would not read. Every short command
answered - SELECT, an unsupported instruction, a malformed MSE - and only
MSE:Set AT with P1P2 C1A4 was silent, which is the one command in the
exchange that starts the PACE ECDH setup and so the only one that ever
asks for more time. Older passports read because they ask for a smaller
multiplier, where the wrong formula still produces a usable number.
Tested on RDV4 against that document: the MSE:Set AT that returned nothing
now answers 9000, and hf emrtd dump completes in 3 seconds with PACE
(ECDH, Generic Mapping, 3DES-CBC-CBC, NIST P-256), every data group read
and every EF_SOD hash matching.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
