I’ve been trying to clone an ISO 14443-A tag by using the Proxmark3 and I’m having issues with the “hf mf autopwn” command, as it it only generates a binary file, there is no .eml file, which I need in order to dump.
=====
[+] generating binary key file
[+] found keys have been dumped to C:\ProxSpace\pm3/hf-mf-0B098F15-key-002.bin
[=] --[ FFFFFFFFFFFF ]-- has been inserted for unknown keys where res is 0
[=] transferring keys to simulator memory ( ok )
[=] dumping card content to emulator memory (Cmd Error: 04 can occur)
[=] downloading card content from emulator memory
[+] saved 1024 bytes to binary file C:\ProxSpace\pm3/hf-mf-0B098F15-dump-002.bin
[+] saved to json file C:\ProxSpace\pm3/hf-mf-0B098F15-dump-002.json
[=] autopwn execution time: 2 seconds
====
These are the responses I get, it is also worth mentioning that all the found keys are “FFFFFFFFFFFF” for some reason.
You’re like the third person to post about this specific issue recently, mind sharing what guide you’re using so I can bug whoever maintains it to update it a touch?
Long story short:
You’re reading an old guide, use the bin or json files in place of the eml file and everything will work fine
This is a pretty common default key, it just means the card probably doesn’t have anything super fancy on it (Unless there are keys you aren’t finding) and might just use UID to authenticate with whatever system it uses. Or maybe it just uses default keys, who knows?
Thanks for the fast reply, I’ve been using this GUIDE so I thought I could only use the .eml files. Anyhow, I’ve now encountered another issue whenever I try to copy I get this error message:
Is the card you’re trying to write to a gen1a magic card?
Ah, well, I’m pretty certain that the guy who maintains that is probably well more aware of it than I am, and will get around to updating it as soon as his busy schedule allows
But, not to go back on my word, @amal consider yourself bugged
Yes, it is a gen1a. I’ve also tried on gen2 just to see if I get any different errors, but no, it’s just the same. The card(s) probably came in bricked…
It’s possible, they can be a bit hit-or-miss depending on where you get them
But, they can also be quite picky regarding placement on the PM3 for a good read/write. Though if you can detect them with ‘’‘hf search’‘’ that shouldn’t be the case. You could try:
Making sure the proxmark isn’t on a metal surface
Putting the cards underneath the proxmark
Putting the cards sort of halfway on, halfway off the proxmark
Holding the cards slightly above and off the proxmark
I’ll keep trying that’s for sure, unfortunately I have only one gen1a card, as far as I know it is not possible to copy a gen1a to a CUID/ Gen 2, right? Since I got way more Gen 2 cards I can try with.
The eml file type has been phased out of use within the RRG Proxmark repo/project in favour of the more industry accepted file type of json. On the older guides where you read “eml”, replace it with “json” and you’ll be fine.
Few things Ive noticed as I was reading the thread:
Source card has 4 byte (N)UID
Source card has weak PRNG
Source card has 1k memory
You are using Proxspace
You have used Autopwn/recovery commands multiple times
You are copying to a gen1a (primarily)
Taking into account the things listed above it’ll help guide your efforts in the correct direction. The ‘magic’ of gen1a cards is their ability to perform ‘backdoor commands’ and being able to write to block 0 repeatably. Trying to use gen1a backdoor commands on a gen2 wont work as they lack that functionality. This is why you are having trouble trying to copy the dumped data to the card as you are using the gen1a command for that functionality.
Have a look at the Mifare Classic commands (hf mf -h) on the proxmark with their descriptions. Notice that any subcommands start with a ‘c’ are for gen1a backdoor commands thus only work on gen1a cards.
The issue you are having with the “wupC1 error” is usually caused by bad/poor coupling from the proxmark high frequency antenna with the card’s antenna. This is easily solved by putting some space between the card and the proxmark then issuing the command. To find the sweet spot you can change commands together to run in sequence by separating each command with a semicolon (eg hf 14a info; hf 14a info; hf 14a info).
You certainly can and Id say its an easier process than copying from a genuine card to a gen2. In your case you have two ways: use the .bin or .json files you already have or dump data from an existing gen1a (if you dont have the files)
The key part when cloning to a gen2 card to remember is that it’ll behave just like a genuine card but will allow you to write to block 0. Meaning that you can write a ‘bad’ block 0 and lock yourself out of the card thus bricking the card in either a faulty not usable state or locking the card in a usable state without the option of rewrite the block 0 data.
The function on Mifare Classic that dictates how the card data should be accessed is the, aptly named, Access Bits. These can be set in a fashion that the data can only be read but never written (using (n)either sector key). The default access bits are FF0780 which means that Key A and Key B can read and write all blocks in the sector.
If you are writing to a gen2 card, I would always urge you to check the data (.json should be easy to read) before writing it to a clone card. Check that you can see all the data in each sector and double check how the access bits are set to avoid bricking a card. There is a great utility to enter the access bits and easily understand what they are set to do.
Hope this clears up a few things, happy to help with anything else.
