search

iceman1001 / proxmark3

[Deprecated] Iceman Fork, the most totally wicked fork around if you are into proxmark3
http://www.icedev.se/pm3.aspx
GNU General Public License v2.0
465 stars 116 forks source link

nonce2key: printf->PrintAndLog #63

Closed micolous closed 7 years ago

micolous commented 7 years ago

Use PrintAndLog instead of printf, so that the logger/UI can pull debugging information, instead of it being sent to stdout.

I've unrolled a loop here so I don't have to mess around with allocating a buffer for each row of the nonce2key table, as every PrintAndLog call includes a newline character.

There's a lot of other printf calls in the client which should be addressed at some point.

iceman1001 commented 7 years ago

Merry X-mas! Thanks for your ideas and commits.

If I understand your reason for this PR its to be working more with your pm3-client-as-a-lib project. You can use the mfkey source under /tools/mfkey to make a stand-alone version instead. I suggest you remove the printf/printandlog at all in a stand-alone version for your build. They don't help you and is a reason I've started to have them printed only when 'verbose mode' is asked for. If you just want the key, you don't need execution time, setup data etc etc.

The main reason for more and more prinft statements in my fork is not to clutter the log file with more or less debugstatements. They are not needed for 99% of the users.

I'm not inclined to merge this PR at the moment if you can't convince me otherwise.

micolous commented 7 years ago

I'm trying to keep my client in sync with the C client for cryptographic functions, which is why I chose this approach. I think non-printf logging is a common issue between both my project and the pm3gui (which IIRC is not currently serviceable, but someone may pick that up in future).

Going and pulling this all into a library is another option, but mfkey32v2 is not the only cryptographic function that I want to reference going forward. I want to avoid a situation where I need to copy large parts of the crypto code.

I am not worried as much about hardware interface and UI code -- this is generally much simpler and harder to mess up.

I understand that exporting a consistent interface from pm3 is difficult, when it is traditionally the only user of that code.

I'd like both the C client and the Android client to be able to share cryptographic code between them. So an alternative way is to move that code into a shared library which both can reference. This would also allow other implementations of the PM3 client in future.