mirror of
https://github.com/RfidResearchGroup/proxmark3.git
synced 2026-09-29 17:38:44 +00:00
iceman1001andClaude Opus 5 (1M context)
ee2d55fafb
Adds the on-device card image a DESFire simulation will read, the client side that packs a dump into it, and eload / esave / eview. The layout is in include/desfire_em.h. Tables grow up from the header, file data grows down from the end, and an allocation only has to leave the two frontiers apart -- so a three-file card spends a few hundred bytes rather than a worst case, and the space between them is what the card has left. The PICC is application 000000 and uses the same struct as any other application, so key settings and keys are always stated against an AID. Delete sets a tombstone rather than compacting, which is not a shortcut: a real card does not reclaim on delete either, measured as 2080 bytes free with zero applications before an experiment and 2560 after FormatPICC. Two size limits, and a reader only ever sees the first. cardsize is what the emulated card claims to hold, so GetFreeMem answers from that and CreateFile will refuse with OUT_OF_EEPROM when it runs out. Without it a card impersonating a 2K part would report 7434 bytes free, which no 2K part does. The image size is what emulator memory physically holds, is the harder limit, and is never visible. cardsize is anchored to the free memory the real card reported when the dump was taken -- observed free plus what we reserve for the same content -- so the emulation answers what its original answered. That is also a check on the reservation rule rather than only a convenience: for the bench card it computed 576 bytes spent, and 1984 + 576 is 2560, exactly what that card reports when formatted. Reservation follows what CommitTransaction covers. Backup data, value and record files each get a shadow region because writes to them are staged until commit; a standard data file writes through and does not. Sizes round to a 32 byte granule, which is the granule a real card allocates in. It deliberately does not reproduce NXP's allocator -- that is undocumented and does not fit a simple model, a declared 1024 byte record file costs 1088 on silicon -- so what matters is that the figure is self-consistent and shrinks as the reader writes. No new device command. Emulator memory is one shared region, so CMD_HF_MIFARE_EML_MEMSET and BIG_BUF_EML already reach it, and both inherit the bounds checking those paths gained earlier. Verified with the client only, no simulation yet: packing a dump taken from a DESFire EV2 and walking it back reproduces every field including file contents byte for byte, the same round trip through the device via eload and esave is identical, and an image too large is refused by name rather than truncated -- 'Out of emulator memory laying out AID 112233 file 00: needs 4066 more bytes'. Co-Authored-By: Claude Opus 5 (1M context)