mirror of
https://github.com/RfidResearchGroup/proxmark3.git
synced 2026-10-06 03:27:38 +00:00
The six plain/mac assertion pairs differed only by -m, and the file they ran against was created with no --amode and no --rawrights - so plain mode, free access. Free access is served in plain whatever the file says, and the client derives the mode from the file settings rather than from -m, so both halves of every pair sent the same bytes: --op credit -m mac -> 90 0C 00 00 05 02 0A 00 00 00 00 --op credit -m plain -> 90 0C 00 00 05 02 0A 00 00 00 00 They passed on a client that could not do MAC mode at all, which is howe1598cd62shipped: it had removed CREDIT/DEBIT/LIMITED_CREDIT from EV1D40TransmitMAC, and this suite stayed green. Build a fixture that makes the client answer a different question per file instead, and drop the -m flags, since deriving the mode is the thing under test: data 00 mac EEEE free access, MACed file data 01 mac 0000 key protected data 02 encrypt EEEE free access, enciphered file data 03 encrypt 0000 key protected value 10 mac 00E0 credit plain, debit MAC, same file value 11 mac 0000 key protected value 12 plain EEEE the original case value 13 encrypt 0000 plus FreeValue, so GetValue is plain File 10 is the one worth having: credit is granted by read & write only, which is free there, while debit is also granted by the write right, which is key 0. A single communication mode for the whole file cannot satisfy both. Also dump the application. It has no ISO file ids, so the client's GetISOFileIDs probe is refused and the PICC ends the session on it; a dump that does not notice reads the first file's plain content as a response CMAC and reports it as no data. Checked against a client built at08e389c0b, before the three fixes: the free access data writes fail -20, the MACed value credit fails -20, and the dump loses file 00. The 00E0 and FreeValue cases pass there too - they guard the derivation against future regressions rather than reproducing an old bug. Co-Authored-By: Claude Opus 5 (1M context)