How Hackers Just Dropped MIFARE Ultralight C’s 3DES Security from 112 Bits to a 5-Minute Joke + Video

Listen to this Post

Featured Image

Introduction:

For over seventeen years, millions of access control systems, hotel key cards, and public transport tickets have relied on MIFARE Ultralight C’s 3DES encryption to secure physical access. This security, however, was anchored by a critical assumption: an attacker could not feasibly brute-force a 112-bit cryptographic key. New research presented at Hardwear.io and published as a Cryptology ePrint paper has shattered that assumption, demonstrating a devastating partial key overwrite attack that collapses the key space from an astronomical 2^112 down to a mere 2^28, with some vulnerable tags surrendering their secrets in under 60 seconds on a standard smartphone. The attack, codenamed “BREAKMEIFYOUCAN!”, is a stark reminder that even widely deployed cryptographic standards can be fatally undermined by subtle implementation flaws.

Learning Objectives:

  • Understand the mechanism of a partial key overwrite attack and how a lack of atomic write operations enables the reduction of a 2^112 key space to 2^28.
  • Use a Proxmark3 and associated Linux tools to verify the presence of default 3DES keys, perform authentication sniffing, and conduct a “tear-off” attack.
  • Identify vulnerable system implementations, assess the risk of counterfeit cards in existing deployments, and implement mitigation strategies like key diversification and reader-side upgrades.

You Should Know:

1. The BREAKMEIFYOUCAN! Attack: Exploiting Non-Atomic Writes

The BREAKMEIFYOUCAN! vulnerability is not a flaw in the 3DES algorithm itself, but a critical implementation weakness in how NXP and its licensees manage key storage on the MIFARE Ultralight C (MF0ICU2). The 112-bit 2-key Triple DES key is split across four consecutive memory pages, typically pages 44 to 47. The root cause of the vulnerability is that the chip’s firmware does not enforce an atomic write operation for the key. This means an attacker, after establishing initial authentication, can issue commands to modify each of the four pages individually rather than requiring a simultaneous update of all four.

The attack unfolds in a straightforward manner. First, the attacker uses a relay-based man-in-the-middle (MitM) technique, often leveraging two Flipper Zero or Proxmark3 devices connected over a 433MHz channel, to gain an initial authenticated session with the card. Once this is achieved, the attacker writes known values (e.g., all zeros) into three of the four key pages. The final page holds the only unknown 28 bits of the key. With the key space now reduced to 2^28, a brute-force recovery is computationally trivial and can be performed in minutes on a modern laptop. Repeating this process for each of the four pages allows the attacker to reconstruct the full 112-bit key.

The research team also discovered that approximately 34% of field-deployed cards in hospitality were not authentic NXP chips, but counterfeit cards from manufacturers like Giantec, Feiju, and USCUID. These counterfeit cards often lack a robust random number generator and are susceptible to even simpler “tear-off” attacks, where abruptly interrupting the power during a write operation leaves the key in a predictable, partially updated state. In the most extreme cases, researchers recovered a full key from a single fraudulent card in less than 60 seconds using only a mobile device.

Step-by-step guide: Testing for the BREAKMEIFYOUCAN! Vulnerability with Proxmark3

To replicate the initial reconnaissance phase of the BREAKMEIFYOUCAN! attack, you can use a Proxmark3. Note: This information is for educational and defensive security testing only. Unauthorized access to or modification of access control systems is illegal. The following steps assume you are acting on a card for which you have explicit permission.

First, set up your Proxmark3 environment on a Linux system:

 Update system and install dependencies
sudo apt update && sudo apt install git make gcc libreadline-dev libusb-1.0-0-dev

Clone the latest Iceman Proxmark3 repository
git clone https://github.com/RfidResearchGroup/proxmark3.git
cd proxmark3

Compile the firmware and client
make clean && make all

Flash the firmware to your Proxmark3 device
./pm3-flash-all

Next, connect your Proxmark3 via USB and launch the client:

 Launch the client with sudo for USB permissions
