mirror of
https://github.com/RfidResearchGroup/proxmark3.git
synced 2026-09-29 19:48:09 +00:00
MsprgandClaude Fable 5.1
0cd1fada0e
The USB-unplug power-off left two ways to drain the battery: a PM5 woken by the button and forgotten, and one left idle after the phone disconnected. Idle trigger (opt-in, PM5_AUTOOFF_IDLE_MS 0 by default so out of the box only the unplug trigger exists, as before): on battery the board powers off after the idle timeout with no interaction and no wireless client. Interaction is a received command over any transport, any button press, or a client connecting or leaving; a standalone mode or a long-running command holds the main loop, so neither can be cut short. The BWM reports its clients with the LINK_STATE broadcast (8092, companion Proxmark5_BWM_esp32 PR) which bwm_forward.c tracks; at boot the BLE half is seeded with a status query since the module only reports changes. When the timer is due but a client is still tracked, the module is asked for its BLE state (at most every 10 s), so a lost "client left" broadcast cannot pin the board on. And right before going off the module is asked once more: older module firmware never sends the broadcast and a "connected" one can get lost, and neither may power the board off under a silent BLE client. No answer means off. --unplug off: the unplug trigger always won, so "survive the unplug, go off after N idle seconds" was not reachable. It is its own setting (default on = unchanged). With it off an unplug only restarts the idle clock - from the unplug, not from the last command, or a board that sat idle on USB for an hour would still die with the cable. Unplug detection is edge-based (VUSB present at the previous poll, absent at this one) instead of "absent and seen since boot", which would fire on every poll after a tolerated unplug. VUSB is followed while the feature is switched off too, so switching it on again on battery is not taken for an unplug. Stored on the BWM: runtime-only settings reset at every boot, which is exactly when the idle trigger matters. The PM5 has no settings store, so the switch, the idle timeout and the unplug switch live in the module's host value slots (APP_CMD_SET/GET_SYS_HOST_VALUE 1021/1022, companion PR; slot 0 switch, 1 idle seconds, 2 unplug), loaded at the first auto-off poll and saved by CMD_PM5_BWM_AUTOOFF with 1 s per write, so a silent or older module still leaves the reply inside the client's 5 s wait. Without a module, or with an older one, the defaults apply and the status says "not stored". hw bwm autooff [on|off] [--idle <sec>] [--unplug <on|off>]; no argument shows the state, one fact per line: switch, idle timeout, unplug power-off, stored on module, USB power, USB seen since boot, unplug trigger armed, tracked client, the module's BLE state, idle time. Payload [action][enabled][idle_s u32][unplug, optional] with keep sentinels; both actions are non-zero so an old firmware, which reads byte 0 as the enable flag, can only be left enabled. hw status prints the module's live BLE state and the auto power-off setting; at debug level also the tracked client, which should agree with the live state. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>