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.
Hi forum,
I'm currently reimplementing a client for the Proxmark from scratch. During development it really struck a nerve with me that the MCU source makes rather sloppy and abundant (!) use of the debug functions Dbpprintf/string. This makes it hard for the client to properly parse messages, especially if the status of the MCU is unknown (for example, a running tune HF command will only reveal tons of debug string messages, but the client will not be able to properly identify the state of the device).
Therefore, I'm currently in the process of reworking the ARM sourcecode in the following manner:
- Have a clear separation between command- and responsecodes (this is currently rather sloppy, they're intermixed. Example: CMD_MEASURE_ANTENNA_TUNING is exclusively a command, but CMD_MEASURED_ANTENNA_TUNING is exclusively a response even though it says "CMD" in the define)
- Use the mostly unused argument fields to have responsecodes and subcodes (i.e. the command CMD_MEASURE_ANTENNA_TUNING_HF in my implementation returns three different messages now: RSP_MEASURE_ANTENNA_TUNING_HF with subcode SUBCMD_MEASURE_ANTENNA_TUNING_HF_STARTED, SUBCMD_MEASURE_ANTENNA_TUNING_HF_VALUE or SUBCMD_MEASURE_ANTENNA_TUNING_HF_ENDED).
- Try to get rid of most debug statements and replace them with properly machine-parsable messages
While I've obviously implement a client for these messages on my own, I wanted to ask if this is a change that you would be willing to incorporate into mainline. Because if so, I'd also modify the command line client to have the same look-and-feel (i.e. display the messages as they are displayed currently). If you don't like my changes and there's no chance of it getting into mainline anyways, I'd rather not bother modifying the client (and just focus on the MCU source and my own client).
Please advise which option you'd be most comfortable with.
Thanks in advance,
Joe
Offline
I'm sorry for being an idiot: Posted this in the wrong forum. Could someone please move it to "General (USB driver, Framework, Protocol)"? Thank you.
Offline
Just so you get an impression on what I mean by the refactoring, this is some WIP (fixed the client too):
http://www.file-upload.net/download-7797958/refactoring.patch.gz.html
Changelog:
- Fixed some coding convention inconsistencies (2 spc vs 4 spc vs tabs)
- Started properly naming commands (CMD_...) and responses (RSP_...)
- Changed CMD_VERSION, CMD_MEASURE_ANTENNA_TUNING and CMD_MEASURE_ANTENNA_TUNING_HF to not emit debug messages, but respond with appropriate subresponses
- Implemented CMD_MEASURE_ANTENNA_TUNING_LF (with appropriate subresponses)
- Renamed some inconsistent API calls (CMD_DOWNLOADED_SIM_SAMPLES_125K is now called CMD_UPLOAD_SIM_SAMPLES_125K, as it actually uploads to the Proxmark, now downloads something from it)
- some const correctness here and there (e.g. cmd_send)
I'd be happy to get some feedback and your thoughts. Thanks!
Offline
Personally, I think it's great. I've been bothered a bit by the protocol myself, but kind of felt that 'it's in place and it works'. My thoughts about the protocol starts of with what you've described, perhaps using some flags to indicate response, or response status (fail, ok, pending.. ) . And then I start to think about using another protocol entirely, e..g protobuffers or something. The problem is, there are a lot of commands, and it is very dificult to test - I can only test comands on proxcards, mifare classic and a few more tags, don't have the equipment to test all possible cards and scenarios. So, I wouldn't want to make any massive sweeping changes across the entire codebase, but sure, if there are gradual improvements that make the protocol more coherent and structured, I'm all for it! Can't speak for anyone else though.
Haven't looked at your code yet, I'll take a look within a few days.
Offline
Another thing; if you're doing this, I think it would be wise to use some form of VCS. Either that you got access to the svn, and implemented the changes in a branch, or that you created a github- or bitbucket repository based on the svn trunk code at the time of creation. It would be a lot easier to maintain for all of us.
A third thing: have you seen the new scripting-capabilities (the scripting branch)? That's another way to interact with the device, using Lua instead. If that is used, the old pm3-stuff could basically become legacy-only, while new stuff could be implemented in lua. This will enable legacy stuff to keep working, but also enable more rapid development and experimentation.
What is the goal of your client?
Offline
First off, thanks for your encouraging words :-)
And I agree with you 100% on the command interface. Diving into the code was a bit confusing at first (for example, that responses from the Proxmark are actually of type struct USBCommand, that's inconsistent and confusing). Also I noticed that commands were a bit abused (mainly the ACK command, which - depending on the exact context - may or may not return a value in the payload and what value that is is anybody's guess). Anyways, since I needed to do some cleanups for my code to work, I figured this may be beneficial for the community as well (since a beginning refactoring makes it easier even if you change the whole thing later on).
Anyways, I'm proceeding with my work (implementing some minor things, such as improved output of the manchester demodulation unit and so on). Yes, obviously I use a VCS, it's all neatly organized in a git repo locally here. I just posted the SVN diff so that you could get an impression of what my plan is.
I don't have SVN access to the public repository and don't want to go around annoying people for access :-) After all, you guys don't know me and shouldn't trust me. I don't know how development is organized with the PM3 project, so this is why I was asking here.
The scripting client, yes, I've taken a look at it. Frankly I'm not the biggest Lua fan, but my client uses a very similar appraoch (but using Python3). Comes with the added benefit of having access to scipy and numpy, two very powerful fast Python libraries for scientific and numerical computation (which I use to analyze traces). I guess the more options there are, the better for the project.
Offline