Can't read Tag recognized as "Mifare Ultralight" and "Not Ultralight"

M@ttia · 2016-11-14 19:12:00

Hallo,
this is my first post in this forum and I've been searching for the last hour in order to see is this was answered elsewere, so I hope not to duplicate any request (in case, excuse me...).

I received my new Proxmark3 Kit more than a week ago and I've been playing with it to learn how RFID works.
I succesfully managed to reade/clone some LF (HID) tags, as well as to learn about the Mifare versions/structure, but now I'm stuck with a tag that I can't read (or even recognize).

The Tag is a KABA keyfob (used to open a door), which I tried to recognize with the following command/output: (please feel free to correct me if I'm doing something wrong! )

proxmark3> hf search    (but also "hf 14a reader" gives the exact same output)

UID : af c0 0e 97
ATQA : 00 04
SAK : 00 [2]
Tag is not Ultralight | NTAG | MY-D  [ATQA: 00 04 SAK: 00]

TYPE : MIFARE Ultralight (MF0ICU1) <magic>
proprietary non iso14443-4 card found, RATS not supported
Answers to chinese magic backdoor commands: NO

Valid ISO14443A Tag Found - Quiting Search

As you can see, the tag is recognized as both (Mifare) Ultralight and not Ultralight...
The following command indeed confirms it:

proxmark3> hf mfu info
Tag is not Ultralight | NTAG | MY-D  [ATQA: 00 04 SAK: 00]

At this point I suspected it was some other Mifare type, so I run the following commands, which however didn't help me to make any progress:

proxmark3> hf mf chk *1 ? t
No key specified, trying default keys
chk default key[ 0] ffffffffffff
chk default key[ 1] 000000000000
chk default key[ 2] a0a1a2a3a4a5
chk default key[ 3] b0b1b2b3b4b5
chk default key[ 4] aabbccddeeff
chk default key[ 5] 4d3a99c351dd
chk default key[ 6] 1a982c7e459a
chk default key[ 7] d3f7d3f7d3f7
chk default key[ 8] 714c5c886e97
chk default key[ 9] 587ee5f9350f
chk default key[10] a0478cc39091
chk default key[11] 533cb6c723f6
chk default key[12] 8fd0a4f256e9
--sector: 0, block:  3, key type:A, key count:13
--sector: 1, block:  7, key type:A, key count:13
--sector: 2, block: 11, key type:A, key count:13
--sector: 3, block: 15, key type:A, key count:13
--sector: 4, block: 19, key type:A, key count:13
--sector: 5, block: 23, key type:A, key count:13
--sector: 6, block: 27, key type:A, key count:13
--sector: 7, block: 31, key type:A, key count:13
--sector: 8, block: 35, key type:A, key count:13
--sector: 9, block: 39, key type:A, key count:13
--sector:10, block: 43, key type:A, key count:13
--sector:11, block: 47, key type:A, key count:13
--sector:12, block: 51, key type:A, key count:13
--sector:13, block: 55, key type:A, key count:13
--sector:14, block: 59, key type:A, key count:13
--sector:15, block: 63, key type:A, key count:13
--sector: 0, block:  3, key type:B, key count:13
--sector: 1, block:  7, key type:B, key count:13
--sector: 2, block: 11, key type:B, key count:13
--sector: 3, block: 15, key type:B, key count:13
--sector: 4, block: 19, key type:B, key count:13
--sector: 5, block: 23, key type:B, key count:13
--sector: 6, block: 27, key type:B, key count:13
--sector: 7, block: 31, key type:B, key count:13
--sector: 8, block: 35, key type:B, key count:13
--sector: 9, block: 39, key type:B, key count:13
--sector:10, block: 43, key type:B, key count:13
--sector:11, block: 47, key type:B, key count:13
--sector:12, block: 51, key type:B, key count:13
--sector:13, block: 55, key type:B, key count:13
--sector:14, block: 59, key type:B, key count:13
--sector:15, block: 63, key type:B, key count:13
Found keys have been transferred to the emulator memory

proxmark3> hf mf mifare
-------------------------------------------------------------------------
Executing command. Expected execution time: 25sec on average  :-)
Press button on the proxmark3 device to abort both proxmark3 and client.
-------------------------------------------------------------------------
.... (the progression point go on for sometimes a couple of seconds and sometimes even 15-20 mins, but after that:)
#db# Mifare: Can't select card
#db# Mifare: Can't select card
#db# Mifare: Can't select card
#db# Mifare: Can't select card
#db# Mifare: Can't select card
(so on, forever...)
[Sometimes the USB connection fails and then it reconnects...]

Do you have any idea about how I could go on with this tag?

If it can be useful, I can run the "sniff" command to sniff the card‐reader communication (I have access to both the card and the reader/lock), but I'm not sure how I could use the collected data to get some information about the keys...

Thank you very much for any help/hint (also about anything I missed or I'm doing wrong, since I'm still learning... )!
Mattia

P.S.
If of any use, here is my proxmark3 info:

proxmark3> hw version
[[[ Cached information ]]]

