RfidResearchGroup
[idea] Implement ST25_TEAROFF in hf 14b wrbl
I see the commit 19789381df5b1e683b3c13f059c9e7972b421c5c, it looks interesting but I would like to try it with the command hf 14b wrbl, looking at the code it seems like it tries to write and then turns off the field after a few uS, so the standalone and flash-only functionality seem like absurd constraints to me.
@SecLabz could you implement this?
You're right, integrating the tear-off directly into the command would likely be more useful for many cases. However, I honestly didn't feel comfortable enough with the wider codebase to implement it cleanly there myself – hence why I opted for the self-contained standalone mode.
If you feel up to the challenge of integrating it properly and submitting a PR, or even if you just want to experiment, I do have a separate, less polished implementation (https://github.com/SecLabz/proxmark3) that works more like what you described (as a command). It's functional (at least on my PM3 Easy), but it would definitely need a good amount of polishing to be ready for a clean merge, which honestly, I probably won't have the bandwidth to do myself.
Thank you for your suggestion and you great work. I tested on block 5 where in a sri4k I have the value 46 46 46 46 and I restored the value F5 FF FF FF, but after many tries I never reached FF FF FF FF which was my target. I see many times FF FF FF FF as green but it never stop. I tested with counter 6 where I have the value 00 00 00 00 but I see always bits at 0 never a change, is it normal?
I don't know if I can make a PR, but I'll evaluate what to do. I think the right way is to put a parameter to the wrbl command, move the tear-off functions into a dedicated c file and then the other parts of the code should use it.
Getting the counter to exactly 0xFFFFFFFF using the tearing method is tricky because that specific state tends to be unstable. Even if some reads momentarily show 0xFFFFFFFF, it likely won't remain reliably in that state due to how the tearing attack affects the tag's internal workings.
To achieve a stable state after resetting, values slightly lower are often necessary. For instance, reaching 0xFFFFFFFD or below usually involves subsequent operations (like two decrements) that help stabilize the tag's internal counters. The state 0xFFFFFFFF achieved directly via tearing hasn't undergone this stabilization.
Regarding the 0x00000000 state: if the counter is already at zero, it's at its absolute minimum. Since the tag prevents decrementing below zero, the tearing attack method described (which typically exploits write/decrement operations) may not be effective or directly applicable in this situation.
For a deep dive into why this happens and how the internal counters behave, the paper explains it all: https://www.sstic.org/media/SSTIC2024/SSTIC-actes/tears_for_fears_breaking_an_rfid_counter/SSTIC2024-Article-tears_for_fears_breaking_an_rfid_counter-marty_granier_delion_JHhE6Td.pdf
@SecLabz I think you have some timing overflows in your standalone mode.
@yashikada the specific 14b tear off functions from SecLabs standalone mode would be nice to have /armsrc/common_tear.c
I am sure you can do it.
