Dans les festivals de musique, les parcs d'attractions, les stades sportifs et les foires populaires du monde entier, le même objet a progressivement remplacé les billets en papier et les espèces : un bracelet au poignet. Il est à la fois billet d'entrée et portefeuille numérique. On y charge des jetons, on paie boissons et repas en approchant le poignet d'un terminal. Pratique, rapide, sans manipulation d'argent liquide. Ce modèle se déploie aussi bien à Lagos qu'à Abidjan, à Dakar, à Casablanca, à Paris ou à São Paulo.
Mais que se passe-t-il réellement à l'intérieur de cette puce ? Qui contrôle ce qui est écrit dedans ? Peut-on la manipuler ? C'est la question que s'est posée le chercheur en sécurité Luigi Gubello. Ce qu'il a trouvé est à la fois simple, élégant et préoccupant : une vulnérabilité de rejeu permettant de recharger le solde du bracelet à l'infini, sans aucune connaissance cryptographique, en reproduisant simplement une opération légitime déjà capturée.
Cette recherche, publiée début juin 2026, illustre une vérité trop souvent ignorée dans la sécurité des systèmes embarqués et des objets connectés : les bugs logiques sont rares, discrets, et souvent dévastateurs.
| Chercheur | Luigi Gubello |
| Date de publication | Juin 2026 |
| Matériel ciblé | Bracelet NFC à puce NXP NTag (NTag213 / 215 / 216) |
| Vecteur d'attaque | NFC (Near Field Communication) — sans contact, portée < 10 cm |
| Type de vulnérabilité | Vulnérabilité de rejeu (Replay Attack) — bug logique |
| Prérequis | Application Android dépaquetée, smartphone NFC, bracelet cible |
| Complexité d'exploitation | Faible — aucune exploitation cryptographique requise |
| Impact | Rechargement illimité du solde en jetons sans paiement |
| CVE assigné | Non communiqué (recherche académique / divulgation responsable) |
Comment fonctionne un bracelet NFC de festival
Pour comprendre la faille, il faut d'abord comprendre le système. Un bracelet de festival repose sur une puce NFC de la famille NXP NTag — NTag213, NTag215 ou NTag216 selon le fabricant. Ces puces sont des mémoires EEPROM passives : elles n'ont pas de batterie propre, elles s'alimentent par induction au moment où un lecteur NFC les approche. Elles stockent des données dans une mémoire organisée en pages de 4 octets.
Le scénario d'usage est simple : à l'entrée du festival, le personnel charge un solde de départ sur le bracelet. Quand un participant veut payer un verre ou un repas, il approche son bracelet du terminal du stand. L'application du stand lit la mémoire de la puce, déduit le montant, et écrit le nouveau solde. Quand le participant veut recharger son bracelet, il utilise l'application Android officielle ou un kiosque de rechargement.
La structure mémoire du NTag — ce que le chercheur a découvert
En dumpant et analysant le contenu de la mémoire du NTag, Luigi Gubello a cartographié l'organisation des données transactionnelles. Chaque transaction occupe 3 slots de 4 octets, organisés ainsi :
| Adresse | Contenu | Rôle |
|---|---|---|
| [07] – [09] | Données de transaction actives | Solde en jetons (3 premiers octets) · Timestamp Unix (4 derniers octets) · 5 octets intermédiaires (signature potentielle) |
| [02] | Lock Bytes | Valeur par défaut — non utilisés, non protégés |
| [03] | Capability Counter | Valeur par défaut — non utilisé |
| [28] – [2A] | Slots opérateurs de stand | Protégés par mot de passe — accès restreint |
| [E2] – [E4] | Configuration d'authentification | [E2] : 00 00 00 BD · [E3] : 04 00 00 28 · [E4] : 07 00 — brute-force bloqué après 7 tentatives |
L'investigation technique : reverse engineering de l'application Android
La puce seule ne suffit pas. Pour comprendre comment les données y sont écrites, Luigi Gubello s'est attaqué à l'application Android officielle du système de paiement. L'objectif : comprendre la logique de rechargement.
Étape 1 — dépaquetage de l'APK
Un fichier APK Android est une archive ZIP. Il suffit de le décompresser pour accéder aux classes compilées au format DEX (Dalvik Executable). Ces classes peuvent ensuite être décompilées en code Java lisible à l'aide d'outils comme jadx, apktool ou JADX-GUI.
Le code source reconstitué révèle la logique de communication avec la puce NFC : quelles pages sont lues, lesquelles sont écrites, dans quel ordre, et avec quelles données.
Étape 2 — analyse de la logique de rechargement
En analysant le code décompilé, le chercheur a identifié la séquence exacte que l'application exécute lors d'une opération de rechargement : lecture du solde actuel, calcul du nouveau solde, écriture sur les pages mémoire concernées, mise à jour du timestamp.
Ce que l'analyse révèle est critique : aucune validation côté serveur n'est effectuée après l'écriture. Le serveur distant délivre une autorisation de rechargement, mais ne vérifie pas ensuite que l'opération n'est pas rejouée. Toute la logique de sécurité repose sur la transaction initiale.
Étape 3 — capture et rejeu de la transaction
Armé de cette compréhension, le chercheur a capturé l'état exact de la mémoire NTag avant et après un rechargement légitime. Il a ensuite développé une application Android modifiée capable de rejouer cette écriture — c'est-à-dire de réécrire les mêmes octets aux mêmes adresses, sans passer par le serveur de rechargement.
Le résultat est limpide : en rejouant l'écriture d'un rechargement légitime, le solde est restauré à son niveau post-rechargement, indéfiniment et sans frais. La même séquence d'octets peut être rejouée autant de fois que souhaité, produisant le même résultat à chaque fois.
Pourquoi ce bug est particulièrement insidieux
Les bugs logiques sont différents des vulnérabilités classiques. Ils n'exploitent aucune faiblesse cryptographique, aucun débordement de mémoire, aucun protocole cassé. Ils exploitent une erreur de conception dans la logique applicative.
Dans ce cas précis, plusieurs hypothèses de sécurité ont été violées simultanément :
- Hypothèse de fraîcheur : le système suppose implicitement qu'une transaction légitime ne peut pas être reproduite. Cette propriété n'est garantie par aucun mécanisme technique sur la puce (nonce, compteur d'écriture vérifié côté serveur, MAC horodaté).
- Hypothèse de séparation client/opérateur : le format de transaction est identique pour les clients et les stands. Seul le mot de passe protège les slots opérateurs — et ce mot de passe est stocké en clair dans une zone mémoire accessible après reverse engineering.
- Hypothèse de validation côté serveur : la sécurité est supposée garantie par l'autorisation initiale du serveur. Mais une fois que l'autorisation est donnée, rien ne l'invalide ni ne la limite à une seule exécution.
Ce que ce type d'attaque exige en pratique
Il est important de calibrer la dangerosité réelle de cette vulnérabilité. Elle n'est pas triviale à exploiter pour n'importe qui dans la rue, mais elle est parfaitement accessible à quelqu'un disposant de connaissances intermédiaires en sécurité mobile.
- Obtenir l'APK de l'application : disponible sur le Play Store ou via extraction depuis un appareil Android.
- Décompiler et analyser : avec jadx ou apktool, accessible gratuitement. Quelques heures de travail pour un analyste expérimenté.
- Effectuer un rechargement légitime : acheter un rechargement réel pour capturer la séquence d'écriture NFC.
- Rejouer la séquence : via une application Android modifiée ou un outil NFC généraliste comme NFC Tools Pro.
- Répéter : aucune limite technique n'empêche la répétition de l'opération.
L'attaque ne nécessite pas d'équipement spécifique au-delà d'un smartphone Android avec NFC. Elle ne laisse aucune trace visible côté serveur si ce dernier ne journalise pas les écritures directes sur puce.
Les mesures de sécurité qui auraient dû être en place
Du point de vue de la conception sécurisée des systèmes embarqués, plusieurs contre-mesures auraient pu neutraliser cette attaque :
Côté protocole NFC
- Compteur d'écriture vérifié côté serveur : les NTag216 disposent d'un compteur monotone non réinitialisable. Ce compteur aurait dû être journalisé côté serveur et vérifié à chaque transaction pour détecter une tentative de rejeu.
- NDEF avec signature asymétrique : utiliser une signature à clé publique sur les données de transaction, avec invalidation côté serveur à chaque utilisation.
- Nonce serveur : intégrer un jeton à usage unique délivré par le serveur dans chaque écriture, rendant la transaction non rejouable sans communication réseau.
Côté application Android
- Obfuscation et durcissement : ProGuard, R8 ou des solutions de protection applicative (RASP) auraient considérablement ralenti le reverse engineering.
- Certificate pinning et attestation d'intégrité : empêcher les applications modifiées de communiquer avec le backend.
- Validation côté serveur obligatoire pour chaque écriture NFC : ne jamais déléguer la confiance à la seule puce ou à la seule application cliente.
Côté architecture système
- Journalisation des transactions à la source : chaque écriture sur puce devrait générer un événement côté serveur, avec vérification de cohérence (solde, séquence, horodatage).
- Modèle de sécurité explicite dès la conception : identifier qui écrit quoi sur la puce, dans quelles conditions, avec quelle autorisation, et comment détecter une anomalie.
Un enjeu de gouvernance : la sécurité par conception comme exigence universelle
Cette vulnérabilité n'est pas un accident isolé. Elle reflète un problème structurel dans la conception des systèmes de paiement embarqués sur puce NFC : la sécurité est souvent traitée comme une couche ajoutée après-coup, plutôt que comme une exigence fondamentale de l'architecture.
Quel que soit le pays où un tel système est déployé, les mêmes questions de fond se posent : qui est responsable de la sécurité du protocole applicatif ? Le fabricant du matériel ? L'éditeur de l'application ? L'opérateur de l'événement ? En l'absence de cadre contractuel ou réglementaire clair, la réponse est souvent : personne, jusqu'à l'incident.
Certains marchés commencent à répondre à cette question par la réglementation. En Europe, le Cyber Resilience Act (CRA) — entré en vigueur en 2024, avec des exigences essentielles applicables progressivement jusqu'en 2027 — impose aux fabricants de produits comportant des éléments numériques d'intégrer la sécurité dès la conception (security by design) et par défaut (security by default). Un système de paiement NFC de festival entre dans le champ d'application de ce règlement : l'absence de protection contre les attaques par rejeu y constituerait une non-conformité documentable, et le fabricant serait tenu de démontrer une analyse des risques, des contre-mesures implémentées, et un engagement de mise à jour sur la durée de vie du produit.
Mais le CRA est un règlement européen. Il ne s'applique pas directement en Afrique subsaharienne, au Maghreb ou au Moyen-Orient. Cela ne signifie pas que ces marchés sont sans recours — cela signifie que la responsabilité de poser ces exigences repose sur d'autres acteurs : les acheteurs publics, les régulateurs nationaux, et les organismes d'homologation.
Les systèmes de paiement cashless sur NFC connaissent une croissance rapide en Afrique : festivals de musique au Sénégal, au Cameroun et en Côte d'Ivoire, événements sportifs en Égypte, au Maroc et en Afrique du Sud, foires et expositions au Nigeria et au Kenya. Dans la quasi-totalité des cas, le matériel — les puces NXP NTag, les terminaux de lecture, les serveurs de gestion — est importé. L'application Android est développée par un prestataire externe. L'organisation achète une solution clé en main, souvent sur la base d'une démonstration fonctionnelle, sans audit de sécurité préalable.
Cette configuration reproduit exactement le schéma de vulnérabilité mis en évidence par Luigi Gubello : une logique applicative non auditée, une puce dont la mémoire n'est pas protégée côté serveur, et aucune exigence contractuelle de sécurité opposable au fournisseur.
Pour les régulateurs africains — dont les autorités de régulation des communications électroniques (ARCE, ARCEP, ANRT, ARTP, NCA…) qui intègrent progressivement des volets cybersécurité dans leurs procédures d'homologation — ce type de faille est un argument concret pour étendre les critères d'évaluation au-delà de la conformité radio. La conformité aux normes de transmission (ISO/IEC 14443, ETSI EN 300 330) est nécessaire ; elle ne suffit pas. La sécurité du protocole applicatif et la résistance aux attaques par rejeu devraient figurer explicitement dans les grilles d'homologation des équipements de paiement embarqués.
Ce que les opérateurs et acheteurs doivent retenir
La recherche de Luigi Gubello pose des questions pratiques immédiates pour quiconque déploie ou achète un système de paiement NFC :
- Le fournisseur peut-il fournir un modèle de menace documenté pour le système NFC ?
- Quelle protection est en place contre les attaques par rejeu ? Est-elle implémentée côté puce, côté application, côté serveur — ou sur les trois niveaux ?
- Les transactions sont-elles journalisées côté serveur avec vérification de cohérence ?
- L'application Android a-t-elle été soumise à un test de pénétration ou à une revue de code sécurité ?
- Le système dispose-t-il d'un mécanisme de détection des anomalies de rechargement ?
- Le fournisseur publie-t-il des mises à jour de sécurité ? Selon quelle fréquence et quel engagement contractuel ?
Conclusion
La vulnérabilité découverte par Luigi Gubello est remarquable à plus d'un titre. Elle ne repose sur aucune faiblesse cryptographique avancée. Elle ne nécessite aucun équipement spécialisé. Elle n'exploite aucune faille zero-day dans le protocole NFC. Elle exploite une erreur de conception logique — l'absence de mécanisme d'invalidation des transactions — dans un système qui gère de l'argent réel.
C'est précisément ce qui la rend instructive. Les systèmes embarqués et les objets connectés à usage transactionnel sont souvent conçus avec une priorité donnée à l'expérience utilisateur, à la performance, et au coût. La sécurité est fréquemment traitée comme une contrainte secondaire, adressée a posteriori.
Or, dès lors qu'un équipement physique gère de la valeur — monétaire, d'accès, ou d'identité — il devient une cible. Et une cible non sécurisée par conception n'est pas seulement un risque pour l'opérateur : c'est un risque pour l'ensemble de la confiance dans les systèmes numériques.
Sources & références
- Denis Laskov — Eye on Cyber : Hacking an NFC wristband for free tokens Substack · Denis Laskov (@it4sec) · 6 juin 2026 — présentation et analyse de la recherche de Luigi Gubello sur la vulnérabilité de rejeu NFC.
- Luigi Gubello — Reversing An Android Application To Hack Transactions On An NFC Tag YouTube · démonstration vidéo complète : reverse engineering de l'APK, analyse de la mémoire NTag, exploitation par rejeu.
- NXP Semiconductors — NTAG213 / 215 / 216 Product Data Sheet nxp.com — spécifications techniques officielles de la famille NTag : organisation mémoire, protection par mot de passe, brute-force protection (NFC_CNT).
- Règlement (UE) 2024/2847 — Cyber Resilience Act EUR-Lex — exigences horizontales de cybersécurité pour les produits comportant des éléments numériques. Applicable aux systèmes de paiement embarqués NFC.
- Android Developer Documentation — NFC Tag Technologies (MifareUltralight / NfcA) developer.android.com — référence de l'API Android pour la communication NFC bas niveau avec les puces de type NTag / MifareUltralight.
- OWASP Mobile Application Security Verification Standard (MASVS) owasp.org — référentiel de sécurité des applications mobiles : résistance au reverse engineering, sécurité des communications NFC, validation côté serveur.