mirror of
https://github.com/RfidResearchGroup/proxmark3.git
synced 2026-10-01 08:39:00 +00:00
iceman1001andClaude Opus 5
2d70fcb4ff
The DESFire simulation gets its own ISO 14443-A loop in armsrc/desfiresim.c rather than hooking into SimulateIso14443aTag(). That function is complicated enough without a DESFire state machine threaded through it, and the hook had already got the ATQA wrong once. It still borrows the library helpers from iso14443a.c -- the precompiled activation answers, the receive call, the send calls -- so there is no duplicated state machine, and iso14443a.c goes back to knowing nothing about DESFire. desfiresim.h exports one symbol. Three fixes were needed to make it actually answer a reader. 1. ISO 7816 wrapping. A reader sends `02 90 60 00 00 00`, not `02 60`. The simulation read in[0] as the DESFire command and so saw 0x90, the class byte, answering ILLEGAL_COMMAND_CODE to everything -- and in native form (status || data) when the reader wanted the wrapped form (data || 91 SW). Both framings are handled now, including the Lc/Le distinction: five bytes means no data and in[4] is Le, longer means in[4] is Lc with data following. 2. A bitstream download frees and clears BigBuf to get scratch space for the decompressor. SimulateIso14443aTagEx() and Mifare1ksim() both guard against this by calling FpgaDownloadAndGo_keep_EM() before they allocate anything; the new loop did not, so iso14443a_setup() wiped the emulator memory holding the card image and the precompiled answers after they had been filled. The pointers survive, the bytes do not, and the tag then clocks out zeros. 3. iso14443a_setup() itself used the plain FpgaDownloadAndGo(), which does BigBuf_free() and BigBuf_Clear_ext() -- taking the emulator memory with it. Every 14a command comes through there, so a card image that `eload` had just put in place was destroyed by the next `hf 14a` command whenever the HF bitstream was not already resident. Demonstrated before and after: `eload` then `hf 14a reader` then `eview` used to report "No DESFire card image in emulator memory" and now returns the image intact. This affected every emulator memory user, not only DESFire. Verified against a second Proxmark3 acting as reader, simulating a real DESFire EV1 8K dump: activation (UID 04268512A25680, ATQA 03 44, SAK 20, ATS 06 75 77 81 02 80), the three frame GetVersion chain over 0xAF, GetFreeMem, GetApplicationIDs, SelectApplication, GetKeySettings and GetFileSettings. `hf mfdes info`, `getaids`, `freemem`, `lsapp` and `lsfiles` all read correctly, including per application key types (AES, 2TDEA, 3TDEA) and all five EV1 file types with their real settings -- a value file holding 1000 with limits [0..10000], a linear record 2/8 of 16 bytes, a cyclic record 1/4 of 24 bytes, standard files of 256 and 64 bytes, and a backup file of 128 bytes in MAC mode with keyed rights 1200. Not implemented yet: GetDFNames (0x6D) and GetISOFileIDs (0x61), so a reader sees empty ISO IDs and DF names. Everything else answers ILLEGAL_COMMAND_CODE, which is what a PICC says to a command it does not have. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>