Both psk3 entries run the same demodulation as the psk2 entry beside them and
differ only in the constant given to test(). test() accepts a word only when
that word's own modulation field matches the constant, so the psk3 entry needs
a recovered word whose field reads 3.
Field 3 is 00011, so it needs two adjacent 1's. What this demodulation recovers
is the data's rising edges, and a rising edge needs a 0 before the 1, so no two
of them are ever adjacent. The words it produces can never carry field 3, and so
the psk3 entries can never match the case they were written for.
What they can do, however, is match on a demodulation error, and then detect
names psk3 and a block 0 word the tag does not hold.
psk3 is still reached, by ruling psk2 out from the broadcast period rather
than by demodulating for it - see t55xx_psk3_resolve().
Tags that only these branches matched now read as psk2, or as undetected
where no offset yields a plausible psk2 word, on the basis that a wrong
answer is worse than none if nothing about it tells you it is wrong.
Edited by a human.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The client demodulates psk2 and psk3 the same way, and against a psk3 tag
that demodulation keeps only the leading bit of every run of ones. A psk3
config word therefore always reads back as its psk2 neighbour, one bit out,
and detect structurally cannot tell the two apart from the waveform alone.
It said psk2 anyway. Worse, the data-block probe meant to settle it
confidently answered psk3 even for a freshly wiped psk2 tag, where a page
of zeroes has no adjacent ones under either modulation.
Report what is actually known:
- print "PSK2 or PSK3 ( ambiguous )" when the read fits both
- list the words block 0 could be, rather than printing one and relegating
the rest to a note
- weight the probe's evidence, so empty blocks settle nothing
- narrow that list with things the tag cannot hide - the subcarrier it
transmits on, and how many blocks it broadcasts, which constrains MAXBLK and
also rules out the sequence terminator
Where that leaves one word, block 0 reports it. Where it does not, detect
says so rather than choosing.
Edited by a human.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
100 array declarations uint8_t x[PM3_CMD_DATA_SIZE]
21 receive sites — GetFromDevice, APDU/smartcard response buffers
All in a days work
Signed-off-by: Niel Nielsen <nieldk@gmail.com>
PM3_CMD_DATA_SIZE went 512 -> 624 without a capabilities bump, so a new
client connects to old firmware and every oversized command dies at the
device's length check with no message.
Append max_cmd_data_size, bump to v9. The client now accepts an older
capabilities struct - it only ever grows by appending, so an older layout
is a prefix - and defaults the frame size for pre-v9 firmware.
SendCommandNG bounds by the device value instead of the compile time one.
Also zero init capabilities_t on the device, it leaked stack bytes.
Allocate EF_SOD parsing scratch buffers on the heap so macOS worker threads do not exceed their stack while reading protected travel documents.
Co-Authored-By: Codex <noreply@openai.com>
chunked by PM3_CMD_DATA_SIZE. Identical today, but if the NG size moves the
chunk would be built oversized, truncated on the wire, and still announced
at full length in oldarg[1] - the client would copy past the valid bytes and
advance by the wrong stride. Bound the client's OLD download branch by the
same constant.
nkeys was a 6 bit field but the client chunked by what fits in a frame -
123 keys in segment mode. nkeys wrapped to 59 while memcpy copied all 123
and the loop advanced by 123, so 64 of every 123 keys were never tested
and never reported. Full key mode was unaffected, it chunks 30.
Give nkeys its own byte. MIFAREU3P_CHKKEY_HEADER goes 18 -> 19, costing
one byte of payload, and segment mode chunks 123 again
Payload layout changed: client and firmware must be updated together.
Thanks Claude!
The OLD frame size was tied to the NG one, but the bootloader only speaks
OLD - growing PM3_CMD_DATA_SIZE would silently change sizeof(PacketCommandOLD)
and break flashing against every deployed bootrom in both directions.
Pin the OLD structs to their own constant and use it on every OLD path:
reply_old and the OLD receive branch on both sides, the bootrom, and the
flasher's write_block/send_finish_write_cmd, which memcpy into a
PacketCommandOLD using the NG size.
No behaviour change - both constants are 512 and armsrc .text is
byte-identical before and after.
