Cloud = obsolescence programmée

J'ai récupéré cette caméra de marque Etiger, modèle ES-CAM2A.

C'est une caméra IP de vidéosurveillance connectée en WIFI avec un micro et un haut-parleur. La caméra s'utilise uniquement via un smartphone/tablette via l'application iSecurity+ qui est un service cloud. Cette caméra a été achetée a Castorama en 2015.

Ce qui n'aurait dû prendre que quelques minutes à configurer va se transformer en galère monumentale pour au final ne pas parvenir à utiliser la caméra à cause du cloud.

Application indisponible sur le Play Store

Pour configurer la caméra, il faut l'appli iSecurity+. Je recherche l'appli sur le Play Store : rien mis à part des résultats qui n'ont rien à voir, les recherches sur le Play Store ne sont pas au point et renvoient souvent n'importe quoi.

Seconde solution : chercher sur Google. Je trouve un lien permettant de télécharger l'APK et je l'installe.

Échec de la connexion

J'ouvre l'appli iSecurity+, parfait tout fonctionne, je suis les instructions, et au moment de connecter la caméra au WIFI, erreur de connexion ! Je fais un reset de la caméra, fais plusieurs essais et toujours une erreur au moment de la connecter à internet. Je remarque que la LED réseau ne clignote plus, ça voudrait dire qu'elle est connectée ? Je vais voir la liste des périphériques connectés dans l'interface de la Freebox et je vois que la caméra est bien connectée au réseau. D'après la notice, si la LED réseau est orange fixe, c'est que la caméra est connectée au WIFI mais pas au service cloud.

Là, je commence à me dire que ça sens mauvais tout ça. Mais c'est bizarre puisque le site iSecurity+ est accessible.

PC Linux, point d'accès WIFI et Wireshark

Pour comprendre ce qui ne va pas, je commence à sortir les gros moyens. Je configure un PC Linux en point d'accès WIFI sur lequel je vais connecter la caméra et grâce à Wireshark, je vais voir ce que fait la caméra sur le réseau.

Je vois qu'elle fait des requêtes DNS vers des sous-domaines de seedonk.com. Ce nom de domaine renvoie vers le site de iSecurity+.

Je vois aussi des ping vers un domaine Amazon AWS qui n'existe pas, c'est ça qui doit faire échouer la connexion au moment de configurer le WIFI.

Là ça pue, et même beaucoup ! Le fait que le serveur n'existe plus empêche de configurer la caméra !

Scan de ports avec nmap

Vu que la caméra se connectait au WIFI, j'ai essayé de voir si l'on ne pouvait pas récupérer le flux vidéo sur un autre port. J'ai donc fait un scan des 65535 ports TCP et UDP avec nmap et les seuls ports ouverts étaient le TCP 80, celui du serveur web et le port UDP 10000 mais impossible de trouver son utilité.

En utilisant l'appli iSecurity+ j'ai eu à un moment donné un message d'erreur qui m‘affichait une URL en me disant qu’elle était injoignable. Je me suis connecté à cette URL et je suis tombé sur la page de configuration que m'affichait l'appli. Les applis sont souvent juste un navigateur internet déguisé, c'est courant sur Android et peut-être aussi sur iOS.

On sors les gros moyens: connexion au port série

Il reste encore un espoir : ouvrir la caméra en espérant y trouver un port série ou port UART. Ce port série souvent présent sur ce type de matériel (caméras, routeurs, etc..) permet de se connecter en mode console à la caméra qui n'est rien d'autre qu'un ordinateur réduit au strict minimum et tournant généralement sous Linux.

J'ouvre la caméra et bingo ! Le port série est présent avec en prime le nom des broches et la tension à utiliser, encadré en rouge image suivante.

Un port série utilise 4 broches :

• GND (ground) masse

