Ainsi fu le contexte :
J'ai un vieux smartphone, plus du tout à jour, avec partition chiffré et mot de passe robuste très robuste …
Tout allait bien jusqu'a ce que je change mon mot de passe de "de session" (android n'a pas vraiment de session, en tout cas cela ne fonctionne pas tout a fait comme sur un GNU\Linux standard). Changement de mot de passe qui a été fait dans un contexte ou je n'ai pas su mémoriser le nouveau mot de passe.
Bien sur comme je suis un débile (ou quelqu'un qui doit faire face a des priorité d'ordres vitales) je n'ai pas fini le backup automatique de mes data et j'ai aussi un autre souci j'aime bien faire les choses que je pense possible si elles me permettent de progresser. J'ai donc décidé que j'allais regagner l'acces a mon téléphone en resetant le mot de passe.
Certains me diront facile il suffit de passé par le compte google ou certains mécanisme constructeurs que neni, ici tout cela ne marche pas (smartphone dégoogelisé + rom android custom). Il est a noté également que le mode développeur est également désactivé (no adb available broth). Mais j'ai un accès a adb et le téléphone est assez ancien.
La planification c'est facile
Après quelques heures de recherche (et de connaissance GNU\Linux) la solution est donc simple boot sur twrp (le système de recovery) monté la partition chiffrée, supprimer le mot de passe reboot et mettre une nouvelle passe phrase. Simple oui mais spoiler alerte : entre le temps de découverte de «j'ai perdu mon mot de passe» a j'ai récupéré l'accès a mon téléphone il s'est passé presque 7 mois avec en temps de travail réél sur le sujet entre 3 et 4 semaines (5/7j 8-12h). Objectivement cela m'aurait pris 2/3 fois plus de temps sans l'aide de l'ia. Allez deep dive.
A l'aventure camarade
On lance le mode recovery on boot twrp et on monte /data. Et bien non cela ne marche pas du tout. Ok probablement version pas a jour ou quelque chose du genre. dl d'une version plus a jour et qui soit supporté par le téléphone (donc pas la derniere), même message… Investigation, tentative de montage via adb (celui de twrp) => non support du déchiffrement. Ok qu'a cela ne tienne ça doit bien se trouver sur internet et bien visiblement je suis pas très bon car j'ai pas trouvé, sniff. Pas grave tout ce stuff est Libre alors on va simplement setup un gcc, télécharger les sources et recompiler ça (les readme git donne deux commande a faire), easy squidy. Mais bien sur Human cause toujours.
Ok bon pour compiler TWRP (je ne parle pas des dépendances) il ne faut pas un dépot mais en gros trois : Twrp, android, la partie spécifiques au modèle de téléphone et chaque dossier doit être au bon endroit (C'est extremement important). Écrit comme ça semble simple et clair mais rien que pour bien comprendre cela, trouvé les bonnes sources et les commandes qu'il faut c'est déjà au moins une bonne dizaine d'heure et cela se fait en même temps que des taches de tentative de compilation. Car oui la compilation est bien funky aussi mais d'abord un poil de configuration.
La configuration se fait via un fichier tout simple préremplis c'est FAUX !!!! Il y a plusieurs fichiers mais c'est pertinent comme organisation ne soyons pas pute a clic. Il est propre a chaque modele et les options dépendent de ce que supporte le modèle entre autres choses.
J'ai évoqué ce qu'est TWRP mais je n'ai pas évoqué les dépendances donc en vrac et de manière pas exhaustive : c, c++, java, python. Évidement avec cela arrive plusieurs choses des numero de version, des numéros de norme. Sur la partie "haut niveau", il y a des soucis de version dans le systeme le plus adapté pour la compilation entre les versionde java, celle de python et les lib native OS et celle cpp et consort. Donc compilation il y a aussi. Mais là ou sur des projets du quotidien pour un dev on a surtout deux (i386, amd64) voir plus qu'une architecture (voir pas du tout avec certains langage) ici c'est un peu plus la fête car nous avons de l'arm en plus. L'architecture est donc dépendante du modèle de téléphone. Qui dit compilation dit linkage, statique ou dynamique bref ici c'est vraiment le bazar. Il a fallu éditer, reconfigurer des makefile. Ah oui pourquoi et bien parce que dans la phase de configuration il a fallu rajouter la prise en compte des bibliothèques cryptographique et verifier certaines compatibilité comme par exemple selinux sachant que chacun des composants TWRP avance a son rythme et qu'il faut la bonne version n'existant quasiment presque aucune maintenance et retro compatibilité sur les composants logiciels. Quand enfin une compilation peut se lancer alors il y a la phase de correction des version de cpp a utiliser pour la prise en charge de certaine fonctionnalité de langage (type null/nullptr, etc). Finalement j'ai obtenu une image twrp a envoyer mais avec une erreur a la compilation concernants la taille, elle était trop grosse ( ;) l'image générée) pour la partition, ce qui pouvait potintiellement entrainer des soucis irréversible sur le téléphone sauf a tout réinstaller. Pour corriger cela il a "suffit" de modifier un peu les configuration de l'image twrp attendue (suppression de certaine langue, qualité du theme). Une fois rebuild avec succès j'ai pu envoyer l'image sur le téléphone. Cette partie à vraiment été la plus longue, la plus complexe de part la necessité de descendre profond dans les rouages de l'organisation globale. J'ai scripté et automatisé le rebuild pour les version dont j'avais besoin pour gagner du temps. En gros un tmux en mode start script et debug plus deux autres, une dédié a la récupération des logs et l'autre a l'édition des fichiers.
La presque fin
Une fois l'image TWRP envoyée j'ai rencontré un nouveau souci, la commande de decrypt était bien connu mais impossible de monté la partition … damned. Après investigation, travail en binome avec un llm et quelques commandes adb le fstab (fichier qui défini le montage des partitions) était corrigé (souci d'option de montage) et j'avais accès a /data/system !!! A ce moment là j'ai pu faire une copie du fichier de mot de passe de session (possible car ancien téléphone) et supprimé l'existant avant de relancer le boot. Qui n'a juste pas marché, je bouclais sur twrp car j'avais oublié de nettoyer les partitions cache et dalvik mais j'avoue avoir eu très peur d'avoir complètement cassé le système et devoir repartir pour un cycle de plusieurs semaine.
La Fin
Le téléphone est de nouveau opérationnel, l'accès au données rétablie, mon cerveau a monté de niveau sur ces aspect là. Il est important donc de noté que le fait d'avoir 2 couches de sécurités est important une «physique» et une «logiciel» en effet il est compliqué d'avoir quelque chose d'a la fois robuste en terme d'utilisabilité et de sécurité. Le mot de passe matériel qui devrait toujours être le plus fort des deux est plus facile a retenir car ne demande pas de rotation aussi régulière que le mot de passe de session et protège des attaques physiques et de perte saisie tandis que le mot de passe de session permet de garantir un peu d'intimité avec les gens du quotidien. Dans l'absolu la sécurité n'existe pas mais si l'on peut faire en sorte d'etre le plus sécurisé possible il faut pas se priver.
NOTES :
- Avoir 2 version de twrp une de production une de debug/maintenance.
- Les projets upstream devrait mettre en place des api/couche interne permettant de compiler avec des techno recentes pour d'anciens modèle et j'ai conscience que le support de techno proprio et leurs retro ingéniérie est un véritable enfer surtout quand l'on manque de bras répondant a la triade éthiques, compétences, temps (ECT).