If an engagement has an NFC or RFID component, the Proxmark is the most thorough and complete tool for the job. You can use it to evaluate card type, demonstrate card cloning attacks, enumeration based attacks and even perform algorithmic bypasses on password protected cards. It’s an invaluable tool, but can be a little bit finicky to setup.
Before plugging the Proxmark into a power source, always ensure that an antenna is connected. Accidentally running search commands without an antenna connected may damage the device. Make sure that the USB to micro-usb cable plugs into the computer and the USB to square (golden port on the Proxmark) cable plugs into the antenna.
Mixing this up will probably damage the device, so make sure that the connections are correct before proceeding.
Flashing Firmware / Update Procedure:
Before you can start ripping through corporate badges like tissue paper, it’s best to ensure that you have the latest firmware (you need to ensure that your client matches the version of firmware installed). Often the repository will be updated with new attack vectors and more card types, so it’s a good idea to stay on the bleeding edge.
The only caveat I would add: do this on a native Linux machine. The Proxmark flashes over a serial interface, and virtual machines can sometimes have timing or driver issues which complicates the process.
If after flashing, the device no longer shows up as USB, hold down the button on the Proxmark before plugging in. After 10 seconds, it should show up as a USB device. Continue holding down the button while you flash the main image. This happened to me after successfully flashing the bootloader but not being able to flash the main image.
Running the Client:
If the firmware flashed okay, you should be in the Proxmark3 repository. Run the following command to start the Proxmark command line interface:
You may need a different dev file to access the Proxmark. You can find this using
sudo dmesg | tail after plugging in the device. The created device file should show up in this system log.
Proxmark comes with a built in LUA scripting interface, but honestly I’ve never used it. The standard proxmark client accepts input straight from STDIN, and it’s pretty easy to whip up a Python script for your use case and pipe it directly to the client.
LF Cards (RFID):
LF (low frequency) cards typically operate at 125 or 134 KHz. They have a longer range than NFC cards, and anecdotally are less likely to have encryption mechanisms. Usually the card can be cloned simply from the text present on the front, which can be noted in attack simulations, and devices such as the RFID tastic thief can steal cards from up to 3 feet away.
hw tune. The output should say that your HF antenna is not suitable for use, indicating that this antenna is intended for LF RFID usage. The following sections will demonstrate usage for the most common RFID keys. If the card type is unknown, first attempt to discover it with:
lf search u
HID Prox Cards:
These cards are extremely common, can be implemented by a number of chips under the hood, including the
T55x7. Typically these cards will not have password protection or encryption, and can be cloned simply by knowing the card ID.
Detect Card ID:
lf hid demod
Generate Card ID:
lf hid encode <format> f <facility code> c <card number>
Clone to T55x7:
lf hid clone <card identifier>
These cards are less common than the HID proxcards, but do exist. Often under a Honeywell brand. In any case, these cards do not rely on any advanced authentication. Cloning the card ID is enough to replicate the card. Brute forcing is possible here as
EM410x does not have good proximity detection. These cards can be spoofed by
Detect Card ID:
lf em 410xread 1
Bruteforce Card IDs:
lf em 410xbrute
Clone Card ID:
lf em 410xwrite <UID> 1
HF Cards (NFC):
NFC cards typically operate at 13.56MHz, resulting in less range. Anecdotally, these cards are more likely to have strong encryption (pray you don’t get a DESFire) and are a step up from basic RFID cards. That said, plenty of models have serious flaws or no encryption at all, showing vulnerabilities similar to those noted in the RFID section.
hw tune. The output should say that your LF antenna is not suitable for use, indicating that this antenna is intended for HF NFC usage.
hf search u
Very common card used in transit (not orca cards sadly), and by various businesses. This card utilizes an authentication scheme with 2 distinct keys, which protect an internal storage of 16 sectors. Each of the 16 sectors has 64 bytes. Each of the 2 keys can be coded to allow R/W to each of the 16 sectors individually. In theory this is a pretty reasonable permission model, in practice it almost always degrades to the following.
Dump using default keys:
hf mf dump
Try Default Keys:
hf mf chk *1 ? d
Try Nested Attack:
hf mf nested 1 0 <KEY A/B> <KEY> d
Read Specific Block:
hf mf rdbl <blockNum> <KEY A/B> <Key>
Read Specific Sector:
hf mf rdsc <sectorNum> <KEY A/B> <Key>
Write Specific Block:
hf mf wrbl <blockNum <KEY A/B> <Key> <data (32 hex chars)>
Sniff card to reader comms:
hf mf sniff
Clone card to tag:
hf mf restore (uses dumpdata.bin in current directory)
Often cloning a Mifare classic card is a valid attack, but the most interesting attacks come from modifying the data stored on the card. This usually involves taking a dump of the card at a known state, and comparing the dump with another dump after minimal changes. This basic form of reverse engineering can be used to deduce what values are being stored where on the card.
MIFARE Ultralight (C):
These cards are marketed as high end and offer “advanced” 3DES encryption containers for the standard NDEF messages. May or may not actually use 3DES, but it is an option here. Here’s the datasheet, describing the auth protocol and relevant lockbits:
It’s important to know that you should probably keep your writes between blocks
7-39. Blocks 40 and above control the lockbits, and setting those may end up permanently(!) locking other blocks. Don’t be like me and brick a card (or three) during your engagement.
Get detailed info:
hf mfu i
Dump using default keys:
hf mfu dump
Dump using custom keys:
hf mfu dump k <KEY>
Read specific block:
hf mfu rdbl b <block_number> k <optional_key>
Write specific block:
hf mfu wrbl b <block_number> d <data_in_hex> k <optional_key>
Experimental / Advanced Features:
There is a community developed repository with continued development and advanced features. I have not tried flashing the firmware on my Proxmark, but if your engagement requires you to mess with any of the NFC cards utilizing serious encryption (DESFIRE ect.) than you will probably need the features in this fork. I’m including a link for reference, but know that all the above commands apply to the official Proxmark repository:
By this point, you should have gained sufficient familiarity with the Proxmark. You can tear through crummy MiFare encryption, clone HID cards and demonstrate that an attacker could waltz into any room they like. Go use this knowledge for good, improve the security of your clients and help guide them towards cards which use strong encryption like the DESFIRE.
Additional Resources and References: