mirror of
https://github.com/RfidResearchGroup/proxmark3.git
synced 2026-09-17 23:15:58 +00:00
iceman1001andClaude Opus 5 (1M context)
6341f40b4c
Thanks @TheArchitect0880 for pointing it out and suggested a first fix. MifareAcquireEncryptedNonces packs two 4 byte encrypted nonces plus one byte holding both their encrypted parity nibbles into every entry, but the reply declared num_nonces * 4 bytes. The client walks that buffer 9 bytes at a time, so on RDV4 it read 612 bytes out of a 544 byte payload and handed roughly 15 of every 136 nonces to add_nonce() from stale packet buffer content. Those fake nonces went into the .bin nonce file too. Count pairs instead of bytes. num_nonces now reports whole pairs only, so a button abort or a static nonce bailout part way through a pair drops the dangling nonce rather than shipping a half built entry whose parity nibble was never filled in. MFC_NONCE_PAIR_SIZE and MFC_MAX_NONCE_PAIRS document the layout next to mf_nonces_resp_t so the 9 vs 4 confusion cannot come back, and the client now refuses a reply too short for the nonce count it carries. Both acquisition functions collect straight into the reply buffer rather than a second PM3_CMD_DATA_SIZE stack array, which halves the stack used per call. MifareAcquireNonces also returned isOK = 2 on button press, which is not a PM3_* status; that is PM3_EOPABORTED now. Co-Authored-By: Claude Opus 5 (1M context)