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

Identify Mifare DESFire #249

Open
johndekroon opened this issue Jan 2, 2020 · 13 comments
Open

Identify Mifare DESFire #249

johndekroon opened this issue Jan 2, 2020 · 13 comments

Comments

@johndekroon
Copy link
Contributor

johndekroon commented Jan 2, 2020

Hi,

I started experimenting with some other cards. I have a DESFire card which I tried to read using the Identify command. However, it shows "unknown card". The ATQA is 0304 and the SAK is 20.

I tried to patch the code, but then I saw the following lines (Application/Reader14443A.c:99-100):
[CardType_NXP_MIFARE_DESFire] = { .ATQA = 0x0344, .ATQARelevant = true, .SAK = 0x20, .SAKRelevant = true, .ATSRelevant = false, .ATSSize = 5, .ATS = {0x75, 0x77, 0x81, 0x02, 0x80}, .Manufacturer = "NXP", .Type = "MIFARE DESFire" }, [CardType_NXP_MIFARE_DESFire_EV1] = { .ATQA = 0x0344, .ATQARelevant = true, .SAK = 0x20, .SAKRelevant = true, .ATSRelevant = false, .ATSSize = 5, .ATS = {0x75, 0x77, 0x81, 0x02, 0x80}, .Manufacturer = "NXP", .Type = "MIFARE DESFire EV1" },

On the forum of the proxmark I saw the following topic: http://proxmark.org/forum/viewtopic.php?id=2982

It stated that the proxmark will correctly identify those cards with the same ATQA as mine. I've tried to change the ATQA to 0x0304, but that doesn't result in a recognised card.

Edit: Hm. While I was reading further in the documentation (https://www.nxp.com/docs/en/application-note/AN10833.pdf) I was reading that the value indeed should be 0344. However:

Page 10:

Never use ATQA to identify a chip or to extract UID size. Follow the ISO/IEC 14443- 3 card activation sequence (fig 1 & 2 of this document) based on SAK. ATQA can be collided and misleading.

So a few questions:

  • If the ATQA and SAK can't be used together to identify the chip, how does identification work?
  • What should I change to make the identification of the card work?
  • I noticed that every time I read the card, the UID is changing. When I read the card with a non-chameleon reader, this phenomenon is also observed. Any idea what's going there?

Thanks!

@johndekroon
Copy link
Contributor Author

I did some more testing. When I set ATQARelevant to false (which the documentation recommends) and the ATSRelevant to true it correctly identifies my card.

In the source code I found the following comment:

// for the following two, setting ATSRelevant to true would cause checking the ATS value, but the NXP paper for distinguishing cards does not recommend this

However, if I read the NXP paper, it seem to suggest the opposite. Am I missing something here?

@johndekroon johndekroon mentioned this issue Jan 2, 2020
@johndekroon
Copy link
Contributor Author

johndekroon commented Jan 2, 2020

In case ATS and ATQA are indeed mixed up, I wrote a fix for this.
It now correctly identifies my card.

@johndekroon
Copy link
Contributor Author

After reading further, NXP indeed does also not recommend the use of the ATS:

As the ATS of different MIFARE ICs can be customized, it is certainly not advisable to rely on the ATS to differentiate the IC type. NXP advises to keep the default value of the ATS to avoid any privacy attack based on the information in ATS.

It states that we have to use the GET_VERSION command. The problem is, how do I issue the GET_VERSION command?

@fptrs
Copy link
Collaborator

fptrs commented Jan 3, 2020

Hi @johndekroon,
sending the GET_VERSION command to distinguish DesFire tags is indeed the way to go. Good work so far. Do you have troubles implementing it on the Chameleon or understanding the commands syntax?

@johndekroon
Copy link
Contributor Author

For what I understand so far is that I have to do "send 60" for the GET_VERSION command. The problem is that I don't receive anything:

SEND 60 101:OK WITH TEXT NO DATA

@fptrs
Copy link
Collaborator

fptrs commented Jan 3, 2020

I think you have to put 60 into the APDU framing. Furthermore you might have to play the anticollision protocol before issuing the GET_VERSION command

@johndekroon
Copy link
Contributor Author

I think I need a little help with that. Is there some example which can help me started?

@fptrs
Copy link
Collaborator

fptrs commented Jan 3, 2020

You can take a look into the code from the libfreefare examples. They have implemented a mifare_desfire_get_version function.

@martinbeier
Copy link

martinbeier commented Jan 6, 2020

just to sum up, something was already mentioned before:
ATQA for a MIFARE DESFire is 0344, but if you config the DESFire with Random UID the ATQA is 0304 -> so you most probably have a DESFire card, configured with Random UID.

Afaik it's not very useful, to identify a card with ATQA and SAK values, cause you would have so many possibilities. Many cards "share" the same values. Purpose for ATQA is for anticollision support and UID length and SAK (select acknowledge) value is for UID (not) complete and ISO14443 Layer 4 support yes/no.

To Identify a MIFARE DESFire card command code "60" is the way to go. You would only need ISO framing for the MIFARE DESFire Light, all other DESFire chips should answer to the desfire native command code "60"

@johndekroon
Copy link
Contributor Author

@martinbeier That is indeed the case, the card has a random UID. Is there a quick / easy way to send commands to the DESFire? I've looked to the libfreefare project, and the only thing that I was able to extract from it was that it would take me a significant amount of time to understand what they actually are doing.

@martinbeier
Copy link

@johndekroon I'm not really aware, what is already implemented in ChameleonMini firmware. You would need to do Anticol L1 -> Select UID part1 -> Anticol L2 -> Select UID part2 -> RATS (request ATS) -> should be implemented, as you mentioned that you got back ATS from DESFire card, afterwards you would only need to send command code 60 in ISO14443-4 frame including CRC.

For testing try to send following three commands: (in order)

  • 0a 00 60 68 b5
  • 0a 00 af 93 8b
  • 0a 00 af 93 8b

did a test with DESFire EV2 8K card:

| Rdr |52 | | WUPA
| Tag |44 03 | |
| Rdr |93 20 | | ANTICOLL
| Tag |88 04 0b XX d4 | |
| Rdr |93 70 88 04 0b XX d4 95 3b | ok | SELECT_UID
| Tag |24 d8 36 | |
| Rdr |95 20 | | ANTICOLL-2
| Tag |YY ZZ 4d 80 d9 | |
| Rdr |95 70 YY ZZ 4d 80 d9 25 d1 | ok | SELECT_UID-2
| Tag |20 fc 70 | |
| Rdr |e0 80 31 73 | ok | RATS
| Tag |06 75 77 81 02 80 02 f0 | ok |
| Rdr |0a 00 60 68 b5 | ok |
| Tag |0a 00 af 04 01 01 12 00 1a 05 bf 16 | ok |
| Rdr |0a 00 af 93 8b | ok |
| Tag |0b 00 af 04 01 01 02 00 1a 05 39 f9 | ok |
| Rdr |0a 00 af 93 8b | ok |
| Tag |0a 00 00 04 0b XX YY ZZ 4d 80 cd 65 11 65 51 51 02 90 | |
| |61 | ok |

cannot proper format the output with markdown :/
https://imgur.com/a/6yzktTS

@johndekroon
Copy link
Contributor Author

@martinbeier what did you use to get this read outs?

@martinbeier
Copy link

martinbeier commented Jan 23, 2020

@johndekroon
not sure, what exactly is your question ...
I sent the three commands to a desfire card and sniffed / logged with a proxmark3.
It's just an example to send a command to a desfire card (in the example: full get_version log)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants