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.
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.
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.
Thanks for the reply and glad to know its not something small Im doing wrong (although that would be an easy fix ).
@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.
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 veryvery last case option but its not out of the question.
Im still open to suggestions and trying anything, thanks in advance!
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.
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.
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? ). 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.
Check tag details, verify its a Gen1a
Read Sector 0 using the backdoor command cgetsc
Set only the UID to all 0 without wiping the card using backdoor command csetuid
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.
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.
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.
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.
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.
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!