Sans dongle, sans root, outil d'évaluation de sécurité Bluetooth pour écouteurs sans fil affectés par la chaîne de vulnérabilités du SDK Airoha (CVE-2025-20700/20701/20702)
Version 1.0.0
Outil d'évaluation de sécurité Bluetooth pour les écouteurs sans fil affectés par la chaîne de vulnérabilités du SDK Airoha (CVE-2025-20700 / CVE-2025-20701 / CVE-2025-20702). Il scanne les appareils à proximité, identifie les puces Airoha connues comme étant affectées grâce à leurs empreintes, et sonde l'accès GATT non authentifié et l'accessibilité du protocole RACE - entièrement via la pile Bluetooth du système d'exploitation (BlueZ) via bleak. Aucun dongle Bluetooth externe n'est requis et les droits root ne sont pas nécessaires. Les résultats sont rapportés en langage clair avec les détails techniques, afin que vous puissiez agir sans connaissance approfondie du Bluetooth.
Cet outil est destiné à évaluer les appareils que vous possédez ou dont vous avez l'autorisation explicite de tester. Les sondages GATT et RACE sont des opérations actives : ils se connectent à l'appareil cible et lui envoient des commandes. N'utilisez pas --gatt, --race, --firmware, --bd-address, --assess, --baseline, --check-drift ou --memory-read contre un appareil qui n'est pas le vôtre ou pour lequel vous n'avez pas obtenu l'autorisation de tester. --scan est passif et écoute uniquement les annonces déjà diffusées publiquement, il est donc sûr de l'exécuter contre tout appareil à portée.
--memory-read va plus loin que les autres sondes actives : il récupère une vraie page en lecture seule (256 octets) du contenu flash réel de l'appareil, à une adresse fixe, comme confirmation définitive de CVE-2025-20702 lorsque la sonde --race (qui ne teste que l'accessibilité) n'obtient aucune réponse. Il est en lecture seule (les lectures flash ne présentent aucun risque d'usure ou de brick, contrairement aux commandes d'écriture/effacement/FOTA, que cet outil n'envoie jamais), optionnel, et nécessite sa propre confirmation séparée au-delà de l'invite de propriété standard, décrivant exactement ce qu'il fait avant d'exécuter quoi que ce soit.
Sonder un appareil voisin arbitraire n'est pas seulement une question de politique - cela peut avoir de réels effets secondaires. --gatt tente une lecture ou un abonnement aux notifications sur chaque caractéristique qu'il trouve, et certains appareils grand public exposent des services de type provisionnement (par exemple le service Fast Pair de Google) qui réagissent en déclenchant une véritable négociation d'appairage sur l'appareil cible, indépendamment de ce que cet outil demande explicitement. Une caractéristique nécessitant un chiffrement peut déclencher la même chose, même contre votre propre appareil, car BlueZ peut acheminer silencieusement cette demande d'authentification vers l'agent que votre bureau a enregistré (par exemple l'invite d'appairage de KDE) - par conséquent, chaque commande active enregistre également son propre agent BlueZ temporaire qui rejette automatiquement toute demande de ce type pendant la durée de la sonde, de sorte qu'aucune invite d'appairage ne peut apparaître. Chaque commande active invite également à confirmer que l'adresse cible est bien la vôtre avant de faire quoi que ce soit sur la radio ; passez --yes pour ignorer l'invite en cas d'utilisation scriptée après avoir déjà confirmé qu'il s'agit de votre appareil :
buds_audit.py --assess --target AA:BB:CC:DD:EE:FF --yes
--watch est passif, comme --scan - il écoute uniquement les annonces déjà diffusées et ne se connecte jamais à quoi que ce soit, donc il ne demande pas de confirmation.
python3 -m venv venv
venv/bin/pip install -r requirements.txt
Nécessite Python 3.10+ (développé avec la version 3.14) et un système Linux exécutant BlueZ avec un adaptateur Bluetooth allumé.
Linux uniquement, et pas automatiquement tous les systèmes Linux :
bleak lui-même a un backend Windows, mais cet outil ne repose pas uniquement sur bleak - la découverte Bluetooth Classic (core/scanner.py) et les vérifications d'état d'appairage (core/gatt.py) utilisent toutes deux directement bluetoothctl en ligne de commande, un outil CLI propre à BlueZ qui n'existe pas sur Windows. Ces chemins de code échoueraient simplement avec « commande introuvable ».bluetoothctl dans le PATH, pas seulement n'importe quel noyau Linux. La plupart des distributions de bureau l'incluent ; une image minimale ou serveur sans le paquet bluez installé ne l'aura pas par défaut. Vérifié sans root sur BlueZ 5.86 - d'autres versions devraient fonctionner de la même manière car bleak cible l'API D-Bus standard de BlueZ, mais cela n'a pas été revérifié indépendamment.usbipd-win, qui ne transfère que les adaptateurs connectés par USB. Le Bluetooth intégré de la plupart des ordinateurs portables est connecté via un bus non USB (SDIO/PCIe, avec le Wi-Fi), que usbipd-win ne peut généralement pas transférer - cela dépend donc entièrement du matériel spécifique.Vous n'avez pas besoin d'une machine Linux personnelle - vous avez juste besoin de Linux avec un accès réel à un adaptateur Bluetooth. Deux moyens pratiques pour y parvenir :
Dans les deux cas, la règle est la même : l'outil lui-même est inchangé - il a simplement besoin de Linux avec un adaptateur Bluetooth que BlueZ peut réellement atteindre.
De nombreux écouteurs TWS cessent d'émettre des annonces (et abandonnent toute connexion active) après une période d'inactivité pour économiser l'énergie, et certains s'éteignent complètement d'eux-mêmes. Si un scan ne trouve pas un appareil trouvé il y a une minute, ou si une sonde échoue en cours de route, c'est généralement que les écouteurs se sont mis en veille, pas un bug - sortez-les de leur boîtier ou appuyez à nouveau sur le bouton d'appairage et réessayez.
Cela affecte également la stabilité de l'adresse : l'unité de test confirmée de ce projet (un Sony WF-1000XM3) a conservé la même adresse BLE à chaque cycle d'alimentation testé, ce qui est attendu pour des écouteurs conçus pour la reconnexion via une application compagnon - ils utilisent généralement une adresse BLE fixe/publique plutôt que rotative (contrairement aux téléphones, qui font tourner les adresses privées et ne sont pas une cible appropriée pour cet outil pour cette raison). Ce n'est cependant pas garanti pour tous les modèles d'écouteurs - certains fabricants utilisent des adresses privées résolubles même en mode pré-appairage/reconnexion, ce qui apparaîtrait comme une adresse différente après chaque cycle d'alimentation pour un scanneur non appairé comme cet outil.
La sonde GATT (--gatt, et l'étape GATT de --assess) peut nécessiter plusieurs reconnexions si l'appareil possède des caractéristiques qui nécessitent un appairage - chacune fait en sorte que BlueZ tente (et que l'agent de cet outil rejette) une véritable négociation d'appairage avant de se reconnecter pour reprendre le balayage, et imprime une ligne de statut avant chaque tentative afin qu'un balayage lent ne semble pas bloqué. Lorsqu'un tel abonnement est rejeté, BlueZ conserve l'intention et la réémet à chaque connexion ultérieure à cet appareil ; pour éviter que cela ne perturbe les reconnexions suivantes, la sonde efface l'enregistrement en cache de l'appareil par BlueZ (équivalent à bluetoothctl remove) avant chaque reconnexion, de sorte que chaque tentative commence dans un état propre. Grâce à cela, des balayages consécutifs répétés contre l'appareil de test confirmé renvoient le même résultat complet à chaque fois. Une observation antérieure - une complétude semblant se dégrader au cours d'une session de tests intensifs et récupérer après une pause - ne s'est pas reproduite depuis, et est considérée comme ayant été la même accumulation d'état retenu plutôt qu'une fatigue de l'appareil.
buds_audit.py
L'exécuter sans aucun drapeau lance un menu numéroté au lieu de vous obliger à déjà connaître une adresse BLE ou quel drapeau fait quoi :
1) Analyse complète (scanner, exécuter l'audit CVE complet et enregistrer une référence)
2) Vérifier l'état actuel par rapport à une référence sauvegardée
3) Rechercher des appareils usurpés / d'imitation
4) Quitter
L'option 1 recherche les appareils affectés connus à proximité et les liste pour que vous puissiez en choisir un par numéro (plutôt que de taper une adresse MAC), exécute l'audit CVE complet (identique à --assess, y compris la requête d'adresse BD), et enregistre une référence (identique à --baseline) afin que les exécutions futures puissent détecter les changements. Elle pose également la même question de lecture mémoire à laquelle --assess --memory-read répond via son invite de confirmation - répondre oui inclut la même lecture réelle en lecture seule d'une page flash RACE décrite ci-dessus ; répondre non se contente d'exécuter l'audit sans elle, cela n'annule pas l'analyse complète. L'option 2 répertorie les appareils pour lesquels vous avez déjà créé une référence et revérifie celui que vous sélectionnez pour détecter une dérive (identique à --check-drift). L'option 3 est --watch. Chaque option passe toujours par la même confirmation de propriété que l'interface basée sur les drapeaux avant de toucher la radio - l'assistant est une interface plus conviviale pour les mêmes vérifications sous-jacentes, pas un chemin séparé et moins prudent.
L'interface basée sur les drapeaux ci-dessous est toujours présente pour une utilisation scriptée ou pour quiconque connaît déjà l'adresse qu'il souhaite cibler.
Toutes les commandes sont exécutées via venv/bin/python buds_audit.py.
buds_audit.py --help
Fonctionne avec un simple python3 buds_audit.py --help même sans venv ni dépendances installées - il n'importe bleak que lorsqu'une commande nécessitant réellement la radio est exécutée.
buds_audit.py --scan
buds_audit.py --scan --flags-only # only show devices matching the known-affected catalog
buds_audit.py --scan --target AA:BB:CC:DD:EE:FF
Scanne passivement les appareils BLE et Bluetooth Classic à proximité, identifie les puces Airoha à partir des données du fabricant et du préfixe d'adresse, et recoupe avec data/affected_devices.json.
Chacune de ces sondes nécessite --target ADDR et est une opération active contre cet appareil unique :
buds_audit.py --gatt --target AA:BB:CC:DD:EE:FF # CVE-2025-20700: unauthenticated GATT access
buds_audit.py --race --target AA:BB:CC:DD:EE:FF # CVE-2025-20702: RACE channel reachability
buds_audit.py --firmware --target AA:BB:CC:DD:EE:FF # CVE-2025-20701: passive firmware/pairing-bypass check
buds_audit.py --bd-address --target AA:BB:CC:DD:EE:FF # Classic BD address via RACE, informational
Les quatre sondes passent proprement (aucune erreur) si l'appareil est déjà appairé - une constatation d'« accès non authentifié » est dénuée de sens contre un appareil lié.
--gatt affiche désormais la valeur réelle renvoyée par chaque lecture ou notification non appairée réussie (encodée en hexadécimal), et pas seulement que la lecture a réussi - la valeur était déjà récupérée, donc cela ne présente aucun risque supplémentaire, elle n'est simplement plus ignorée.
--race ne teste que l'accessibilité (une requête d'informations SDK bénigne, pas d'accès mémoire) - un service RACE peut être présent et accepter l'écriture proprement mais ne pas répondre, ce qui est un résultat véritablement non concluant, et non une preuve que quoi que ce soit a été corrigé. Pour une réponse définitive, voir --memory-read ci-dessous.
--bd-address est informatif, pas une constatation de vulnérabilité en soi : il interroge la véritable adresse Bluetooth Classic (BR/EDR) de l'appareil via le même canal RACE non authentifié, avec le même niveau de risque que la requête de version de build de --firmware (une commande de métadonnées sans charge utile). Utile si vous souhaitez effectuer vous-même des tests actifs de CVE-2025-20701 avec un adaptateur/dongle compatible Classic, car cet outil n'a pas de transport Classic propre - voir la section Exigences matérielles ci-dessous.
buds_audit.py --memory-read --target AA:BB:CC:DD:EE:FF
Tente une véritable lecture en lecture seule d'une page flash RACE (256 octets, depuis une adresse fixe) pour une confirmation définitive de CVE-2025-20702 - utile lorsque --race trouve le service RACE présent mais sans réponse à sa requête bénigne. Ceci est optionnel et séparé de --race intentionnellement : un succès ici récupère le véritable contenu du firmware de l'appareil, et non pas seulement un signal oui/non sur l'accessibilité du canal. Il n'écrit jamais, n'efface pas, n'extrait pas de clés de liaison, et ne lit pas la RAM/les registres (seulement la flash, qui n'a pas d'effets secondaires en lecture) - voir les sections Phase 8 et Hors de portée de ROADMAP.md pour le raisonnement complet. Il nécessite sa propre confirmation séparée, décrivant exactement ce qu'il fait, au-delà de l'invite de propriété standard.
buds_audit.py --assess --target AA:BB:CC:DD:EE:FF
buds_audit.py --assess --target AA:BB:CC:DD:EE:FF --json result.json
buds_audit.py --assess --target AA:BB:CC:DD:EE:FF --memory-read
Exécute les sondes GATT, RACE, firmware et BD-address ci-dessus contre une cible et produit un verdict unique : PASS, PARTIAL, VULNERABLE ou SUSPECTED_COMPROMISE. Le verdict et chaque constatation individuelle sont imprimés avec une interprétation en langage clair à côté du détail technique, de sorte que le résultat soit lisible sans connaissance approfondie du Bluetooth - cet outil est destiné à quiconque vérifie ses propres appareils, pas seulement aux spécialistes en sécurité. --json écrit en plus le résultat complet (informations sur l'appareil, verdict et son explication en langage clair, indicateurs avec preuves et leur glossaire en langage clair, et notes de correction) dans un fichier. L'ajout de --memory-read intègre la confirmation de lecture mémoire dans le même audit et verdict, avec sa propre invite de confirmation séparée d'abord. La requête d'adresse BD s'exécute automatiquement dans le cadre de --assess (pas de drapeau séparé nécessaire, pas d'invite de confirmation supplémentaire) car elle a le même profil de risque faible de requête de métadonnées que la vérification du firmware.
--assess est délibérément limité à une seule cible, comme les sondes individuelles - il n'y a pas de mode « évaluer tous les appareils à portée », car cela signifierait sonder activement des appareils qui ne sont peut-être pas les vôtres.
buds_audit.py --baseline --target AA:BB:CC:DD:EE:FF
buds_audit.py --check-drift --target AA:BB:CC:DD:EE:FF
--baseline capture un instantané de confiance pour un appareil la première fois que vous l'évaluez - identité (nom et données du fabricant), table GATT, version du firmware RACE et état d'appairage local (booléens appairé/confiance/lié uniquement, jamais de matériel de clé) - et le stocke dans data/device_baselines.json. Il n'est jamais capturé automatiquement ; vous devez le demander explicitement, et l'exécuter à nouveau écrase la référence existante.
--check-drift recapture le même instantané et le compare à la référence stockée, produisant un verdict basé sur toute dérive trouvée : IDENTITY_DRIFT, GATT_TABLE_DRIFT, FIRMWARE_DOWNGRADE ou BOND_STATE_DRIFT. Cela répond à la question « quelque chose a-t-il changé depuis que j'ai fait confiance à cet appareil ? », pas « cet appareil est-il vulnérable » - c'est un signal heuristique de compromission, pas une preuve médico-légale. Un appareil avec un indicateur de dérive reçoit un verdict SUSPECTED_COMPROMISE, qui supplante tout le reste.
buds_audit.py --watch
Scanne en continu par fenêtres de durée fixe (Ctrl+C pour arrêter) et corrèle chaque annonce vue par nom et données du fabricant. Si deux adresses différentes diffusent la même identité avec des fenêtres d'observation qui se chevauchent - ce qui signifie que les deux étaient sur les ondes avec cette identité en même temps - il signale POSSIBLE_IMPERSONATION. Un seul appareil physique faisant tourner son adresse BLE au fil du temps (vu séquentiellement, pas simultanément) n'est pas signalé ; seul un véritable second émetteur l'est. Correspond à la dernière étape du modèle de menace : usurper les écouteurs vers le téléphone de la victime.
data/affected_devices.json est un catalogue organisé, pas une liste exhaustive. Actuellement confirmé :
| Marque | Modèle | SoC Airoha | CVEs | Firmware corrigé |
|---|---|---|---|---|
| Sony | WF-1000XM3 | AB1562 | CVE-2025-20700, CVE-2025-20701, CVE-2025-20702 | Aucune version publiée |
Selon la divulgation d'ERNW, d'autres marques utilisant des SoC des séries Airoha AB1562/AB1565/AB1568 (y compris Bose, Jabra, JBL, Marshall et les modèles Beats antérieurs au correctif) sont également signalées comme affectées, mais ne figurent pas encore dans le catalogue car leurs préfixes d'adresse exacts et les détails de la puce n'ont pas été confirmés sur du matériel réel dans ce projet. Un appareil hors catalogue peut toujours être sondé activement avec --gatt/--race/--firmware/--assess - le catalogue n'affecte que la correspondance passive du --scan et la pondération du verdict, pas ce que les sondes elles-mêmes testent.
Cet outil évalue CVE-2025-20701 (absence d'application de l'appairage Bluetooth Classic) uniquement de manière passive, via la vérification de la version du build du firmware RACE. Tester activement si une négociation d'appairage silencieuse peut être réalisée nécessite un accès HCI brut via Bumble et un dongle Bluetooth USB dédié compatible Bumble - ce qui n'est pas réalisable via BlueZ/bleak, c'est pourquoi cet outil ne tente pas de le faire. Voir le race-toolkit d'ERNW pour une implémentation de référence interactive basée sur un dongle couvrant les trois CVE.
La chaîne de vulnérabilités du SDK Airoha (CVE-2025-20700 / CVE-2025-20701 / CVE-2025-20702) a été découverte et divulguée par Dennis Heinze et Frieder Steinmetz chez ERNW. Leur race-toolkit est l'implémentation de référence à côté de laquelle ce projet comble une lacune sans dongle, et les UUIDs GATT exacts du protocole RACE ainsi que le cadrage des paquets utilisés ici ont été lus directement dans son code source plutôt que devinés - voir core/race.py pour les détails. race-toolkit n'est pas sous licence (pas de fichier LICENSE, vérifié directement dans le dépôt) - rien de son code source n'est réutilisé ici au-delà des faits de protocole sous-jacents (UUIDs, structure, codes de commande), qui décrivent le protocole propre d'Airoha et ne sont pas l'expression originale de ses auteurs à licencier en premier lieu.
MIT - voir LICENSE.
venv/bin/ruff check . --fix && venv/bin/ruff format .
venv/bin/python -m pytest tests/