Prox/RFID mark3 RFID instrument
bootrom: master/v2.3 2016-09-19 20:28:38
os: master/v2.3 2016-09-19 20:28:38
LF FPGA image built for 2s30vq100 on 2015/03/06 at 07:38:04
HF FPGA image built for 2s30vq100 on 2015/11/ 2 at  9: 8: 8

uC: AT91SAM7S512 Rev B
Embedded Processor: ARM7TDMI
Nonvolatile Program Memory Size: 512K bytes. Used: 183707 bytes (35%). Free: 340581 bytes (65%).
Second Nonvolatile Program Memory Size: None
Internal SRAM Size: 64K bytes
Architecture Identifier: AT91SAM7Sxx Series
Nonvolatile Program Memory Type: Embedded Flash Memory

marshmellow · 2016-11-14 19:27:26

can you do a `hf mfu dump` ?

looks like you may have an unknown mifare UL type or a locked mifare UL card.
(or you have found a bug...?)

M@ttia · 2016-11-14 19:30:55

marshmellow wrote:

can you do a `hf mfu dump` ?

All mfu commands give the same result, including this:

proxmark3> hf mfu dump
Tag is not Ultralight | NTAG | MY-D  [ATQA: 00 04 SAK: 00]

By the way, I forgot to mention that I had the opportunity to scan another key (same brand/shape, to which however I don't have access at the moment, since it doesn't belong to me) that opens the same door lock, with this result:

If maybe a lock can only support one type of key (?), could this information throw some light on the mystery?

Thanks!

Last edited by M@ttia (2016-11-14 19:36:36)

iceman · 2016-11-14 19:44:00

Very different tags, one seems to be a UL type and the other is a Desfire.

Do a "hf mfu info"?

M@ttia · 2016-11-14 19:45:28

iceman wrote:

Do a "hf mfu info"?

