The selectaid_response buffer in `hf 14a simaid` was capped at 100
bytes, which is well below the ISO 14443A frame maximum of 256 bytes
and prevents users from emulating tags whose SELECT AID response is
larger than a trivial status word.
This bumps selectaid_response from 100 to 256 in all three locations
(ARM packet handler, client locals, client payload struct) along with
the argparse help text. getdata_response is left at 100. The payload
struct overlays PM3_CMD_DATA_SIZE (512) via packet->data.asBytes;
with the new sizes it totals 435 bytes, so it still fits.
Pairs with the earlier tosend bounds check / DYNAMIC_MODULATION_BUFFER2
fix, which raised the actual transmit ceiling to the 256-byte frame
limit — this change lets callers supply a response up to that limit.
Pushing a potential fix for https://github.com/RfidResearchGroup/proxmark3/issues/3250
Use the masked variant with an explicit zero source. _mm512_maskz_andnot_epi32(0xFFFF, a, b) is semantically identical to _mm512_andnot_si512(a, b) but goes through a different code path that takes a proper src argument instead of calling _mm512_undefined_epi32(). No uninitialized read, no warning, single instruction.
It compiles to the exact same single vpandnd instruction as _mm512_andnot_si512. The all-ones mask is resolved at compile time and folded away — the encoder just emits the unmasked form. Zero cycle difference, zero code-size difference.
Looks like either I, or someone else, has never thought about encrypted mode enforcement in mfpreadsector.
Now during readouts data is decrypted on the fly.
Checked on real tag.
Signed-off-by: team-orangeBlue <63470411+team-orangeBlue@users.noreply.github.com>
Issue origin:
Commit 6b7665ed5 "Added live fc/cn update to hf iclass tagsim" added a data_available() poll inside the per-byte DMA loop of GetIso15693CommandFromReader so the ARM could drop out of RF-listen and process live emulator updates.
Before that commit, that tight loop had no USB poll at all — only gotFrame / BUTTON_PRESS / WDT_HIT. Verified via git show 6b7665ed5^:armsrc/iso15693.c.
Why it shows up on sim -t 3/6/7: those are the FULL sim modes that share do_iclass_simulation. Between reader commands the decoder sits in STATE_READER_UNSYNCD, so the gated poll at iso15693.c:1570-1575 fires every byte (reading UDP peripheral registers). With DMA filling at ~1 byte / ~19 µs, the added USB register reads plus jitter occasionally push the CPU past the 90% lag threshold → behindBy 461 with DMA_BUFFER_SIZE=512.
Commit fb8f94fa2 narrowed the gate to UNSYNCD to stop mid-frame exits, but the per-byte poll itself is still what's new on that path.
Fix:
New mode constant in include/iclass_cmd.h:
#define ICLASS_SIM_MODE_FULL_LIVE 8 // FULL + allow USB interrupt for live emul updates
Treat it identically to ICLASS_SIM_MODE_FULL everywhere except for the poll gate.
Add a flag param to GetIso15693CommandFromReader — e.g. bool allow_usb_interrupt in iso15693.c:1495 and iso15693.h:42. Wrap the poll:
if (allow_usb_interrupt &&
(dr->state == STATE_READER_UNSYNCD ||
dr->state == STATE_READER_AWAIT_1ST_FALLING_EDGE_OF_SOF) &&
data_available()) { ... }
Pass true only for live mode in do_iclass_simulation iclass.c:502:
bool live = (simulationMode == ICLASS_SIM_MODE_FULL_LIVE);
len = GetIso15693CommandFromReader(receivedCmd, MAX_FRAME_SIZE, &reader_eof_time, live);
The len == -2 drain block stays but becomes dead code for non-live modes (never returns -2).
Client side: cmdhficlass.c:1687 (CmdHFiClassTagSim) sends ICLASS_SIM_MODE_FULL_LIVE. CmdHFiClassSim -t 3/6/7 keeps sending ICLASS_SIM_MODE_FULL / _GLITCH / _GLITCH_KEY.
Other callers (iso15693.c:2270, iclass.c:1121 = reader-attack sim) pass false.
Result:
hf iclass sim -t 3/6/7 → byte-inner loop is back to its pre-tagsim shape → no blow-buffer abort.
hf iclass tagsim → keeps live update ability; still has the overhead, but that's the trade-off the feature needs.
kormax