Proxmark 3, Cloning a Mifare Classic 1K

Cloning a Mifare Classic 1k card using the Proxmark 3

When I first started using the Proxmark, it all sounded like it was going to be easy, you wave a card at the device, the Proxmark works it’s magic and then you can emulate or clone the card.

Wrong, wrong, wrong. For most cards I’ve encountered anyway.

It’s really not that straight forward, there are different cards with different functionality, some have defaults that make it simple to clone them (if the defaults haven’t been changed), some have good security and there are currently no methods to clone them – unless you’ve already got access keys. Maybe some of the security isn’t that strong but the card type isn’t popular enough to have had people scrutinise it.

I have so far had experience with a few different card types, the only relatively easily cloneable one being the Mifare Classic 1K. Understanding how to clone this card felt like a bit of a trek, but once I got there it didn’t seem like such a big deal. Hopefully this step by step guide means others won’t need to do the trek.

A quick note on cloning a card

Cards typically have their own unique ID (UID). They get written when the card is created and that area of memory is then made read only, so it can’t be changed. If you want a clone of the card then you want both the UID and the data on the card to be copied across to the new card, but this isn’t normally possible due to the UID being read only.

Enter the “UID changeable”, aka “Chinese backdoor” (seriously) cards, which allow you to change their UID. It’s useful to have one of these before progressing.

A good start is to update the device………

Install from the command line (I’m using a Mac here):

> brew tap proxmark/proxmark3
> brew install proxmark3

Connecting to the proxmark:

Change to your proxmark client directory:

> cd proxmark3/client

List modems, e.g. /dev/cu.usbmodem14101 :

> ls /dev/cu*

Connect to the modem show from the last command:

> /proxmark3 /dev/cu.usbmodem14101

The cloning process

You should now have a proxmark command prompt, so with a card on the proxmark, assuming it’s a high frequency card, you can:

proxmark3> hf search

Which results in a response along the lines of:

 #db# DownloadFPGA(len: 42096)
 UID : ba 2e a6 ab
ATQA : 00 04  
 SAK : 08 [2]
proprietary non iso14443-4 card found, RATS not supported  
Answers to chinese magic backdoor commands: NO  
Valid ISO14443A Tag Found - Quitting Search 

In this case it’s a Mifare 1k card. This also shows us the UID (ba2ea6ab) of the card, which we’ll need later. From there we can find keys in use by checking against a list of default keys (hopefully one of these has been used):

proxmark3> hf mf chk * ?

This should show us the key we require looking something like:

No key specified, trying default keys  
chk default key[ 0] ffffffffffff  
chk default key[ 1] 000000000000  
chk default key[ 2] a0a1a2a3a4a5  
chk default key[ 3] b0b1b2b3b4b5  
chk default key[ 4] aabbccddeeff  
chk default key[ 5] 4d3a99c351dd  
chk default key[ 6] 1a982c7e459a  
chk default key[ 7] d3f7d3f7d3f7  
chk default key[ 8] 714c5c886e97  
chk default key[ 9] 587ee5f9350f  
chk default key[10] a0478cc39091  
chk default key[11] 533cb6c723f6  
chk default key[12] 8fd0a4f256e9  
--sector: 0, block:  3, key type:A, key count:13
Found valid key:[ffffffffffff]  
...omitted for brevity...
--sector:15, block: 63, key type:B, key count:13
Found valid key:[ffffffffffff]  

This shows a key of ffffffffffff, which we can plug into the next command, which dumps keys to file:

proxmark3> hf mf nested 1 0 A ffffffffffff d

This dumps keys from the card into the file dumpkeys.bin.

Now to dump the contents of the card:

proxmark3> hf mf dump

This dumps data from the card into dumpdata.bin

At this point we’ve got everything we need from the card, we can take it off the reader.

To copy that data onto a new card, place the (Chinese backdoor) card on the proxmark:

proxmark3> hf mf restore 1

This restores the dumped data onto the new card. Now we just need to give the card the UID we got from the original hf search command:

proxmark3> hf mf csetuid ba2ea6ab

We’re done, the new card should work.

This whole process can be completed in a minute or two, so it’s not a quick read of the card by any means.

Why do we need keys

When most modern cards are placed next to a card reader there’s a handshake to ensure the card has the expected keys. This handshake moves the card through a number of states and only when the handshake successfully completes will the card allow access to all data stored on it. This is the reason that you can’t simply clone most cards, you need the correct key to complete the handshake and allow access to the contents of the card.

A defensive lesson

Some cards use default keys, while this makes it easy to clone a card, it also makes it pretty poor from a defensive point of view. It’s like using default admin credentials for a database, it makes an attackers life easy.

The lights on the Proxmark

I have to admit pretty much ignoring them. When I use it, it’s always connected to the laptop, so I’ve got the console output to see what it’s doing. There was a point where I tried to understand them, I found a guide, they were starting to make sense. Then I updated the device and that changed what the lights did completely. I’ve ignored them ever since.

Fix a broken card

We had a situation where we wanted to clone a Mifare Desfire card but didn’t have an identical card to copy it to – we only had a Mifare Classic 1K. We also couldn’t read the complete card as we didn’t have the key to authenticate, so all we could usefully get was the UID. Some research suggested a small chance that just using the UID might be enough to get past a secure door if there was a (very) sloppy implementation. We copied that UID (10 bytes) to a Mifare Classic 1K card (which uses a 7 byte UID). The difference in UID size was another indication that this was very unlikely to work. it didn’t work. Doing this left our Mifare Classic card in a state where the Proxmark wouldn’t even read it, so to fix that we did:

proxmark3> hf mf cwipe 1 w f


In your proxmark/client/scripts directory, you’ll notice lots of Lua scripts. Some of these may be useful to you, so it’s worth a quick look to see what they do. They’ll also be useful if you plan to automate some of your use of the Proxmark. Looking at the scripts should help understand what you can do.


There is a potentially useful app called Andprox which allows you to run a Proxmark on your mobile phone. All of the commands you can run on the Proxmark from a laptop can also be done from Andprox, with the exception of Lua scripts.

The only issue I had with Andprox was that the connection from my mobile to the Proxmark kept dropping. My assumption was that it may not have been getting enough power from my mobile (Nexus 5X – yes, I really need a new mobile)


RFID is close range, recommendation is that you hold card 1cm above the Proxmark. Typically I just put the card on the Proxmark, sometimes just the position on the device is important, turn it over, move it round a bit. If that fails a lot then I’ll try holding it a little higher.


Commands (and the github repo):

Mifare Classic help:

Mifare Classic Universal Toolkit (MFCUK):

Mifare Classic Offline Cracker (MFOC):

NFC Writer:

None of this makes me an expert, so far I’ve got a basic understanding, at least enough to get something working!

You can pick up a proxmark from here: Elechouse Proxmark3 Kit RDV2
Got a comment or correction (I’m not perfect) for this post? Please leave a comment below.
You've successfully subscribed to Gavin Johnson-Lynn!

My Pluralsight Courses: (Get a free Pluaralsight trial)

API Security with the OWASP API Security Top 10

OWASP Top 10: What's New

OWASP Top 10: API Security Playbook

Secure Coding with OWASP in ASP.Net Core 6

Secure Coding: Broken Access Control

Python Secure Coding Playbook