Exploring RFID Cards Security: A Practical Analysis

3.1 Card Identification

Like most transit cards out there, this local transit card uses RFID, specifically NFC (Near Field Communication) which is a set of communication protocols that enables communication between two electronic devices over a distance of 4 cm or less.

Luckily for me they also used MIFARE Classic, a series of integrated circuit chips used in contactless smart cards and proximity cards, developed by NXP Semiconductors, that employ a propietary security protocol for authentication and encryption called Crypto1.

In this case, it was a MIFARE Classic 1K card, meaning it stores 1024 bytes of data. These bytes are organized into 16 sectors, and each sector contains 4 blocks. Each sector is protected by two cryptographic keys:

• Key A
• Key B

The last block of each sector (called the Sector Trailer) stores Key A, Key B, and access control bits that define what operations (read, write, etc.) are allowed with each key. Some systems usually only use Key A, while others use both keys for different levels of access.

Unfortunately for businesses still relying on MIFARE Classic, their security protocol, Crypto1, has been deprecated for years, making it relatively easy to break.

3.2 Data Extraction

In order to reverse engineer the transit card, I first needed to dump its data into a binary file, so I used my Proxmark3 to extract the card’s contents. There are multiple attack methods available to recover MIFARE Classic keys, with nested and hardnested attacks being the most common. Before diving into which one I used, lets briefly explain how they work.

• Nested Attack: This attack takes advantage of the fact that once you authenticate to a sector of the card using a known key, you can extract encrypted data that helps recover other keys more quickly. The attack works as follows:

  • Authenticate with a known key in any accessible sector.
  • Intercept the encrypted messages exchanged between the card and the reader.
  • Exploit weaknesses in the Crypto1 encryption to compute keys for other sectors.

  This attack is fast and works on vulnerable cards without additional protections.

• Hardnested Attack: The hardnested attack is an improved version of the nested attack. It was designed to bypass security measures that blocked the original method. It uses more efficient calculations and optimized brute-force techniques to extract keys faster and with fewer failed attempts.

  The main difference from the nested attack is that it relies on advanced mathematical techniques to significantly reduce the time needed to recover keys, even when the card has stronger protections.

In my case, I used the hardnested attack, which allowed me to retrieve all the keys in less than 15 minutes. Once I had all the keys, I used my Proxmark3 again to dump the entire card into a binary file as well.

3.3 Reverse Engineering the Data Structure

Lets take a look at a tiny portion of the card dump.

(For the sake of simplicity, the screenshot does not show the entire binary—note that it stores 1024 bytes in total—and the sector keys have been redacted.)

At first glance, it is difficult to get an idea of how the card’s data structure is designed. Performing a static analysis based on a single dump would be a highly complex and time-consuming task. My primary goal was to identify the bytes storing the balance to see if I could modify them, effectively changing the card’s balance at will.

The first sector contains the card’s UID (Unique Identifier). The next few appear to be empty, and the following sectors seem to store information related to the card’s balance, a history of recent transactions, and possibly other transit-related data.

Having identified the relevant sectors, I continued with my byte elimination strategy. To do this, I made payments with the card and dumped its data after each transaction. By repeating this process, I was able to track the bytes that kept changing after every transaction in the relevant sectors.

After repeating this process a few times without being able to eliminate more bytes, I began analyzing the ones that changed after each transaction. Knowing that my card had a balance of €27.98 in the dump I was analyzing, I started searching for bytes that could be related to this value. Before long, I noticed something interesting in a particular block.

When converting some hexadecimal values to decimal, I found that 0xDC15 equaled 56,341, which didn’t seem to have any clear relationship with my balance. However, I then tried interpreting the bytes in little-endian format, which is defined as a byte order wherein the least significant byte (or ‘little end’) of a multibyte data value is stored at the lowest memory address.

By reading the value in little-endian, I obtained 0x15DC, which equals 5,596. It didn’t take long for me to realize that if I took my card balance (€27.98) in cents, I would get 2,798, which is exactly half of 5,596.

With this, I had successfully identified the specific bytes holding the balance, where the value represents twice the actual card balance in cents and is stored in little-endian format.

4.1 Modifying the Balance Field

Once I had a clear understanding of the card’s data structure and identified the bytes storing the balance, I began a trial-and-error process to see if I could modify the balance without breaking the card.

I calculated that if I wanted to set the balance to €50, it would be stored as 10,000. In hexadecimal this is 0x2710, and since the bytes are stored in little-endian format, the final modified block would look like this:

After using my Proxmark3 to modify the card, I attempted to verify the new balance using the city’s official transit application, expecting to see €50. However, the app returned a reading error and failed to display the modified balance.

This confirmed that I was still missing a critical piece of the puzzle. The fact that the official app rejected the card—despite the raw bytes being changed—was a clear indicator that an integrity check (likely a checksum) was in place invalidating my modification because the data didn’t match the expected signature. This led me to investigate further.

I was certain that there had to be a checksum validating the card’s balance. So, I continued analyzing the dump, this time looking for bytes that changed along with the balance and had some sort of mathematical relationship. Surprisingly, it took me half the time to find the checksum and understand its logic than it did to find the balance itself.

4.2 Understanding and Bypassing the Checksum

For those who have been paying attention, you might have noticed that in the screenshot of the block that stores the balance, there was another byte that changed apart from the balance bytes.

Knowing that the balance bytes were stored in little-endian format, I assumed the checksum would be as well. So, I decided to convert 0xFFFFEA23 to decimal, which resulted in 4,294,961,699—an extremely large number that didn’t seem to have any obvious relation to the balance. That was until I went back and checked the previous dumps I had made after each transaction.

I discovered that every time I made a transaction, the exact amount deducted from the balance was added to the checksum. This inverse relationship led me to suspect a logical operation rather than a complex algorithm.

Not long after, I realized that the checksum was simply the bitwise NOT (or 1’s complement) of the balance. In binary arithmetic, this is equivalent to XORing the balance bytes with 0xFFFF (the two fixed 0xFF 0xFF bytes visible next to the checksum bytes). Looking at the image above, if you were to XOR 0xDC15 with 0xFFFF, you would, unsurprisingly, get 0x23EA, exactly the checksum value associated with that balance value.

4.4 Testing the Modified Card

Finally, the moment of truth arrived. The only way to verify if my analysis of the checksum logic was accurate was to check the current balance of the card using that city’s transport application again. After writing the modified balance and checksum to the card using my Proxmark3, I verified the card state using the transit application, which accepted the modified data and correctly displayed the new balance.

This confirmed that the custom checksum logic was valid and that the card’s data structure was fully reverse-engineered.