The SRIX4K block scrambler in cmdhf14b.c was a three entry lookup table with
its callers commented out, so `hf 14b valid` printed hard coded values and
nothing ever decoded. The scrambler is a 4x4 transpose of the block read as
sixteen crumbs. A transpose is its own inverse and it reproduces all three
entries of the old table, so the stub is replaced by a working parser.
client/src/parsers/parsemykey.c reads the application off a dump: key id,
production date, operations counter, vendor code, lock id, current and
previous credit, and the eight slot transaction ring. Every block carries a
checksum in its top byte and the parser reports how many hold up, which
catches a wrong UID or a torn write. The credit blocks are XORed with a
session key derived from the UID, the vendor code and the count down counter
in block 6, so the file name has to carry the UID.
`hf 14b valid` is removed. Checking that the maths holds is now
`hf 14b view --selftest`, following `hf mf view --selftest`, and it runs
against traces/hf-14b-D0021F673CB26556-dump.json, a dump of a real reset key.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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>
This was done programmatically using python.
The `lf_Keri.pm3` was in range `[-508 .. 491]` (1000 value range).
Each value was divided by four, cast to integer, and then adjusted by +1 (to center the values).
The data plot in the pm3 client now shows discernible changes in amplitude.
The resulting samples are all within range [-128,127].
This final fix allows ALL sample `.pm3` traces to be converted to one-byte-per-sample binary format.
This was done programmatically using python.
Files with a range that fell outside of [-128,127], but which would fit into that range, were offset by the noted amount to ensure the file woul now fit within range [-128,127]. This allows the trace files to be converted to one-byte-per-sample binary format, for example.
offset | filename
-----|-----
`-14` | `lf_Q5_mod-manchester.pm3`
`-14` | `lf_Q5_mod-nrz.pm3`
`-10` | `lf_Q5_mod-fsk1.pm3`
`-15` | `lf_Q5_mod-biphase.pm3`
`-9` | `lf_Q5_mod-fsk2.pm3`
