Mifare 1K Classic

I’ve recently started delving back into RFID attacks since a lot of businesses will likely be asking for physical PenTests or, at the least, Risk Assessments since the majority of the population has been vaccinated. In this article, I’m going to outline how a Mifare 1K Classic card is laid out, how you can edit the information stored in it and how to clone it. During physical PenTests or Risk Assessments, one of the items we check for is the security of the physical ingress points be it with traditional locks or by using RFID/NFC/PAN cards and the strength of protection they offer to the client. Being able to clone a card and bypass the security of an electronic reader is something we would bring up during these engagements.

Before we dive into this, keep in mind that there are a multitude of RFID cards in both the Low and High Frequency range and in this article, I’m only covering the Mifare 1K Classic High Frequency ISO14443A (13.56MHz) cards. For other cards, stay tuned as I’ll add more when I get the chance.

I’ll be using a Proxmark3 RDV4 for this endeavour however the information provided in this article applies mostly to the cards and other RFID read/writers will have similar functions to that of the Proxmark.

Data Structure

Mifare Classic 1K cards allow for 1024 bytes of storage with 720 bytes usable. The data is organized in 16-byte blocks with four blocks per sector and a total of sixteen sectors to allow for the 1024 byte storage on the card.

Mifare 1K Sector Example

The first four bytes (Sector0,Byte0~Byte3) represent the UID of the card. The fifth byte (Sector0,Byte4) is the total of the first four bytes added through an XOR process. If the first four byte entries (the UID) of the card are “2F AB 5B 3C”, then we can use a tool such as https://toolslick.com/math/bitwise/xor-calculator to generate the fifth byte checksum as “E3”.

The first three blocks in a sector are data blocks which can store information. The last block in each sector is the “Sector Trailer” which holds “A Key” and “B Key” as well as the access permissions to the previous three data blocks. The “A Key” is stored in the first six bytes of the block, then are three bytes for the access permissions, one “free” byte and lastly, the “B Key” which is optional. If the “B Key” isn’t used, the data bytes can be used for user storage.

Data Modification

The Sector Trailer blocks can only be written or read however data blocks can be written, read, incremented or decremented. Setting what options are available per block is done with the access permissions bytes in the Sector Trailer block starting at byte offset 6 (the seventh byte) and ending with byte offset 8 (the ninth byte) inclusive.

Mifare Permissions Bits

You will see that in the above table, each access bit is stored in two places. The access bit for block 0 (data) is stored normally in bit address 4 and inverted in bit address 0. For example, if the access bits for block 4 are normally set to 101, then the access bits in block 0 would be inverted at 010. Keep in mind, however, that the order (1, 2, 3) are stored in different bytes depending on the access bit being set. For example, access bit “2,0” is located in byte 6, bit position 4 for the normal reading but is in byte 8, bit position 0 for the inverted reading.

Sector Trailer Settings

Above are the bit settings which can be set for the Sector Trailer blocks. The first “Key A” column specifies what permissions are set for who can read the “Key A” value and who can write the “Key A” value. Next are the permissions for who can read or modify the Access Bit permissions and, lastly, are the values for the “Key B” values.

Data Block Settings

The chart above shows the permission settings for who can modify the Data Block values and what those values are.

To generate the full bit chart, create an 8x3 table in LibreOffice or Excel and refer to the “Mifare Permissions Bits” image above. Here is what this would look like being calculated:

Mifare Access Permission Bits Calculation

And here is what the final Sector Trailer block should look like with the aforementioned settings applied (assuming that the “Key A” and “Key B” data are all “0xFF” bits):

Mifare Sector Trailer with Access Permissions Set

Data Reading

With the card within proximity of the Proxmark RDV4, you can issue the command “hf mf cview” and you will be provided with the data on the card, sorted by sectors:

Snippet of “Victim” card

Magic Cards

Normally, a card has a set, Read-Only UID in the first block (Sector0, Block0) which is generated during the manufacture process. Attempting to write to this area will normally fail unless you are using a “Magic” card. These cards allow for writing to all sectors and all blocks. When ordering cards to write to, ensure they are listed as “Magic” cards — Older terminology is “Chinese Backdoor” or “Chinese Magic” so be aware of those descriptions as well.

Data Writing

To write data to the card you will use the “hf mf csetblk” command. In the above example, the contents of blocks 4, 5 and 6 were written with the following commands:

hf mf csetblk -b 4 -d 74686973206973206120746573742020

hf mf csetblk -b 5 -d 666f722077726974696e672064617461

hf mf csetblk -b 6 -d 746f204d6966617265314b2063617264

The command uses the “-b” variable to set which block is going to be written to and the “-d” variable to specify the data to be written to the block sequence. All the data is written in hexadecimal and can easily be generated by using CyberChef with the “To Hex” recipe. Ensure that there are sixteen hex bytes (a total of 32 ASCII characters) in the data you want to generate as this is the amount of data which can be stored in one block of the Mifare card.

Data Dumping (Saving Victim Card)

Once you have verified that you are using a Mifare 1K card, you can dump the card to files stored on your computer. Using the command “hf mf autopwn” will use the default dictionary (./client/dictionaries/mfc_default_keys.dic) in an attempt to get the “Key A/B” data on the card. You can specify a specific dictionary with “-f <name_of_dictionary>” if you have a unique one to use. If all goes well, you will see something similar to the following:

Snipped “hf mf autopwn” Command

Final “hf mf autopwn” Command

You will end up with a few files on your computer such as the “.bin”, “.json” and “.eml” files. These files represent the card you’ve just cloned.

Data Loading (Cloning Victim Card)

Now that you have a copy of the card, we can use a Mifare 1K Magic card to create an exact duplicate of the victim card. Place your blank Mifare Magic card on the Proxmark and take note of the “.eml” file you have on your computer. For my example, the file is: “hf-mf-2FAB5B3C-dump.eml” The filename should correspond to the UID of the original card you’ve saved in the previous step. To load the victim card into the new blank card (cloning the original), run: “hf mf cload -f hf-mf-2FAB5B3C-dump.eml” while replacing the filename with your actual filename. You should get:

Loading a Dump File to a Blank Card

Congratulations! You have now cloned a Mifare 1K Classic card.