xM1 Proxmark ATQA:00 Anticollision Error

Not the one I originally recall reading but still a good source.
Also found this but still not the one I originally recall reading.

More specifically this from that post:

A Mifare “magic” chip is a special grey-market chip made in China that can emulate the memory structure and functionality of real Mifare chips, but also allow sector 0 to be modified.

The premise that there even are any “genuine” gen1a chips is at issue… there aren’t. Various chip factories make them, but the identity of these factories are shadowy because it’s not perfectly legal what they are doing… especially when products ship outside of China… so it’s very tough to confirm sources and secure inventory.

1 Like

Possibly… but we test every xM1 first before putting them into glass tubes. You can try to treat it like a gen2 and see if you can change sector 0.

1 Like

The premise that there even are any “genuine” gen1a chips is at issue… there aren’t.

When I said genuine I should have said *confirmed; comparing what the vendor is advertising and what a consumer is receiving. I understand what you mean though and appreciate the explanation.

identity of these factories are shadowy because it’s not perfectly legal

Totally understand. My issue from this would be around reliability. Can these vendors continually make these grey market components while staying under the radar enough not to get caught and shutdown? And, can they actually make the components and not just trying to make some money selling something similar (think white label from another factory)?

Possibly… but we test every xM1 first before putting them into glass tubes

I was already aware of this and was hesitant to make my original comment as I didnt want to insult or be rude on something that I dont have all the facts on. I appreciate the information and it makes logical sense
to it.

Already tried with no avail. Since I have not documented this previously please see below for specifics:

Output of some Gen2 commands

I started with trying some of the default keys since rdsc requires a key to read the sector. The last key (the 1f1f…) was the one I found on the xM1 initially when I dumped its contents to a file. Testing the keys with both A & B to rule out using the wrong key for read. Originally I was trying to copy a card to my xM1 and tried the keys on the source card just in case but still no avail (output redacted).
Lastly, I tested with the backdoor command to get sector 0 which it replied but not with expected results.

[usb] pm3 --> hf mf rdsc 0 A ffffffffffff
--sector no:0 key type:A key:FF FF FF FF FF FF

#db# Auth error
isOk:00
[usb] pm3 --> hf mf rdsc 0 B ffffffffffff
--sector no:0 key type:B key:FF FF FF FF FF FF

#db# Auth error
isOk:00
[usb] pm3 --> hf mf rdsc 0 A 000000000000
--sector no:0 key type:A key:00 00 00 00 00 00

#db# Auth error
isOk:00
[usb] pm3 --> hf mf rdsc 0 B 000000000000
--sector no:0 key type:B key:00 00 00 00 00 00

#db# Auth error
isOk:00
[usb] pm3 --> hf mf rdsc 0 A 1f1f1f1f1f1f
--sector no:0 key type:A key:1F 1F 1F 1F 1F 1F

#db# Auth error
isOk:00
[usb] pm3 --> hf mf rdsc 0 B 1f1f1f1f1f1f
--sector no:0 key type:B key:1F 1F 1F 1F 1F 1F

#db# Auth error
isOk:00
[usb] pm3 --> hf mf cgetsc 0

  # | data    |  Sector | 00/ 0x00
----+------------------------------------------------
  0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  1 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  2 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  3 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

As always happy for some suggestions and many thanks to those who have replied already!!

1 Like

Yeah totally… we still run into this a lot… we test everything we get from China… everything… twice usually. Often times it’s crap or not to spec or not what you ordered. In fact, the first time I ever saw a T5577 chip was when I wanted a batch of EM4102 chips and received T5577s programmed as EMs… blew me away they were sold as legit EM4102 chips… now nothing surprises me coming out of China.

absolutely no insult perceived… just stating the facts to help resolve the case.

Man this sucks. Sector 0 being set up with all 0s… I’m fairly confident that this is causing violations of the ISO14443 standard and that’s the problem because that’s how PICCs talk to the reader and vice versa.

