bin4ry/unipwnFramework d'exploitation BLE pour robots Unitree : l'injection de commandes via des clés AES codées en dur permet la prise de contrôle à distance, l'injection de payload et la propagation de type ver.
Auteur: Bin4ry aka Andreas Makris [[email protected]]
Co-auteur: h0stile aka Kevin Finisterre
Contributeur: legion1581 aka Konstantin Severov de theroboverse a aidé à corriger le payload de l'injection et l'a prouvé avec un PoC entièrement fonctionnel 🙂 merci mec, ce fut une contribution cruciale, vraiment très appréciée !
Date: 20 septembre 2025
CVE-2025-35027
CVE-2025-60017
CVE-2025-60250
CVE-2025-60251
Les recherches de ce dépôt sont intégrées dans un article qui présente une évaluation systématique de la sécurité du Unitree G1. L'impact des recherches n'est cependant PAS limité au seul G1, mais concerne toute la gamme de produits Unitree à partir de la série Go2. Le code des robots Unitree plus récents semble être un fork du codebase Go2, ce qui rend précisément la lignée Go1 et les autres robots Unitree antérieurs au Go2 non vulnérables. Toutes les variantes modernes sont cependant impactées à l'heure actuelle. Unitree n'a pas encore publié d'advisory clarifiant l'impact exact sur l'ensemble de la gamme.
Lien vers l'article: https://arxiv.org/abs/2509.14139
Titre: Cybersecurity AI: Humanoid Robots as Attack Vectors
Auteurs: Víctor Mayoral-Vilches, Andreas Makris, Kevin Finisterre```bibtex
@misc{mayoralvilches2025cybersecurityaihumanoidrobots,
title={Cybersecurity AI: Humanoid Robots as Attack Vectors},
author={Víctor Mayoral-Vilches and Andreas Makris and Kevin Finisterre},
year={2025},
eprint={2509.14139},
archivePrefix={arXiv},
primaryClass={cs.CR},
url={https://arxiv.org/abs/2509.14139},
}
Table des matières
=================
* [Analyse de l'injection de commandes dans le service BLE du robot Unitree](#unitree-robot-ble-service-command-injection-analysis)
* [Aperçu](#overview)
* [Découverte du service BLE](#ble-service-discovery)
* [Rétro-ingénierie du protocole](#reverse-engineering-the-protocol)
* [Instruction 1 : La poignée de main "sécurisée"](#instruction-1-the-secure-handshake)
* [Instruction 2 : Obtenir le numéro de série](#instruction-2-get-serial-number)
* [Instruction 3 : Initialiser le mode WiFi](#instruction-3-initialize-wifi-mode)
* [Instruction 4 : Définir le SSID](#instruction-4-set-ssid)
* [Instruction 5 : Définir le mot de passe](#instruction-5-set-password)
* [Instruction 6 : Définir le code pays (le déclencheur !)](#instruction-6-set-country-code-the-trigger)
* [Le thread de configuration WiFi](#the-wifi-setting-thread)
* [La fonction vulnérable : injection de commandes](#the-vulnerable-function-command-injection)
* [Résumé du déroulement de l'attaque](#attack-flow-summary)
* [La menace auto-propagée](#the-wormable-threat)
* [Preuve de concept](#proof-of-concept)
* [Déploiement réel & impact](#real-world-deployment--impact)
* [Déploiements actuels](#current-deployments)
* [Évaluation de l'impact](#impact-assessment)
* [Impact sur les forces de l'ordre & l'armée](#law-enforcement--military-impact)
* [Environnements d'entreprise](#corporate-environments)
* [Impact sur les consommateurs](#consumer-impact)
* [Propagation auto-propagée](#wormable-propagation)
* [Détails techniques](#technical-details)
* [Architecture du service BLE](#ble-service-architecture)
* [Paramètres cryptographiques](#cryptographic-parameters)
* [Structure des paquets](#packet-structure)
* [Enseignements tirés](#lessons-learned)
* [Chronologie de la divulgation](#disclosure-timeline)
* [Première et dernière tentative de signaler un autre problème de sécurité dans vos robots phares G1, Go2 et autres robots](#first-and-last-attempt-to-report-another-security-issue-in-your-flagship-g1-and-go2-and-other-bots)
* [Avertissement](#disclaimer)
* [Un schéma récurrent de problèmes de sécurité](#a-pattern-of-security-issues)
* [Conclusion](#conclusion)
* [Mention légale](#legal-notice)
* [Contribution](#contributing)
* [Licence et accès à ces fichiers](#licensing-and-access-to-these-files)
---
## Aperçu
Au cours de nos recherches en sécurité sur les plateformes robotiques Unitree, nous avons découvert une vulnérabilité critique dans l'interface de configuration Wi-Fi Bluetooth Low Energy (BLE). Cette vulnérabilité affecte plusieurs modèles de robots Unitree, notamment les séries Go2, G1, H1 et B2, jusqu'au dernier firmware en date [20 septembre 2025].
**🎯 Il s'agit du premier exploit divulgué publiquement ciblant les robots humanoïdes !**
La vulnérabilité combine plusieurs problèmes de sécurité : des clés cryptographiques codées en dur, un contournement trivial de l'authentification et une injection de commandes non assainie. Ce qui rend cela particulièrement préoccupant, c'est qu'il est totalement **auto-propagateur** — les robots infectés peuvent automatiquement compromettre d'autres robots à portée BLE. Cette vulnérabilité permet à l'attaquant de prendre entièrement le contrôle de l'appareil.
Nous avons publié les clés cryptographiques en juillet [Lien vers le tweet](https://x.com/Bin4ryDigit/status/1950566849072005304) mais Unitree n'en a pas tenu compte.
Plongeons dans les détails techniques de la façon dont nous avons découvert et exploité cette vulnérabilité.
## Découverte du service BLE
La première étape consistait à identifier les services BLE exposés par les robots. Tous les modèles Unitree concernés exposent un service BLE personnalisé pour la configuration Wi-Fi :```
Service UUID: 0000ffe0-0000-1000-8000-00805f9b34fb
Write Characteristic: 0000ffe2-0000-1000-8000-00805f9b34fb
Notify Characteristic: 0000ffe1-0000-1000-8000-00805f9b34fb
Grâce à la rétro-ingénierie, nous avons découvert que le robot implémente un gestionnaire de réception qui traite les paquets BLE chiffrés. Voici ce que nous avons trouvé :
Le gestionnaire de réception déchiffre d'abord les paquets entrants à l'aide de paramètres AES codés en dur :```python AES_KEY = "df98b715d5c6ed2b25817b6f2554124a" AES_IV = "2841ae97419c2973296a0d4bdfe19a4f" Mode: AES-CFB128
Après déchiffrement, les paquets sont traités en fonction des codes d'instruction dans une structure switch-case. Examinons chaque instruction :
## Instruction 1 : le handshake « sécurisé »
L'« authentification » du handshake est ridiculement simple :
En gros, le robot vérifie si le paquet déchiffré contient la chaîne `"unitree"` comme secret du handshake, puis passe le flag `valid_incoming_user` à 1. C'est tout le mécanisme d'« authentification » !
## Instruction 2 : obtenir le numéro de série
Cette instruction vérifie si l'utilisateur est « authentifié » (c'est-à-dire si le flag est défini), puis lit le fichier de numéro de série et le renvoie. Cela confirme que nous avons accès au système.
## Instruction 3 : initialiser le mode WiFi
Cette instruction initialise les paramètres WiFi. Les utilisateurs peuvent choisir entre le mode AP (sous-commande = 1) ou le mode STA (sous-commande = 2) :
## Instruction 4 : définir le SSID
Cette instruction stocke le SSID WiFi. Voici notre premier point d'injection :
## Instruction 5 : définir le mot de passe
Comme pour la commande SSID, celle-ci stocke le mot de passe WiFi. Un autre point d'injection :
## Instruction 6 : définir le code pays (le déclencheur !)
Cette instruction définit le code pays WiFi et, surtout, déclenche la fonction `WifiSettingThreadFunction` :
Lorsque l'instruction 6 est exécutée, elle démarre le thread de configuration WiFi, ce qui nous mène aux fonctions vulnérables.
## Le thread de configuration WiFi
Le thread de configuration WiFi appelle soit `restart_wifi_ap`, soit `restart_wifi_sta`, selon le mode :
## La fonction vulnérable : injection de commande
Les fonctions `restart_wifi_ap` (`hostapd_restart.sh`) et `restart_wifi_sta` (`wpa_supplicant_restart.sh`) suivent toutes deux le même schéma vulnérable.
Voici la preuve irréfutable (en prenant comme exemple la fonction `restart_wifi_ap`) :
La fonction construit la commande suivante :```bash
sudo sh /unitree/module/network_manager/upper_bluetooth/hostapd_restart.sh "wifi_ssid wifi_pass"
Cette commande est ensuite passée directement à system() sans aucune validation ni assainissement des entrées !
Si nous contrôlons soit wifi_ssid soit wifi_pass, nous pouvons injecter nos propres commandes. Un payload simple comme :```bash
";$(reboot -f);#
Il suffirait de redémarrer le robot. Mais nous pouvons faire bien plus...
## Résumé de la chaîne d'attaque
Voici la séquence d'attaque complète que nous devons exécuter :
1. Envoyer la charge utile chiffrée AES « unitree » comme données pour l'instruction 1
2. Envoyer la commande get_sn et déchiffrer la réponse pour vérifier l'accès
3. Envoyer init_wifi avec la sous-commande 1 (AP) ou 2 (STA)
4. Définir wifi_ssid sur notre charge utile d'injection comme `";$(reboot -f);#`
5. Définir wifi_pass sur une valeur arbitraire
6. Définir le code pays WiFi pour déclencher le thread vulnérable
Si tout fonctionne, le robot devrait exécuter notre commande injectée avec les privilèges root.
## La menace de type ver
Ce qui rend cette vulnérabilité particulièrement dangereuse, c'est sa nature de **ver**. Avec cette méthode, nous pouvons :
- Exécuter des commandes arbitraires avec les privilèges root
- Transférer et exécuter des malwares via l'injection de charge utile
- Forcer les robots à se connecter à des réseaux WiFi contrôlés par l'attaquant
- Créer un malware robotique auto-propageant qui infecte les robots à proximité
Un robot infecté peut simplement rechercher d'autres robots Unitree à portée BLE et les compromettre automatiquement, créant ainsi un botnet de robots qui se propage sans intervention de l'utilisateur.
## Preuve de concept
Nous avons développé un framework d'exploit de preuve de concept complet qui démontre cette vulnérabilité. L'exploit comprend :
- Un scanner BLE et un framework d'exploit basés sur Python
- Une APK Android (précédemment partagée le 5 septembre 2025 dans le canal Slack aux testeurs via un zip protégé par mot de passe)
- Plusieurs charges utiles prédéfinies (activation SSH, redémarrage du système, commandes personnalisées)
- Prise en charge de tous les modèles de robots concernés (Go2, G1, H1, B2, ...)
Composants clés de notre exploit fonctionnel :```python
AES_KEY = bytes.fromhex("df98b715d5c6ed2b25817b6f2554124a")
AES_IV = bytes.fromhex("2841ae97419c2973296a0d4bdfe19a4f")
HANDSHAKE_CONTENT = "unitree"
def build_pwn(cmd):
return f'";$({cmd});#'
Les robots Unitree sont déjà déployés dans des scénarios critiques du monde réel, ce qui rend cette vulnérabilité particulièrement préoccupante :
Forces de l'ordre : La police du Nottinghamshire teste actuellement des robots Unitree pour des scénarios d'intervention armée, notamment :
Opérations militaires : Les robots Unitree sont utilisés par l'APL de la Chine pour des applications militaires, ce qui soulève des implications de sécurité importantes pour les opérations de défense.
Les implications de cette vulnérabilité sont assez graves :
0000ffe0-0000-1000-8000-00805f9b34fb0000ffe2-0000-1000-8000-00805f9b34fb0000ffe1-0000-1000-8000-00805f9b34fbdf98b715d5c6ed2b25817b6f2554124a (codée en dur, identique sur tous les appareils)2841ae97419c2973296a0d4bdfe19a4f (codé en dur, identique sur tous les appareils)Encrypted([0x52, length, instruction, data, checksum])
```
## Leçons apprises
Cette recherche met en évidence plusieurs principes de sécurité critiques :
- **Ne jamais utiliser de clés codées en dur :** Chaque appareil devrait disposer d'un matériel cryptographique unique
- **Défense en profondeur :** Plusieurs couches de sécurité évitent les points de défaillance uniques
- **Validation des entrées :** Toujours assainir les entrées utilisateur, surtout avant les appels système
- **Tests de sécurité :** Des tests d'intrusion réguliers peuvent détecter ces problèmes rapidement
## Chronologie de la divulgation
Nous avons initialement tenté une divulgation responsable auprès d'Unitree concernant cette vulnérabilité :
- **Bug trouvé :** Le bug a été trouvé le 14 avril 2025 par Andreas Makris (Bin4ry) et discuté en message privé Slack avec Kevin Finisterre (h0stile) et Konstantin Severov (legion1581).
- **PoC développé :** Le 25 avril 2025, Konstantin Severov a pu corriger le payload incorrect d'Andreas et concevoir un payload fonctionnel correct pour l'injection. Le premier PoC était né.
- **BLE non sécurisé trouvé :** Après que Konstantin a vérifié la vulnérabilité d'injection, Andreas a trouvé les clés codées en dur et la faible authentification pour le BLE.
- **Contact initial :** Plusieurs e-mails ont été envoyés aux canaux de sécurité et d'assistance d'Unitree
- **Problèmes de communication :** L'un des auteurs (Andreas Makris) a été retiré à plusieurs reprises des fils de discussion e-mail sans explication
- **Aucune réponse :** Unitree n'a montré aucun engagement ni intérêt significatif pour résoudre les problèmes de sécurité
- **Résultat :** Aucune reconnaissance ni calendrier de correctif n'a été fourni
Compte tenu du manque de réponse d'Unitree et de son apparent désintérêt pour les questions de sécurité, **Andreas Makris a décidé de cesser les tentatives de divulgation privée auprès d'Unitree pour les vulnérabilités futures**. Tout problème de sécurité supplémentaire découvert sera divulgué publiquement sans notification préalable au fournisseur.
Cette décision reflète le refus démontré d'Unitree de s'engager de manière constructive sur les questions de sécurité, ce qui est particulièrement préoccupant compte tenu de leur déploiement dans des contextes d'application de la loi et militaires.
### Première et dernière tentative de signaler un autre problème de sécurité dans votre produit phare G1, et Go2, et autres robots
(Initiée par Kevin Finisterre)
- **14 mai 2025** — Tentative de contact pour divulgation effectuée via [LinkedIn](https://www.linkedin.com/posts/kevin-finisterre-6431069a_fyi-unitree-robotics-is-being-given-an-opportunity-activity-7328446278852407296-qZB4) et [issue GitHub #126](https://github.com/unitreerobotics/unitree_ros/issues/126) malgré plusieurs années où Unitree a ignoré d'autres tentatives de signalement *de notre part*, et de nos pairs chercheurs.
-
E-mail intitulé *« Première, et dernière tentative de signaler un autre problème de sécurité dans votre produit phare G1, et Go2, et autres robots »* envoyé à :
Tony Yang <[email protected]>, <[email protected]>, <[email protected]>, Laikago <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]>, Xing <[email protected]>, XMath <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]>
- Unitree a immédiatement suggéré un éventuel programme de bug bounty à l'avenir, mais c'était une discussion prématurée à ce moment-là.
- **28–29 mai 2025** — Après deux semaines de discussion sur le manque général de *sérieux* d'Unitree en matière de sécurité, `[email protected]` est créée comme un geste d'effort.
-
E-mail intitulé *« Prochaines étapes... concernant le signalement d'une vulnérabilité critique dans Unitree G1 »* a souligné le manque de pratiques de divulgation, ignoré Darknavy et les rapports antérieurs, et a suggéré soit une démonstration en personne avec une version de débogage, soit un robot prêté (comme Unitree en envoie aux influenceurs). Les deux ont été refusés, y compris une offre de rencontre à l'ICRA.
- **8 juin 2025** — Unitree a répondu : « Un correctif pour Go1 « Zhexi » est déjà en ligne depuis avril » avec le lien <https://www.unitree.com/download/go1>, ajoutant « Github est uniquement pour les problèmes d'exécution de référentiel. Donc pour la cybersécurité, nous suggérons d'utiliser de nouvelles méthodes. » Les réponses se sont raréfiées.
- **14–26 juin 2025** — Nous les avons pressés sur la transparence du code sous licence MIT Cheetah ; par opposition à l'utilisation de routines de chiffrement et d'un accès contrôlé à leurs instances de sous-système Linux pour masquer du code emprunté.
- La réponse est arrivée le 26 juin : *« désolé pour ma réponse tardive. Je n'ai pas oublié. J'ai juste besoin de plus de temps. »*
- À peu près à cette époque, Unitree a publié une offre d'emploi pour du personnel de sécurité. [Offre d'emploi](https://m.zhipin.com/web/common/security-check.html?seed=F0HDtXiugDFyEi4Ap0g8%2FTu2hnxkObxC1s2HV5XA8%2Fw%3D&name=8955eed0&ts=1757704720826&callbackUrl=%2Fjob_detail%2F8f6b34a1ca755b4f03Fz2tq7EFVU.html&srcReferer)
- **18 juillet 2025** — E-mail intitulé *« Aloooors, on a terminé ici ? Parce que je suis sur le point d'en avoir fini ici… »* envoyé en raison du silence et du manque de progrès dans la négociation des limites de divulgation.
- **20 juillet 2025** — Unitree a reconnu que nous avons « des vulnérabilités connues du G1 », mais a affirmé que la résolution de nos prétendues constatations avec des correctifs « nécessite une itération complète du système qui prend *des trimestres ou des années, ”* et a indiqué un futur portail public de sécurité comme une étape importante.
- **25 juillet 2025** — Unitree a lancé le marketing du R1. Après cela, aucune autre communication n'a été reçue.
- Décision prise de divulguer publiquement et de laisser Unitree gérer les choses selon son propre calendrier. Aucune autre tentative de divulgation pour de nouvelles découvertes ne sera faite.
- **2 septembre 2025** — Unitree annonce un objectif de valorisation de 7 milliards de dollars US pour son introduction en bourse (IPO) à venir au 4e trimestre 2025.
## Avertissement
⚠️ **Avertissement :** Ce code est uniquement destiné à des fins éducatives et de recherche. Ne l'utilisez pas sur des appareils qui ne vous appartiennent pas.
## Un schéma de problèmes de sécurité
Cette vulnérabilité n'est pas un incident isolé. Nos propres recherches précédentes ont révélé des schémas préoccupants dans les pratiques de sécurité d'Unitree :
**CVE-2025-2894 :** [Des chercheurs ont découvert une porte dérobée dans les robots de la série Go1 antérieurs](https://takeonme.org/cves/cve-2025-2894/), qu'Unitree a ensuite prétendu être du « code restant ». Cependant, comme nous l'avons noté dans le rapport Go1, qu'il s'agisse d'une porte dérobée intentionnelle ou d'une programmation négligente, les deux scénarios indiquent une entreprise qui ne priorise pas la sécurité.
Désormais, dans la prochaine génération de robots (Go2, G1, H1, B2), nous constatons les mêmes défaillances de sécurité fondamentales : des clés codées en dur, une authentification triviale et des appels système dangereux. Cela suggère qu'**Unitree n'a pas tiré les leçons des problèmes de sécurité précédents** et continue de commercialiser des produits présentant des vulnérabilités critiques.
Le schéma est clair :
- **Série Go1 :** Portes dérobées cachées (CVE-2025-2894)
- **Rapport inconnu de DarkNavy** « Lors de GeekPwn 2022, nous... avons contacté Unitree pour une divulgation responsable (mais n'avons reçu aucune réponse) »
- **Série Go2/G1/H1/B2 :** Injection de commandes via BLE (cette recherche)
Pour une entreprise qui déploie des robots dans des contextes d'application de la loi et militaires, ce niveau de négligence en matière de sécurité est inacceptable.
## Conclusion
La combinaison de clés cryptographiques codées en dur, de contournement trivial de l'authentification et d'injection de commandes crée une tempête parfaite pour une exploitation généralisée. La nature auto-propagatrice de cette vulnérabilité la rend particulièrement dangereuse dans les environnements comportant plusieurs robots.
Compte tenu des antécédents d'Unitree en matière de problèmes de sécurité et de leur déploiement dans des scénarios critiques d'application de la loi et militaires, une action immédiate est nécessaire pour remédier à ces défaillances de sécurité systémiques.
Nous avons suivi les pratiques de divulgation responsable et travaillons avec Unitree pour résoudre ces problèmes. Cette recherche est destinée uniquement à des fins éducatives et défensives.
---
## Avis légal
⚖️ Cette recherche a été menée sur des équipements légalement détenus à des fins éducatives et de recherche en sécurité. Toute utilisation de ces informations à des fins malveillantes est strictement interdite et peut violer les lois applicables.
Souvenez-vous : Un grand pouvoir implique de grandes responsabilités. Utilisez ces connaissances pour construire des systèmes meilleurs et plus sécurisés !
## Contribution
Si vous trouvez des problèmes supplémentaires ou des améliorations, n'hésitez pas à soumettre une pull request ou à ouvrir une issue.
## Licence et accès à ces fichiers
Ces fichiers sont publiés sous licence Creative Commons [CC BY-NC-SA 4.0](https://creativecommons.org/licenses/by-nc-sa/4.0/).
<p align="left">
<img src="https://assets.kitploit.com/production/public/readmes/49064/29490d1f406beb842255421807acdf0e4327f9cdf7547041398560fd7452a5ea.png">
</p>
Cette licence vous accorde des droits spécifiques, mais limités, pour utiliser ces fichiers.
<p align="left">
<img src="https://assets.kitploit.com/production/public/readmes/49064/00bb7938b330aa21407316a9f3d62fdad4e502fddc76237f7ae4e6b518386dcb.png">
</p>
[Licence internationale Attribution Pas d'Utilisation Commerciale Partage dans les Mêmes Conditions 4.0](https://creativecommons.org/licenses/by-nc-sa/4.0/legalcode.en)
Vous êtes libre de :<br>
Partager — copier et redistribuer le matériel dans tout support ou format<br>
Adapter — remixer, transformer et construire à partir du matériel<br>
Le concédant ne peut pas révoquer ces libertés tant que vous respectez les termes de la licence.<br>
Selon les conditions suivantes :<br>
Attribution — Vous devez donner le crédit approprié, fournir un lien vers la licence et indiquer si des modifications ont été effectuées. Vous pouvez procéder de toute manière raisonnable, mais pas d'une manière qui suggère que le concédant vous soutient ou soutient votre utilisation.<br>
Pas d'Utilisation Commerciale — Vous ne pouvez pas utiliser le matériel à des fins commerciales.<br>
Partage dans les Mêmes Conditions — Si vous remixez, transformez ou construisez à partir du matériel, vous devez distribuer vos contributions sous la même licence que l'original.<br>
Aucune restriction supplémentaire — Vous ne pouvez pas appliquer des conditions juridiques ou des mesures technologiques qui restreindraient légalement autrui d'effectuer tout ce que la licence permet.<br>
Avis : Veuillez lire l'[interprétation NonCommercial de Creative Commons](https://wiki.creativecommons.org/wiki/NonCommercial_interpretation) pour plus d'informations sur la licence.<br>
Cela signifie directement que vous ne pouvez PAS facturer l'accès à ces fichiers, et vous ne pouvez pas les ajouter à votre plateforme commerciale d'exploitation de vulnérabilités, ni les mettre derrière un paywall, car vous n'avez explicitement pas la permission de le faire ; vous êtes en fait spécifiquement interdit de le faire sans risques de conséquences juridiques.
Cette recherche est partagée à des fins éducatives. Veuillez l'utiliser de manière responsable.