I’m back! This time, as no doubt spoiled by the title, I’m looking for some help cloning an old hotel key, what I assume to be a MF Classic 1K to my xM1.
Am I correct in assuming these are compatible for cloning and am I on the right track?
Did the csetuid fail because I did not -w first (this was my first thought but I wanted to seek help before I commanded my pm3 to “wipe” anything)?
Is the information listed under Tag Signature relevant to this undertaking and did I fail because neglected it?
Is there a convenient place where I can further read up on the results of these searches and what the results (Ex. ATQA, SAK, RATS, wupC1) all mean?
I did poke around in the search results for xM1 and MF Classic 1k but didn’t seem to find what I was after. Sorry if I missed something and this kind of stuff has been covered elsewhere, please point me to it if I have.
Any and all help and replies are appreciated. I look forward to 'em.
Resulted in a write block send command error, I should note at this point I’m cloning to a Proxgrind Gen1A S50 and whilst the UID, ATQA and SAK have all been cloned all of the ‘Tag Signature’ data was not.
Doesn’t take much of a leap to infer that the partial dump file is the reason that this information is missing but is that inference correct? Is it perhaps an incompatibility between the hotel key and the S50 card?
And how do you think I would go about making that partial dump file just a regular old complete dump file?
The magic ring is a gen 2 magic chip. As such you can just write to any part of the chip without first using the backdoor commands. The backdoor commands won’t work, so the gen 1 backdoor commands will fail. Try just copying the data without using any special “magic” commands.
ETA: My mistake I assumed that we were talking about the Magic Ring, not the XM1.
Unfortunately you cannot write a mifare chip onto a NeXT. The NeXT contains a T5577 which is capable of emulating a bunch of low frequency chips, and an NTAG216 which is a very capable chip, but cannot have its UID modified. You would need a Magic chip to modify the UID in it.
Most door locks act on just the UID so you will probably have two options.
Buy a Magic chip based implant and clone your door card onto that (assuming that your door card uses a mifare chip)
Have whoever is in charge of the door system enroll your implant in it. For my front door I have the power to add my own chips, so this is the route that I go.
The card you have is a Mifare Classic Ev1 which contains a hardened (but exploitable) PRNG and a signature from NXP to ensure its a genuine card. From my experience with Mifare, no manufacturers are checking the signature of Ev1 cards and there arent many manufacturers that know the signatures exist on Ev1 nor where they are located. This is partly due to this ‘feature’ not being documented on NXP datasheets (from what I recall)
Given the above about the lack of use for the signature of Ev1, there are no magic Mifare cards which support signature cloning; there is no need for it given no manufacturer checks that data.
From your first screenshot, after autopwn, there are some command errors when the command tries to write the found data to simulator memory. This is also most likely the reason why it shows the dump file is partially complete.
For what device did you compile the client and what version of the proxmark are you using?
Your second screenshot, showing cload, from my experience, bad magic card block writes are usually due to bad coupling from the tag antenna and the PM3 antenna. Try putting some air distance between the card and PM3 and run the command again.
General tip: since you know the card is a Mifare which is (closely compliant) with 14a, you can use the command hf 14a info rather than hf search to get basic card info faster.
I have the same error. Would you please let me know if I am understanding you correctly. If I can copy the other data correctly the signature should be immaterial for the time being because it is not being checked.
Also cmd error 04… Should I try to update. Last update was Dec. 29th. I set up in proxspace on a windows machine. I set up following dangerous things video and written directions. Is there a work around to dump the file?
Any help or guidance would be greatly appreciated.
Hello Dangerousthings Community!
I have had an xM1 gen2 Mifare Classic implant since last week. I am very satisfied so far.
Today I wanted to clone my Gym card
cload is to write a dump to a backdoor (gen1a) card. You’re just using the wrong command. Because the gen2 card operates just like any normal mifare chip (but with sector 0 unlocked for writing), you just use the normal write commands used for any mifare card. In this case, I believe you want to just use the restore command instead of cload.
Be sure to check your firmware version’s help section, but this is mine;
The first thing I did was create a dump file using the “hf mf autopwn” command. Three files were then stored in my directory. “dump.bin”, “key.bin” and “dump.json”.
Then I placed my implant on the PM3 and executed the following command:
Memory Size: MIFARE Classic cards come in two main variations - 1K and 4K. The 1K version has 1024 bytes of memory, while the 4K version has 4096 bytes.
Sectors and Blocks:
1K Version: Divided into 16 sectors, each with 4 blocks.
4K Version: Divided into 40 sectors, where the first 32 sectors contain 4 blocks each, and the last 8 sectors are “extended” sectors, containing 16 blocks each.
Each block is 16 bytes long.
Data Storage: User data is stored in the blocks, but not all blocks are available for data storage because one block in each sector is used as a “sector trailer”.
Sector Trailer
Location: The last block of each sector is the sector trailer.
Contents:
Key A: 6 bytes. Used for various access control purposes.
Access Bits: 4 bytes. Define the access conditions for each block in the sector, including the sector trailer itself.
Key B: 6 bytes. Optional and can also be used for access control or can be used to store other data if not used for security purposes.
Access Control in Sector Trailer
The access bits in the sector trailer determine how the blocks in the sector can be accessed (read, write, increment, decrement, etc.).
The keys (Key A and Key B) and the access bits work together to define the security for each block.
The configuration of the access bits is critical because if they are set incorrectly, they can render the sector permanently inaccessible.
Ok well, it got the important stuff about how the memory is structured. The dump data file contains only the memory blocks from each sector and not the keys stored in the sector trailer. Those are kept in the separate key file because reasons.
I understand more and more how the whole NFC world goes. But I’m not a professional yet and I need your help again…
Ultimately I just want to copy my gym card to a Mifare Classic 1k Magic gen2 Card / xM1gen2. I proceeded as follows:
I read in the tag/implant to be written on:
hf mf info
Now I have with the help of the command
hf mf restore -f C:\Users\khageney\working\ProxSpace\pm3\hf-mf-C25CFAEB-dump.bin
tried to play the dump file from the gym card on the Mifare Classic 1k Magic gen2.
But that didn’t work. The UID remains the same and the dump files are also different.
What I’ve done now is definitely not the right way, but I haven’t found any other solution. I only changed the name of the key file from the gym card (UID Gym card) with the UID of the Mifare Classic 1k Magic gen2
Now I started the command again:
C:\Users\khageney\working\ProxSpace\pm3\hf-mf-C25CFAEB-dump.bin
Now the UID has also changed and the DUMP files are matching!
BUT my big problem is I can only do this process once. Now I can no longer describe the Mifare Classic 1k Magic gen2 in a my way.
How is it possible for me to write the chip again?
Or could you show me another (correct) way to clone Mifare Classic to Mifare Classic 1k Magic gen2 over and over again?
Here is also a one drove link with the Dump and Key Files:
),