The real question is, can the proxmark3 even perform a select on a card with UID set to all 0s … then the next question is will the card allow itself to be selected. If the latter is possible, then I feel like this is something that could be fixed with the proper code for the proxmark3 … but whether or not that ever comes is questionable.

Man this sucks. Sector 0 being set up with all 0s… I’m fairly confident that this is causing violations of the ISO14443 standard and that’s the problem because that’s how PICCs talk to the reader and vice versa.

I would agree but I’m not well versed on the standard. Plus, since these are ‘magic’ can we accurately assume they even care to conform to the standard? After all, they shouldnt really exist and are made in a round about way.

The real question is, can the proxmark3 even perform a select on a card with UID set to all 0s … then the next question is will the card allow itself to be selected

I have time and, now you mention it, want to know the answer to those questions. Short answer, yes

Details of testing

I have some MiFare Classic 1K Gen1a tags laying around (who doesn’t? :laughing:). Grabbed the tag, gave it a read to make sure it is the type I thought it was and ensured Im not actually using it for anything before writing trying anything.

  1. Check tag details, verify its a Gen1a
  2. Read Sector 0 using the backdoor command cgetsc
  3. Set only the UID to all 0 without wiping the card using backdoor command csetuid
  4. Check the card details again
  5. Check sector 0 again

Commands output:

[usb] pm3 --> hf 14a info

[+]  UID: 11 11 11 11
[+] ATQA: 00 02
[+]  SAK: 88 [2]
[+] POSSIBLE TYPE:    MIFARE Classic 1K / Classic 1K CL2
[+] POSSIBLE TYPE:    MIFARE Plus 2K / Plus EV1 2K
[+] POSSIBLE TYPE:    MIFARE Plus CL2 2K / Plus CL2 EV1 2K
[=] proprietary non iso14443-4 card found, RATS not supported
[+] Magic capabilities : Gen 1a
[+] Prng detection: weak
[usb] pm3 --> hf mf cgetsc 0

  # | data    |  Sector | 00/ 0x00
----+------------------------------------------------
  0 | 11 11 11 11 00 98 02 00 00 00 00 00 00 00 10 01
  1 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  2 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  3 | FF FF FF FF FF FF FF 07 80 00 FF FF FF FF FF FF
[usb] pm3 --> hf mf csetuid 00000000
--wipe card:NO  uid:00 00 00 00
[+] old block 0:  11 11 11 11 00 98 02 00 00 00 00 00 00 00 10 01
[+] new block 0:  00 00 00 00 00 98 02 00 00 00 00 00 00 00 10 01
[+] Old UID : 00 00 00 00
[+] New UID : 00 00 00 00
[usb] pm3 --> hf 14a info

[+]  UID: 00 00 00 00
[+] ATQA: 00 02
[+]  SAK: 88 [2]
[+] POSSIBLE TYPE:    MIFARE Classic 1K / Classic 1K CL2
[+] POSSIBLE TYPE:    MIFARE Plus 2K / Plus EV1 2K
[+] POSSIBLE TYPE:    MIFARE Plus CL2 2K / Plus CL2 EV1 2K
[=] proprietary non iso14443-4 card found, RATS not supported
[+] Magic capabilities : Gen 1a
[+] Prng detection: weak
[usb] pm3 --> hf mf cgetsc 0

  # | data    |  Sector | 00/ 0x00
----+------------------------------------------------
  0 | 00 00 00 00 00 98 02 00 00 00 00 00 00 00 10 01
  1 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  2 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  3 | FF FF FF FF FF FF FF 07 80 00 FF FF FF FF FF FF

Going a little further and trying to replicate the issue with my xM1, I done the following:

  1. Checked the tag details, make sure everything is in order
  2. Set block 0 to all 0 using backdoor command
  3. Got block 3 to check what its values were
  4. Set block 3 to all 0 using backdoor command
  5. Tried to check the tag again (like in step 1)
  6. Got sector 0 using backdoor command to check its values
  7. Set UID, ATQA and SAK without wiping tag with backdoor command
  8. Check tag details again
  9. Got sector 0 using backdoor command to check values

