¿Por qué "adb root" no hace nada?

Tengo un OnePlus 6T. Está rooteado por TWRP y Magisk. he puesto ro.debuggablea 1. Pero cuando escribo adb roothace esto:

C:\Users\ituser> adb root

C:\Users\ituser> adb remount
Not running as root. Try "adb root" first.

ingrese la descripción de la imagen aquí

Ni siquiera puedo usar adb pullen archivos del sistema.

Me pregunto si no arroja un mensaje de error. Que yo sepa, adb rootno funciona en "compilaciones de producción" (como ROM de stock, incluso si está rooteado). Entonces, a menos que tenga una "ROM de desarrollador", las posibilidades de que esto haga algo son bastante bajas.

Respuestas (1)

En producción, usercompilación de una ROM, no puede comenzar adbdcomo root a menos que la ROM o al menos el adbdbinario se reconstruya con las modificaciones necesarias. El motivo es el ALLOW_ADBD_ROOTindicador de compilación ( 1 , 2 ) .
Es por eso que se desarrolló adbd Insecure , que reemplazó el adbdbinario por uno modificado.

En una compilación userdebugo eng(o con un binario inseguro adbdextraído de cualquiera de estos tipos de compilación):

  • Si ro.secure=0, adbdse ejecuta como root cuando está habilitado desde Configuración (Opciones de desarrollador) ( 3 ) . Sin embargo adb root, no funcionará ( 4 ) .
  • Si ro.debuggable=1, adb rootse reiniciará adbdcomo root ( 5 , 6 ) .

Sin embargo adbd, se puede construir a partir del código fuente modificado para omitir todas estas comprobaciones. Además, también se debe tener cuidado con SELinux, si está en enforcingmodo. adbddebe poder ejecutarse en un contexto de superusuario sin restricciones : u:r:su:s0 ( 7 , 8 ) , que no es el caso de las usercompilaciones ( 9 , 10 , 11 ) . Ver esta respuesta para más detalles.

Las propiedades de Android se pueden sobrescribir utilizando /data/local.propon userdebug/ engbuilds, es decir, si ALLOW_LOCAL_PROP_OVERRIDEse establece el indicador de compilación ( 12 , 13 ) . Pero esto no funciona para ro.*las propiedades ( 14 ) y lo mismo ocurre con la setpropherramienta de línea de comandos. Sin embargo , el archivo default.prop/ prop.default, que podría ubicarse en varias ubicaciones posibles según las configuraciones de compilación del dispositivo ( 15 ) , se puede modificar para cambiar las propiedades de solo lectura (si no se ha configurado ya desde algún otro archivo o *.rcarchivo de propiedades). Si el archivo está en ramdisk, boot.imgdebe modificarse.

La herramienta resetprop de Magisk puede restablecer las propiedades de solo lectura incluso si ya están configuradas. ro.securey ro.debuggablees posible que ambos hayan sido modificados como parte de la política de MagiskHide ( 16 ) , que puede revertir para permitir que adbdse ejecuten como root.

Otra propiedad relacionada es ro.adb.secure, que controla la autenticación de clave pública. Al configurar / builds, se omite la autenticación (ningún ro.adb.secure=0mensaje nunca) ( 17 , 18 , 19 ) ; relacionado: Ubicación de almacenamiento de “adb_keys” .userdebugengdevice unauthorized

Como información adicional, el tipo de compilación de la rom se puede encontrar mirandoro.build.type
¿Por qué "adb root" no hace nada?
RespuestasAquíPolítica de privacidad1y, 0v