mirror of
https://github.com/RfidResearchGroup/proxmark3.git
synced 2026-10-06 16:27:45 +00:00
iceman1001andClaude Opus 5
4dc412e403
The DESFire simulation now plays the EV1 protocol rather than just the activation and a handful of unauthenticated queries. A reader authenticates, enumerates, reads and writes files, and commits or aborts transactions against the card image `hf mfdes eload` put in emulator memory. Authentication covers 0x0A, 0x1A and 0xAA with DES, 2TDEA, 3K3DES and AES keys taken from the image. A key the image only holds a version for still refuses to authenticate rather than authenticating with zeros. Secure messaging follows the file's communication mode, with the rule that the mode only applies when a key right matching the authenticated key granted the operation -- access granted by the free-access right runs plain whatever the file settings say. Responses are MACed or enciphered accordingly, and the session CMAC is taken over every command and response in order so the two sides' IVs stay together even where neither puts a MAC on the wire. Reads cover ReadData, ReadRecords, GetValue and GetCardUID. Writes cover WriteData, WriteRecord, UpdateRecord, Credit, Debit and LimitedCredit, plus CommitTransaction, AbortTransaction and ClearRecordFile. Backup data, value and record files write into their shadow region and only move across on commit, so an abort really does discard. Three fixes were needed to interoperate with the client, and all three share a shape worth naming: the authentication handshake still succeeded, because it runs on the original key, and only the traffic afterwards was wrong. 1. A DES or 2TDEA key is stored as 16 bytes and the key itself decides which cipher the PICC uses -- if the second half equals the first it is a single DES key, and that governs session key generation too (M134034 8.1). The all-zero default key is the common case. Deriving a 2K3DES session key from it left the card MACing under a key the reader did not have. Confirmed by decrypting a captured GetCardUID response offline: under the session key the reader derives it yields the UID and a valid CRC32, under the other it does not. 2. Session keys are built here rather than through Desfire_session_key_new(), whose 3K3DES branch clears the low bit of the first eight bytes. Those bits are key version, which a session key does not have, and the reader keeps them. 3. The reader's 0xAF continuation is not a command, it continues one. Giving it its own CMAC restarted the running calculation halfway through a chained answer, so every chained response longer than one frame carried a wrong MAC while single-frame answers verified fine. The sample card in traces/mifare is rekeyed from all zeros to the sequence 01 02 .. 10, extended to .. 18 for 3TDEA. An all-zero key has matching halves, so it exercises only the degenerate path of fix 1 above and hides the bug; distinct halves surface a wrong derivation on the first MACed frame. tools/desfire_sim_test.sh loads an image, simulates it, drives the second Proxmark3 at it and reports. It stops the simulation the way the client does, a newline on its stdin, through a fifo held open for the run rather than a fixed timer -- a run that outlives its timer leaves the device simulating. A command counts as passing only if it prints something that says it worked: card errors, client side argument rejections and MAC or CRC complaints all fail, because several of those print a plausible result line as well and matching on the result alone reports passes that never happened. Tested on two RDV4s, one simulating and one reading: activation, info, application and file enumeration, all three key types, enciphered GetCardUID, plain and MACed reads up to 256 bytes over chained frames, and writes verified by reading the image back out with `hf mfdes esave`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>