Command output:

[usb] pm3 --> hf 14a info

[+]  UID: 11 11 11 11
[+] ATQA: 00 02
[+]  SAK: 88 [2]
[+] POSSIBLE TYPE:    MIFARE Classic 1K / Classic 1K CL2
[+] POSSIBLE TYPE:    MIFARE Plus 2K / Plus EV1 2K
[+] POSSIBLE TYPE:    MIFARE Plus CL2 2K / Plus CL2 EV1 2K
[=] proprietary non iso14443-4 card found, RATS not supported
[+] Magic capabilities : Gen 1a
[+] Prng detection: weak
[usb] pm3 --> hf mf csetblk 0 00000000000000000000000000000000
--block number: 0 data:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[usb] pm3 --> hf mf cgetblk 3
--block number: 3
data: FF FF FF FF FF FF FF 07 80 00 FF FF FF FF FF FF
Trailer decoded:
Key A: FFFFFFFFFFFF
Key B: FFFFFFFFFFFF
Access block 0: rdAB wrAB incAB dectrAB
Access block 1: rdAB wrAB incAB dectrAB
Access block 2: rdAB wrAB incAB dectrAB
Access block 3: wrAbyA rdCbyA wrCbyA rdBbyA wrBbyA
UserData: 00
[usb] pm3 --> hf mf csetblk 3 00000000000000000000000000000000
--block number: 3 data:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[usb] pm3 --> hf 14a info

[=] Card doesn't support standard iso14443-3 anticollision
[+] ATQA: 00 00
[usb] pm3 --> hf mf cgetsc 0

  # | data    |  Sector | 00/ 0x00
----+------------------------------------------------
  0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  1 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  2 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  3 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[usb] pm3 --> hf mf csetuid 01020304 0004 08
--wipe card:NO  uid:01 02 03 04
[+] old block 0:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[+] new block 0:  01 02 03 04 04 08 04 00 00 00 00 00 00 00 00 00
[+] Old UID : 00 00 00 00
[+] New UID : 01 02 03 04
[usb] pm3 --> hf 14a info

