Working notes from setting up and verifying a Proxmark5. Two documents, the session log, the captures, and the tooling used to produce them.
Everything here was run on real hardware. Every external claim is checked against the source, the log, or upstream. Where something is unproven, it says so.
| File | What it is |
|---|---|
docs/proxmark5-beginners-guide.md |
Start here if you have never used a Proxmark. What it is, installing the client, first reads, sniffing, emulating, and a full worked setup with everything that went wrong |
docs/proxmark5-runbook.md |
Operational reference. Flashing rules, what is verified, known traps, quick command reference |
Both also exist as self-contained HTML with the screenshots embedded, so they open in any browser with nothing else present:
docs/proxmark5-runbook.htmldocs/proxmark5-beginners-guide.html
The HTML is generated from the markdown by tools/mkhtml.py. Edit the markdown, re-run the
script. Do not hand-edit the HTML.
1. Do not flash mainline onto a PM5. Master does not support the hardware and the
bootloader rejects the image. Everything else about flashing is less scary than it sounds:
PR #3449's PLATFORM=PM5 build is flashed daily by its author, by maintainers and by
testers, and there is a documented unbricking path that needs no J-Link. Hold the button 6
seconds for ISP mode, flash with Artery's AT32 ISP tool. What you actually lose by flashing
is your unit's shipped -dirty image, which no public commit reproduces and which cannot be
read off the board to back up. Treat that as a one-way door, not as a brick risk.
2. PM5 support is real but unmerged. There is no separate Proxmark5 repository, which is
why proxmark5.com links to RfidResearchGroup/proxmark3. The work is PR #3449, branch
xianglin1998:proxmark5. As of 2026-08-17 it is open, draft, not merged, 131 commits, 316
files, committed to daily. It defines PLATFORM=PM5 with -DCHIP_AT32F435_37, and that is
the build PM5 owners flash today. Still a draft with open bugs, so there is a reason to wait.
3. Build the client at the firmware's base commit. Not a recent client. The matching one.
No distro package can do this. Kali shipped v4.18994 (Sept 2024) for most of 2026, which
makes healthy antennas report Antenna tuning failed; on 2026-08-17 it moved to v4.21611,
which is now newer than this firmware's base commit and mismatches the other way.
git clone https://github.com/RfidResearchGroup/proxmark3.git ~/proxmark3
cd ~/proxmark3 && git checkout 6df95a2dc9a8e529037ebe75256e8dee5555f60d
make client -j$(nproc) # NOT `make all`, and NEVER `sudo make install`
cd ~/proxmark3 && ./pm3
hw pingis the liveness test, notlsusb. USB CDC stays enumerated through an ARM hang, so the device looks connected when it is not answering.- A sniffing or simulating device is indistinguishable from a hung one. Press the button before you reach for the USB cable.
hf 14a sniffdoes not block without-i. A scriptedtrace liston the next line reports0 bytes.- T55xx commands cache config from
lf t55xx detectfor that session only. Use a command script with-s <file>to keep them together. - Ignore every trace annotation after an AUTH frame. CRYPTO1 encrypts the parity bits, so
the client mis-decodes ciphertext as commands like
WRITEBLOCK. No write occurred. libnewlib-devhas no candidate on current Kali, and apt installs nothing at all when one name in the list fails to resolve.libnewlib-devandlibnewlib-arm-none-eabiexist up to Debian trixie but are gone from testing/sid, which is what Kali tracks.picolibc-arm-none-eabiis the survivor, and a client-only build needs neither.- Packaged and prebuilt clients ship firmware images and
pm3-flash-allalongside the client. True of Kali'sproxmark3-firmwares, the Homebrew formula and ProxSpace's precompiled binaries. Build client-only from source instead. - One unexplained firmware wedge, cause not established. It happened once.
hf searchcompleted and returned; the wedge began during the followinghf 14a info. Nobody pressed the button before replugging, so it is not even certain the firmware was hung rather than busy. n = 1.tools/hf-search-stability-test.shexists to settle it.
| Capability | State |
|---|---|
| LF read / write / verify / recover | Verified |
| HF identify / key recovery / backdoor / UID rewrite | Verified |
| Emulator memory load and readback | Verified |
| Sniffing | Verified, 240 frames captured |
| Emulation against a live reader | Verified |
| UHF | Blocked. No client support exists anywhere |
| BLE / Wi-Fi | Blocked on PM5 ARM firmware, not on the client or the module |
Everything public software can reach is working. The two blocked items need vendor software that is not published.
On wireless: the client already has tcp:, udp:, bt: and socket: transports, and the
BWM's ESP32-C2 firmware is public and fully documented. What is missing is the PM5 ARM
firmware that would drive the module over UART, and that is absent from mainline and from PR
#3449. Fitting the module gets you a battery, not a wireless link. The host side is probably
ready, so retry ./pm3 tcp:<ip>:<port> after any firmware release.
docs/ both documents in markdown and HTML, plus 5 screenshots
captures/ card dumps and the sniffed trace
logs/ session log from the whole setup day
tools/ pm3shot.sh terminal screenshot helper
hf-search-stability-test.sh wedge-reproduction harness, NEVER RUN yet
mkhtml.py + shared-style.html regenerate both HTML docs
LICENSE CC BY 4.0 for docs, MIT for tools
| File | From |
|---|---|
hf-mf-6A0B1F5E-*.bin/.json |
Gen1a magic card, full 1K dump plus recovered keys, all default FFFFFFFFFFFF |
lf-t55xx-FFEFB4DD-FBDF0062-dump.* |
T5577 carrying the synthetic DEADBEEF01 EM410x ID |
sniff-capture.trace |
3174 bytes, 240 frames (184 reader, 56 tag), ISO14443-A off an Android phone |
All captures are from owned blank test cards. Nothing here relates to any real credential.
Credential data from a personal access card was removed and replaced with [REDACTED]
markers, along with the surrounding narrative and the credential type. Eight markers remain
to show where content was cut. Do not re-derive or re-record any of it.
Lines mentioning Pattern ELECTRA, DEZ 8 and similar near the top of the log are not
credential data. They belong to the synthetic DEADBEEF01 test card, where 57005 is
0xDEAD. Those were deliberately kept.
Everything in this archive is safe to share as it stands. Two things to know:
- The device's SPI flash UID is deliberately withheld. It is a per-device serial that also
appears in the USB descriptor, so publishing it is a fingerprint. Read it back with
hw statuson your own device. tools/hf-search-stability-test.shhas been syntax-checked and never executed. It needs the hardware.
CHANGELOG.md records how these documents were verified and what changed along the way.