C’est quoi un Potensic Atom 2 ?
Le Potensic Atom 2, c’est un drone grand public a ~$360 USD (~300 EUR). Moins de 249 grammes, capteur Sony 48MP avec gimbal 3 axes, GPS, suivi de sujet automatique, environ 25 minutes de vol en pratique. Sur le papier, un drone de loisir classique.
Sous le capot, c’est une autre histoire. Le fabricant — Shenzhen Deepsea Group, une boite chinoise — a mis dedans une puce normalement faite pour les cameras de surveillance professionnelles, avec un processeur d’intelligence artificielle, un firmware entierement chiffre, et quelques surprises.
J’ai voulu savoir ce qui se passait vraiment la-dedans. Ce qui a commence comme un “voyons ce qu’il y a sous le capot” s’est transforme en plusieurs semaines de reverse engineering et une bataille epique contre le logiciel du drone.
Le hardware
Le cerveau : HiSilicon Hi3519DV500
C’est la puce principale du drone, fabriquee par HiSilicon (la branche puces de Huawei). Elle embarque :
- Un processeur double coeur a 1.0 GHz — c’est lui qui fait tourner Linux et le logiciel du drone
- Un processeur d’IA capable de 2.5 mille milliards d’operations par seconde — oui, dans un drone a 300 euros
- Un encodeur video capable de traiter du 4K
A la base, cette puce est concue pour les cameras de surveillance professionnelles. La trouver dans un drone grand public, c’est inattendu.
Le controleur de vol
Un GigaDevice GD32F470 — un microcontroleur ARM a 240 MHz. C’est lui qui gere tout ce qui fait voler le drone : stabilisation, GPS, moteurs. L’equivalent chinois du STM32 qu’on retrouve dans beaucoup de drones. Il communique avec le cerveau principal via un port serie.
La connectivite
Deux puces de communication : un ESP32 pour le Bluetooth et un Realtek RTL8821CS pour le WiFi. C’est ce dernier que j’ai detourne pour connecter le drone a mon reseau domestique.
La telecommande communique en RF proprietaire et se branche au telephone en USB pour relayer la video et la telemetrie.
Obtenir un acces administrateur
Un shell root, c’est un acces administrateur complet au systeme d’exploitation du drone. Comme avoir le mot de passe admin d’un ordinateur — on voit tout, on controle tout.
La methode : une carte SD et un mot de passe
En analysant le logiciel principal du drone avec Ghidra (un outil de reverse engineering), j’ai decouvert qu’au demarrage, le drone verifie si un fichier specifique existe sur la carte SD. Si ce fichier contient un mot de passe code en dur dans le logiciel, le drone execute ce qu’on veut en tant qu’administrateur.
En gros :
- On cree un fichier sur la carte SD
- On met le mot de passe magique dedans
- On ajoute nos commandes (activer l’acces a distance, connecter au WiFi de la maison…)
- On insere la carte, on allume — le drone obeit
Resultat : le drone se connecte a mon reseau local et j’ai un acces a distance permanent. A chaque demarrage, tout se remet en place automatiquement.
Premiere decouverte : le drone tourne sous Linux
Une fois dedans, on decouvre que ce drone fait tourner Linux — le meme systeme d’exploitation qu’on retrouve sur les serveurs et beaucoup d’appareils connectes. Tout le logiciel est contenu dans un seul gros programme de 21 Mo, lance au demarrage.
Premier piege : la memoire de stockage du drone est pleine a 99%. J’ai failli le rendre inutilisable en ecrivant des fichiers au mauvais endroit. Il a fallu trouver un espace temporaire en memoire vive pour travailler.
La guerre du WiFi
C’est la partie qui m’a donne le plus de fil a retordre. Connecter le drone au WiFi de la maison, ca semble simple. En realite, le logiciel du drone se bat activement contre vous.
Le probleme
Le drone a un systeme de surveillance interne qui verifie chaque seconde l’etat du WiFi. Si quelque chose ne correspond pas a ce qu’il attend, il coupe tout et relance sa propre configuration. Resultat : chaque seconde, le drone tue ma connexion et relance la sienne. Je perds l’acces a distance, je perds tout.
La solution : 3 couches de tromperie
Pour garder le controle, il a fallu tromper le drone sur 3 niveaux :
- Remplacer les scripts WiFi du drone par des scripts vides — quand le drone essaie de relancer son WiFi, il ne se passe rien
- Creer de faux processus qui font croire au drone que son systeme WiFi tourne normalement
- Un gardien qui surveille en permanence que toute cette supercherie reste en place
Le drone est convaincu que tout va bien. Pendant ce temps, il est connecte a mon reseau et je fais ce que je veux.
Le bug des 75 copies
Bonus : le programme WiFi sur le drone avait un nom tronque. Mon script cherchait le mauvais nom, ne le trouvait jamais, et en lancait une nouvelle copie a chaque fois. Apres quelques heures : 75 copies du meme programme en parallele. Oups.
Le firmware chiffre
Le firmware (les mises a jour logicielles du drone) est distribue sous forme d’un fichier de ~82 Mo contenant 12 modules : controleur de vol, gimbal, batterie, camera…
Chaque module est chiffre en AES — le meme algorithme utilise par les banques et les VPN. En theorie, sans la cle, impossible de voir ce qu’il y a dedans.
La cle etait en clair
En fouillant dans le logiciel avec Ghidra, j’ai trouve la fonction qui dechiffre les mises a jour. Et la cle de chiffrement ? Elle etait ecrite en clair, directement dans le code, lisible par n’importe qui.
C’est comme si une banque mettait le code du coffre-fort sur un post-it colle sur la porte. La puce du drone dispose pourtant d’un systeme materiel pour stocker les cles de maniere securisee dans le silicium — le fabricant ne l’a tout simplement pas utilise.
Resultat : tous les 12 modules firmware — batterie, gimbal, controleur de vol, moteurs, logiciel camera — ont ete dechiffres et verifies. A partir de la, on peut tout analyser et tout modifier.
4 modeles d’IA embarques
C’est la que ca devient vraiment interessant. Le drone embarque 4 modeles d’intelligence artificielle qui tournent en temps reel pendant le vol, sur le processeur dedie de la puce HiSilicon.
| Modele | Role |
|---|---|
| NanoDet | Detecter les personnes et vehicules dans l’image |
| NanoTrack | Suivre un objet d’une image a l’autre |
| MobileSAM | Decouper le sujet du fond (mode portrait) |
| OSNet | Retrouver une personne par son apparence |
Quand vous activez le suivi de sujet, voila ce qui se passe :
- NanoDet repere une personne dans l’image
- NanoTrack la suit image par image en predisant ou elle sera
- Si la cible disparait (derriere un arbre, virage brusque), OSNet la retrouve en reconnaissant ses vetements et sa silhouette
- MobileSAM decoupe la personne du fond pour les effets portrait
Tous ces modeles sont open-source a l’origine. Le fabricant les a adaptes pour tourner sur le processeur d’IA du drone. Impressionnant pour un appareil a 300 euros.
Le protocole USB
L’application officielle communique avec le drone via la telecommande, qui sert de relais USB. J’ai decompile l’application Android — 8072 classes de code a parcourir — et reconstitue le protocole complet.
Ce que le drone envoie
Le drone transmet en permanence :
- Sa position GPS, son altitude, sa vitesse, son cap
- Le niveau de batterie (drone et telecommande)
- L’etat de vol (au sol, en vol, mode RTH…)
- Les positions des joysticks de la telecommande
- Le flux video en 1080p
Toutes ces donnees circulent dans des paquets structures avec des identifiants numeriques. En croisant le code de l’application avec des captures reseau, j’ai reconstitue la table de correspondance complete.
Ce qu’on peut lui envoyer
Decollage, atterrissage, retour maison, prise de photo, enregistrement video, mouvements des joysticks… Chaque commande doit etre envoyee plusieurs fois pour simuler un appui maintenu — exactement comme le fait l’application officielle.
L’application proxy
A partir de ce reverse, j’ai developpe une application Android qui se branche sur la telecommande et expose tout via le reseau :
- Video live re-streamee en temps reel
- Telemetrie complete consultable depuis n’importe quel navigateur
- Commandes de vol depuis une interface web
- Positions des joysticks physiques de la telecommande visibles en direct
Par contre, piloter le drone depuis le web via la telecommande est impossible : la telecommande ne relaie pas les commandes de mouvement dans ce sens. C’est du code mort dans l’application officielle — une fonctionnalite prevue mais jamais finalisee.
Le pipeline video
Le plus gros defi : obtenir le flux video live du drone sur mon reseau local, sans passer par l’application officielle.
Le probleme
Le drone est prevu pour envoyer la video uniquement en WiFi Direct (connexion point-a-point avec le telephone). Quand il est connecte a mon reseau domestique, il pense que personne ne regarde et n’active pas le streaming.
5 tentatives echouees
J’ai essaye de modifier differentes variables en memoire pour convaincre le logiciel de demarrer le streaming. Aucune n’a marche — le systeme a trop de verifications croisees, et une tentative trop agressive a meme fait crasher le drone.
La solution : voler le flux video
Au lieu de demander poliment au drone, j’ai ecrit un programme qui s’interface directement avec la puce video pour intercepter le flux a la source. En gros, on court-circuite le logiciel du drone et on va chercher les images directement dans le materiel.
Le programme detruit le canal video existant et le reconstruit sous notre controle. Chaque image encodee est envoyee sur le reseau local.
Resultat : video live 1080p a 24 fps, visible dans n’importe quel navigateur, avec environ 1 seconde de latence. Le tout tourne directement sur le drone, sans ordinateur intermediaire.
J’ai aussi du ecrire deux petits programmes supplementaires : un pour forcer le framerate a 24 images/seconde (au sol, le drone descend a 3 fps pour economiser la batterie), et un pour reduire la latence.
Compiler du code pour un drone
Petit detail qui m’a coute pas mal de temps : on ne peut pas simplement compiler un programme sur son PC et le copier sur le drone. Le drone utilise un systeme different de la plupart des ordinateurs. Il a fallu mettre en place un environnement de compilation special, et trouver des astuces pour transferer les fichiers (la carte SD bloque l’execution de programmes, le transfert de fichiers classique ne marche pas).
Ecouter la conversation interne
Le controleur de vol et le cerveau principal du drone communiquent via un port serie interne. J’ai pu intercepter cette conversation en mettant brievement en pause le processus qui occupe ce port.
Le plus gros paquet de donnees contient la navigation complete : orientation du drone dans l’espace, pression atmospherique, et coordonnees GPS. C’est la conversation la plus intime du drone — ce que les deux cerveaux se disent en permanence pour maintenir le vol.
Securite
L’analyse approfondie du logiciel a revele des vulnerabilites de securite, certaines liees a des outils de production oublies dans le produit final. Ces decouvertes sont en cours de traitement dans le cadre d’une divulgation responsable avec Tim Schmidt de Neodyme (voir section dediee ci-dessous). Les details techniques seront publies apres ce processus.
Modifier le logiciel en vol
Pour certaines modifications, impossible de toucher au logiciel stocke sur le drone (plus de place). La solution : modifier le programme directement dans la memoire pendant qu’il tourne. C’est comme operer a coeur ouvert — on change des instructions dans le cerveau du drone sans l’eteindre.
Exemple : pour activer le streaming video, on remplace une verification par “retourne toujours OK”. Le drone croit que tout est normal et demarre le flux video.
L’interface web
Pour rassembler tout ca, j’ai cree une interface web accessible depuis n’importe quel navigateur :
- Video live 1080p
- Telemetrie : batterie, altitude, etat de vol
- Commandes : decollage, atterrissage, retour maison, photo, video
- Joysticks virtuels : tactile, souris ou clavier
Le tout tourne sur le drone lui-meme. On ouvre un navigateur, on tape l’adresse, et on a le controle complet.
Tim Schmidt & Neodyme
Si ce projet a depasse le stade du “je regarde ce qu’il y a sous le capot”, c’est en grande partie grace a Tim Schmidt de Neodyme, une entreprise allemande de recherche en securite.
Tim a publie un premier article de recherche sur les drones DeepSea/Potensic (Neodyme Part 1) qui a ete un tournant dans mon propre travail. Ses travaux m’ont fourni des renseignements cruciaux : la confirmation qu’il n’y avait pas de port de debug physique sur la carte electronique, des pistes sur l’architecture logicielle interne, et surtout la validation que ce hardware cachait des choses qui meritaient d’etre creusees bien plus en profondeur.
Sans ses recherches, j’aurais probablement arrete apres l’acces root. C’est en lisant son travail que j’ai compris l’ampleur de ce qu’il y avait a trouver. Tim n’a pas ete un simple contact : il a ete un vrai partenaire de recherche. On a echange sur nos decouvertes, croise nos analyses, et coordonne la divulgation responsable ensemble.
Son Part 2 (a paraitre) couvrira les vulnerabilites en detail. C’est pour respecter son travail et le processus de divulgation responsable que certains details ne sont pas encore publies ici.
Outils utilises
| Outil | Usage |
|---|---|
| Ghidra | Analyse du logiciel principal du drone |
| jadx | Decompilation de l’application Android |
| Wireshark | Capture et analyse du protocole USB |
| nRF Connect | Analyse Bluetooth |
| Dropbear | Serveur SSH ultra-leger deploye sur le drone |
| websocat | Relais video vers le navigateur |
Etat actuel
Le drone est actuellement soft-bricked — le logiciel est hors service suite aux modifications, mais le hardware est en parfait etat (carrosserie neuve, gimbal, camera, batterie). La recherche est terminee de mon cote.
References
- Potensic Atom 2 — Page officielle
- Potensic Atom 2 — Specifications
- Hi3519DV500 — Brief Data Sheet (PDF)
- GigaDevice GD32F470VGT6 — Fiche produit
- Realtek RTL8821CS — Fiche produit
- NanoDet — Detection d’objets
- NanoTrack — Suivi d’objet
- MobileSAM — Segmentation
- OSNet — Re-identification
- Neodyme — Security Research
- HiSilicon — Wikipedia