-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NFC: Files from DESFire cards appear truncated; more reads may be necessary #3347
Comments
@gornekich I was thinking you might know and have some ideas |
See https://discord.com/channels/740930220399525928/954422716138676254/1193342799215603814 for more information. |
I think this was intentional to either prevent OOM or simplify memory management. |
@gornekich I noticed something important that might inform that this bug actually is due to a buffer sizing problem elsewhere in the code. When reading my "large" cards, even with this new loop code, I see this in the logs:
It could be that the card is responding with the full file PDU, but the poller code simply isn't being set up to handle such large responses. |
Fixed in dev. Please, reopen if the issue persists |
Summary
The DESFire card "poller" does not appear to be able to adequately dump more than 472 bytes from any DESFire card file, even if the file's metadata indicates it is larger.
Background
The Mifare DESFire is a particular kind of ISO 14443-compliant "smart card" which, amongst other things, provides several file-based abstractions for saving and retrieving data on the card. The flipperzero NFC framework has wonderful support for querying and interacting with such cards, including an automatic "poller" which attempts to dump as much information as possible from the card when read in the NFC application.
The issue at hand may be related to how the poller attempts to read file data from the card.
Theories
Tracking down the source to the entire process, I direct your attention to line 403 in
flipperzero-firmware/lib/nfc/protocols/mf_desfire/mf_desfire_poller_i.c
Line 403 in 7eeb60e
wherein the PDU to read the file data is constructed and sent to the card. The PDU requests to read the entire file in one go, which may be an issue due to limitations in PDU response size.
Next, observe where the response to the file read request is processed in
flipperzero-firmware/lib/nfc/protocols/mf_desfire/mf_desfire_i.c
Line 228 in 7eeb60e
Note that the response handler doesn't check (nor have enough information to check) whether the response data actually includes all of the bytes requested.
It may be that underlying ISO 14443 restrictions prevent read responses from exceeding a certain size, and as such, a state machine might have to be set up to read such files in smaller chunks, using multiple read requests, until satisfied.
Reproduction
/nfc/
directory on the SD Card..nfc
file.Example:
Target
No response
Logs
No response
Anything else?
I discovered this issue while attempting to write a "ride history" display in my Clipper card parser at #3344
The text was updated successfully, but these errors were encountered: