URL: https://linuxfr.org/users/delaunoi/journaux/robot-cuiseur-abandonne-et-reverse-engineering Title: Robot cuiseur abandonné et reverse engineering Authors: Meap Date: 2026-11-01T18:21:07+01:00 License: CC By-SA Tags: cacert, android, abandonware, maintenabilite, robot et rétro-ingénierie Score: 17 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_