Intenté desbloquear mi bootloader con fastboot pero eso no funcionó
>fastboot oem relock XXXXXXXXXXXXXXXX
FAILED (remote: 'root type is risk')
Finished. Total time: 0.014s
Así que pensé que adb funcionaría (si es posible)
Intenté desbloquear mi bootloader con fastboot pero eso no funcionó
>fastboot oem relock XXXXXXXXXXXXXXXX
FAILED (remote: 'root type is risk')
Finished. Total time: 0.014s
Así que pensé que adb funcionaría (si es posible)
Si su dispositivo Android está modificado de alguna manera, como tener una recuperación personalizada, binarios, o de cualquier otra forma. Intentar volver a bloquear el gestor de arranque generalmente debería causar que el gestor de arranque emita una excepción fatal como: FAILED (remoto: 'root tipo es riesgo')
. Esto sucede debido a las modificaciones personalizadas del dispositivo. Es una medida de seguridad, si bloquea su gestor de arranque con un dispositivo modificado es muy probable que termine brickeando su dispositivo.
Fragmentos técnicos sobre la verificación de Android Developers:
Funciones Seguras de AOSP Verificación de Arranque El arranque verificado requiere verificar criptográficamente todo el código ejecutable y los datos que forman parte de la versión de Android que se está arrancando antes de ser utilizados. Esto incluye el kernel (cargado desde la partición de arranque), el árbol de dispositivos (cargado desde la partición dtbo), la partición del sistema, la partición de proveedor, y así sucesivamente.
Particiones pequeñas, como boot y dtbo, que se leen solo una vez, suelen ser verificadas cargando todo el contenido en la memoria y luego calculando su hash. Este valor de hash calculado se compara con el valor de hash esperado. Si los valores no coinciden, Android no se cargará. Para más detalles,
Particiones más grandes que no caben en la memoria (como sistemas de archivos) pueden utilizar un árbol de hash donde la verificación es un proceso continuo que ocurre a medida que los datos se cargan en la memoria. En este caso, el hash root del árbol de hash se calcula durante la ejecución y se comprueba con el valor esperado de hash root. Android incluye el controlador dm-verity para verificar particiones más grandes. Si en algún momento el hash root calculado no coincide con el valor esperado de hash root, los datos no se utilizan y Android entra en un estado de error.
Los valores de hash esperados suelen almacenarse al final o al principio de cada partición verificada, en una partición dedicada, o en ambos sitios. Es crucial que estos valores de hash estén firmados (ya sea directa o indirectamente) por la root de confianza. Como ejemplo, la implementación de AVB admite ambos enfoques.
La verificación puede fallar ya sea en el momento del arranque (por ejemplo, si el hash calculado en la partición de arranque no coincide con el hash esperado) o en tiempo de ejecución (por ejemplo, si dm-verity encuentra un error de verificación en la partición del sistema). Si la verificación falla en el momento del arranque, el dispositivo no podrá arrancar y el usuario final deberá seguir pasos para recuperar el dispositivo.
Si la verificación falla en tiempo de ejecución, el flujo es un poco más complicado. Si el dispositivo utiliza dm-verity, debería estar configurado en modo de reinicio. En el modo de reinicio, si se encuentra un error de verificación, el dispositivo se reinicia inmediatamente con una bandera específica establecida para indicar la razón. El cargador de arranque debería notar esta bandera y cambiar dm-verity para utilizar el modo de Error de E/S (eio) y permanecer en este modo hasta que se haya instalado una nueva actualización.
Cuando se arranca en el modo eio, el dispositivo muestra una pantalla de error informando al usuario que se ha detectado corrupción y que el dispositivo puede no funcionar correctamente. La pantalla se muestra hasta que el usuario la cierre. En el modo eio, el controlador dm-verity no reiniciará el dispositivo si se encuentra un error de verificación, en cambio se devuelve un error de E/S y la aplicación debe lidiar con el error.
La intención es que el actualizador del sistema se ejecute (para que se pueda instalar un nuevo SO sin errores de corrupción) o que el usuario pueda extraer la mayor cantidad de sus datos del dispositivo. Una vez que se haya instalado el nuevo SO, el cargador de arranque notará el nuevo SO instalado y cambiará de nuevo al modo de reinicio."
Sin saber qué dispositivo tiene o qué versión de Android está utilizando, no podré ofrecer una conclusión detallada adaptada a su dispositivo, pero sí una genérica. También tenga cuidado con la prevención de retroceso si corresponde.
Dicho esto, obtenga y descargue el firmware de fábrica firmado. Utilice fastboot, el modo de descarga, o cualquier modo que su dispositivo utilice para borrar y flashear particiones. Dependiendo del protocolo, borre y luego flashee el firmware de fábrica firmado para volver completamente a la configuración original. Reinicie el cargador de arranque y vuelva a emitir el fastboot oem relock XXXXXXXXXXXXXXX
y debería estar listo para seguir adelante.
Para evitar el acceso no autorizado a sus datos personales, bloquear el gestor de arranque también eliminará todos los datos personales de su teléfono.
Manténgalo simple, no es necesario hacer malabares para evitar flashear el firmware con el fin de preservar los datos del usuario, a menos que no pueda encontrar firmware de fábrica firmado, pero eso sería otra cuestión.
PreguntAndroid es una comunidad de usuarios de Android en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.
4 votos
¿Tu dispositivo Android está modificado de alguna manera, como una recuperación personalizada, binario, u otra forma? La razón por la que usualmente ocurre esta excepción fatal es precisamente por eso. Es una medida de seguridad; si bloqueas el bootloader con un dispositivo modificado, brickearás tu dispositivo. El bootloader te impide bloquearlo porque al verificar tu dispositivo, no pasó como un firmware de fábrica original. Necesitas tener un dispositivo sin modificaciones para volver a bloquear el bootloader. En otras palabras, tu bootloader acaba de salvarte de brickear tu dispositivo. Si tu dispositivo está modificado, entonces convertiré este comentario en una respuesta
0 votos
No estoy seguro si todavía tengo magisk flasheado. Ya no tengo twrp, lo eliminó después de que flasheé una recuperación, también podría ser la recuperación...
0 votos
@lobstermaster, ¿podrías por favor informarnos sobre qué dispositivo estás hablando y con qué versión de Android? También tu pregunta trata sobre bloquear el bootloader mientras la primera declaración menciona el desbloqueo. Si está desbloqueado, ¿qué método usaste para desbloquearlo? Por favor agrega detalles editando la pregunta.