[+]  UID: 01 02 03 04
[+] ATQA: 00 04
[+]  SAK: 08 [2]
[+] POSSIBLE TYPE:    MIFARE Classic 1K / Classic 1K CL2
[+] POSSIBLE TYPE:    MIFARE Plus 2K / Plus EV1 2K
[+] POSSIBLE TYPE:    MIFARE Plus CL2 2K / Plus CL2 EV1 2K
[=] proprietary non iso14443-4 card found, RATS not supported
[+] Magic capabilities : Gen 1a
[+] Prng detection: weak
^[[A[usb] pm3 -->mf cgetsc 0

  # | data    |  Sector | 00/ 0x00
----+------------------------------------------------
  0 | 01 02 03 04 04 08 04 00 00 00 00 00 00 00 00 00
  1 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  2 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  3 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Many thanks @amal for continuing to help me on this, always happy for new ideas!

all good points… probably not… but that’s kind of the point… it’s doing what it’s told to do, even if it goes against the standard… somehow sector 0 was wiped to 000s and now the question is … how does the tag respond when a reader tries to select it…

So are you unable to set block 3 to all 0s then… or am I reading this wrong?

I think on your xM1 I would attempt to set block 3 first to a default set of MAD keys… see if that sticks… like try to read block 3 again … all without removing the xM1 from the field… I’m curious if removing from the field has any effect after a write attempt… like does it revert back after you remove it from the field or does it even retain the values as written while in the field at all?

So are you unable to set block 3 to all 0s then… or am I reading this wrong?

I was able to set the spare Gen1a tag block 3 to all 0 and could get sector 0 to confirm this

I think on your xM1 I would attempt to set block 3 first to a default set of MAD keys… see if that sticks…

I haven’t tried this so will give it a shot (will update after work). What are the default MAD keys (all FF for A&B)?

I’m curious if removing from the field has any effect after a write attempt… like does it revert back after you remove it from the field or does it even retain the values as written while in the field at all?

During most of my testing, I will keep the xM1 on the PM3 (thus in field) and issue any commands. I usually que up the commands prior so that I can easily just use the up arrow to recall the command history; saves trying to type with one hand.
The result of doing this doesn’t seem to have a difference. While keeping the xM1 in field I’ll write a change (eg UID) then, a few seconds later without removing the xM1, I’ll issue a verify command (eg. hf 14a info) to see the result. So far, even with the xM1 always in the field, there have been no write commands that have stuck to the implant. Feels like trying to write to a tag that has been locked but isn’t giving you any auth errors when you try to write something.

Thanks again for the help!

FF works… ensure the access bits are correct though too. Check page 2 of the PDF I wrote for unformatted and NFC formatted sector 0 sector trailer values.

Sorry for the delay in reply.

Tried what you said and tried to set block 3 with A&B keys = FF and access bits FF078069. Sadly still to no avail. Looks like the PM3 tries to write to it and the tag pretends to accept the command despite not showing any changes.

Command Output

[usb] pm3 --> hf 14a rea
[=] Card doesn’t support standard iso14443-3 anticollision
[+] ATQA: 00 00
[usb] pm3 --> hf mf csetblk 3 ffffffffffffff078069ffffffffffff
–block number: 3 data:FF FF FF FF FF FF FF 07 80 69 FF FF FF FF FF FF
[usb] pm3 --> hf mf cgetblk 3
–block number: 3
data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Trailer decoded:
Key A: 000000000000
Key B: 000000000000
Access block 0: rdAB wrAB incAB dectrAB
Access block 1: rdAB wrAB incAB dectrAB
Access block 2: rdAB wrAB incAB dectrAB
Access block 3: rdAbyA rdCbyA rdBbyA wrBbyA
UserData: 00
[usb] pm3 --> hf 14a rea
[=] Card doesn’t support standard iso14443-3 anticollision
[+] ATQA: 00 00

Talking off channel with Iceman… do you know when / how this happened? He suspects it might have been an encounter with a system that actively detects backdoor clones and purposely tries to fuck them up. If you can think of that being the case, maybe try taking one of your magic gen1a cards around to the same systems with a good clone on board and see if it also gets wiped.

Talking off channel with Iceman

I really appreciate reaching out to him and for you both trying to help!!

do you know when / how this happened?

When: same as the original post 22/07/20 (dd/mm/yy)
How: that part is more of a blur now. I believe I was trying to load a card that I already had cracked and dumped to a file.

He [Iceman] suspects it might have been an encounter with a system that actively detects backdoor clones and purposely tries to fuck them up

I strongly doubt that. The only device/reader my xM1 has been in contact with is my Proxmark3, not even my phone. I’ve not had the xM1 working enough to try it on any live system.
Given that it’s a PM3 easy, I thought it may be a bad clone that tries to ruin cards but I have successfully cloned hardened Mifare Classic 1K cards to various magic Gen1a tags (several vendors) several times.

magic gen1a cards around to the same systems with a good clone on board and see if it also gets wiped.

This isn’t the case. Before getting the implant, I had cloned a Mifare Classic to a Gen1a and verified it working on the live system in question. This is part of some academic research I’m doing for my degree. It was after this I done more research and found DT. I thought I had the process nailed and could make clones of one source card to many Gen1a tags. I still have some of the first Gen1a tags I cloned the source card to and they still work now.

1 Like

Ok hmm… well… I’m kinda running out of ideas…

I’m kinda running out of ideas

I thought I’d say that first :laughing:

My next option would be removal or another xM1/flexM1 and leave the existing bad implant in place. My worry about that would be running into this same issue again. I understand this is a very rare issue as no one else seems to have reported anything similar.
Other option could be to upgrade my proxmark to the RDV4 and see if its a reader/writer issue. Issue there is that if it doesn’t work I’m still in the same boat and that money could have been spent on a new, working, implant.

I do want to say thank you @amal. I really appreciate the support and willingness to help me with this!

2 Likes

Iceman suggests using the new command; Hf mf Cwipe cmd … so update your firmware to the latest rrg/iceman version and try that?

image

1 Like

I updated the proxmark3 client to the latest Iceman fork. In short, still no difference.
I couldnt find hf mf cwipe cmd and, from the screenshot read it as the hf mf cwipe command?

Command Output
[usb] pm3 --> hw ver

 [ Proxmark3 RFID instrument ]

 [ CLIENT ]
  client: RRG/Iceman/master/v4.9237-620-gf3d4553d 2020-07-30 20:03:02
  compiled with GCC 9.3.0 OS:Linux ARCH:x86_64

 [ PROXMARK3 ]

 [ ARM ]
  bootrom: RRG/Iceman/master/v4.9237-618-g84a49bf0 2020-07-23 22:32:11
       os: RRG/Iceman/master/v4.9237-618-g84a49bf0 2020-07-23 22:32:18
  compiled with GCC 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]

 [ FPGA ]
  LF image built for 2s30vq100 on 2020-02-22 at 12:51:14
  HF image built for 2s30vq100 on 2020-01-12 at 15:31:16

 [ Hardware ]
  --= uC: AT91SAM7S512 Rev B
  --= Embedded Processor: ARM7TDMI
  --= Nonvolatile Program Memory Size: 512K bytes, Used: 227408 bytes (43%) Free: 296880 bytes (57%)
  --= Second Nonvolatile Program Memory Size: None
  --= Internal SRAM Size: 64K bytes
  --= Architecture Identifier: AT91SAM7Sxx Series
  --= Nonvolatile Program Memory Type: Embedded Flash Memory

[usb] pm3 --> hf mf cwipe
 🕑 wipe block 63
[+] Card wiped successfully
[usb] pm3 --> hf 14a rea
[=] Card doesn't support standard iso14443-3 anticollision
[+] ATQA: 00 00

[usb] pm3 --> hf mf cwipe -u 01020304 -a 0004 -s 08
 🕙 wipe block 63
[+] Card wiped successfully
[usb] pm3 --> hf 14a rea
[=] Card doesn't support standard iso14443-3 anticollision
[+] ATQA: 00 00

yeah you’re right… I was skipping through my task list pretty fast this morning. sorry about that. man, if it comes down to it, we’ll ship you another xM1

1 Like

I was skipping through my task list pretty fast this morning

Don’t worry about it, Ive been there more often than not lately at work.

sorry about that

No need for the apology, you’ve been a great help!

man, if it comes down to it, we’ll ship you another xM1

I appreciate that you’re willing to do that! I already asked my installer if they would remove the bad xM1 and they didn’t feel comfortable doing it. I have now been looking at the flexM1 since I could get it put somewhere more flat on the same hand.
If it comes down to shipping another one (let me know what those conditions will be), could I get the flexM1 and pay the difference between them? If not, I’m more than happy enough to get another xM1!

Thanks again for the support and I greatly appreciate considering to replace the xM1!!

1 Like

We suggest the 4g needle approach for the xM1… you can basically insert a 4g needle around it to scoop it out… most piercers are ok with this since it does not require a scalpel or sutures.

yeah we can do that… hit the orange help floaty on the site and i’ll put you in touch with @mdanger to arrange it.

2 Likes

you can basically insert a 4g needle around it to scoop it out

I made my installer aware of this but they are still not comfortable with it. I, personally, dont mind as everyone has their limits and thanked them for letting me know instead of just doing it for some cash.

yeah we can do that… hit the orange help floaty on the site and i’ll put you in touch with @mdanger to arrange it.

Will get on that now! Thanks again @amal!

Any new ideas in the mean time for the tag, I’m all ears!

1 Like