Sommaire
- Le robot, sa vie son histoire
- Premier round et fiche technique
- Deuxième round et reverse engineering
- Certificats SSL et magasin de CA racines
- Epilogue
Salut les moules,
Je profite du retour des longues soirées d'hiver pour vous conter l'histoire de la résurrection inespérée d'un robot cuiseur délaissé par son fabricant.
Le robot, sa vie son histoire
L'histoire commence il y a déjà bien longtemps en 2015 quand ma femme a fait l'acquisition d'un robot i-Cook'in de Guy Demarle (plus de 1000€ quand même).
Il s'agit d'un robot de cuisine dit "connecté". En gros, le robot est connecté à une base de données de recettes de cuisine.
Tu lances la recette et le robot récupère puis t'indique l'algorithme les étapes de la recette pas à pas (ingrédients, quantité, cuisson, mixage etc.)
Sans connexion internet, il reste utilisable mais tu dois tout faire manuellement (programmer les durées, définir chaque étape,…), ce qui enlève beaucoup l'intérêt de la fonction "connectée" de l'appareil…
Bref, tout va bien jusqu'à un beau (ou pluvieux je sais plus) jour de mars 2026. Sur l'écran, un "problème de connexion" et une erreur Null NetworkResponse, me renvoyant vers un SAV.
Je me dis d'abord : "bah, leur serveur est down, d'ici quelques jours ce sera réparé, flemme, patientons".
Sauf que plusieurs mois plus tard, le problème est toujours là. Plus moyen d'accès aux recettes, utilité du robot connecté largement entamée.
Et pour couronner le tout : le numéro de téléphone indiqué pour le SAV est… non attribué.
Le robot n'étant plus vendu depuis de nombreuses années, je me suis dis : çà y est, Demarle arrête le serveur et abandonne ses clients.
Et là tu te rappelles les nombreuses heures ou tu moulais sur Linuxfr à lire les articles sur les abandonwares, l'importante du logiciel libre, les problèmes de dépendances envers les fabricants et le Right To Repair…
Premier round et fiche technique
Plein d'espoir, je commence mes petites recherches sur internet. D'autres personnes ont certainement déjà eu le problème, je trouverai une jolie solution toute simple, tout sera résolu en moins de 5 minutes, avec la paix dans le monde (et les ménages), mais… non. Rien. Ou plutôt personne ne semble rencontrer le problème. Ou alors personne ne se plaint, ou personne n'utilise encore ce robot, je sais pas…
Là j'ai envie de me mettre en PLS comme diraient mes ados.
Mais non, sursaut d'orgueil ou temps à perdre (ou quelque chose comme çà), je vais creuser et examiner l'appareil.
Après un premier tour d'horizon :
- aucune mise à jour disponible pour l'appareil chez le fabricant (la dernière date de 2018…)
- l'interface du robot est une tablette Android (visible dans les stacktraces quand le robot plante :D)
- elle se connecte (via wifi 2.4GHz) à mon réseau et effectue des requêtes SSL à api.guydemarle.com
- Aucun APK trouvable, ni sur Internet (Play Store, dépôts publics) ni sur les serveurs Guy Demarle (accès restreint)
- API privée accessible uniquement avec authentification mTLS du hardware
- Aucun port TCP ouvert en écoute
- Aucun port USB visible sur l'extérieur de l'appareil
J'ai tenté un MITM avec du ARP spoofing pour observer le trafic entre le robot et le serveur mais sans succès. Ce sont des connexions HTTPS et les certificats sont réellement vérifiés des deux côtés, pas possible de se substituer à l'un ou l'autre.
Pour un objet connecté, c'est plutôt une bonne nouvelle, mais cela ne fait pas du tout mes affaires.
Deuxième round et reverse engineering
Après quelques semaines à mouler de rumination et de frustration, j'ai profité d'un WE un peu plus calme pour sortir mon plus beau tournevis.
Bonne nouvelle, l'appareil est ouvrable facilement via des vis parfaitement standard (tête PZ2).
Dedans, sans surprise, on découvre la tablette, alimentée directement en 5V et connectée au hardware (balance, résistance chauffante etc.) via un port micro-USB.
Hop, je décolle et déconnecte le câble micro-USB et connecte mon PC à la place.
Sachant que c'est une tablette Android, je tente un adb devices et… bingo je vois un device en Android 4 avec un hardware plus ou moins exotique (Rockchip rk312x / GoClever Tab R83), accès root direct et /system déjà monté en RW.
Là je respire, et enchaîne avec la récupération de l'APK et des fichiers depuis la tablette. On y trouve d'ailleurs aussi les identifiants de connexion et API keys, le certificat privé du hardware et le username et le mot de passe de ma femme… stocké en clair. Mouais.
Ensuite: décompilation (avec jadx) et analyse avec un peu d'IA (bah oui çà aide quand même, j'ai pas plus d'un WE pour y arriver). Mais je manque d'indice pour spotter le souci.
Et malheureusement quand la tablette est connectée au PC, l'application du robot ne se lance pas, attendant probablement la détection de son hardware.
Comme il n'y a qu'un seul port micro-USB, impossible donc en même temps de jouer avec le robot pour reproduire le problème et garder le PC connecté au port pour avoir des logs en temps réel.
Heureusement, même sur cette tablette en Android 4, on peut activerr l'ADB par wifi. Hop un adb tcpip 5555 pour l'activer et libérer le port, puis surtout reproduire le problème et visualiser les logs en direct.
Certificats SSL et magasin de CA racines
Et là un log apparaît :
com.android.volley.NoConnectionError: javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found
Le robot n'ayant plus reçu de mise à jour depuis de nombreuses années (2018 pour les plus attentifs), un problème de validation de certificat SSL se révèle, cassant les connexions SSL vers le serveur. J'ai fini par déterminer que le serveur api.guydemarle.com a migré en mars vers un certificat TLS récent remontant à un CA racine absent du magasin de CA de la tablette (datant de 2015 je le rappelle). C'est certainement passé inaperçu chez Demarle car le changement s'est opéré dans la chaîne en amont du certificat serveur…
A partir de là, la correction a été relativement simple, avec l'ajout du CA racine manquant (au format Android : nom = hash du sujet):
adb push fix-ca/35105088.0 /system/etc/security/cacerts/35105088.0
adb shell chmod 644 /system/etc/security/cacerts/35105088.0
Puis un reboot du robot.
Puis jouer mon rôle de sauveur auprès de ma femme et frimer auprès de mes potes.
Epilogue
Et hop, le robot retrouve une nouvelle jeunesse, retour des petits plats faciles.
Que retenir ?
Déjà je me dis que ce scénario va fatalement se reproduire avec n'importe quel objet connecté suffisamment sécurisé (se connectant en SSL) dès le moment où il n'est plus maintenu par son fabricant.
Et ici, j'ai encore de la chance que le hardware était facilement démontable avec du software bien connu.
Si le fabricant cesse son service / arrête son serveur, je pense pouvoir recréer un service similaire hébergé chez moi (bon reste le problème de la DB des recettes), çà fait rêver…
Et puis peut-être que ce journal rendra un peu d'espoir à un cuisiner quelque part dans le monde ! bon ok j'arrête de rêver.
Bonne fin de WE, ou bonne semaine et peut-être bon appétit !
PS: si cela vous intéresse j'ai des photos du démontage que je peux ajouter (mince comment on fait ?), mais là flemme, j'ai faim
# Photos
Posté par Olivier Esver (site web personnel) . Évalué à 4 (+2/-0).
Je veux bien voir les photos du démontage.
Donc si je comprends bien, la "tablette" commande le robot par la liaison USB ? Aucune autre connexion ?
Si c'est ça, cela veut dire que si un jour la "tablette" meurt, comme tu as récupéré tous les APK, tu pourrais te refaire une "tablette" avec un soft équivalent avec du reverse encore plus poussé.
S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.
# La réponse est 4
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3 (+0/-0).
Est-ce que le robot dispose par hasard du fameux certificat emudhra dont la clé privée est 4? Parce que cela peut être un moyen de contourner ce problème en créant un certificat valide.
Si le serveur de l'autre côté vérifie le certificat du robot, par contre, ça ne suffira pas.
J'avais vu une démo d'une autre méthode (lors des rmll il me semble) qui consiste à mettre un breakpoint dans les fonctions read et write oes sockets de openssl, là où l'application envoie et reçoit (en clair) les données qui vont ensuite être chiffrées en https, afin d'espionner le traffic.
Vu que ça va peut-être être le dernier robot à se connecter au service, il est temps de faire un peu d'enregistrement de données avant que le serveur soit hors ligne, cela facilitera grandement l'écriture d'un serveur de remplacement le jour où ce sera nécessaire.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.