mirror of
https://github.com/RfidResearchGroup/proxmark3.git
synced 2026-09-26 00:14:20 +00:00
Paul KilarandClaude Opus 5
30b57591c7
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>
