So I just got a Proxmark3 Easy 512k and I’ve been playing around with it in preparation for my next implant. Yesterday, I was able to flash both the official repo and Iceman’s repo bootloaders/full images. However today, after swapping back to Iceman’s, I’ve run into an error with flashing the full image, which I suspect is also the reason my Proxmark throws a fit when I try to “auto” (i.e. disconnects and reconnects a bunch of times). I have tried both the pm3-flash-all, flashing the bootloader and fullimage separately, and just flash-all then both. At this point, I’m now wondering if there’s a way to just straight factory reset the PM3 and so I can just reinstall the firmware.
I should mentioned I have reinstalled ProxSpace, and that I am able to run the official repo no problem, but I think that may be because it’s smaller and doesn’t access the deeper storage that Iceman’s does. Attached you can find the error in question, which looks to be a locked segment?
Indeed that make clean && make all is part of the installation procedure and happens in both the official and Iceman, but I can try again as I’ve decided I’ll set up to directories, one for each of the repos for testing purposes.
I thought about admin privileges as well, but when I attempt to run the “runme64.bat” or “runme.bat” as admin, the command terminal will open for a brief second, then disappear. It appears to have some predisposition to being called normally.
Yeah I made that mistake the first time I was make clean && make all, but since then I’ve just always renamed the Makefile.platform.simple and just commented out the RDV4 line and uncomment the PM3 generic. It doesn’t have seemed to make a difference, but that was my first thought as since it seemed like the flasher was going beyond its limits, so to speak.
Overall, while it’s been a not super great experience, I can certainly appreciate the flexibility of a device like the PM3 and PM3 easy, but damn are they right when they say it’s not user friendly. @Pilgrimsmaster, if you’re not a fan of the PM3, what do you use for read/writing to your implants?
An RDV4… but that doesn’t mean I like it.
Purely a means to an end.
I would prefer to have something small and “robust” I can just throw in my bag,
read - write - done
There are125kHz readers you can plug into your phone… if only they could write!
There is the Keysy, If only it had a more suitable antenna for xSeries, But It would be interesting to see if it could read a “New” LF Flex?, I will try this when I am out of Lockdown ( I’m currently separated from my FlexMT ), Even if it works to read, it would be a pity we wouldn’t be able to write with it, because it uses a proprietry write method and will only write to Keysy products
The Blue cloner would be awesome IF it didn’t write it’s stoopid password, it had a more suitable antenna, and could write to HF implant(s)
A while ago there was mention of a DT reader / writer project, but it never eventuated, The market would likely be too small to make it viable.
Paraphrasing Amal here ~“We have the Proxmark, that will do what we want, we would be better of spending time and money elsewhere”~
I am really hoping that the Flipper ,that, as well as reading HF and LF, it will be capable of writing also.
In my opinion, the Holy Grail of a what I want:-
HF & LF, small form factor, easy to use, basic interface with expansion to Phone App, and then add the other functionalities ontop
FYI – I’ve fixed the randomization of the COM ports under Windows.
That randomization was caused by the PM3 devices not previously exposing a unique serial number (via the USB protocol). When you update the bootloader to a version(*) with the above fix included, it will then expose a unique ID, and your COM port will be (mostly(**)) static / safe from changes.
(*) it’s part of the iceman fork main branch already, since February 19th, 2023. The last official release as of today was Nitride (v4.16191) was released January 29th, 2023, and thus does not have this fix. Therefore, you would need to build the binary yourself.
(**) If it was COM4, and the PM3 is not connected, then something else might come along and “claim” COM4. To reduce that chance, you could assign the PM3 device a higher number COM port (e.g., COM87).