sudo ./pm3

Once inside the Proxmark3 client, you can identify and interact with a MIFARE Ultralight C tag:

[ Proxmark3 ] > hw tune
[ Proxmark3 ] > hf search
[ Proxmark3 ] > hf mfu info
[ Proxmark3 ] > hf mfu dump -k 425245414b4d454946594f5543414e21
[ Proxmark3 ] > hf mfu auth -k 425245414b4d454946594f5543414e21
[ Proxmark3 ] > hf mfu rdbl -b 44 -k 425245414b4d454946594f5543414e21
  1. From Vulnerability to Breach: The Critical Role of Counterfeit Cards and Relay Attacks

The BREAKMEIFYOUCAN! attack is particularly dangerous because it does not require expensive hardware or advanced cryptanalysis. The research team demonstrated a practical relay attack using two off-the-shelf Flipper Zero devices. One device acts as a “ghost reader,” placed near the legitimate card reader, while the second acts as a “ghost card,” placed near a vulnerable MIFARE Ultralight C tag. The devices relay communication over a long-range radio frequency, effectively tricking the card and the reader into believing they are in close proximity. This breaks the fundamental physical security assumption of NFC systems, allowing an attacker to compromise a card from meters or even kilometers away.

Once the relay is established, the attacker first probes the card by attempting to authenticate with the NXP factory default key. This default key—425245414b4d454946594f5543414e21 in hex—is the ASCII text “BREAKMEIFYOUCAN!” and was burned into every MIFARE Ultralight C shipped since 2008. A staggering number of systems in the field still use this default key, meaning an attacker with a Proxmark3 and this key can bypass 3DES without any brute-force effort. For cards that have changed their key, the non-atomic write flaw is exploited to reduce the key space.

The presence of counterfeit cards dramatically accelerates this attack. Research on cards like the Giantec GT23SC4489 revealed that they lack proper anti-tearing mechanisms and often have predictable pseudo-random number generators (PRNGs). An attacker can simply rip the card away from the reader in the middle of a key update transaction, causing the key to be stored in a predictable state. This type of “card-only” attack is a critical supply chain risk for any organization procuring NFC tags from unauthorized vendors.

Step-by-step guide: Simulating a Relay Path with Proxmark3

While a full relay attack requires two devices, you can simulate a man-in-the-middle surveillance scenario by using a single Proxmark3 to sniff the communication between a legitimate reader and a card. This allows you to capture authentication traces and identify if a default key is in use.

[ Proxmark3 ] > hf 14a sniff

[ Proxmark3 ] > hf list 14a

[ Proxmark3 ] > hf 14a info

[ Proxmark3 ] > hf mfu chk
  1. The Immediate Aftermath: What This Means for Access Control and Physical Security

The BREAKMEIFYOUCAN! paper has been presented at major security conferences, including Hardwear.io USA 2026, and the accompanying tooling has been merged into the mainline Proxmark3 codebase. This means that the attack, once theoretical, is now accessible to any security researcher or threat actor with a Proxmark3 and basic technical skills. The implications for physical security are severe. Millions of hotel key cards, office badges, and parking access tags based on the MIFARE Ultralight C are now effectively compromised.

The vulnerability highlights a systemic issue in the access control industry: the reliance on security through obscurity and a failure to enforce basic best practices like key diversification. The NXP design allowed for a per-card unique key derived from a master key and the card’s serial number, a method that would have rendered the partial key overwrite attack far less practical. However, many integrators left the default key in place or used static keys across entire deployments. Furthermore, the widespread infiltration of counterfeit cards into legitimate supply chains indicates a significant breakdown in hardware security validation.

Step-by-step guide: Mitigation and reader-side hardening

