mirror of
https://github.com/RfidResearchGroup/proxmark3.git
synced 2026-10-03 16:58:37 +00:00
iceman1001andClaude Opus 5
950ba026bf
`hf mfdes chk` reported "No keys found" on a card whose PICC master key was still the factory default, and missed a key handed to it on the command line. The AID list comes from GetApplicationIDs, which never returns 000000, so the PICC level was never swept - only an explicit `--aid 000000` reached it. That list is itself gated by PICC key settings bit 1, and a card refusing it aborted the whole run rather than falling back to the one key number still reachable. 000000 now seeds the sweep, and a refused list leaves the PICC level to check. A key given with `--key` was written into the key list at parse time and then overwritten: every round resets the length and refills the same buffer from index 0. It was counted in "Loaded N keys" and never tried. It is now re-inserted at the head of its list after each fill, so it is attempt one. When key settings are unreadable the fallback walked the file access rights to name the key numbers in use. GetFileIDs, GetISOFileIDs and GetFileSettings are gated by the same settings bit that just refused GetKeySettings, so that fallback could never run. GetKeyVersion is not gated at all and names the key numbers directly, absent ones answering 0x40 NO_SUCH_KEY. AuthenticateISO (0x1A) was read only when Authenticate (0x0A) had answered first, but 0x1A covers DES, 2TDEA and 3TDEA where 0x0A covers only the first two. An application holding 3TDEA keys answers 0x1A alone, so it named no key type and was skipped outright. chk and detect both read it on its own now. Because 0x1A cannot separate 2TDEA from 3TDEA, detect also drops a key type on the first wrong-length challenge instead of waiting for its error counter. Measured on a DESFire EV2 2K: PICC master key and an application AES key are both recovered in one run, and the unauthenticated GetKeyVersion sweep keeps answering across a run of NO_SUCH_KEY errors with no re-select. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>