proxmark3¶
Proxmark3 v3 and v5 — RFID and NFC research tool (RDV4 not covered)
Vendor: Proxmark community / RRG
Status: supported — the identifiers and setup recipe are believed correct.
Maintainer-verified 2026-08-26 on Pop!_OS 22.04: Attached and enumerated, twice, with scripts/identify-device.sh. Both captures returned the same identifier, no product string and no serial. The client was not built and no card was read.
What it is¶
A research tool for low-frequency (125 kHz) and high-frequency (13.56 MHz) RFID and NFC, able to read, emulate and analyse a wide range of card technologies.
What you can do with it¶
Read and analyse access cards and transit tokens, study the protocols they use, and emulate them for testing systems you are authorized to test.
Setup¶
Kali packages the client (proxmark3 4.21611-0kali1, measured 2026-08-26) and the proxmark3 package installs it there. On Debian 13 and Parrot it must be built from source against matching firmware, which needs the source backend this project has not written — those steps are not documented yet, because writing an untested path would be a documentation bug.
Known problems¶
Two attached at once cannot be told apart. The device supplies no product string and no serial, so /dev/serial/by-id/ gives both the same path and no udev symlink can distinguish them. Use /dev/serial/by-path/, which names the physical port, and keep track of which board is in which socket. This is the one device in this catalog for which by-path beats by-id. Client and firmware are version-locked, and a mismatch is the most common source of confusing behaviour. Several incompatible hardware generations share the name. This entry covers the v3 and v5 boards, which are what is available to test against; an RDV4 is planned and not owned, and is deliberately not claimed here. Neither the client nor a udev rule is packaged by any target distribution.
How it identifies itself¶
| USB id | What | Confirmed | Node |
|---|---|---|---|
2d2d:504d |
Proxmark3 in normal operating mode | yes | serial |
What is not yet known¶
Narrowed sharply, and what remains is a real limitation rather than missing work. The operating-mode identifier is confirmed. What is NOT established: Whether the v3 and v5 boards differ at all in their descriptors. Both captures returned identical output, which suggests they do not, but the two runs cannot be attributed to two specific boards with confidence from the record kept. The bootloader identifier. A Proxmark enumerates differently while its bootloader is running, and that was not captured -- it needs the button held during attachment. Whether any firmware variant supplies a serial. The stock build does not, and if some variant does, that changes the story above completely: a serial would restore /dev/serial/by-id/ as the answer.
Who can close it: the maintainer owns this hardware; the gap closes at the next capture session.
Access and permissions¶
Group membership required: dialout, plugdev — added at install, applies at next login.
Firmware modes¶
- bootloader_button — tooling: — The Proxmark client flashes both bootloader and application images, and the device enumerates with a different identifier while in the bootloader. The client is built from source against the firmware it will talk to — client and firmware are version-locked and a mismatch is the most common source of confusing behaviour. Not packaged in Debian; this needs the source backend.