If you mean on my key, I posted it in my original message (to confirm it wasn't an UL).

marshmellow · 2016-11-14 20:46:39

I'll have to look at the code to see why it would detect a MF UL and then say it is not one... i'm surprised the hf mfu dump command has a dump out if it doesn't think it is a UL, it should try anyway...

iceman · 2016-11-14 21:27:40

Sry but I can't see anywhere that you did a "hf mfu info"

marshmellow · 2016-11-14 21:29:22

M@ttia wrote:

As you can see, the tag is recognized as both (Mifare) Ultralight and not Ultralight...
The following command indeed confirms it:
proxmark3> hf mfu info
Tag is not Ultralight | NTAG | MY-D  [ATQA: 00 04 SAK: 00]

iceman · 2016-11-14 21:53:29

Ok,
the HF search command doesn't seem to continue after the failed UL ident.

Inside (cmdhf14areader / cmdhf14a.c ) method, its the SAK == 0x00 in your tag that makes it belive its a UL kind of tag.
It should have been SAK = 0x10, 0x11, 0x... etc etc to be identifed as Desfire / Mifare PLus.

Your friends tag gives SAK 0x20, which makes it a Desfire et al identification.

Your problem could be a bad read, try distance/placement from antenna (1.5cm)

M@ttia · 2016-11-14 22:19:50

I just tried from various distances/angles but the tag is either unrecognized or gives the exact same info as above (including the SAK 00 [2]).
I also tried to switch the onboard switch (the Antenna is the original HF one you see in the picture above) to match either the 100pF or the 47pF capacitor, but the results are the same.

Tomorrow I'll try to sniff the communications while opening the door to see if it can somehow help...

Thank you very much for your interest by the way!

M@ttia · 2016-11-15 23:48:32

Here I am with some additional information/tries:

First of all I tried to sniff the communication with the tag opening the lock:

proxmark3> hf mf sniff
-------------------------------------------------------------------------
Executing command.
Press the key on the proxmark3 device to abort both proxmark3 and client.
Press the key on pc keyboard to abort the client.
-------------------------------------------------------------------------
.......>
received trace len: 37 packages: 1
tag select uid:af c0 0e 97  atqa:0x0004 sak:0x00
RDR(0):50 00 57 cd
.....>
received trace len: 111 packages: 1
tag select uid:af c0 0e 97  atqa:0x0004 sak:0x00
RDR(1):50 00 57 cd
tag select uid:af c0 0e 97  atqa:0x0004 sak:0x00
RDR(2):50 00 57 cd
tag select uid:af c0 0e 97  atqa:0x0004 sak:0x00
RDR(3):50 00 57 cd
.#db# cancelled by button
#db# COMMAND FINISHED  .
#db# maxDataLen=1proxmark3> , Uart.state=0, Uart.len=0


----------


Trying to open the lock with a wrong (random) RFID tag, this is the output of the sniff command:

RDR(0):50 00 57 cd
tag select uid:45 78 1f a6  atqa:0x0004 sak:0x08

Next I tried to simulate the tag by its UID using all the possible methods:

proxmark3> hf mf sim u afc00e97 i
 uid:af c0 0e 97 , numreads:0, flags:3 (0x03)
Press pm3-button to abort simulation
#db# 4B UID: afc00e97
#db# Emulator stopped. Tracing: 1  trace length: 0


----------


proxmark3> hf mf sim u afc00e97 i x
 uid:af c0 0e 97 , numreads:0, flags:11 (0x0b)
Press pm3-button to abort simulation
#db# 4B UID: afc00e97
#db# Failed to obtain two AR/NR pairs!
#db# Emulator stopped. Tracing: 1  trace length: 0


----------


proxmark3> hf 14a sim 1 afc00e97
Emulating ISO/IEC 14443 type A tag with 4 byte UID (afc00e97)
#db# Button press
#db# 0 0 0


----------


proxmark3> hf 14a sim 2 afc00e97
Emulating ISO/IEC 14443 type A tag with 4 byte UID (afc00e97)
#db# Received unknown command (len=6):
#db# 20 03 00 05 9a 61
(...)
#db# Received unknown command (len=6):
#db# 20 03 00 05 9a 61
#db# Button press
#db# 0 0 2a


----------


proxmark3> hf 14a sim 3 afc00e97
Emulating ISO/IEC 14443 type A tag with 4 byte UID (afc00e97)
#db# Received unknown command (len=5):
#db# d0 11 00 52 a6
(...)


----------


*****proxmark3> hf 14a sim 4 afc00e97
Emulating ISO/IEC 14443 type A tag with 4 byte UID (afc00e97)
#db# Received unknown command (len=5):
#db# d0 11 00 52 a6
(...)
#db# Received unknown command (len=5):
#db# d0 11 00 52 a6
#db# Button press
#db# 0 0 79


----------


proxmark3> hf 14a sim 5 afc00e97
Emulating ISO/IEC 14443 type A tag with 4 byte UID (afc00e97)
#db# Received unknown command (len=6):
#db# 20 03 00 05 9a 61
(...)
#db# Received unknown command (len=6):
#db# 20 03 00 05 9a 61
#db# Received unknown command (len=2):
#db# 7f 00
#db# Button press
#db# 0 0 83

It doesn't seem to throw any light on the mystery, but maybe I'm missing some relevant information about these outputs?

Thanks!

P.S.

The lock used is exactly this one. From the datasheet I read "Supported RFID standards: LEGIC (advant & prime) and MIFARE (DESFire & Classic)".
I've been allowed to scan a third key (owned by the janitor), and the proxmark doesn't detect it at all (both with lf and hf)!!!

Last edited by M@ttia (2016-11-15 23:57:51)

dabox · 2018-12-19 16:57:44

Hi i'm replying to this topic because i haven't found an answer for the same problem and same solution applied as explained in this topic, anyone have found a way to recognised this tag ?
thanks in advance
I've a proxmark3 up to date (3.0.1)

Mackwa · 2018-12-25 17:19:20

dabox wrote:

Hi i'm replying to this topic because i haven't found an answer for the same problem and same solution applied as explained in this topic, anyone have found a way to recognised this tag ?
thanks in advance
I've a proxmark3 up to date (3.0.1)

the proxmark firmware has got lot's of improvements over the last two years.
It would be interetsing, what "hf search" and "hf mfu info" would tell us nowadays ...

Can you please give some output of your "unidentified card/token"?

Proxmark3 community

Announcement

#1 2016-11-14 19:12:00

Can't read Tag recognized as "Mifare Ultralight" and "Not Ultralight"

#2 2016-11-14 19:27:26

Re: Can't read Tag recognized as "Mifare Ultralight" and "Not Ultralight"

#3 2016-11-14 19:30:55

Re: Can't read Tag recognized as "Mifare Ultralight" and "Not Ultralight"

#4 2016-11-14 19:44:00

Re: Can't read Tag recognized as "Mifare Ultralight" and "Not Ultralight"

#5 2016-11-14 19:45:28

Re: Can't read Tag recognized as "Mifare Ultralight" and "Not Ultralight"

#6 2016-11-14 20:46:39

Re: Can't read Tag recognized as "Mifare Ultralight" and "Not Ultralight"

#7 2016-11-14 21:27:40

Re: Can't read Tag recognized as "Mifare Ultralight" and "Not Ultralight"

#8 2016-11-14 21:29:22

Re: Can't read Tag recognized as "Mifare Ultralight" and "Not Ultralight"

#9 2016-11-14 21:53:29

Re: Can't read Tag recognized as "Mifare Ultralight" and "Not Ultralight"

#10 2016-11-14 22:19:50

Re: Can't read Tag recognized as "Mifare Ultralight" and "Not Ultralight"

#11 2016-11-15 23:48:32

Re: Can't read Tag recognized as "Mifare Ultralight" and "Not Ultralight"

#12 2018-12-19 16:57:44

Re: Can't read Tag recognized as "Mifare Ultralight" and "Not Ultralight"

#13 2018-12-25 17:19:20

Re: Can't read Tag recognized as "Mifare Ultralight" and "Not Ultralight"

Board footer