La récupération du système d'Android est-elle une question de firmware ou d'Android ? Peut-on empêcher la réinitialisation d'usine ?

La récupération Android fait partie de boot.img situé à /boot partition. Le signal d'appui sur une touche pour le chargeur de démarrage et le mode de récupération est codé en dur dans le chargeur de démarrage Android (ABL). L'ABL écoute le signal d'appui sur la touche et lance le chargeur de démarrage ou le mode de récupération. Sur les appareils Qualcomm Snapdragon, si l'ABL est corrompu, l'Extended Bootloader (XBL) de Qualcomm revient au mode EDL pour le flashage des partitions de l'appareil.

Voir le flux de démarrage de l'appareil avec le SoC de Qualcomm :

Dans cette image, elle montre la récupération du noyau, ce qui n'est plus le cas. Dans les slots A/B, la récupération fait partie de boot.img pour qu'il puisse être démarré directement par ABL.

Android a mis en place une sécurité physique faible. Une personne disposant d'un accès physique peut accéder au chargeur de démarrage et au mode de récupération en redémarrant brutalement l'appareil et en appuyant sur des combinaisons de touches. Le redémarrage brutal est câblé dans le SoC. En appuyant sur le bouton d'alimentation pendant 15 secondes, le SoC redémarre et cette fonction est indépendante du système d'exploitation, mais la politique de redémarrage, comme le délai d'attente avant d'appuyer sur le bouton, est codée en dur dans le firmware du SoC.

Si la protection contre la réinitialisation en usine (FRP) ne présente aucune vulnérabilité non corrigée, elle empêchera la réutilisation d'un appareil volé après une réinitialisation en usine sans authentification de votre compte. Mais les équipementiers l'appliquent mal et ses méthodes de contournement deviennent rapidement disponibles.

Une bonne conception de la sécurité est celle où une personne non autorisée ne devrait même pas avoir l'autorisation de réinitialiser l'appareil. Les appareils Android 8+ sont parfaitement capables d'authentifier le mode bootloader et le mode recovery. Les appareils Android modernes sont équipés de TEE qui se réveille au démarrage et, sur les appareils Qualcomm, il est réveillé par XBL. TEE peut effectuer une authentification biométrique ou utiliser une authentification par code PIN pour le verrouillage de l'écran, même si le système d'exploitation hôte n'est pas encore chargé. La raison pour laquelle l'AOSP et les OEM ne l'appliquent pas n'a pas de justification.

Que votre chargeur de démarrage soit verrouillé ou déverrouillé, il n'y a pas de protection anti-effacement. Mais au moins avec le bootloader verrouillé, le FRP entièrement patché ne peut pas être contourné.

C'est le dilemme de l'oeuf et de la poule. vous ne pouvez pas faire de modifications sur un bootloader verrouillé. un bootloader déverrouillé permet au voleur de faire tout ce qu'il veut.

Vos données sont protégées contre le vol (par cryptage, et la clé de cryptage est effacée lors de la réinitialisation de l'usine). Votre appareil est protégé contre la réutilisation par un voleur tant que la protection par réinitialisation d'usine FRP est activée (et que vous avez un compte google play lié). Il ne protège pas vos données de l'effacement et la réinitialisation d'usine est toujours possible, mais le voleur a besoin de votre mot de passe google afin d'utiliser le téléphone à nouveau. déverrouiller bootloader désactivera FRP

après une réinitialisation d'usine, tant que le FRP est activé, le voleur ne peut pas terminer la configuration initiale, il ne peut donc pas activer le déverrouillage OEM dans les options des développeurs et n'a pas la possibilité de déverrouiller le bootloader. cependant, certains hacks sont possibles pour contourner le FRP, mais cela ne concerne pas la sécurité de vos données.

le plus intéressant est le cryptage surmonté - tant que les informations d'identification de votre écran de verrouillage font partie du cryptage, vos données sont sécurisées. Mais si votre appareil utilise le cryptage FDE avec default_password, l'attaque (sur le bootloader verrouillé) est possible pour les appareils pour lesquels les OEM ont divulgué des programmateurs/outils pour un accès brut.