Comment verrouiller mon bootloader avec adb ?

Si votre appareil Android est modifié de quelque manière que ce soit, par exemple par une restauration personnalisée, un binaire ou tout autre moyen. Essayer de reverrouiller le chargeur de démarrage devrait (devrait au lieu de serait, car tous les OEM ne suivent pas le protocole) généralement causer le chargeur de démarrage à émettre une exception fatale comme : FAILED (remote: 'root type is risk') . Cela se produit en raison de modifications personnalisées de l'appareil. C'est une question de sécurité, si vous verrouillez votre bootloader avec un appareil modifié, vous risquez de le détruire.

Extraits techniques sur la vérification de Développeurs Android :

Fonctions sécurisées de l'AOSP Vérification de l'amorçage L'amorçage vérifié exige la vérification cryptographique de tout le code exécutable et de toutes les données qui font partie de la version d'Android en cours d'amorçage avant leur utilisation. Cela inclut le noyau (chargé depuis la partition boot), l'arborescence des périphériques (chargée depuis la partition dtbo), la partition système, la partition fournisseur, etc.

Les petites partitions, telles que boot et dtbo, qui ne sont lues qu'une seule fois sont généralement vérifiées en chargeant tout le contenu en mémoire, puis en calculant son hachage. Cette valeur de hachage calculée est ensuite comparée à la valeur de hachage attendue. Si la valeur ne correspond pas, Android ne se charge pas. Pour plus de détails,

Les partitions plus grandes qui ne tiennent pas dans la mémoire (comme les systèmes de fichiers) peuvent utiliser un arbre de hachage où la vérification est un processus continu qui se produit au fur et à mesure que les données sont chargées en mémoire. Dans ce cas, le hachage de la racine de l'arbre de hachage est calculé pendant l'exécution et est comparé à la valeur de hachage de la racine attendue. Android inclut le pilote dm-verity pour vérifier les partitions plus importantes. Si, à un moment donné, le hachage racine calculé ne correspond pas à la valeur de hachage racine attendue, les données ne sont pas utilisées et Android entre dans un état d'erreur.

Les hachages attendus sont généralement stockés à la fin ou au début de chaque partition vérifiée, dans une partition dédiée, ou les deux. Il est essentiel que ces hachages soient signés (directement ou indirectement) par la racine de confiance. À titre d'exemple, la mise en œuvre d'AVB prend en charge les deux approches.

La vérification peut échouer soit au moment du démarrage (par exemple, si le hachage calculé sur la partition de démarrage ne correspond pas au hachage attendu) soit au moment de l'exécution (par exemple, si le dm-verity rencontre une erreur de vérification sur la partition système). Si la vérification échoue au moment du démarrage, le périphérique ne peut pas démarrer et l'utilisateur final doit suivre les étapes pour récupérer le périphérique.

Si la vérification échoue au moment de l'exécution, le flux est un peu plus compliqué. Si le dispositif utilise dm-verity, il doit être configuré en mode de redémarrage. En mode redémarrage, si une erreur de vérification est rencontrée, le périphérique est immédiatement redémarré avec un drapeau spécifique activé pour indiquer la raison. Le chargeur de démarrage doit remarquer ce drapeau et faire basculer le dm-verity en mode d'utilisation des erreurs d'E/S (eio) et rester dans ce mode jusqu'à ce qu'une nouvelle mise à jour ait été installée.

Lors du démarrage en mode eio, l'appareil affiche un écran d'erreur informant l'utilisateur qu'une corruption a été détectée et que l'appareil risque de ne pas fonctionner correctement. L'écran s'affiche jusqu'à ce que l'utilisateur le quitte. En mode eio, le pilote dm-verity ne redémarre pas le périphérique si une erreur de vérification est rencontrée, mais une erreur EIO est renvoyée et l'application doit traiter l'erreur.

L'objectif est soit de lancer la mise à jour du système (afin d'installer un nouveau système d'exploitation sans erreurs de corruption), soit de permettre à l'utilisateur de retirer le maximum de données de son appareil. Une fois le nouveau système d'exploitation installé, le chargeur de démarrage remarque le nouveau système d'exploitation installé et repasse en mode de redémarrage."

Sans savoir quel appareil vous avez ou quelle version d'Android vous utilisez. Je ne serai pas en mesure de donner une conclusion détaillée adaptée à votre appareil mais plutôt une simple conclusion générique. Méfiez-vous également de l'anti-roll back si applicable.

Dans ce cas, obtenez et téléchargez le firmware d'usine signé. Utilisez fastboot, le mode téléchargement, ou tout autre mode utilisé par votre appareil pour effacer et flasher les partitions. En fonction du protocole, effacez puis flashez le firmware d'usine signé, ce qui vous ramène complètement à l'état d'origine. Redémarrez le bootloader et ré-émettez la commande fastboot oem relock XXXXXXXXXXXXXXX et vous devriez être prêt à partir.

Pour empêcher tout accès non autorisé à vos données personnelles, le verrouillage du bootloader supprimera également toutes les données personnelles de votre téléphone.

C'est simple, il n'y a pas besoin de sauter à travers une liste de cerceaux pour éviter de flasher le firmware afin de préserver les données de l'utilisateur, sauf si vous ne pouvez pas trouver le firmware d'usine signé, mais ce serait une autre question.