For defenders, the path forward involves immediate action. The first step is to conduct an inventory to identify any MIFARE Ultralight C tags in your environment and determine if they are genuine NXP silicon or counterfeit. Contact the original system integrator to ascertain if key diversification was ever implemented. If the cards were deployed with the default key, they must be considered compromised and replaced with a newer, more secure technology like MIFARE DESFire EV3. In the short term, if your reader hardware supports it, you can attempt to implement reader-side checks to detect and block the known attack patterns, such as sudden power loss or rapid key overwrite attempts.

4. Code-Level Analysis: The Partial Overwrite Loop

The core of the BREAKMEIFYOUCAN! attack can be broken down into a conceptual four-step loop. The following pseudo-code demonstrates the process an attacker would use to reconstruct a full 112-bit key.

 Python pseudo-code for a conceptual key overwrite attack loop
 Note: This code is for educational purposes only.

from proxmark3.interface import Proxmark3CommandRunner
import itertools

Assume pm3 is an authenticated connection to the card
def breed_attack(pm3, target_page, known_page_values):
 1. Overwrite 3 of the 4 key pages with zeros
for i in range(44, 48):
if i != target_page:
pm3.write_mem(page=i, data=b'\x00'  4)

<ol>
<li>The keyspace is now 2^28, which is brute-forceable
Hypothetical function to brute-force the remaining 28 bits
recovered_partial_key = brute_force_28bit(pm3, target_page)</p></li>
<li><p>Repeat for all four pages to assemble the full key
return recovered_partial_key

Attack loop
full_key = bytearray()
for page in [44, 45, 46, 47]:
partial_key = breed_attack(pm3, page, known_zeros)
full_key.extend(partial_key)</p></li>
</ol>

<p>print(f"Recovered Full 3DES Key: {full_key.hex()}")

5. Proactive Defenses: Configuring Proxmark3 for Security Audits

Instead of waiting for an incident, security teams should proactively audit their physical access control systems (PACS). The Proxmark3 is an invaluable tool for this purpose. Compile the firmware with the latest patches, including the updated `hf mfu` commands that now integrate the BREAKMEIFYOUCAN! detection logic. Automated bash scripts can be employed to dump, verify, and check emulation status, helping to identify vulnerable cards at scale.

Step-by-step guide: Automated dumping and verification

The following Bash script automates the process of checking a batch of cards for default keys.

!/bin/bash
 Script: scan_vulnerable_cards.sh
 Use: Sudo ./scan_vulnerable_cards.sh

DEFAULT_KEY="425245414b4d454946594f5543414e21"
LOG_FILE="vulnerable_tags.log"

echo "Starting Proxmark3 Vulnerability Scan. Logging to $LOG_FILE"
echo "Place card on the reader and press Enter."
read

echo "[+] Checking card for default 3DES key..."
./pm3 -c "hf mfu auth -k $DEFAULT_KEY; hf mfu dump -k $DEFAULT_KEY" > scan_result.txt

if grep -q "Authentication successful" scan_result.txt; then
echo "!!! VULNERABLE: Card uses NXP factory default key. !!!"
echo "$(date) - VULNERABLE card detected with DEFAULT KEY" >> $LOG_FILE
else
echo "[-] Card does not use default key. Further analysis required."
echo "$(date) - Card uses custom key." >> $LOG_FILE
fi

rm scan_result.txt

What Undercode Say:

  • The “BREAKMEIFYOUCAN!” disclosure transforms a theoretical 3DES weakness into a practical, cheap, and fast physical access exploit, effectively killing MIFARE Ultralight C for any high-security application. The combination of a non-atomic write flaw and a factory default key is a catastrophic failure of secure design.
  • The widespread presence of counterfeit chips with predictable PRNGs is a supply chain crisis. Organizations cannot assume that their hardware is secure, even if they follow NXP’s specifications. This attack represents a paradigm shift: the cost of breaking physical security has dropped to nearly zero for millions of existing systems, forcing an urgent, industry-wide migration to more resilient technologies like MIFARE DESFire EV3 with diversified keys.

▶️ Related Video (76% Match):

🎯Let’s Practice For Free:

IT/Security Reporter URL:

Reported By: Herrmann1001 Proxmark3 – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky