Flipper Zero NFC Hacking - cannon fooder

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                             |
        |                                                  |
        | |
        |                                                  |
        | |
        |                                                  |
        | |
        | E0 50 BC A5                                      |
        |                                                  |
        | |    
        | D0 73 87                                         |
        |                                                  |
        | |
        | 0200A404000E325041592E5359532E444446303100E042   |
        |                                                  |
        | 



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

<h2>
  
  
  4 - Flipper Zero implementation
</h2>

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

<p>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.</p>

<p>The Flipper provides the function furi_hal_nfc_iso14443a_listener_set_col_res_data to handle all of this.</p>

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

• 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.

+----------------+                                  +----------------+
|   Reader       |                                  |   Card         |
+----------------+                                  +----------------+
        |                                                  |
    Field activation                                       |
        |                                                  |
        | --- REQA (Request Command Type A) -------------> |
        |                   26                             |
        |                                                  |
        | |
        |                                                  |
        | |
        |                                                  |
        | |
        | E0 50 BC A5                                      |
        |                                                  |
        | |    
        | D0 73 87                                         |
        |                                                  |
        | |
        | 0200A404000E325041592E5359532E444446303100E042   |
        |                                                  |
        | 



<p>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.</p>

<p>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.<br>
</p>

<pre class="brush:php;toolbar:false">    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, 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.

FuriHalNfcEvent event = furi_hal_nfc_listener_wait_event(100);

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.

    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) {

• 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.

+----------------+                                  +----------------+
|   Reader       |                                  |   Card         |
+----------------+                                  +----------------+
        |                                                  |
    Field activation                                       |
        |                                                  |
        | --- REQA (Request Command Type A) -------------> |
        |                   26                             |
        |                                                  |
        | |
        |                                                  |
        | |
        |                                                  |
        | |
        | E0 50 BC A5                                      |
        |                                                  |
        | |    
        | D0 73 87                                         |
        |                                                  |
        | |
        | 0200A404000E325041592E5359532E444446303100E042   |
        |                                                  |
        | 



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

• 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.

    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;
    }

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.

FuriHalNfcEvent event = furi_hal_nfc_listener_wait_event(100);

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.

+----------------+                                  +----------------+
|   Reader       |                                  |   Card         |
+----------------+                                  +----------------+
        |                                                  |
    Field activation                                       |
        |                                                  |
        | --- REQA (Request Command Type A) -------------> |
        |                   26                             |
        |                                                  |
        | |
        |                                                  |
        | |
        |                                                  |
        | |
        | E0 50 BC A5                                      |
        |                                                  |
        | |    
        | D0 73 87                                         |
        |                                                  |
        | |
        | 0200A404000E325041592E5359532E444446303100E042   |
        |                                                  |
        | 



<h3>
  
  
  6.3 A little bit of Proxmark as well
</h3>

<p><img src="/static/imghwm/default1.png" data-src="https://img.php.cn/upload/article/000/000/000/172964254814325.jpg?x-oss-process=image/resize,p_40" class="lazy" alt="Flipper Zero NFC Hacking - cannon fooder"></p>

<p>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.<br>
</p>

<pre class="brush:php;toolbar:false">    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;
    }

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!

The above is the detailed content of Flipper Zero NFC Hacking - cannon fooder. For more information, please follow other related articles on the PHP Chinese website!