¿Obteniendo root modificando default.prop(ro.secure)?

Para obtener un shell privilegiado, debe modificar las siguientes líneas a los valores dados en el archivo default.prop ro.secure=0

ro.depurable=1

persistir.servicio.adb.habilitar=1

He extraído la imagen de recuperación del modelo de mi teléfono: Entonces, ¿es posible modificar los siguientes valores en el archivo default.prop, volver a empaquetar la imagen y actualizarla usando fastboot (el cargador de arranque está desbloqueado) para obtener un shell privilegiado y luego copiar el su binario después de volver a montar el sistema como lectura/escritura?

¿Necesito cambiar algún otro valor en alguno de los archivos? ¿Y funcionará, al menos teóricamente?

Antes de reinventar la rueda, ¿buscó en xda-developers un método raíz oficial para su dispositivo?
Sí, no hay métodos "oficiales" y quería hacerlo yo mismo por una vez, es un dispositivo chino renombrado, por lo que no hay mucho soporte allí,
¿Qué dispositivo quieres rootear?
@Flow Karbonn A9/K-Touch W680. Actualización: el enfoque anterior no funcionó, ya sea porque la imagen no era una recuperación de stock en primer lugar o porque no es tan fácil. El teléfono está rooteado ahora.
default.prop se encuentra en ramdisk, que se "reinicia" cada arranque
¿Puedes vincular o explicar cómo extraer recovery.img o boot.img del teléfono (sin tener ya la raíz)? ¡Gracias!
@ user29020 Esto fue hace bastante tiempo, no recuerdo.

Respuestas (2)

Este enfoque funcionará (siempre que no haya bloqueos divertidos patentados en ningún lugar), pero la partición de recuperación no forma parte de él desde el principio. El default.prop se sobrescribe en el arranque, se copia desde la partición de arranque, que no es un sistema de archivos accesible directamente. Necesita una imagen de la partición de arranque, que luego descomprimirá, realizará el cambio y volverá a empaquetar.

Suponiendo que sepa cómo hacer todo eso (ya que dice que lo intentó con la recuperación), debo advertirle que muchas veces es necesario incluir la dirección base al crear la imagen con mkbootimg. No hay forma de saber cuándo se requiere, por lo que es seguro incluir siempre una dirección base. Puedes seguir un tutorial aquí:

www.freeyourandroid.com/guide/extract-edit-repack-boot-img-windows

El script incluye el comando od con el que puedes obtener la dirección base, en caso de que quieras hacer tu propio script. Para obtener más información sobre los pasos manuales (para reproducir en GNU/Linux):

android-dls.com/wiki/index.php?title=HOWTO:_Unpack%2C_Edit%2C_and_Re-Pack_Boot_Images

No recomiendo el uso de los scripts de desempaquetar/reempaquetar, ya que tienen líneas codificadas que no se pueden transferir entre casos. Use split_bootimg.pl, luego gunzip y cpio extráigalo, después de lo cual volverá a usar cpio y gzip, seguido del comando mkbootimg. La única excepción es para los dispositivos MTK65xx, donde necesitará las herramientas de desempaquetado/reempaquetado relevantes (porque tienen compensaciones muy diferentes; también omitirá el mkbootimg ya que el script de reempaquetado lo hace por usted):

github.com/bgcngm/mtk-herramientas

Y aquí hay un ejemplo continuo de un teléfono chino renombrado que pasa por lo mismo para finalmente obtener la raíz:

foro.xda-developers.com/showthread.php?t=1818146&page=5

Lamento tener que eliminar los enlaces adecuados, pero aparentemente se me considera spam potencial. Además, no he sido bastante minucioso porque no estoy muy seguro de que quieras más verbosidad.

¿Puedes vincular o explicar cómo extraer recovery.img o boot.img del teléfono (sin tener ya la raíz)? ¡Gracias!

El enfoque anterior no parecía funcionar.

Ya sea porque la recuperación de stock no estaba destinada al dispositivo o porque el método no es tan fácil y puede implicar realizar otros cambios. El teléfono no entraría en el modo de recuperación, que es el único modo en el que obtendría un shell privilegiado para realizar las operaciones necesarias para obtener la raíz permanente.

Otro método sería modificar build.prop en la imagen de arranque, volver a empaquetarlo y luego actualizarlo y adb para obtener un shell privilegiado en el modo operativo normal.

Es mejor seguir el procedimiento de otra persona cuando no estás muy seguro del tuyo.

Esto no funciona porque la versión ADB enviada no es compatible con la raíz. (Busqué el archivo make y la fuente ADB, sé de lo que estoy hablando)
@Orri Aunque esto puede ser años después, estoy bastante seguro de que la aplicación ADBD insegura de Chainfire existía cuando se publicó la respuesta.