proxmark3.exe com3 -allow_hf_field_constantly_on_despite_overheating_risk_and_yes_I_know_what_I_am_doing
?
]]>* Continuously usage will cause overheating, so try not to use it under crazy conditions (Under the sun or extreme condition)
* Official Repo will cause overheating, since it is quite lax in turning off the antenna.
I am hesitating to re-enable this option and risk RDV4 damage. On the other hand there are still commands which leave the field on if required (emv commands. hf 14a raw) - and so far no RDV4 user had complained damage so far.
Any idea how to handle this?
]]>Maybe a stupid question: Is there a way to keep the reader field active after a "hf 15 cmd raw" as it seems to be possible in "hf 14a..."?
Background:
I am playing around with a SLIX-L tag which is in a so called "privacy mode".
This means it will not respond to no ISO15693 command except "Get random number".
The tag will respond with a 2Byte random number, and with this you can "unlock" the chip by sending the 4Byte password XOR 2 times the previous received random number. (This means no security at all, I dont really understand the purpose of the XOR...)
After that the chip will reply to all defined 15693 commands like inventory and give Access to the memory.
I have sniffed the communication with the original application, and was able to capture the "secret" password.
(Thanks for adding hf 15 snoop by the way…).
My problem now is, I can send "hf 15 cmd raw -c 02B204" to it and get the random number, but as I understand, the proxmark here turns the rf on, sends the command, awaits the response and turn the rf off after receiving the answer…
So in communication with a SLIX this means the random number is invalidaded.
Even if this would not be the case and I would sucessfully unlock the tag with "hf 15 cmd raw -c 02B3...", turning off the reader field afterwards would mean the unlocked SLIX would immediately lock again…
So is there a way to manually control the reader field?
Thanks,
datatype