• +VCC plus (on n'utilise pas cette broche)

• TX émission données

• RX réception données

Si le brochage n'est pas indiqué, il faudra d'abord trouver la tension du port série avec un voltmètre. Cette tension est de 3,3 V ou 5 V et plus rarement 12 V. Le port série des ordinateurs c'est toujours 5 V. Le mieux est d'utiliser un convertisseur série-USB sur lequel un jumper permet de choisir entre 3,3 V ou 5 V, ça se trouve pour environ 6 € sur Amazon.
Le voltmètre va aussi te permettre d'identifier la masse et le +VCC.

Pour la connexion entre le PC et ton appareil, tu dois utiliser 3 fils:

•  broches GND connectés ensemble

• RX connecté à TX. On émets (TX) d'un côté et on reçoit (RX) de l'autre.

Pour identifier la broche TX, démarre ton appareil et regarde si une tension est présente sur l'une des 2 broches restantes. Au démarrage il y a beaucoup d'affichage qui va envoyer une tension sur la broche TX.

Dernière étape, trouver la vitesse à utiliser. Si durant la phase de démarrage de ton appareil, tu vois pleins de caractères bizarres, c'est que tes branchements sont corrects, mais pas la vitesse de ton terminal. Pour ça il faut tester différentes vitesses jusqu'à ce que du texte s'affiche correctement. Pour cette caméra, la vitesse est de 57600 bits/s.

Pour le terminal, j'utilise minicom avec cette commande

minicom -D /dev/ttyUSB0 -b 57600

Options:

-D => chemin du port série
-b => vitesse en bits par seconde

Voilà les premières lignes du démarrage de la caméra

U-Boot 1.1.3 (Aug 16 2012 - 09:57:38)
Board: Ralink APSoC DRAM:  64 MB
relocate_code Pointer at: 83fb4000
******************************
Software System Reset Occurred
******************************
spi_wait_nsec: 21 
spi device id: ef 40 18 0 0 (40180000)
find flash: W25Q128FV
raspi_init sector_size=65536, n_sectors=256
raspi_read: from:30000 len:1000 
.*** Warning - bad CRC, using default environment
============================================ 
Seedonk UBoot Version: 2.1(3.5.0.0)
-------------------------------------------- 
ASIC 5350_MP (Port5<->None)
DRAM_CONF_FROM: Boot-Strapping 
DRAM_TYPE: SDRAM 
DRAM_SIZE: 256 Mbits
DRAM_WIDTH: 16 bits
DRAM_TOTAL_WIDTH: 16 bits
TOTAL_MEMORY_SIZE: 32 MBytes
Flash component: SPI Flash
Date:Aug 16 2012  Time:09:57:38
============================================ 
icache: sets:256, ways:4, linesz:32 ,total:32768
dcache: sets:128, ways:4, linesz:32 ,total:16384
##### The CPU freq = 360 MHZ #### 
estimate memory size =64 Mbytes
Please choose the operation: 
  0: Load image 0 then write to Flash via TFTP. 
  1: Load system code to SDRAM via TFTP. 
  2: Load system code then write to Flash via TFTP. 
  3: Boot system code via Flash (default).
  4: Entr boot command line interface.
  7: Load Boot Loader code then write to Flash via Serial. 
  9: Load Boot Loader code then write to Flash via TFTP. 
0 
  
3: System Boot system code via Flash.
## Booting image at bc050000 ...
raspi_read: from:50000 len:40 
.   Image Name:   A200
  Created:      2015-09-22   5:59:14 UTC
  Image Type:   MIPS Linux Kernel Image (lzma compressed)
  Data Size:    5531883 Bytes =  5.3 MB
  Load Address: 80000000
  Entry Point:  803ae000
raspi_read: from:50040 len:5468eb 
..................................................................................... 
Verifying Checksum ... OK
  Uncompressing Kernel Image ...
U-Boot 1.1.3 (Aug 16 2012 - 09:57:38)
Board: Ralink APSoC DRAM:  64 MB
relocate_code Pointer at: 83fb4000
spi_wait_nsec: 21 

Une fois le démarrage terminé, ma joie aura été de courte durée puisque j'arrive sur un prompt demandant login et mot de passe. Bien sur les combinaisons du style admin/admin ou root/root ne fonctionnent pas, j'en ai essayé plusieurs sans succès. Dans les messages de démarrage je voit passer password for ‘root’ modified, je suppose que le login doit être root.

J'ai tenté le boot en single user. Au moment du U-Boot appuyer sur la touche 4 pour l'option Entr boot command line interface. On arrive sur un prompt, taper ces deux commandes:

setenv bootargs ${bootargs} init=/bin/bash
bootm

Laisser le système démarrer, on arrive sur un prompt où l'on peut exécuter quelques commandes mais en y regardant de plus près on est sur un autre système. Durant le boot je voit password for ‘admin’ modified. D'ailleurs dans le fichier /etc/passwd le seul utilisateur présent est admin avec comme mot de passe admin.

L'interrupteur de la caméra est en mode installation et je me connecte au WIFI de la caméra avec le PC. J'ai découvert une nouvelle interface web permettant de modifier divers paramètres mais après redémarrage ça ne reste pas.

http://10.68.68.22/ralink/home.asp

En tâtonnant j'ai réussi à trouver ces URL accessibles lorsque la caméra est en mode installation, mais là encore ça n'apporte rien de plus.

http://10.68.68.22/apcam/for-android/CamPreview.asp
http://10.68.68.22/apcam/for-android/aplist.asp
http://10.68.68.22/apcam/for-android/finish.asp
http://10.68.68.22/apcam/for-android/CreateAccount.asp
http://10.68.68.22/apcam/for-android/CamRegister.asp
http://10.68.68.22/apcam/for-android/VerifyMode.asp

http://10.68.68.22/apcam/adm/upload_firmware.asp
http://10.68.68.22/apcam/adm/management.asp

http://10.68.68.22/goform/getSystemSettings?systemModel&systemVersion&brandName&longBrandName
http://10.68.68.22/goform/camRegister
http://10.68.68.22/goform/syslog
http://10.68.68.22/goform/login
http://10.68.68.22/goform/createAccount
http://10.68.68.22/goform/surveySites
http://10.68.68.22/goform/getApSitesInfo
http://10.68.68.22/goform/succeedAccess
http://10.68.68.22/goform/apcamMode?action=clear
http://10.68.68.22/goform/apcamMode

Le flux vidéo est accessible à l'adresse http://10.68.68.22/apcam/for-android/CamPreview.asp sauf que quand on bascule l'interrupteur en mode utilisation, ces adresses deviennent inaccessibles. La solution serait de laisser la caméra en mode installation sauf que tu vas te retrouver avec une belle faille de sécurité dans ton réseau local. La caméra laisse un point d'accès WIFI ouvert, celui utilisé pour la configuration, tout en étant connectée à ton réseau local et l'interface web permet d'afficher le nom et la clé de ton réseau WIFI.
Autant dire que faire ça reviendrait à écrire en gros le code WIFI sur ta maison.

Dump du firmware

Vu que j'ai accès au port série, je vais tenter un dump du firmware pour voir si j'arrive à trouver ce mot de passe root ou des indications d'URL pour récupérer le flux vidéo. Le problème c'est qu'il faut faire ça au U-Boot alors que la caméra n'est connectée à aucun réseau. La seule méthode est de passer par le port série qui est très lent pour transférer des fichiers. La méthode est expliquée là mais je n'ai pas bien compris quelles valeurs il faut mettre, j'ai pas trouvé d'explications claires sur le fonctionnement du U-Boot et des firmwares. J'ai mis comme dans l'exemple et j'ai obtenu quelque chose d’intéressant. 

J'ai réussi à avoir le fichier /etc/passwd avec une unique ligne correspondant à root. Sauf que là encore, en cherchant l'empreinte du mot de passe sur les moteurs de recherche ça n'a rien donné.

John the ripper

C'est un programme pour casser les mots de passe et là encore c'est l'échec. J'ai laissé tourner 2 jours sans succès, le mot de passe doit être bien compliqué.

OpenWrt

J'ai essayé de voir s'il existait un firmware pour cette caméra mais sans succès.

Recherches sur internet

Si l'on cherche ES-CAM2A la seule chose que l'on trouve sont des notices ou des sites de vente. En revanche, en cherchant avec des indications affichés durant le boot, par exemple “seedonk” on trouve des choses intéressantes. D'autres modèles de marques différentes ont l'air d'être exactement le même matériel. Ce qui ne me surprend pas puisque ces caméras, comme d'autres produits sont vendus en marque blanche et le distributeur n'a plus qu'à y apposer sa marque.

Cette caméra serait identique à la Belkin NetCam et je suis tombé sur un communiqué de Belkin indiquant que les serveurs ont été arrêtes ce qui a rendu ces caméras inutilisables.

En cherchant encore, Belkin semble aussi utiliser le service iSecurity+.

Malheureusement, je n'ai trouvé personne qui s'est intéressé à ces caméras pour tenter de les faire fonctionner.

Conclusion: fuis les objets connectés dépendant exclusivement du cloud

Le bilan de cette expérience est que j'en suis dégouté que l'on puisse commercialiser des merdes pareilles et que l'on en a rien à foutre de l'écologie en générant des déchets.

Cette caméra pourrait fonctionner sans dépendre d'un serveur cloud et être parfaitement utilisable sans avoir besoin d'une connexion internet, sauf que le fabriquant à décidé qu'il fallait absolument passer par le cloud sans laisser de possibilité de l'utiliser en local. Au final tu te retrouves à devoir jeter un objet qui fonctionne et réponds à tes besoins, et après on viens nous dire que l'on consomme trop, que les ressources s'épuisent, qu'il y a de la pollution et on laisse faire ce genre de pratiques immondes. Une simple mise à jour du firmware permettant l'utilisation sans internet aurait suffit à rendre la caméra utilisable après l'arrêt des serveurs.

Maintenant, la prochaine fois que je vois un truc qui dépend du cloud, il restera à sa place: sur l'étagère du magasin ! Le cloud c'est de la merde !

On devrait obliger les fabricants à proposer un fonctionnement en local du matériel qu'ils vendent, cette caméra devrait pouvoir être utilisée sans avoir besoin d'une connexion internet.

Si quelqu'un a réussi à faire fonctionner cette caméra ou si tu as des idées, je suis preneur.