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>
Execution of hf 14a reader against a 4b UID card with RATS
hf_14a_reader_7b_rats.trace
Execution of hf 14a reader against a 7b UID card with RATS
hf_14a_mfu.trace
Reading of a password-protected MFU
hf_14a_mfuc.trace
Reading of a UL-C with 3DES authentication
hf_14a_mfu-sim.trace
Trace seen from a Proxmark3 simulating a MFU
hf_14b_reader.trace
Execution of hf 14b reader against a card
hf_14b_cryptorf_select.trace
Sniff of libnfc select / anticollision ofa cryptoRF tag
hf_14b_xerox_info.trace
Execution of hf xerox info against a tag
hf_15_reader.trace
Execution of hf 15 reader against a card
hf_mfp_mad_sl3.trace
hf mfp mad
hf_mfp_read_sc0_sl3.trace
hf mfp rdsc --sn 0 -k ...
hf_visa_apple_ecp.trace
Sniff of VISA Apple ECP transaction
hf_visa_apple_normal.trace
Sniff of VISA Apple normal transaction
hf_visa_apple_transit_bypass.trace
Sniff of VISA Apple transaction bypass
hf_mfdes_sniff.trace
Sniff of HID reader reading a MIFARE DESFire SIO card
hf_iclass_sniff.trace
Sniff of HID reader reading a Picopass 2k card
hf_mf_hid_sio_sim.trace
Simulation of a HID SIO MFC 1K card
hf_14a_mful_aes_defaultkey.trace
Reading of a UL-AES with AES authentication
hf_14a_mful_aes_defaultkey_secure_message.trace
Reading of a UL-AES with AES authentication, GetVersion with secure message
LF demodulated traces
filename
description
lf_hitag_crypto_dump.trace
Execution of lf hitag dump --crypto against Hitag2 card in crypto mode
LF emulator dumps
Tag images for lf hitag eload, used to simulate a Hitag 2 in each of its
operating modes. Byte 0 of page 3 is the configuration byte that selects the
mode, so the files differ mainly in that one byte.
filename
description
lf-hitag-CE129911-dump.bin
Hitag2 in password mode (config 0x06), password BDF5E846
lf_ht2_crypto.bin
Hitag2 in crypto mode (config 0x0E), key 4F4EBDF5E846
lf_ht2_crypto_1CAEFD13.bin
Hitag2 in crypto mode (config 0x0E)
lf_ht2_publicA.bin
Hitag2 in Public Mode A (config 0x02), Manchester, pages 4-5, carries an EM4102 payload
lf_ht2_publicB.bin
Hitag2 in Public Mode B (config 0x00), biphase 32 T0, pages 4-7
lf_ht2_publicC.bin
Hitag2 in Public Mode C (config 0x04), biphase 64 T0, pages 4-7
MIFARE DESFire card images
Card images for hf mfdes eload, used by hf mfdes sim. All three are in the
mfdes v1 dump format documented in doc/mfdes_dump_format.md.
The 8K images come off a genuine MIFARE DESFire EV1 8K, UID 04268512A25680,
batch B9 0C 17 49 70, week 27 / 2017, hardware 04010101001A05, software
04010101041A05.
The same image edited to present as an EV1 4K. Derived, not dumped from 4K silicon -- the storage size byte of VersionHW/VersionSW is changed from 0x1A to 0x18, and FreeMem set to 3840, the nominal 4096 minus the 256 bytes of overhead the 8K part shows
hf-mfdes-ev1-8k-test.json
The same card with three applications and all five EV1 file types, for exercising a simulation
hf-mfdes-ev1-8k-test-keys.json
Application keys for the above, in the mfdes v2 format hf mfdes chk -j writes
hf-mfdes-ev1-8k-empty-keys.json
Key file for the empty 8K image. Empty by construction, a blank card has no applications
hf-mfdes-ev1-4k-empty-keys.json
Key file for the empty 4K image. Likewise empty
Keys
Every key on this card is the counting sequence 01 02 03 .. 10, extended to
.. 18 for the 24 byte 3TDEA keys. The PICC master key is 2TDEA
0102030405060708090A0B0C0D0E0F10; each application uses its own algorithm,
and all of its keys are that algorithm's length of the same sequence.
Deliberately not the all-zero key, and not a key whose two halves match. A
16 byte DES/2TDEA key string whose second half equals the first is handled as a
single DES key by the PICC -- during authentication and session key
generation (M134034 8.1) -- and the all-zero key is the common case of that. A
card image keyed with it exercises only the degenerate path: an implementation
that derives the wrong session key still authenticates, and only fails later on
the first MACed or enciphered frame. This sequence has distinct halves, so a
wrong derivation shows up immediately.
The mfdes v2 key files carry application keys only -- that format has no
place for the PICC master key, because hf mfdes chk only walks the application
list and takes the PICC key from -k. Hand it in explicitly:
Note that every key is also stored inside the dump itself, under each
application's Keys object, so eload and sim need no key file at all --
the key files are for reading or rebuilding the physical card.
hf-mfdes-ev1-8k-test.json holds:
AID
keys
ISO DF name
files
010203
AES, 3
test1
01 standard 256 B free access, 02 backup 128 B MAC mode, rights 1200
112233
2TDEA, 2
test2
00 value, 1000 with limits [0..10000], 01 linear record, 2 of 8 records, 16 B each
AABBCC
3TDEA, 5
test3
05 cyclic record, 1 of 4 records, 24 B each, 03 standard 64 B free access
