Dans un précédent post, nous avons vu comment mettre en place un lecteur transparent avec le Flipper Zero. Et si on reprenait le même concept mais cette fois pour implémenter un émulateur de carte transparent ? Nous pourrions utiliser notre Flipper Zero comme un canon pour attaquer des forteresses numériques, comme les lecteurs ou les smartphones, en envoyant des requêtes erronées. Commandes mal formées, commandes non attendues dans le cycle de vie, fuzzing, débordement de tampon : tout est possible !
Tout comme avec le lecteur de carte transparent, je souhaite communiquer avec le Flipper en utilisant sa CLI série depuis mon ordinateur. L'ordinateur gère toute la logique, c'est-à-dire qu'il décide quelle réponse donner en fonction de la commande, à l'aide d'un script Python par exemple.
Maintenant, concernant l'implémentation des commandes de l'émulateur de carte, il s'agit essentiellement d'une sorte de mode miroir par rapport au lecteur :
Sauf qu'il y a un petit détail qui complique les choses. N'oubliez pas que lors de la communication carte/lecteur, c'est le lecteur qui fait office de maître, c'est-à-dire que c'est lui qui initie la communication et envoie les commandes.
Donc, si nous créons un émulateur de carte, il doit attendre les événements du lecteur. Vous pouvez le considérer comme un serveur, le lecteur agissant en tant que client. Nous devrons coder cela dans le Flipper Zero.
Très bien, tout d'abord, faisons un petit récapitulatif des échanges de communication entre un lecteur et une carte selon la norme ISO 14443-A.
Voici un schéma qui résume les principaux échanges entre un lecteur et une carte communiquant 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 |
Maintenant, la question est : « Comment implémenter tout cela sur le Flipper ? »
Comme dans mon article précédent, je vais continuer à étendre le fichier applications/main/nfc/nfc_cli.c (voir le fichier sur ma branche ).
Tout d’abord, un petit point sur le matériel. Pour la gestion NFC, le Flipper Zero utilise la puce ST25R3916. C'est génial car cela nous permet de créer à la fois un lecteur sans contact et un émulateur de carte. La puce gère automatiquement l'envoi des commandes impliquées depuis l'activation du champ jusqu'à l'anticollision. Tout ce que nous avons à faire est de spécifier l'ATQA, le SAK, l'UID et sa longueur que nous souhaitons renvoyer.
Le Flipper fournit la fonction furi_hal_nfc_iso14443a_listener_set_col_res_data pour gérer tout cela.
C'est pourquoi j'ai ajouté 3 commandes à la CLI NFC du Flipper pour configurer ces éléments :
Et juste avant de démarrer l'émulation, on appellera furi_hal_nfc_iso14443a_listener_set_col_res_data avec ces paramètres.
+----------------+ +----------------+
| 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 |
Ensuite, le réglage du Flipper Zero en mode émulateur de carte se fait à l'aide de la fonction furi_hal_nfc_set_mode. Cette fois, nous précisons le mode FuriHalNfcModeListener, et pour les technologies, nous utilisons les valeurs standards : FuriHalNfcTechIso14443a, FuriHalNfcTechIso14443b, et FuriHalNfcTechIso15693.
Enfin, pour démarrer l'émulation, j'ai implémenté la commande run_emu, qui va initier une boucle infinie en attendant un lecteur à proximité. La surveillance des événements est gérée par la fonction 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;
}
Ensuite, l'événement peut prendre plusieurs valeurs selon ce qui a été détecté :
FuriHalNfcEvent event = furi_hal_nfc_listener_wait_event(100);
Voyons maintenant comment gérer la réception de la commande et l'envoi de la réponse.
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) {
Ensuite, le terminal envoie une réponse que l'on récupère grâce à la fonction nfc_emu_get_resp(cli, rx_cmd). Cette partie est un peu délicate car, dans une commande shell, vous n’avez généralement pas d’échange aller-retour. J'utilise donc la fonction cli_getc(cli) pour lire un caractère.
Enfin, nous convertissons la chaîne hexadécimale en un tableau uint8_t en utilisant unhexify(tmp, (uint8_t*)bit_buffer_get_data(rx_data), len);.
Si nécessaire, on ajoute un CRC en utilisant add_crc.
Enfin, nous pouvons envoyer la réponse au lecteur en utilisant :
FuriHalNfcError r = furi_hal_nfc_listener_tx(rx_data, bit_buffer_get_size(rx_cmd));.
Et maintenant, comment fait-on pour valider tout ça ?
Eh bien, nous pourrions utiliser notre lecteur transparent du post précédent pour valider notre émulateur. Nous aurions donc besoin de deux Flipper Zeros... ce que je n'ai pas. Cependant, je possède un Hydra NFC v2, qui permet une configuration de lecteur transparente.
J'ai juste besoin d'utiliser un script de pynfc.
+----------------+ +----------------+
| 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 |
C'est très pratique car cela permet d'envoyer les commandes une à une pour tout valider :
Cependant, en réalité, les communications sont un peu plus compliquées. J'ai donc utilisé un lecteur PC/SC, l'ACR122U, pour envoyer/recevoir une commande APDU complète, en combinaison avec un script Python (utilisant pyscard ) pour faire un test réel.
Dans mon cas, je sélectionne simplement l'application PPSE.
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;
}
Alors maintenant, l'émulateur de carte doit gérer beaucoup plus d'événements. Par conséquent, j'ai créé un script Python ci-dessous pour gérer ce cas. Il y a beaucoup de choses à expliquer, comme les différents types de TPDU (i-block, r-block, s-block), mais cela sera dans un prochain article de blog.
FuriHalNfcEvent event = furi_hal_nfc_listener_wait_event(100);
Avec ça, ça marche très bien, et l'émulation est extrêmement stable. Je peux placer ou retirer le Flipper du lecteur et envoyer les commandes plusieurs fois, et cela fonctionne à chaque fois. Encore une fois, le Flipper a une excellente implémentation de sa couche NFC, et son API permet de nombreuses fonctionnalités avec un minimum d'effort dans la mise en œuvre.
Ci-dessous, vous avez un exemple de la sortie du script Python.
+----------------+ +----------------+
| 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 |
L'utilisation du Proxmark 3 a été utile pour déboguer la communication en mode sniffing : je l'ai placé entre le lecteur et la carte (qui pouvait être une vraie carte ou le Flipper), et j'ai pu vérifier les échanges de données.
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;
}
Bien, quelle est la prochaine étape ?
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
Caractères d'échappement JavaScript
Comment annuler le renouvellement automatique de la carte Taobao Money Saving
Comment utiliser la fonction de décodage
Méthode de détection des liens morts d'un site Web
Que signifie Jingdong plus ?
Langages informatiques
Comment fermer le port 135
Quels sont les avantages du framework Spring Boot ?
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
