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
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 reflashed the boot along with firmware, fully prepared with JTAG and the connectors necessary.
This is the result of the latest firmware flash:
proxmark3-RfidResearchGroup (master) 22:59 % ./client/proxmark3 /dev/ttyACM0
██████╗ ███╗ ███╗ ████╗ ...iceman fork
██╔══██╗████╗ ████║ ══█║ ...dedicated to RDV40
██████╔╝██╔████╔██║ ████╔╝
██╔═══╝ ██║╚██╔╝██║ ══█║ iceman@icesql.net
██║ ██║ ╚═╝ ██║ ████╔╝ https://github.com/rfidresearchgroup/proxmark3/
╚═╝ ╚═╝ ╚═╝ ╚═══╝ pre-release v4.0
Support iceman on patreon - https://www.patreon.com/iceman1001/
on paypal - https://www.paypal.me/iceman1001
[=] Session log /home/ondro/.proxmark3/log_20191123.txt
[=] Using UART port /dev/ttyACM0
[=] Communicating with PM3 over USB-CDC
[!] Received packet frame with variable part too short? 246/308
I.e. Iceman's last fork works (3003686d01e8c9b3842cdda281168358477df7ba) but flashing "RfidResearchGroup/proxmark3" (b82f1279bad9f8e78898edf2857d6eaaa73d43e7) leaves you with non-working proxmark.(
Latest bootrom checked out and built today:
[ ARM ]
bootrom: RRG/Iceman/master/ed0bbe4 2019-11-09 22:08:49
os: iceman/master/ice_v3.1.0-1096-g3003686 2019-10-29 20:49:59
So plz make the version tags in repo.
In general my rule of thumb has been to use various repos depending on type/purpose. For this I have one checkout just for the legacy PM3 hardware and one for the RDV4 hardware:
For the legacy PM3 hardware:
[~/Projects/proxmark3]$ git remote -v
iceman git@github.com:iceman1001/proxmark3.git (fetch)
iceman git@github.com:iceman1001/proxmark3.git (push)
origin ssh://git@github.com/Proxmark/proxmark3 (fetch)
origin ssh://git@github.com/Proxmark/proxmark3 (push)
upstream
And for the RDV4 hardware:
[~/Projects/proxmark4]$ git remote -v
origin git@github.com:RfidResearchGroup/proxmark3.git (fetch)
origin git@github.com:RfidResearchGroup/proxmark3.git (push)
upstream
In this way, I haven't had any issues (except on occasion when trying to use the vanilla PM3 client (./client/proxmark3) with the Iceman firmware (and vice versa).
Honestly, most of my reason for this has been I never have issues with the upstream (it's generally my local code changes causing problems). The proxmark code hasn't historically been focused around a semver style "plan a feature, wrangle developers to build it, QA it, release it" model. Doing that would add to the overhead of administrivia without adding a lot of value to what/how most of us are using the project. Beyond that, there's the parallel issue of chinese clones using god knows what in their forks which Iceman is generally pretty patient with addressing. I'd hate to see the maintainers have to get into the boat of managing even more binaries (people get confused enough with the binary FPGA bitstreams) because there's a "release" it github with no compiled assets attached.
As far as I can tell, you're in the same boat as me (even with the same grip of hardware under your belt). Given the number of times where the project has had sparse leadership over the past decade... I'm pretty stoked to have Iceman, 0XFFFF and others continuing where rule left off. My preference is to have them keep driving things at the pace we've had over the latter half of the decade as opposed to the former.
Of course let me also take a moment to eat some crow (pardon the non-english speakers for using idioms) when I see that just a few days ago a public roadmap was updated:
Fun thing, the iceman fork is deprecated since we made RRG/Iceman repo compile for most legacy Proxmark3 device's (there are known hardware where it doesn't work)
https://github.com/RfidResearchGroup/pr … ameters.md
The really old Proxmark3 devices from 2008-2009, with 64kb flash, is beyond help. Someone on DC27 told me about it.
The idea of tags isn't new, once we feel we have gotten onboard with some important functionality, we will make a v4.0 release and this becomes a non-issue. For ref: https://github.com/RfidResearchGroup/pr … issues/319
It was in the process for make install
Looking at @mnemarchon problems, I notice a mix of RRG/Iceman bootrom and Iceman fork fullimage. Not a great idea to mix like that.
[ ARM ]
bootrom: RRG/Iceman/master/ed0bbe4 2019-11-09 22:08:49
os: iceman/master/ice_v3.1.0-1096-g3003686 2019-10-29 20:49:59
The RRG/Iceman client also reports more on what compiler/when/targeted os information to keep things easier.
Its this projects strenght and at the same time causes most dispare is that the project is designed to run differernt firmwares.
Today there are even more of options in HW/FW with actors always trying hard to it lock down. Bringing everyone to a open source table would be nice, its the end user who comes here or to GH for help that draws the shortest stick.
The 3 repos make things much more complicated since each has different features - e.g.:
Desfire support
ISO-15396 magic card commands
There are recent commits to each of them. Often you have look for the right commit to get things working (hence making the version tags request).
So far monkeypatching some RRG scripts into iceman's repo has the best results for me.
Spending time bisecting by commit to find which one works is not exactly fun. Especially if it wants you to reflash bootloader and you have to find the mental energy if you are ready for soldering and desoldering JTAG pin header to RDV4 in case the bootloader flashing bricks it (that happened to me few times and everyone I know with proxmark).