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've been working on a standalone mode for reading several HID cards while on battery and keep them for later categorization and storage. For now, I'm keeping the collected tag IDs in an array of structs, and then spit them out over USB once connected to the client.
Sometimes I need to turn the PM3 off to conserve the battery or because I won't be reading cards for a while. Doing so would erase all the read tag IDs. Does the PM3 have a user-writable memory where I can store tag IDs so they'd survive a power cycle?
Offline
Yes. It has a flash memory (256K or 512K, depends on your version). Not all of it is used for the firmware, you could use the rest to store user data.
To be considered:
The flash memory can only be written in blocks, single bytes or words cannot be written.
you need to take care of its lifetime. It is specified for 10000 writes. You would need to implement some kind of wear leveling or restrict the writes to a few per day
Offline
Thank you for the answer. I'm wondering if there's a preferred "interface" for reading/writing to arbitrary memory blocks. For reading,
ReadMem(int addr)
seems to be the way to go. Any similarly preferred function for writing? Would something along the lines of write_block be suitable?
write_block(uint32_t address, uint8_t *data, uint32_t length)
Good call on the wearing warning. I hadn't thought about that. Luckily, in my case total writes wouldn't exceed 10/month.
Offline
Unfortunately writing isn't that easy. Have a look in bootrom.c around CMD_SETUP_WRITE and CMD_FINISH_WRITE.
Last edited by piwi (2017-04-03 15:59:07)
Offline
@piwi
I proposed in a mail that the 256K upper FLASH could be used with a JFFS2 implementation and some more POSIX implemented syscalls (yes, it's some work to be done here) .
This would be used to both provide easily writable FLASH and to have some data harvesting spitted out by a Mass_storage implementation on the device (may it be switched to or dual implemented with the actual CDC-ACM).
Could be used to provide "dynamic" configuration files. Or even some scripts for a small implented interpreted langage...
This could have the "standalone mode" extended frankly
Offline