¿Por qué no se puede simplemente copiar el binario su (respuesta técnica, por favor)?

He rooteado varios dispositivos Samsung y el "objetivo" subyacente, por así decirlo, parece ser obtener el subinario /system/xbine instalar Superuser.apk .

Mi pregunta es ¿por qué uno tiene que pasar por todos estos aros para rootear el teléfono (instalar una recuperación personalizada y flashear la ROM previamente rooteada o explotar la instalación actual)? ¿No podría simplemente descargar un su precompilado, moverlo a la tarjeta SD y ejecutarlo a través de adb? Lo que parece hacer una ROM "pre-rooteada" es que tiene Superusuario y el binario su en sus respectivas rutas del sistema. No veo por qué es tan importante que se ejecute desde /system/xbin.

Respuestas (2)

El binario su necesita tanto la ejecución como el conjunto de bits de permiso setuid. El primero es necesario para que el archivo se pueda ejecutar y el segundo es que se ejecute automáticamente con los derechos del propietario del archivo (establezca la identificación del usuario o setuid. En este caso, el propietario es root. Lea más aquí ).

Los archivos en el almacenamiento externo no tienen configurados los bits de permiso ejecutable y setuid y no se pueden otorgar sin derechos de root. Tenga en cuenta también que la tarjeta SD está montada con el indicador 'noexec' para evitar la ejecución en general al arrancar:

shell@android:/sdcard $ ./su
/system/bin/sh: ./su: can't execute: Permission denied
126|shell@android:/sdcard $ chmod 4755 su
Unable to chmod su: Operation not permitted
10|shell@android:/sdcard $ mount | grep /mnt/sdcard
/dev/block/mmcblk0p1 /mnt/sdcard vfat [...],noexec,[...]

Esa es básicamente la razón por la que no puede simplemente copiar suen la tarjeta SD y luego ejecutarla para otorgarle la raíz.

Entonces, eso es lo único que impide el enraizamiento, ¿el hecho de que /sdcard no es ejecutable y no puedes chmod? Una vez que su está en la ubicación adecuada, se puede cambiar el ejecutable a su golden. Creo que habría una capa de seguridad para evitar que alguien simplemente ejecute su. En mi servidor y caja de Debian no puedo simplemente ejecutar su como un usuario normal, se me solicita una contraseña. Supongo que la suposición es que si uno puede instalar su, ¿pueden sobrescribir el archivo oculto para cambiar la contraseña?
@ user974896: Bueno, no hay ningún otro lugar para que un usuario que no sea del sistema lo pueda ejecutar, y Android ni siquiera tiene passwdo shadowarchivos de todos modos. Literalmente, necesita root para colocar suuna ubicación ejecutable, razón por la cual los métodos de enraizamiento implican una explotación de escalada de privilegios o ingresar a una recuperación personalizada (donde todas las apuestas están básicamente desactivadas).
Sí. Esta es la respuesta.
@user974896: además de que /sdcard está montado noexec, la llamada al sistema setuid solo se puede llamar cuando el bit de permiso suid está configurado en el ejecutable, y la llamada al sistema chown y chmod solo permitirá que root configure el bit setuid de un archivo propiedad de root (efectivamente, solo root puede crear un ejecutable que pueda ejecutarse con privilegios de root). Cualquiera puede llamar a su, pero a menos que la persona que llama tenga permiso para hacerlo en la base de datos del Superusuario (o en Linux tradicional, en la base de datos passwd/shadow), la llamada no tendrá éxito. Solo la aplicación de superusuario (y los procesos privilegiados) pueden modificar la base de datos de superusuario.
@user974896: Esto, además del sistema de seguridad normal en Android en el que cada aplicación dalvik se ejecuta como su propio usuario, significa que las aplicaciones que solo la aplicación en la lista blanca del superusuario puede escalar a la raíz sin aviso, todos los demás serán rechazados (si es en la lista negra), o hará que el superusuario solicite permiso al usuario.

El enraizamiento implica explotar la debilidad dependiendo de la versión de Android, por lo tanto, " salta a través de todos los aros para enraizar el teléfono " .

¡Es un huevo y la gallina!

Para explotar la raíz, necesita un demonio adb no seguro (es decir, la capacidad de volver a montar /system) en el teléfono, y para tener un adb no seguro, ¡necesita la raíz! Y también, necesita un gestor de arranque desbloqueado.

Eche un vistazo a un exploit llamado zergRush que se encuentra en github; se llama a la función de interés do_fault()cuando se intenta "romper" el marco de pila del volddaemon de 's conectándose a la tubería de su propiedad, y hacer que se bloquee sobrescribiendo el puntero de pila para que apunte a una copia versión del shell boomshque luego se ejecuta desde /data/local/tmp.

Después de leer la fuente, ahora se dará cuenta de por qué copiar el subinario no es suficiente para tener el teléfono "rooteado" y por qué se deben saltar los aros. Y también, como el bit ejecutable en el nivel del sistema de archivos para la tarjeta SD está bloqueado, no vaya allí, ¡eso está allí por razones obvias! :)

Gracias por los enlaces, los leeré más tarde. Entonces, incluso si la tarjeta sd se modificó chmod 777 de fábrica, ¿todavía no podría convertirme en root simplemente descargándola y ejecutándola?
¡correcto! ¡No vayas! No hace ni un ápice de diferencia y dado que la ROM instalada de fábrica tendrá eso protegido, ¡necesita root para lograr eso chmod, y los permisos de la tarjeta SD para hacer eso! :)
Bueno, ¿qué hace que su sea tan especial si está en /system/xbin? Si ingresa adb shell (o ejecuta una aplicación como un usuario normal), es un usuario sin privilegios. ¿Por qué ejecutar su cuando está en /system/xbin lo convierte en root en lugar de ejecutarlo en nuestro teóricamente chmod 777 /sdcard?
/system/xbines el directorio donde entran las utilidades de busybox, y... en un teléfono rooteado, emitir esto echo $PATHgenerará /sbin:/vendor/bin:/system/sbin:/system/bin:/system/xbin <- ¡obsérvelo! ¡Está en el camino! Para tener eso allí, necesitas root, por lo tanto, muchas situaciones del huevo y la gallina... :RE
Sí, sé que ahí es donde va por defecto. Lo que quiero decir es qué tiene de especial ejecutarlo allí. ¿Por qué no funcionaría la ejecución de ./su en /sdcard/, /data/, o cualquier directorio no requerido por la raíz, suponiendo que la fábrica envió la ROM con el directorio chmodded en 777? Lo que quiero decir básicamente es lo único que impide que uno descargue y ejecutar ./su es el hecho de que los directorios en los que un usuario no root puede hacer esto no son ejecutables o hay una imagen más grande.
Vamos a la sala de chat para ahorrarnos todos estos comentarios....
¿Por qué no se puede simplemente copiar el binario su (respuesta técnica, por favor)?
RespuestasAquíPolítica de privacidad1y, 0v