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>
