Heim >Backend-Entwicklung >Python-Tutorial >Flipper Zero NFC Hacking – Kanonenfutter
In einem früheren Beitrag haben wir gesehen, wie man mit dem Flipper Zero einen transparenten Leser implementiert. Was wäre, wenn wir das gleiche Konzept verfolgen, dieses Mal jedoch einen transparenten Kartenemulator implementieren? Wir könnten unseren Flipper Zero wie eine Kanone einsetzen, um digitale Festungen wie Lesegeräte oder Smartphones anzugreifen, indem wir fehlerhafte Anfragen senden. Fehlerhafte Befehle, im Lebenszyklus nicht erwartete Befehle, Fuzzing, Pufferüberlauf – es gibt keine Grenzen!
Genau wie beim transparenten Kartenleser möchte ich mit dem Flipper über seine serielle CLI von meinem Computer aus kommunizieren. Der Computer übernimmt die gesamte Logik, d. h. er entscheidet abhängig vom Befehl, welche Antwort gegeben werden soll, beispielsweise mithilfe eines Python-Skripts.
Was nun die Implementierung der Kartenemulatorbefehle betrifft, handelt es sich im Wesentlichen um eine Art Spiegelmodus im Vergleich zum Lesegerät:
Außer es gibt ein kleines Detail, das die Sache verkompliziert. Denken Sie daran, dass bei der Kommunikation zwischen Karte und Lesegerät das Lesegerät als Master fungiert, das heißt, es ist derjenige, der die Kommunikation initiiert und Befehle sendet.
Wenn wir also einen Kartenemulator erstellen, muss dieser auf Ereignisse vom Lesegerät warten. Man kann es sich wie einen Server vorstellen, bei dem der Leser als Client fungiert. Wir müssen dies in den Flipper Zero codieren.
Okay, lassen Sie uns zunächst einen kurzen Rückblick auf den Kommunikationsaustausch zwischen einem Lesegerät und einer Karte unter Verwendung von ISO 14443-A geben.
Hier ist ein Diagramm, das die wichtigsten Austauschvorgänge zwischen einem Lesegerät und einer Karte zusammenfasst, die über ISO 14443-A kommunizieren.
+----------------+ +----------------+ | 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 |
Jetzt stellt sich die Frage: „Wie setzen wir das alles auf dem Flipper um?“
Wie in meinem vorherigen Artikel werde ich die Datei „applications/main/nfc/nfc_cli.c“ weiter erweitern (siehe die Datei in meinem Zweig).
Zunächst ein kurzer Hardware-Punkt. Für die NFC-Verwaltung nutzt der Flipper Zero den ST25R3916-Chip. Das ist großartig, denn es ermöglicht uns, sowohl ein kontaktloses Lesegerät als auch einen Kartenemulator zu entwickeln. Der Chip übernimmt automatisch die Übertragung der beteiligten Befehle von der Feldaktivierung bis zur Antikollision. Wir müssen lediglich die ATQA, SAK, UID und deren Länge angeben, die wir zurücksenden möchten.
Der Flipper stellt die Funktion furi_hal_nfc_iso14443a_listener_set_col_res_data zur Verfügung, um all dies zu bewältigen.
Deshalb habe ich der NFC-CLI des Flippers drei Befehle hinzugefügt, um diese Elemente zu konfigurieren:
Und kurz bevor wir mit der Emulation beginnen, rufen wir furi_hal_nfc_iso14443a_listener_set_col_res_data mit diesen Parametern auf.
+----------------+ +----------------+ | 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 |
Als nächstes wird der Flipper Zero mit der Funktion furi_hal_nfc_set_mode in den Kartenemulatormodus versetzt. Dieses Mal geben wir den Modus FuriHalNfcModeListener an und für die Technologien verwenden wir die Standardwerte: FuriHalNfcTechIso14443a, FuriHalNfcTechIso14443b und FuriHalNfcTechIso15693.
Um die Emulation zu starten, habe ich schließlich den Befehl run_emu implementiert, der eine Endlosschleife initiiert, die auf einen Leser in der Nähe wartet. Die Ereignisüberwachung erfolgt durch die Funktion furi_hal_nfc_listener_wait_event.
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; }
Als nächstes kann das Ereignis mehrere Werte annehmen, je nachdem, was erkannt wurde:
FuriHalNfcEvent event = furi_hal_nfc_listener_wait_event(100);
Jetzt wollen wir sehen, wie wir mit dem Empfang des Befehls und dem Senden der Antwort umgehen.
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) {
Dann sendet das Terminal eine Antwort, die wir mit der Funktion nfc_emu_get_resp(cli, rx_cmd) abrufen. Dieser Teil ist etwas knifflig, da es bei einem Shell-Befehl normalerweise nicht zu einem Hin- und Her-Austausch kommt. Also verwende ich die Funktion cli_getc(cli), um ein Zeichen zu lesen.
Schließlich konvertieren wir die hexadezimale Zeichenfolge mit unhexify(tmp, (uint8_t*)bit_buffer_get_data(rx_data), len); in ein uint8_t-Array.
Bei Bedarf fügen wir einen CRC mit add_crc hinzu.
Zuletzt können wir die Antwort an den Leser senden mit:
FuriHalNfcError r = furi_hal_nfc_listener_tx(rx_data, bit_buffer_get_size(rx_cmd));.
Und wie können wir das alles nun validieren?
Nun, wir könnten unseren transparenten Reader aus dem vorherigen Beitrag verwenden, um unseren Emulator zu validieren. Wir bräuchten also zwei Flipper Zeros ... die ich nicht habe. Allerdings habe ich einen Hydra NFC v2, der eine transparente Leseeinrichtung ermöglicht.
Ich muss nur ein Skript von pynfc verwenden.
+----------------+ +----------------+ | 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 |
Es ist sehr praktisch, weil es uns ermöglicht, Befehle einzeln zu senden, um alles zu validieren:
In Wirklichkeit ist die Kommunikation jedoch etwas komplizierter. Deshalb habe ich einen PC/SC-Leser, den ACR122U, zum Senden/Empfangen eines vollständigen APDU-Befehls in Kombination mit einem Python-Skript (unter Verwendung von pyscard ) verwendet, um einen Test in der realen Welt durchzuführen.
In meinem Fall wähle ich einfach die PPSE-Anwendung aus.
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; }
Jetzt muss der Kartenemulator also noch viel mehr Ereignisse verarbeiten. Daher habe ich unten ein Python-Skript erstellt, um diesen Fall zu verwalten. Es gibt viel zu erklären, beispielsweise die verschiedenen Arten von TPDU (i-Block, R-Block, S-Block), aber das wird in einem zukünftigen Blog-Beitrag behandelt.
FuriHalNfcEvent event = furi_hal_nfc_listener_wait_event(100);
Damit funktioniert es sehr gut und die Emulation ist äußerst stabil. Ich kann den Flipper am Lesegerät platzieren oder daraus entfernen und die Befehle mehrmals senden, und es funktioniert jedes Mal. Auch hier verfügt der Flipper über eine hervorragende Implementierung seiner NFC-Schicht und seine API ermöglicht viele Funktionen mit minimalem Implementierungsaufwand.
Unten finden Sie ein Beispiel der Ausgabe des Python-Skripts.
+----------------+ +----------------+ | 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 |
Die Verwendung des Proxmark 3 erwies sich als nützlich für das Debuggen der Kommunikation im Sniffing-Modus: Ich platzierte ihn zwischen dem Lesegerät und der Karte (bei der es sich um eine echte Karte oder den Flipper handeln konnte) und konnte den Datenaustausch überprüfen.
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; }
Gut, was kommt als nächstes?
Das obige ist der detaillierte Inhalt vonFlipper Zero NFC Hacking – Kanonenfutter. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!