Ingénierie inverse d'une caméra IP (Partie 2): Libérer une vieille caméra du Cloud chinois
Publié le 21 Janvier 2026
Vous connaissez ces appareils IoT (interphones vidéo, caméras, capteurs) qui deviennent soudainement inutiles parce que l'application officielle disparaît des magasins ou que les serveurs cloud en Chine sont éteints, transformant l'appareil en un presse-papier inutile et coûteux? Cela m'est arrivé avec une caméra IP Unotec basé sur un chipset HiSilicon Hi3510. Aucune interface Web accessible, juste du matériel têtu essayant de contacter des serveurs distants désormais inexistants.
Dans cet article je vais vous expliquer comment j'ai repris le contrôle total de l'appareil, transformer un presse-papier en une sentinelle locale qui enregistre les images sur un serveur Debian “dans la maison”, sans passer par des serveurs externes.
La stratégie: Détournement DNS et mise en miroir FTP
Analyser le trafic réseau, il s'est avéré que la caméra essayait de résoudre le domaine www.myidoorbell.com pour télécharger du contenu via FTP. L'idée était aussi simple qu'efficace: mettre en œuvre un Amichevole de l'homme du milieu.
1. Redirection DNS avec Pi-hole
Pour intercepter la caméra, j'ai utilisé Pi-trou. J'ai créé un enregistrement DNS local afin que chaque requête adressée au domaine cloud soit résolue avec l'adresse IP de mon serveur Debian interne. (192.168.5.110).
Configuration du serveur FTP (vsftpd)
La caméra est “vieille école” et utilise le protocole FTP dans mode passif. De nombreuses configurations modernes de vsftpd ils échouent car ils mappent les connexions en IPv6 ou ne communiquent pas correctement l'adresse IP locale pour le transfert de données.
Après divers tests, la configuration gagnante dans le fichier /etc/vsftpd.conf était:
listen=YES
listen_ipv6=NO
pasv_address=192.168.5.110
pasv_enable=YES
pasv_min_port=40000
pasv_max_port=40100
Sans la directive pasv_address, le serveur a répondu avec une adresse nulle (0.0.0.0), empêcher la caméra de transmettre les octets de l'image, même si la connexion a réussi.
Le “Télécommande” Image de synthèse: Activer les capteurs
Une fois le pont DNS et FTP en place, la caméra s'est connectée mais a envoyé des fichiers vierges. La raison? Le capteur de mouvement (Détection de mouvement) il était désactivé par défaut dans les paramètres internes.
Impossible de reconditionner le firmware en raison de contrôles d'intégrité (somme de contrôle), J'ai profité de l'API Image de synthèse exposé par la puce Hi3510. Utilisation des informations d'identification trouvées dans les fichiers de configuration (admin:admin), J'ai envoyé les commandes via HTTP:
# Forza uno scatto immediato e l'invio via FTP
curl -u admin:admin "http://192.168.5.123/cgi-bin/hi3510/param.cgi?cmd=testftp"
# Attiva il rilevamento movimento nell'area principale
curl -u admin:admin "http://192.168.5.123/cgi-bin/hi3510/param.cgi?cmd=setmdattr&-m1_enable=1"
Résultat final
Au lancement de la commande testftp, le serveur Debian a enregistré avec succès le téléchargement: un fichier JPG net, capturé directement par le capteur de came et enregistré localement.
Conclusions
- DNS et alimentation: Si vous vérifiez la résolution de nom sur votre réseau, vous contrôlez le comportement de vos appareils IoT.
- Ingénierie inverse “Lumière”: Il n'est souvent pas nécessaire de réécrire le firmware; il faut juste comprendre comment l'appareil communique avec l'extérieur.
- Confidentialité garantie: La Cam est désormais isolée du Web, il n'envoie pas de données à des serveurs inconnus et continue d'effectuer son travail sur site.
- Faire: Je dois encore trouver un presse-papier.




0 commentaires