Unable to clone a Mifare 1K 7UID tag


I just started out so I’m a total beginner. Feel free to delete my question if it’s not the right place to ask :sweat_smile:

I have a Mifare classic 1k 7UID tag I’m attempting to clone. In order to do that I acquired a Chinese magic gen3 1k 7UID card.

I put on the original tag to be cloned and executed:

hf mf autopwn

After that I put on the magic card and executed:

hf mf gen3uid --uid ORIGINALCARDSUID

Then I did:

hf mf restore

But I get errors all time time saying (fail) key A, (fail) key B, Auth error. All of that about 60 times?

What am I doing wrong? Any help is greatly appreciated!:slight_smile:

Thanks in advance.

1 Like

the -k keyfile you use in the restore commands needs to be the keyfile for the gen3 not the keyfile for the original.

autopwn the gen3 and supply its keyfile as the parameter

1 Like

Thanks so much for your answer! @Equipter

I did it but I’m getting kind of the same result.

Now in the table in the “blk” column I have 0,0,1,1,2,2 etc. basically every entry is duplicated. One of the entries says (fail) Key B the other entry is (ok).

I’m guessing it just retried and wrote it successfully?

But entries 16 through 59 give me an “Auth error” still.

The console suggested to me I should try ‘hf mf dump --ns’ and I did it with the original tag and also with my newly written tag. The data looks the same. Does it mean it actually succeeded?

I don’t think it did because after issuing “hf search” the original tag has an additional category being displayed which is:

— Tag Signature
IC signature public key name: PLACEHOLDER1
IC signature public key value: PLACEHOLDER2
Elliptic curve parameters: PLACEHOLDER3
Signature verification: successful

After issuing “hf search” on the cloned tag it has the same UID but it doesn’t have this “Tag signature” category. How do I clone that over?

1 Like

I’m encountering something weird I think.

Whenever I do “hf search” on the original tag it shows a SAK: 08 [2]

after doing “hf mf autopwn” on the original tag and opening the dump.json file the SAK says 88.

Also after issuing "hf mf gen3blk -d NUMBER it executes successfully but doesn’t write the NUMBER 1:1. it differs with 1 digit and it’s the 0 instead of an 8. It just ignores the command without throwing an error?

1 Like

i wouldn’t bother cloning the sig it’s likely not even checked (very common to not check.) and i’m currently fuzzy if gen3s are even capable of sig emulation.

do data diff -a original.bin -b clone.bin substituting original & clone for the correct file names, the differ will tell you if the files have any incosistencies you need to change, if there are you can easily do so with hf mf wrbl


oh i just saw this: read this: Explaination of Mifare Classic SAK Swapping anti cloning defense · GitHub

keep it at 08 unless you find the necessity to change it to 88 after testing your clone against the system.

if it rejects your 1:1 clone (sans SAK being different in b0) you’ll need to sniff the comms between emulated card & reader to see what’s going on under the hood.

IF you need to do that, instructions below :arrow_down:

hf mf eload -f original.bin 
hf mf sim --1k -u UID 

present the proxmark (still plugged in) to the reader, it should beep with some acknowledgement positive or negative, press the button to end the sim and then run
hf mf list
this will produce the trace decoded in a mifare classic context where we will be able to look at what’s going on.

for easier access, save the trace with trace save -f pickaname and send it here for evaluation :slight_smile:


All right I’ll try without the actual sig but do you have any idea about the SAK thing? Why does it show 08 with ‘hf search’ and the .json file says 88?

I think that’s why I can’t write block 0 to the number I want since it just writes it with only 1 mistake (0 instead of 8).

1 Like


I’ll check it out!

1 Like

haha maybe just a little bit too much.


All right I did the diff and indeed it only differs in the SAK entry.

I’ll try it out tomorrow. Let’s see how it goes haha

By the way why am I not able to write block 0 with ‘hf mf gen3blk -d NUMBER’ 1:1 as I want?

The command writes block 0 except it doesn’t write 88 somewehre in the number but it replaces it with 08.

What is preventing the command to write the exact block 0 I actually want?

1 Like

And thank you very much for your help :hugs:

1 Like

By the way I have a proxmarkV3 easy. Do you think this is going to work with it?

1 Like

if you were to try it with changing the whole block 0 to something else (still a valid block 0 for a 7b card, do NOT just type random stuff) using gen3blk does it take affect?

Gen3s are tricky, it could be just write prevention on those bits specifically to prevent you writing data that could potentially cause identification issues.

gen3blk should be able to overwrite block0 so i’m curious as to why it isn’t tbh


oh yeah that should be no problem. the proxmark3 easy is a very capable device.

if the scale of your laptop is a problem you can use an android phone with an OTG (on the go) cable connecting your proxmark to your phone using the termux app. there is more info on that on the Proxmark Repo under termux


Thank you:)


Yes it definitely does take effect. Everything changed except for 1 byte which is weird since this command is not dependent on any dump and I just want to change that block 0.

Here’s what I mean cause I think it’s not clear haha:

Lets say 1111111111 were a valid block 0 and the default one of the gen3 magic card.

Lets say 1234887890 were the valid block 0 of the original card.

After typing ’ hf mf gen3blk -d 1234887890’ it says that it successfully wrote the block but it wrote 1234087890 instead of 1234887890.

(I know that block 0 is longer and those might not be valid values but this is just for illustration purposes to get my point across what I mean)

So basically it writes everything except for just that one byte. I guess now its more understandable what I mean. Sorry for the confusion.


oh yah then it’s just enforcing security on the SAK to force it to remain as 08.

it shouldn’t be much of an issue unless a block0 check is sent by the reader to validate it but that’s neither here nor there till we know what’s actually happening with the reader.

excited to find out whether or not your clone card works as intended! fingers crossed all goes well!


I update you in like two days. I’m excited as well. Stay tuned haha