Skip to content
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

Get some flexibility in the tag type detection #17

Merged
merged 5 commits into from
Jan 19, 2016
Merged

Conversation

smortex
Copy link
Contributor

@smortex smortex commented Jan 18, 2016

Currently an internal table helps guessing the type of tag based on its SAK & ATS.
But now phones start being able to emulate tags (CyanogenMod, Kitkat,...) while SAK & ATS are still not under control, so being different than expected.

How to get more flexibility?

Getting an environment variable to bypass entirely detection and assume that we've a tag of the right type requested by the application?

Or instead of guessing the tag from its SAK/ATS, test proactively if the tag is of a specific type?

E.g. ASSERT_MIFARE_DESFIRE(tag) would not check a preset flag but would test actively if the card is a DESFIRE by sending a GetInfo command.

Original issue reported on code.google.com by yob...@gmail.com on 3 Dec 2013 at 3:23

@smortex
Copy link
Contributor

smortex commented May 5, 2015

The best is probably to trust the developer. If he find a tag and manipulates it with the DESFire API, he is likely expecting a DESFire target and presenting another type of tag is likely to fail quickly.

I therefore propose to basically remove the target type detection code.

A bunch of new API functions may however be created to proactively check if a tag behaves as expected by the developper, e.g.

int mifare_desfire_taste (MifareTag tag);

int main (void) {
    // ...
    if (mifare_desfire_taste (tag) < 0)
        errx (EXIT_FAILURE, "Not a MIFARE DESFire tag");
    // proceed
}

@smortex smortex added this to the 1.0.0 milestone Jan 18, 2016
@smortex smortex self-assigned this Jan 18, 2016
smortex added a commit that referenced this pull request Jan 18, 2016
smortex added a commit that referenced this pull request Jan 18, 2016
@smortex
Copy link
Contributor

smortex commented Jan 18, 2016

@doegox, since you initially opened this issue, maybe you would like to comment on this pull request?

This idea is to make the xxxxxxxxxx_tag_new() functions public, and pass them a nfc_device * and a nfc_target. The new xxxxxxxxxx_taste() helper functions accepting the same arguments can be used to check if a given tag is likely to act as some type of tag, but there is no requirement to use this.

nfc_device *device;
nfc_target target;
// [...]
if (!mifare_ultralight_taste(device, target)) {
  if ('n' == prompt_user("This does not look like a Mifare Ultralight.  Try anyway?"))
    return;
}
FreefareTag tag = mifare_ultralight_tag_new (device, target);
// [...]
mifare_ultralightc_tag_free (tag);

Split Mifare Classic 1 and 4K tag allocation.
Rely on new tasting functions.
It's available through tag->type.
@doegox
Copy link
Member

doegox commented Jan 19, 2016

I like the API you proposed and the removal of the static checks.
merge!

doegox added a commit that referenced this pull request Jan 19, 2016
Get some flexibility in the tag type detection
@doegox doegox merged commit 48c9383 into master Jan 19, 2016
@smortex smortex deleted the tag-detection branch April 3, 2017 22:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants