xM1 Proxmark ATQA:00 Anticollision Error

I saw this from your post…

Please note I am using a PM3 Easy and have disconnected my LF antenna, makes reading the implant easier as I can make it flat.

What I think this means is that you are positioning your hand over the pm3 easy, so removing the LF antenna makes that easier… however… the HF coil is actually on the bottom PCB. This separation is good for cards but terrible for implants. Flip the pm3 over and put your hand on the bottom pcb. Take a peek in there and you’ll see the HF coil is printed on tbe bottom PCB not the top one with the silkscreening.

1 Like

Photos speak louder than words so attach some pix of you with your hand on the pm3 for confirmation. Frankly if you were positioning your hand over it on the top PCB, I’m shocked you got anything to work at all.

1 Like

some pix

Here are some pix and explanation of whats happening.

Here is the PM3 Easy without the LF antenna, middle layer and all the stand off removed.

To make it easier to show and also helps me with alignment, I put some sharpie around where my xM1 sits.

This is a good image that shows the PM3 resting atop the implant making sure the antenna is perpendicular to the implant. I usually extend my small finger/pinky a little to help with stability.

Not the best image but it can be see that the PM3 is just resting on the hand at a little angle paying particular attention to the antenna:implant placement.

…if you were positioning your hand over it on the top PCB…

I somewhat started like that. I done it with the PM3 stripped back to a single board and would rest my hand as best I could perpendicular to the antenna but this was never consistent.

1 Like

Hmm yeah that looks good to me… dang

1 Like

Thanks for the reply and glad to know its not something small Im doing wrong (although that would be an easy fix :laughing:).

@amal I remember reading somewhere (will update if I find the source) that the xM1 chips are acquired from a grey market vendor so there is no guarantee its a ‘genuine’ Gen1a. Is there any chance this is a Gen2 thats slipped through?
I understand to check this would be to issue a backdoor command and if it responds its a Gen1a (correct me if wrong). When I issues backdoor commands now the command ‘completes’ but the changes dont stick on the tag.

See below for example:
proxmark3> hf mf  cetuid 03040d1c 0004 08
uid:03 04 0d 1c
--atqa:00 04 sak:08
Chinese magic backdoor commands (GEN1a) detected
old block 0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
new block 0:  03 04 0d 1c 16 08 04 00 00 00 00 00 00 00 00 00
old UID:00 00 00 00
new UID: 03 04 0d 1c

proxmark3> hf mf cgetsc 0
--sector number:0
Chinese magic backdoor commands (GEN1a) detected
block 0 data:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
block 1 data:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
block 2 data:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
block 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: read AB; write AB; increment AB; decrement transfer restore AB
Access block 1: read AB; write AB; increment AB; decrement transfer restore AB
Access block 2: read AB; write AB; increment AB; decrement transfer restore AB
Access block 3: read A by A; read ACCESS by A; read B by A; write B by A
UserData: 00

In case there is no hope in reviving the tag, it may come to the point in removing (& replacing?) it. I got it installed on 22/07/20 so still fairly fresh. I know encapsulation makes the implants harder to remove and since mine is still new, how long roughly should I expect to wait before encapsulation has properly set in around the implant?
I ask as if I can get the implant remove before then the process should be easier but also dont want to give up on trying to revive the implant until all options are exhausted. Im treating removal as a very very last case option but its not out of the question.

Im still open to suggestions and trying anything, thanks in advance!

This one?

1 Like

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