The firmware powers off at 3300 mV (BWM_SHUTDOWN_MV) but the gauge
Terminate Voltage was its 3200 mV default, so the PM5 switched off while
`hw status` still showed a few percent. The gauge setup (setcap and the
boot check) now writes Terminate Voltage 3300 mV with the capacity and
chem ID, and `hw dbg -3` shows it on the Gauge line.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The fitted cell is 3.7 V nominal (500 mAh, 1.85 Wh), full at 4.2 V. The
charger stopped at 4.095 V and the BQ27427 stayed on its ROM default
4.35 V profile (chem ID 3230), so the gauge never saw a full charge:
Qmax kept its default 16384 and never updated, "charge done" read 83 %,
and a discharge reached 0 % with over 100 mAh still in the cell.
- default charge target 4200 mV (boot and plain `hw bwm vchg`)
- `hw bwm setcap` also selects chem ID 1202 (4.2 V) in the same config
update and verifies both afterwards; still a no-op when correct
- boot re-applies the gauge setup after a gauge reset (Flags ITPOR, RAM
back on ROM defaults) or when the profile is wrong, keeping a capacity
set with setcap
- `hw dbg -3` shows the gauge chem ID on the Gauge line
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
configure_environment.sh only modelled the USB serial link, so on a PM5 driven
over wifi or BLE it printed "plug the Proxmark3 in" and checked nothing that
applied. The udev rule and dialout membership stay flagged exactly as before,
since every Proxmark gets flashed over USB sooner or later; what was missing
was everything else:
- the bluetooth group, which 'make accessrights' already adds when the group
exists, and which 'pm3 -p bt:' / 'ble:' need. A warning on PM5 or BTADDON,
a note elsewhere so a plain PM3 build stays quiet.
- cap_net_raw on an installed client. ble_resolve_name() opens a raw HCI
socket, so without it 'pm3 -p ble:<name>' needs sudo while 'ble:<MAC>' does
not; client/Makefile grants it on install unless SKIP_SETCAP=1.
- an absent /dev/ttyACM* no longer reads as an absent Proxmark.
Adds client/requirements.txt, since nothing listed the packages the scripts in
client/ import: bleak for the BLE roles of pm5_ble_bridge.py (lazy import, the
native ble:<MAC> and tcp: transports and the --relay role do not need it), and
Unidecode and jq for the two maintenance scrapers. The bleak floor is 0.19
because the API the bridge uses is present in 0.19.5, 0.22.3 and 3.1.0 alike.
--extras now checks it too.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A first-run check for a freshly cloned repo, so a new user finds out what is
missing before a build fails halfway through.
Checks the host toolchain (GNU make, gcc/g++, pkg-config, git, gcc >= 8 for
Qt6), the arm-none-eabi toolchain plus a linkable ARM C library, the required
client libraries (readline, bz2, lz4, libcrypto) and the optional ones, the
bundled-fallback ones, a Python venv with tools/requirements.txt, and on Linux
the dialout/uucp membership, the udev blacklist rule, ModemManager and the
rights on /dev/ttyACM*. Also the tracked .dummy files that hold the firmware
object directories in git, since nothing recreates those.
Detection is by probe, not by querying the package manager: pkg-config where a
.pc file exists, otherwise a real compile-and-link of the header with its -l
flag. Python requirements are compared offline through importlib.metadata.
The device side is covered too: it resolves PLATFORM and PLATFORM_EXTRAS the
way make does, rejects unknown platforms and the combinations Makefile.hal
errors on later (BWM off PM5, BTADDON on PM5, ...), and when there is no
Makefile.platform at all it lists the platforms and offers to write one for the
device the user picks, rather than silently building an RDV4 image.
It changes nothing by default. It asks before creating a venv and before
writing a Makefile.platform, and only --install touches the package manager.
Missing items are mapped to package names for apt, pacman, dnf, zypper, brew
and port and printed as one paste-ready line; NixOS is pointed at
tools/shell.nix.
make configure runs it. The script stays directly callable because make stops
on an invalid PLATFORM before it could run any target.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Default level is down to 7 lines:
- Battery: charge %, voltage, temperature and charge state on one line,
draw and runtime left while discharging; capacity and health
- BWM: firmware, chip, link speed and BLE state on one line
- Power: power save with the auto-off triggers, Flipper link
Charge %, health and temperature are colour coded. Charger detail is
shown on a fault or FET_DIS. Charge profile, raw gauge values, chip
and heap details and the idle / sleep counters need hw dbg -3. A
negative temperature now keeps its sign.
pm5_battery_test.py parses the new Charge / Capacity lines.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Parsing:
- all subcommands parse through the argtable: --on/--off, -m <mode>,
-u <on|off> via CLIGetOptionList, wifi --status/--stop; no more
sscanf positional words, so every option shows in the help
- wifi status and stop split into helpers; help examples aligned, the
SSID example shows quoting
Output:
- 20 column labels as in hw status, state colour coded
- autooff: 4 lines; the idle timer shows when a client pauses it,
USB / client / BLE inputs only in client debug mode
- wifi --status, wifipower and the bring-up share one WiFi state line
- ble status: the factory passkey is shown red; the pairing hint shows
only while pairing is off, the passkey hint only for the default key
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Release asset from RfidResearchGroup/Proxmark5_BWM_esp32 tag V5
(built Nov 12 2026 08:31:33, ESP-IDF v5.5.2).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Release asset from RfidResearchGroup/Proxmark5_BWM_esp32 tag V4
(built Nov 11 2026 13:40:09, ESP-IDF v5.5.2).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Release asset from RfidResearchGroup/Proxmark5_BWM_esp32 tag V3
(built Nov 11 2026 11:01:47, ESP-IDF v5.5.2).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Release asset from RfidResearchGroup/Proxmark5_BWM_esp32 tag V2
(8b133b0, ESP-IDF v5.5.2). OTA-tested on PM5: V1-12-g23bfa7b -> V2.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
client/resources/PM5_FPGA_fix_loedge_bug.bin was a Gowin IDE build
posted in #3449 on 2026-08-15, before the FPGA sources were opened in
#3697. Its lo_edge_detect fix (adc_clk = pck0) has been in the sources
since 7666e8444, so the shipped binary only lagged behind them and
could not be checked against anything in the tree.
Add `make -C fpga fpga_pm5_release`, which builds fpga_pm5.bin and
copies it with its sha512 to client/resources. It stays out of `all`
so a local test build does not replace the shipped image by accident.
Point update_fpga.cmd and update_fpga_and_bwm.cmd at fpga_pm5.bin and
document the build in Getting_Started_With_PM5.md.
The image was built with oss-cad-suite 2026-10-11, the release pinned
in fpga-pm5.yml. A clean rebuild gives the same bytes, IDCODE is
0x1100381B, and all clocks meet timing.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
New `hf gp` command family. Every subcommand works without keys and
never sends INITIALIZE UPDATE / EXTERNAL AUTHENTICATE, so no card
retry counter is used. All take -w for the contact interface, -a to
log APDUs and -v for verbose output.
hf gp info
Selects the ISD, or the default applet when A000000151000000 is
absent, and reads:
- Card Recognition Data, decoding the GP version, SCP and Java Card
version from their OIDs
- CPLC, with the fabricator name and BCD dates decoded
- the Key Information Template (KVN, key id, type, length, with
SCP02 / SCP03 key sets marked)
- IIN, CIN and the SCP sequence counter
GET DATA retries with CLA 00 on cards that reject CLA 80.
hf gp crs
GET STATUS on the Contactless Registry Service (GPC_SPE_025 3.11),
following 6310 to fetch more data. Lists each applet's AID,
lifecycle, contactless activation state, display data, URL, group
and CREL members. --aid filters on a full or partial AID.
hf gp aids
Finds applet AIDs by partial SELECT (P2=00, first occurrence):
- finds the shortest prefix the card accepts
- tries aidlist.json prefixes and every registered RID A0 00 00 0x xx
(--quick skips the RID sweep)
- extends each hit one byte at a time to the full AID
- --prefix limits the search to one subtree
Cards whose default applet accepts any SELECT are detected and
refused. The walk is capped at 200000 APDUs and can be stopped with
<Enter>. Without partial selection it falls back to the full
aidlist.json AIDs.
aidlist.json gains the GP ISD, CRS and ARA-M AIDs, plus USIM, ISIM,
CSIM, UnionPay, and ICCOA so found AIDs get named. The CCC digital key entry gets a description.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
demod splits the starting digit from the reserved bits, writes the
animal code as CCC NNNNNNNNNNNN, knows all 249 ISO 3166-1 countries
and shows Bio-Thermo only for the chips' exact trailer. clone and sim
refuse values the frame can't carry, sim sends the data block flag for
--extended 000000 and stops with Enter, reader also tries 125 kHz.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
lf destron sim only printed "To be implemented". It now sends the
frame that lf destron clone writes, FSK2 RF/50 as in the clone's T5577
config. Both take 5 bytes of 00-7F: clone wrote a byte above 7F
without its top bit and padded a short uid with FF of bad parity.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
clone took negative FC and CN, and MS values above 5 and 22 bits,
without a word: MS FC 40 wrote the card of FC 8. sim let ids of 32
bits or more change the fixed bits, so --id 2147483648 simulated id 0,
and printed the shifted frame as Internal Id. The sim help example
used --cn, the option is --id, and the clone hint named lf keri read.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
HPP32 wrote its card number 10 bits past the 32-bit frame, it now uses
bits 13-30 as cardinfo shows. H10320 wrote its first digit over the
leading one, so decode refused most numbers, and two of its parity
masks had typos. S12906b needed ParityValid, which no caller sets.
HGen37 decode checked bit 28 instead of 26. The limits of nine formats
did not match the fields Pack writes. wiegand list printed the usage
of wiegand info.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The gen2 branch refused `-u` with "Not supported on this card". These
cards do take a UID write: a five command knock, the new UID one byte
per command (always seven commands, zero padded), then a HLTA which
commits it. The card answers the halt instead of staying silent, and
without it everything before is discarded when the field drops - which
is why the sequence is absent from the vendor app, whose HLTA is emitted
by the Android NFC stack on teardown.
The new UID must match the card's current UID length, the parts are
physically 4b or 7b. Outcome is decided by re-selecting and comparing
the UID, not by the status byte.
Verified on a 4 byte card. The 7 byte path is inferred from the sequence
always carrying seven UID bytes and is untested.
A refused -r / -u now returns an error instead of PM3_SUCCESS.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Problem
The native hf mfu countertear used a device-side
CMD_HF_MFU_COUNTER_TEAROFF path with a static increment payload,
decided once per run. The pyscript mfuev1_counter_reset.py implements
the same attack with auto-calibration, a 3-phase attack loop,
per-attempt BD delay tuning (hunting) and stuck-value handling,
which the native command lacked.
Change
- rewrite the client command around the generic tear-off hook
(hw tearoff) and raw INCREASE_CNT frames, mirroring the pyscript
step by step: preflight checks, CHECK_TEARING_EVENT support gate,
targeted repair/normalize, BD sweep calibration (working delay
accepted only on 0xBD), and the DECREMENT -> PREPARE (0x00FFFF)
-> RESET phases with the same increment payloads (000100 for
decrement steps, 010000 for reset/repair)
- same delay tuning on counter movement: +1 when unchanged, -1 when
a jump exceeds 10, delay locked after a successful decrement
- remove CMD_HF_MFU_COUNTER_TEAROFF usage from the client; device
side stays untouched
- add Lua port client/luascripts/mfuev1_counter_reset.lua with the
same behaviour, using core.console capture and Enter-to-stop
- regenerate doc/commands.md and doc/commands.json
Behaviour change
Same CLI shape as the pyscript (-c/-f/--DelayBD/--Delay00, legacy
-i/-l/-s/-x options removed). Console output now matches the pyscript.
Testing
gcc warningless for client, armsrc and bootrom (RDV4). make check
green. doc regenerated with GD enabled. Verified 1:1 against the
pyscript and the new Lua port on hardware (EV1 card). Not tested
here: clang, Windows/ProxSpace and macOS. No build files are touched,
so the usual client-side review applies.
Co-Authored-By: opencode agent (GLM-5.3-Flash-Free) <noreply@opencode.ai>
Add an opt-in simulator probe that checks a reader's AES authentication continuation against a supplied candidate and stops before the final card response. Expose the result through the firmware protocol and etest bench command, and document the evidence and handshake scope.
Co-Authored-By: OpenAI Codex <noreply@openai.com>
New CLI command `lf cotag sim` with COTAG tag simulation implementation.
Detects COTAG reader activation sequence and emulates a COTAG tag.
Signed-off-by: andrej@towelbyte.net
RF over CEP works now that the FPGA bitstream step is done - it was
never actually CEP-blocked. Note CMD_CEP_STATUS (Hardware Status
dashboard) and the real open bug (Read Hitag2 over CEP fails with
stale cached data, firmware-side). SPI bit-order/phase is confirmed,
not pending.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
`lf t55xx detect -p <pwd>` reached for the password whenever detection
failed without one, and sent it across every downlink mode and again
after a wake. On a tag that is not password protected those frames can
be taken for a write: the PWD bit gets set and the tag's data is
destroyed, leaving it locked behind whatever block 7 already held.
`lf t55xx read` and `lf t55xx dump` already guard against this. They
verify the PWD bit in the configuration block before using a password,
and expose -o/--override to bypass the check deliberately. detect had
neither, and T55xxReadBlockEx() treats a live `detect -p` as proof the
bit is set.
detect cannot run the same check -- reading the configuration is what it
is for, and the password is only reached for once that has failed -- so
the risk has to be the user's to accept. Gate it behind -o/--override to
match read and dump, and carry read's warning banner into the help.
No change in behaviour for anyone not passing -p.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
