Can nfc reader send "magic" checks to detect invalid card?

Support
1

Hello!
I have:

  • 2 readers, to which I don’t* have access
  • 1 Mifare Classic 1k tag
  • proxmark3

I don’t have permanent access to readers to make trace recordings between reader and tag, however I did make a few of them
Then I was able to decrypt the keys from my tag and successfully clone the tag completely, to the new device. Now all identifiers including Manufacturer data, access bits, etc are completely identical.
And one of the readers now can accept the new magic-tag.
But the problem is that the other reader does NOT accept it, although it works with the old original tag.
And for me it is very strange, because tags are completely identical, communication standards should be the same. And if the tag is the same, it works on one reader, but not on the other - it means that the problem is in the second reader. Fair enough, isn’t it?
My only assumption was that the reader tries to write data to the card, for example, in the Manufacturer block, and then if it succeeded - then the tag is considered Magic and such a tag can not be trusted, we do not work with such a reader - drop the connection.

And so to check it somehow, I made some sniff-overs on the second reader and recorded their trace. What confused me in some of them was that I saw new to me Magic WUPC1, which was never seen in traces recorded on the first reader. Here’s the main part of that trace:

      Start |        End | Src | Data (! denotes parity error)         | CRC | Annotation
------------+------------+-----+---------------------------------------+-----+--------------------
          0 |       1056 | Rdr |26(7)                                  |     | REQA
    1679472 |    1680528 | Rdr |26(7)                                  |     | REQA
    1686624 |    1689088 | Rdr |93  20                                 |     | ANTICOLL
    1702032 |    1712496 | Rdr |93  70  16  27  91  fa  5a  34  21     |  ok | SELECT_UID
    1873872 |    1874928 | Rdr |26(7)                                  |     | REQA
    1881088 |    1883552 | Rdr |93  20                                 |     | ANTICOLL
    1896496 |    1906960 | Rdr |93  70  16  27  91  fa  5a  34  21     |  ok | SELECT_UID
    1914464 |    1915456 | Rdr |50(7)                                  |     | HALT
    1985232 |    1986224 | Rdr |40(7)                                  |     | MAGIC WUPC1
    2056000 |    2057056 | Rdr |26(7)                                  |     | REQA
    2065584 |    2076048 | Rdr |93  70  16  27  91  fa  5a  34  21     |  ok | SELECT_UID
    2145888 |    2146944 | Rdr |26(7)                                  |     | REQA
    2154704 |    2165168 | Rdr |93  70  16  27  91  fa  5a  34  21     |  ok | SELECT_UID
    2217024 |    2221728 | Rdr |60  38  3e  c6                         |  ok | AUTH-A(56)
    2313648 |    2323024 | Rdr |a5! 96! b0  83! 71! a2  6e! d6         |  !! | ?
    2389472 |    2394240 | Rdr |79  21  b8! f4                         |  !! | 
    2714640 |    2715696 | Rdr |26(7)                                  |     | REQA
    2721792 |    2724256 | Rdr |93  20                                 |     | ANTICOLL
    2737200 |    2747664 | Rdr |93  70  16  27  91  fa  5a  34  21     |  ok | SELECT_UID
    2801504 |    2806208 | Rdr |60  01  7c  6a                         |  ok | AUTH-A(1)
    2898384 |    2907696 | Rdr |2b  27! 0e! 16! 49  fc  7d! 9d!        |  !! | 
    2975552 |    2980256 | Rdr |44! d3  e0  73!                        |  !! | 
    3160944 |    3165712 | Rdr |bc! d5! 82! ec                         |  !! | 
    5123120 |    5124176 | Rdr |26(7)                                  |     | REQA
    5130272 |    5132736 | Rdr |93  20                                 |     | ANTICOLL
    5145680 |    5156144 | Rdr |93  70  16  27  91  fa  5a  34  21     |  ok | SELECT_UID

Just in case, I will attach all 10 traces that I managed to record, but (for me) in most cases they were not very useful. The piece above is taken from sniff-02-27_strange.trace.

My assumption is that the reader somehow makes this check for magic tag and in case of success (unfortunately the responses from the tag weren’t recorded in the trace) it stops working with the tag.
But this is just an assumption and I want to ask you - is it possible? If there is a way around it - how?

traces.zip (5.7 KB)

1 Like
2

Great write up and work sniffing out the data.
The reader is sending a wakeup command to detect a Gen1 magic tag (or any magic tag that responds to that command)
The way around this is to use a different generation magic card like a Gen2 (CUID I believe) which can be written with an android, or PM3 etc.

3 Likes
3

Oh, if the only option is to change the magic tag gen, then that’s … disappointing. I understand that I can’t change the firmware of my magic tag to not answer to this request, but I was hoping, idk, maybe some software solution that can lock uid\keys in the tag permanently

Anyway, thank you very much for your response! You helped me put this whole thing together

1 Like
4

Sorry for the bad news.
Good news is that Gen2 cards are freely available and cheap.
This site helps to breakdown Gen1,2,3 Mifare Magic cards. There are Gen4 cards as well, but this site doesn’t touch on them.

For more detailed notes on these and Gen4 check out:

3 Likes