Mifare info

[douniwan5788]

No description provided.

[github-actions]

You are welcome to add an entry to the CHANGELOG.md as well

[iceman1001]

The name change of the array is not needed. When doing pull requests please focus on the problem not adding your own code style. We have a code style you can change old code to follow, see https://github.com/RfidResearchGroup/proxmark3/blob/master/CONTRIBUTING.md

[douniwan5788]

The name change of the array is not needed. When doing pull requests please focus on the problem not adding your own code style. We have a code style you can change old code to follow, see https://github.com/RfidResearchGroup/proxmark3/blob/master/CONTRIBUTING.md

I'm trying to clean up the code and outputs make it more intuitive(don't leave a title without content). In CmdHF14AMfInfo, we're getting data from signature block, block 0, and checking if the key for sector 1 matches. Since we might get fingerprints from other blocks later, I'm renaming the variable to block0data to make it clearer what it contains.

[douniwan5788]

I am striving to adhere to the code style guidelines as closely as possible. Many pieces of code do not initially conform to these standards. I often find it challenging to decide whether to maintain the existing code or update it to meet the required style standards…

[iceman1001]

Modifying to following the code style is good. Its a long task to rework the whole code base. Thank you for your efforts.
With that being said, We don't code for what "might" come later. We code for what we got.
If there are no concrete plans for using more blocks for identification then there is no reason for the name change.

Fixing is good, making clear simple code is good, making changes for the sake of changes is bad.

[douniwan5788]

Modifying to following the code style is good. Its a long task to rework the whole code base. Thank you for your efforts. With that being said, We don't code for what "might" come later. We code for what we got. If there are no concrete plans for using more blocks for identification then there is no reason for the name change.

Fixing is good, making clear simple code is good, making changes for the sake of changes is bad.

Got it, I am reverting the rename.

[iceman1001]

There seem to be a binary filed added in the PR now tools/mfc/card_reader/mfkey32nested
Please remove it.

And a final question, why the rename of "static nonce" -> "nonce" only? In which does this PR has anything to do with the static nonce identification?

[douniwan5788]

There seem to be a binary filed added in the PR now tools/mfc/card_reader/mfkey32nested Please remove it.

And a final question, why the rename of "static nonce" -> "nonce" only? In which does this PR has anything to do with the static nonce identification?

Sorry, I accidentally added the bin file. My mistake.
The NONCE_FAIL doesn't only mean you can't get a static nonce; it means you can't get a nonce at all.
This PR is all about improving the hf mf info, and correcting the PRNG Information outputs is one of the improvements.

[iceman1001]

The idea with the "static nonce" message is to give a uniform answer about static nonce. if failing to read it , its still part of the static nonce analyse part. Its not a separate message.

Same thing goes with the suggested printing ASCII values of the block0 change. We don't need all information all the time.

As I see your PR its a modification of the anti-collision on the arm side with some minor adaptations on client side.
Please, keep PR's to one change at a time.

[douniwan5788]

The idea with the "static nonce" message is to give a uniform answer about static nonce. if failing to read it , its still part of the static nonce analyse part. Its not a separate message.

Same thing goes with the suggested printing ASCII values of the block0 change. We don't need all information all the time.

As I see your PR its a modification of the anti-collision on the arm side with some minor adaptations on client side. Please, keep PR's to one change at a time.

Not all command-line users are aware of the implementation details. The title states PRNG Information, and the output includes not only Static nonce but also Static enc nonce. If it fails, at the very least, it should indicate Static enc nonce failed as well. However, the truth is that it’s not related to Static or enc, so a generic nonce fail should be reasonable.

The Block 0 fingerprints typically include ASCII characters such as bcdefghi, FDS70V01, 1498, 07:0, and RTTQR_P. These are easily recognizable visually. Even random bytes could have a stronger visual memory effect. I believe the ASCII will assist users in quickly recognizing them.

The refactoring of iso14443a_fast_select_card is involved while I am following hf mf info down to the ARM part. I can split it into another PR if you prefer.