Describe the Bug
hf mf autopwn consistently fails with [!!] Error: No response from Proxmark3 on a MIFARE Classic 1K card. This happens right after successfully recovering all keys for sectors 0–15 (both Key A and Key B), during or immediately after the final nested/hardnested phase. The failure is 100% reproducible on every single run, on the same card, at the exact same point in the process.
Hardware & Environment
- Device: Proxmark3 (generic, non-RDV4)
- Device ID:
9ac4:4b8f (J. Westhues ProxMark-3 RFID Instrument)
- Microcontroller: AT91SAM7S512 Rev A, ARM7TDMI (64K SRAM, 512K flash)
- Peripherals: No external flash, no smartcard reader, no BT
- Card Type: MIFARE Classic 1K
- OS: Linux x86_64
Steps to Reproduce
- Run command:
hf mf autopwn
- All 16 sectors' keys (A and B) are successfully recovered and printed to the console.
- The process crashes/halts with:
[!!] Error: No response from Proxmark3.
Everything tried (all fail identically):
Command variants:
hf mf autopwn (default)hf mf autopwn --slowhf mf autopwn --in (forcing no-SIMD instead of default AVX512)hf mf autopwn --slow --in (combined)hf mf autopwn -l (legacy mode, uses hf mf chk instead of nested/hardnested — fails too, which was surprising since this mode doesn't even touch hardnested)
Firmware/client versions tested (all clean builds, PLATFORM=PM3GENERIC, client/firmware confirmed in sync via hw version):
v4.19552 (2024-11-22)v4.21128 (2026-02-25)v4.21611 (2026-04-14, latest stable at time of writing)- Same result on all three, ~1.5 years apart.
Ruled out (checked individually before concluding this is likely a firmware-level issue):
- USB disconnect/reset: confirmed device stays visible in
lsusb throughout the failure (no drop in device number)
- Kernel-level USB events:
dmesg -w shows nothing new at the exact moment of failure
- USB autosuspend:
power/control forced to on for the device — no change
- ModemManager interference: service was inactive, not the cause
- TLP power management: checked, not the cause
- Antenna:
hw tune shows normal HF/LF voltage
- Firmware/device mismatch:
hw version shows none
hardnested benchmark test (hf mf hardnested -t): completes successfully in a few seconds, so raw CPU brute-force performance is not the bottleneck
Workaround currently in use: manually building a key dictionary from the keys already recovered before the crash, then running hf mf dump --1k -k mykeys.dic to complete the dump without triggering nested/hardnested again.
Additional context: found two older reports with the same symptom — #1734 (RDV4 hardware) and iceman1001/proxmark3#212 (also AT91SAM7S-based hardware, from 2018) — suggesting this might be a longstanding issue tied to how hardnested behaves on this microcontroller family rather than something version-specific.
Nota (en español):
Muy buenas, quería añadir un comentario aparte. Soy nuevo usando GitHub y estoy empezando la carrera de Teleco, así que puede que se me escape algo técnico, pero quería compartir lo que he ido probando, mi intuición,conversaciones con cht-gpt y lo que he leido en varios foros, por si ayuda.
He estado varios días intentando resolverlo por mi cuenta antes de reportarlo aquí: cambié de versión del firmware dos veces (una mucho más reciente y otra de hace año y medio), probé una velocidad de comunicación más lenta y sin aceleración por hardware para ver si el problema era de rendimiento, y probé también un modo alternativo que evita el ataque más complejo. En todos los casos el fallo era exactamente igual, en el mismo punto.
También comprobé que no era un problema de cable o de conexión, porque el dispositivo nunca desaparece del sistema durante el fallo, ni el sistema operativo registra ningún evento en ese momento. Descarté igualmente temas de ahorro de energía y otros programas que pudieran estar interfiriendo.
Creo que esto es lo que está pasando: En parte sí es un problema de comunicación, pero no por un cable suelto ni un puerto USB roto. Lo que ocurre es que en el paso final (cuando calcula las claves más difíciles con el método "hardnested"), el Proxmark3 tiene que hacer tantísimos cálculos seguidos que se queda "colgado" antes de terminar; al dejar de responder, el programa del ordenador entiende que perdió la conexión y por eso muestra ese aviso. El fallo real sería que el aparato se queda sin capacidad para seguir en ese momento tan exigente, algo más probable en mi caso porque tengo la versión básica (sin memoria extra), que se satura antes que las versiones más nuevas como la RDV4. Y no creo que sea solo cosa mía: a otras personas les pasa exactamente lo mismo, quedándose atascadas justo en ese mismo paso con ese mismo mensaje (ver los issues #1734 y iceman1001/proxmark3#212 que menciono arriba).
Si alguien conoce alguna solución, o sabe si esto se puede arreglar por firmware en el futuro, se agradece muchísimo. Y si me he equivocado en algo de la explicación, encantado de que me corrijáis.
Un saludo y mil gracias a Iceman y sus colaboradores.
Describe the Bug
hf mf autopwnconsistently fails with[!!] Error: No response from Proxmark3on a MIFARE Classic 1K card. This happens right after successfully recovering all keys for sectors 0–15 (both Key A and Key B), during or immediately after the final nested/hardnested phase. The failure is 100% reproducible on every single run, on the same card, at the exact same point in the process.Hardware & Environment
9ac4:4b8f(J. Westhues ProxMark-3 RFID Instrument)Steps to Reproduce
hf mf autopwnEverything tried (all fail identically):
Command variants:
hf mf autopwn(default)hf mf autopwn --slowhf mf autopwn --in(forcing no-SIMD instead of default AVX512)hf mf autopwn --slow --in(combined)hf mf autopwn -l(legacy mode, useshf mf chkinstead of nested/hardnested — fails too, which was surprising since this mode doesn't even touch hardnested)Firmware/client versions tested (all clean builds,
PLATFORM=PM3GENERIC, client/firmware confirmed in sync viahw version):v4.19552(2024-11-22)v4.21128(2026-02-25)v4.21611(2026-04-14, latest stable at time of writing)Ruled out (checked individually before concluding this is likely a firmware-level issue):
lsusbthroughout the failure (no drop in device number)dmesg -wshows nothing new at the exact moment of failurepower/controlforced toonfor the device — no changehw tuneshows normal HF/LF voltagehw versionshows nonehardnestedbenchmark test (hf mf hardnested -t): completes successfully in a few seconds, so raw CPU brute-force performance is not the bottleneckWorkaround currently in use: manually building a key dictionary from the keys already recovered before the crash, then running
hf mf dump --1k -k mykeys.dicto complete the dump without triggering nested/hardnested again.Additional context: found two older reports with the same symptom — #1734 (RDV4 hardware) and iceman1001/proxmark3#212 (also AT91SAM7S-based hardware, from 2018) — suggesting this might be a longstanding issue tied to how hardnested behaves on this microcontroller family rather than something version-specific.
Nota (en español):
Muy buenas, quería añadir un comentario aparte. Soy nuevo usando GitHub y estoy empezando la carrera de Teleco, así que puede que se me escape algo técnico, pero quería compartir lo que he ido probando, mi intuición,conversaciones con cht-gpt y lo que he leido en varios foros, por si ayuda.
He estado varios días intentando resolverlo por mi cuenta antes de reportarlo aquí: cambié de versión del firmware dos veces (una mucho más reciente y otra de hace año y medio), probé una velocidad de comunicación más lenta y sin aceleración por hardware para ver si el problema era de rendimiento, y probé también un modo alternativo que evita el ataque más complejo. En todos los casos el fallo era exactamente igual, en el mismo punto.
También comprobé que no era un problema de cable o de conexión, porque el dispositivo nunca desaparece del sistema durante el fallo, ni el sistema operativo registra ningún evento en ese momento. Descarté igualmente temas de ahorro de energía y otros programas que pudieran estar interfiriendo.
Creo que esto es lo que está pasando: En parte sí es un problema de comunicación, pero no por un cable suelto ni un puerto USB roto. Lo que ocurre es que en el paso final (cuando calcula las claves más difíciles con el método "hardnested"), el Proxmark3 tiene que hacer tantísimos cálculos seguidos que se queda "colgado" antes de terminar; al dejar de responder, el programa del ordenador entiende que perdió la conexión y por eso muestra ese aviso. El fallo real sería que el aparato se queda sin capacidad para seguir en ese momento tan exigente, algo más probable en mi caso porque tengo la versión básica (sin memoria extra), que se satura antes que las versiones más nuevas como la RDV4. Y no creo que sea solo cosa mía: a otras personas les pasa exactamente lo mismo, quedándose atascadas justo en ese mismo paso con ese mismo mensaje (ver los issues #1734 y iceman1001/proxmark3#212 que menciono arriba).
Si alguien conoce alguna solución, o sabe si esto se puede arreglar por firmware en el futuro, se agradece muchísimo. Y si me he equivocado en algo de la explicación, encantado de que me corrijáis.
Un saludo y mil gracias a Iceman y sus colaboradores.