NFC: Add write support for the password-protected MF ultralight tag

[nekolab]

What's new

• Add write capability for password-protected MF Ultralight tags.
• Fix the check condition in mf_ultralight_poller_handler_read_tearing_flags. Support for MfUltralightFeatureSupportSingleCounter doesn't imply support for reading tearing flags, as seen in NTAG21x series.
• Revised MF Ultralight poller logic from auth => read **THEN** write to auth => read **OR** write. According to NXP specifications, NTAG commands should maintain the tag in ACTIVE or AUTHENTICATED state. However, some compatible tags deviate from this spec and accept only one read/write command in the AUTHENTICATED state. This change addresses write command failures because in the previous logic it would issued after the read commands.
• More debug logs to provide users with better NFC status insights without needing to rebuild the firmware.

Verification

Testing was conducted on an NTAG shipped with an air purifier:

• Read, unlock, and save the tag first. Modified a sector and wrote it back to the NFC tag without issues. The altered sector was correctly read in subsequent actions.
• Attempted to write with an incorrect password resulted in expected write failure.

Additional testing on devices without password protection needs reviewer's help due to limited device availability.

Checklist (For Reviewer)

• PR has description of feature/bug or link to Confluence/Jira task
• Description contains actions to verify feature/bugfix
• I've built this code, uploaded it to the device and verified feature/bugfix

[gornekich]

Thanks for PR!

While your solution works for the case you mentioned, it could be dangerous in other cases. For instance, if we want to write data on a tag with different password and AUTHLIM set, we might brick card after several AUTH attempts.

Personally I think that writing to NTAG/Ultralight can be done in separate application. In general to write data from one card to another we should think about:

1. Is target card password protected? Can we successfully auth to target card?
2. Does target card has AUTHLIM?
3. Is source card password protected?
4. Does user want to write full card dump, including configuration paged and password + pack, or just user data?

The consideration of all possible scenarios will result in quite big logic diagram. Also I think during writing logic we should address mentioned issues in UI, which we may not want to implement in NFC application. That's why I think this Ultraight/NTAG writing would be a good separate application.

The bottom line: we can't accept this PR because it may bricks some users cards, and I can't think about how to modify it without writing too much code. Please let me know your thoughts on it and what do you think about separate application.

[gornekich]

It bricks a target card that has different password and AUTHLIM set not 0.

[nekolab]

@gornekich Thanks for the review! I totally understand your concern. I think we can separate this PR into two parts:

1. Can we consider merging the bug fix parts first? This should include the flag correction and the read or write fix. It's not related to the password but only the logic and bug fix.
2. For the write support to password-protected card part. IMO, for the NFC app, the basic scenario would be "I dumped a card and edit the nfc file, then I want to write it back to the original card". So what if we just rename the "write" to "write back to origin", validate the UID before writing, and add a new warning screen display something like "A full card write will be performed, please make sure the password is correct or it may break your card"? The write operation only happens with the full user concentration.

Also, I totally agree if the user wants to write a single sector or tune a feature with interactive UI, it should not be done in the NFC app.

[gornekich]

Still thinking about writing to password protected cards. I need some time.

[nekolab]

@gornekich Sorry for the disturbing but would you mind if I create a new PR that only contains changes to this file? These changes correct the wrong feature detection behavior and avoid performing an unnecessary read before write

[gornekich]

@nekolab Sorry for late response. Yes, it would be better to make this fix in separate PR.

Regarding writing to original card, we have this task in backlog and will implement this soon.