Research, development and trades concerning the powerful Proxmark3 device.
Remember; sharing is caring. Bring something back to the community.
"Learn the tools of the trade the hard way." +Fravia
You are not logged in.
Time changes and with it the technology
Proxmark3 @ discord
Users of this forum, please be aware that information stored on this site is not private.
I made a utility that reads transponder UIDs from various kinds of "ordinary" RFID / NFC readers (here if you're curious) and I recently added support for the Proxmark3. Essentially, it turns it into a dumb desktop reader.
It does this quite simply by issuing read commands continuously through the client to poll for transponders in the vicinity. This is of course incredibly inefficient and clearly not something the Proxmark3 was built for, but at least it lets me use my utility with transponders that I don't have dedicated readers for. Also, my Proxmark3 does something useful instead of gathering dust when I don't hack around with it.
I left it running overnight, and this morning I noticed it had become quite hot. Not impossible to touch kind of hot, but definitely warmer than I would have anticipated.
Is it okay to use it that way, or do I risk damaging it?
Another question: when I configure my utility to read HF and LF transponders alternatively, it's almost unusable because the Proxmark3 seems to be doing some lengthy context switching, or reconfiguration, to switch from operating in one frequency to another. It's fine if I sequentially do different kinds of reads only in HF or only in LF (it sets itself up once then the next reads happen quickly) but if I do HF > LF > HF > LF... reads in sequence, it takes several seconds between reads.
Is there any simple way to speed things up? Or am I just asking too much of the device?
Offline
Since the division between LF and HF part for the FPGA code, the pm3 isn't good at doing context switching between them.
It has to upload and program the fpga each time you switch, it takes about 1sec to do, then you need to sample for card which takes more time for LF, switching over to hf, and I guess you are doing this from the client, you would need to execute "hf search", which looks for different HF cards and each failed test has to timeout, taking more time. So no, in the current shape of the firmware, using it like you are doing is a bad idea.
The device becomes hot but as long as you don't keep it in the sun when doing so it will be fine.
Offline
Okay thanks. I guess I'll add something in my code to stay in one particular frequency. I don't much like the idea of reprogramming the FPGA a dozen times per minute.
Yes, I'm doing all that from the client's console. I started out making a custom LUA script. I went as far as issuing the right USB commands to sample and then download the samples back (in LF anyway), when I finally realized there just aren't any callbacks to leverage the demod routines in the C code. So I would have had to recode everything in LUA, which is stupid. So instead I remote-control the client. It's significantly slower, but I don't have to reinvent the wheel.
EDIT: I don't do a hf search actually. It's too long. I just try to read each enabled format in turn. As for LF, I just take as many samples as needed for the worst case format enabled, then ask different kinds of demod on the same samples. If you stick to EM410x, it can be pretty quick, as it doesn't need very many samples.
if pm3_read_iso14443a:
cmd_sequence.append("hf 14a reader -3")
if pm3_read_iso15693:
cmd_sequence.append("hf 15 cmd sysinfo u")
if pm3_read_em410x:
lf_samples=8201
if pm3_read_indala:
lf_samples=30000
if pm3_read_fdx:
lf_samples=39999
if lf_samples:
cmd_sequence.append("lf read s {}".format(lf_samples))
if pm3_read_em410x:
cmd_sequence.append("lf em 410xdemod")
if pm3_read_indala:
cmd_sequence.append("lf indala demod")
if pm3_read_fdx:
cmd_sequence.append("lf fdx demod")
Last edited by Rosco (2020-05-15 08:30:09)
Offline
yeah, only doing LF or HF make a difference. Also limit the bytes to download help significantly, You can try a generic limit of 20 000samples and 'lf search 1' will find most of them with that.
Offline