xM1 UID and command issues

@amal told me to bring it here so ill lay it out in an understandable format;

i have an xM1 in my R0 that for a long while seems to not like receiving commands, in the past few days iceman helped me sort out a solution but even then it takes multiple attempts at putting commands into the chip for them to stick it isn’t coupling or getting the reader close enough as the xm1 is distinctly visible on my hand and can get the reader close as hell.

multiple custom cwipes and csetuids remagics and cloads on both a pm3 easy on the old iceman firmware, a pm3 easy on the newest firmware and an rdv4 on a recent firmware all results came out the same the UID and info on the chip would be jumbled as if randomly assigned a value.

after much persistence iceman was able to get the desired uid to stick but after further attempts, the method isn’t replicable as I tried it this morning upon receiving a new college ID card and it took me a good 20 minutes and random UIDs and card info was written it took mass spamming commands (all of which gave confirmations that they worked) to get it correct.

i do plan on taking this one out as its not really functional for my needs but if anyone has any clue what to do I’m more than interested

1 Like

I do recall seeing something in the Discord that’s similar (if not the same). If Amal and Iceman have gave some advice and the issue persists, I’m not sure what else can be attempted.

Using some basic logic, if known good devices are using known good firmware and issuing known good commands to an already problematic chip, to me that sounds like a problem with the chip.

it’s me andy from the forums lol :stuck_out_tongue: yeh i think the chip is buggered :frowning:

update: got some g1a test cards and they do all the magic commands fine so its definitely something wrong with the xm1 @amal

So far we’ve determined that bad coupling can put the xM1 into a crap state, but the new wipe command should be able to recover it… but only if the coupling issue that caused the problem in the first place is not still a problem. Cards are not tiny x-series implants inside of people, so you need to be absolutely sure you are able to solve the coupling problem first, then attempt recovery.

Can you post photos of exactly how you are putting the proxmark3 HF antenna up to your xM1? By that I mean, mark on top of your skin with a sharpie exactly where the xM1 is and then exactly how you are placing the proxmark3 up to it.

one photo is just to show the approx place my xm1 is and the other is showing how I read/write it with my 3easy. as of late all I can get it to do is read commands all write commands say they are done successfully but when rescanned arent applied at all @amal

Thanks for the photos! I can see that it appears you are placing the proxmark3 at the crux of the antenna trace at a 45 degree angle. Reads require much less power than writes so it is possible that you are able to get good reads but not enough power to properly write. Also the placement of the metal screw right at that corner could be really messing with the field at that exact spot.

I would do this to maximize your write power;

  • remove the LF junk from the board with a T6 screwdriver

  • exposing the HF trace antenna

  • place the HF antenna down so that is perfectly perpendicular over your xM1, but avoid that crazy crossover spot where the traces dive under vias in the PCB

FYI, write commands have no validation built in so they will always “succeed”… just like writes to a hard drive in your computer, it’s just taking it on faith that the bits are actually changed.

1 Like

ill give that a go now but the xfd only picked up strong in that corner also tried it on an rdv4 and got 0 write ability :confused:

1 Like

are you using the RRG/iceman firmware on your pm3 ez?

yup yup newest one as of like yesterday or whenever the announcement was made that iceman had had a look at xm1s

ok cool. to help with positioning use the HF TUNE command…

You will see a rapidly changing voltage. A well coupled tag pulls down the voltage because it is drawing power. Move your antenna around until you get the maximum voltage drop, and that’s your sweet spot.

ill give that a go too find the perfect spot for it, got a t6 coming tomorrow to unscrew this bad boi and then ill see whatsup thanks for the help so far amal :}

1 Like

Is that a thing? I thought M1ks had anti-tearing.

apparently my 3d printer came with a t6 so i just took the antennae off, tuned found the perfect spot (literally right near where i had it before) and still no luck on the write commands :confused: was able to get the tune down to ~13000 so i guess that must be the right spot



hmm… what would give you that impression?

Hmm, yes true. Not sure why I had that in mind.

But there’s one key difference between a M1k and a T5577: if data gets miswritten on a M1k, you don’t risk losing all access to it. Nothing you could possibly do to it with an NFC reader will change its fundamental firmware, frequency or protocol. So whatever happens, a magic Chinese chip should always be able answer the magic Chinese command, and you should always be able to wipe it, read it or write it.

I did lost (regular) access to my glass M1k once when I was originally programming it as a key to my front door. Got me sweating for a minute. But it answered cwipe without any problem, and then a bunch of writes later, I was back in business.

That’s why I was a bit surprised by your stating it was possible to weird out the chip with bad coupling.

Yes, it should be possible… but this is wild west China firmware we’re talking about here… even Iceman says he’s not found a “perfect” magic chip yet. They all have oddities, and because there is no standard at all for these, the names we give them like gen1 and gen2 are just prayers in the wind… a search for meaning in the chaos.

It’s confirmed even with certain magic cards that bad couplings and bad writes with bit errors can put various types of magic chips into the shithouse, specifically when writing to block 0… but so far it seems it’s possible to recover with the updated commands that Iceman put into the latest rev… but again… tears and bit errors are random, so maybe some of the bit errors we created during testing meant the chip was recoverable while bit errors others may have accidentally introduced might not be… no manuals, no tech reps, no official products… it’s chaos my friend.

Good to know, particularly since my stupid door lock writes to my chip every time I open the door. I’ve never liked this, initially because I don’t like something that writes to the same flash cells over and over without wear leveling. But now I like it even less…

I’m pretty confident the only bits that matter with regard to “misconfiguring” the chip are block 0 and sak and atqa settings. Writing to normal memory blocks shouldn’t be an issue… you just end up with wonky data… unless of course you mess up the sector trailer… that should lock the sector permanently, but the sector can be overwritten with magic commands…