mirror of
https://github.com/RfidResearchGroup/proxmark3.git
synced 2026-10-15 11:09:59 +00:00
iceman1001andClaude Opus 5 (1M context)
2449bb2472
The PICC applies a file's communication mode only when access is granted by
a key right matching the authenticated key. When the operation is granted by
the free access right (0x0E) instead, it runs in plain, whatever the file
settings say. The client used the file comm mode unconditionally, so any file
created with the default EEEE rights failed with 0x917E on write, and a free
access Full file was printed as its data plus eight unstripped CMAC bytes
instead of being decrypted. Fixes #3393.
Which rights can grant an operation varies, and the rule above is evaluated
over that set. Measured on DESFire EV2, ev1 and ev2 secure channels:
read / write data w (or r), rw
GetValue 0x6C r, w, rw
Credit 0x0C rw only
Debit 0xDC r, w, rw
LimCredit 0x1C r, w, rw
Credit is the odd one out: a file with r=key0 w=key0 rw=free needs Credit in
plain but Debit in MAC, in the same session. The FreeValue option bit forces
GetValue to plain regardless of the rights.
hf mfdes value never read the file settings at all, which is #2712. e1598cd62
worked around that by dropping CREDIT/DEBIT/LIMITED_CREDIT from
EV1D40TransmitMAC and retrying in plain on a length error. That made MACed
value files impossible to credit by any route, and the retry resent a
byte-identical APDU after the failure had already desynced the CMAC chain,
turning a clear 0x7E into a misleading 0x91AE. Both are reverted and the
command now reads the file settings like read and write do. Fixes #2712.
hf mfdes write resolves the comm mode even when --type is given explicitly,
since that path skipped detection entirely.
The DACLRP branch in the read path is left alone: no LRP capable card was
available to test against.
Co-Authored-By: Claude Opus 5 (1M context)