La recuperación del sistema de Android, ¿es cosa del firmware o de Android? ¿Se puede evitar el restablecimiento de fábrica?

La recuperación de Android forma parte de boot.img situado en /boot partición. La señal de pulsar la tecla para el cargador de arranque y el modo de recuperación están codificados en el cargador de arranque de Android (ABL). ABL escucha la señal de pulsación de la tecla y arranca el cargador de arranque o el modo de recuperación. En los dispositivos Qualcomm Snapdragon, si el ABL está dañado, entonces el Extended Bootloader (XBL) de Qualcomm vuelve al modo EDL para flashear las particiones del dispositivo.

Vea el flujo de arranque del dispositivo con el SoC de Qualcomm:

En esta imagen, se muestra la recuperación de las botas del kernel, que ya no es el caso. En las ranuras A/B, la recuperación es parte de boot.img para que pueda ser arrancado directamente por ABL.

Android ha implementado débilmente la seguridad física. Alguien con acceso físico puede acceder al bootloader y al modo de recuperación reiniciando el dispositivo y pulsando combinaciones de teclas. El reinicio duro está conectado al SoC. Al pulsar el botón de encendido durante 15 segundos, el SoC se reinicia y esta función es independiente del sistema operativo, pero la política de reinicio, como el temporizador de retardo de pulsación, está codificada en el firmware del SoC.

Si la protección de restablecimiento de fábrica (FRP) no tiene vulnerabilidades sin parchear, evitará la reutilización del dispositivo robado tras el restablecimiento de fábrica sin autenticar su cuenta. Pero los fabricantes de equipos originales la implementan mal y sus métodos para eludirla están disponibles rápidamente.

Un buen diseño de seguridad es aquel en el que una persona no autorizada ni siquiera debería tener autorización para restablecer el dispositivo de fábrica. Los dispositivos Android 8+ son totalmente capaces de autenticar el modo bootloader y el modo recovery. Los dispositivos Android modernos están equipados con TEE que se despierta en el arranque y en los dispositivos Qualcomm, se despierta por XBL. TEE puede realizar la autenticación biométrica o puede utilizar la autenticación por PIN de la pantalla de bloqueo, incluso si el sistema operativo anfitrión no está cargado todavía. Por qué AOSP y los OEMs no lo están aplicando no tiene una excusa que lo justifique.

Tanto si tu bootloader está bloqueado como si está desbloqueado, no hay protección contra el borrado. Pero al menos con el bootloader bloqueado, el FRP totalmente parcheado no puede ser eludido.

no se pueden hacer modificaciones en el bootloader bloqueado. el bootloader desbloqueado permite al ladrón hacer todo lo que quiera

Sus datos están protegidos de ser robados (por el cifrado, y la clave de cifrado se borra en el restablecimiento de fábrica). Su dispositivo está protegido contra la reutilización por el ladrón, siempre y cuando la protección de restablecimiento de fábrica FRP está activada (y usted tiene cuenta de Google Play vinculado). No protege tus datos del borrado y el restablecimiento de fábrica sigue siendo posible, pero el ladrón requiere tu contraseña de Google para poder utilizar el teléfono de nuevo. el desbloqueo del bootloader desactivará el FRP

después de restablecer la fábrica, siempre y cuando FRP está activado, ladrón no puede terminar la configuración inicial, por lo tanto no puede habilitar el desbloqueo OEM en las opciones de los desarrolladores y no tiene disponibilidad para desbloquear el gestor de arranque. sin embargo, algunos hacks son posibles para by-pass FRP, pero que no se refiere a la seguridad de sus datos

Lo más interesante es superar el cifrado: mientras tus credenciales de la pantalla de bloqueo formen parte del cifrado, tus datos estarán seguros. Pero si su dispositivo está ejecutando el cifrado FDE con default_password, el ataque (en el cargador de arranque bloqueado) es posible para los dispositivos donde los OEMs filtraron programadores/herramientas para el acceso crudo