im trying to program my XM1, it is not being recognized by the reader on the door. I have followed the MF1k tutorial on the Proxmark DT store page… what am i doing wrong? The fob Im trying to clone is MF1k as well.
Im getting Auth error on HF SEARCH
Its not writing the tag signature to the clone
so im getting the auth error
So you are getting Auth error on both Fob and xM1?
Could you possibly have firmware mismatch?
Do you have any other HF cards you can try?
What other fault finding have you tried?
just the cloned xm1
went through the autopwn on the fob then loaded the .eml to the xm1
the reader on the door refuses to read the chip.
when I HF Search both, the only thing that is missing from the xm1 is the AUTH.
what do you mean as far as the mismatch?
+] UID: BE F2 56 C2
[+] ATQA: 00 04
[+] SAK: 88 [2]
[+] Possible types:
[+] MIFARE Classic 1K
[=] proprietary non iso14443-4 card found, RATS not supported
[+] Magic capabilities : Gen 1a
[+] Prng detection: weak
[#] Auth error
[?] Hint: try hf mf commands
In this context I think auth error means the keys have been set and the search function can’t determine anything else about the content.
I’m currently away from the office today as it is my birthday, I don’t have access to a proxmark at the moment but I’d explore trying to wipe the xM1 back to a default state and then try again
already done multiple times
The source chip data you posted but then removed seemed to be a hardened chip with ev1 signature. There might be a problem cloning this type of chip, ice never had one to try with before.
When you wipe it does the sak go back to 08?
we’ve fixed the SAK but are still having other issues, currently sniffing / working out reader model
This community is really the jewel of our little corner of biohacking.
This is a dormakaba system.
Based on now removed information the tag type of your source transponder is a MFC1C14_x which is a mifare classic ev1 chip with improved / hardened random number generator. It seems though that your proxmark3 was still able to determine access bits and make a dump of the protected memory in secured sectors. What’s not matching up here is the SAK, but there may also be other checks the readers are doing.
With the advent of magic chips out of china, it’s now possible and has been seen in the wild that readers will issue magic chip backdoor commands to the chip to see if it responds… and if it does then it will refuse to work. I’m unsure if your system is doing this, but it is a possibility.
One approach might be to obtain a magic gen1a and a magic Gen2 in card or key fob format and attempt to get the system to recognize those. The gen2 magic chip type does not use backdoor commands, it simply allows sector 0 to be written. The down side is that because there is no backdoor to get around all security settings, accidentally setting access bits incorrectly can result in a sector being locked out forever, just like any normal mifare chip. Some people have talked about ways to recover these types of sectors from a magic Gen2 chip but I don’t recall any actual proof.
There are proper instructions laid out to attempt to fix a soft brick of sector 0 in the proxmark 3 magic card notes: proxmark3/doc/magic_cards_notes.md at master · RfidResearchGroup/proxmark3 · GitHub
However, that definitely doesn’t help when it’s the access bits. Saying that, that’s literally no different at all to a genuine mifare chip… it’s less of a detractor / ‘easy’ way to brick your implant and more of a reason that the gen1a might be a better option, especially if the system that you are cloning from has weird access conditions. IIRC Mifare Classic tool even has an access condition encoder and decoder, and I think the dev was looking into adding warning before attempting to clone weird / permanent access conditions, though I don’t know if that has been implemented yet.
While there are ways to set access bits in such a way that the keys are blocked from reading or changing each other, that is not my primary concern. The Mifare spec dictates that access bits be written in a specific way with both normal and matching inverted bits… and if you write an invalid bit pattern or there is a bit flip error during transmission, the entire sector will be bricked… no data will be readable and no keys either. This is my primary concern when playing around with writing data to sectors, especially since we are dealing with magic chips with sometimes wonky signal detection, small antennas, and one-handed proxmark3 operation.
NFC-Access-Control-for-Mifare-S50.pdf (631.1 KB)
That said, it would still be a concern if you were dealing with a mifare card that had secured one or more sectors using access bit settings which permanently set the entire block to read-only with no key access (meaning you can’t change the keys or access bits).
Interesting, is there any data as to how often this happens with flexM1 gen 2 devices vs with flexM1 gen 1a devices that can be recovered?
not really… i don’t think we’ve sold more than a handful of flexM1 gen2 (pun!) … the xM1 is more popular by far.
so do the block 0 keys have to match the rest?
and can I rewrite them in the JSON if i need to?
Each sector can be secured individually so the keys can be whatever the application wants them to be. Sector 0 on a mifare chip is a special sector with the ID and the MAD (mifare application directory) and is normally read only.
You can definitely change the content of the JSON file, however when changing access bits there is a calculation that needs to be done properly to set the bits correctly or the sector will brick. To read more about this, check this post;
In short the important thing I think is that the xM1 sector data matches the source chip. If the sak value doesn’t match after cloning then I believe there is a way to change it after the fact. Can you write the dump file to the xM1 and then do an autopwn on it to save it’s own dump file (be sure to back up your original source dump file first). Then you can compare to see that the sector data and keys are identical.