Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Mifare 1K Classic

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 9

https://grave-rose.medium.

com/mifare-1k-classic-dd561424a41b

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.

You might also like