Pros y contras de rootear usando aplicaciones ("Soft Root") en comparación con otros métodos ("Hard Root")

Existen bastantes métodos de rooteo basados ​​en aplicaciones. Una revisión reciente de 9 aplicaciones de software gratuitas para rootear dispositivos Android , apunta a algunas de ellas y puede haber más aplicaciones, de pago o de otro tipo.

Por lo que entiendo,

Puntos Plus

1. Facilidad de enraizamiento

2. No necesito una laptop o computadora

Menos

1. Basado en exploits, por lo que puede no funcionar si las actualizaciones del sistema operativo niegan los exploits

2. Dificultad para desrootear (como veo en algunos foros para mi dispositivo Huawei Honor 6)

Preguntas:

• ¿Cuáles son las ventajas y desventajas aparte de las anteriores?
• Si un dispositivo tiene ambas opciones: rooteo basado en aplicaciones y rooting por métodos de desarrolladores, ¿cuál debo elegir?

Nota: no estoy buscando sugerencias o recomendaciones de aplicaciones.

Hay algunas ventajas de rootear usando el proceso oficial.

1. Es oficialmente compatible con muchos teléfonos. Esto significa que puede utilizar un proceso documentado por el fabricante y herramientas de una fuente oficial o un tercero confiable (CWM o TWRP), en lugar de tener que ejecutar una herramienta que obtuvo de un sitio web poco fiable.

2. Debido a que es oficialmente compatible, la mayoría de las veces, una actualización del sistema no cambiará el proceso, por lo que no necesita buscar "el último" método de enraizamiento. Por el contrario, las actualizaciones de software tienden a corregir las vulnerabilidades, por lo que los métodos de explotación a menudo dejarán de funcionar después de una actualización.

3. Debido a lo anterior, después de "rootear", podría verse tentado a no instalar una actualización del sistema, porque esa actualización parchea la vulnerabilidad y detiene el funcionamiento de su método de rooteo. Con el proceso oficial, no hay razón para quedarse con una versión antigua y vulnerable.

Además de la conveniencia de un método de un solo clic (mencionado en la pregunta), existen otras ventajas de hacerlo de esa manera.

1. Desbloquear el gestor de arranque para "root" borra el teléfono, por lo que debe configurar las cosas nuevamente y restaurar los datos de la copia de seguridad. Por lo general, el "enraizamiento suave" a través de una vulnerabilidad no necesita borrar el teléfono, y eso puede ser mucho más conveniente.

2. Debido a que el enraizamiento modifica la partición del sistema, normalmente no se puede hacer una actualización de OTA después: el actualizador reconoce que el sistema se modificó y se rescata. Pero algunos métodos de "raíz suave" en algunos teléfonos evitan este problema, por lo que puede hacer una actualización de OTA sin tener que desrootear o flashear una nueva imagen del sistema. Esto también es un poco más fácil. De cualquier manera, aún tendrá que rootear nuevamente después de una actualización.

3. Como no tiene que desbloquear el gestor de arranque, no hay tentación de dejarlo desbloqueado. Esto tiene el beneficio de seguridad de que las personas no pueden actualizar nuevas ROM a su teléfono (por ejemplo, si es robado y quieren evadir el bloqueo de pantalla o la protección de restablecimiento de fábrica).

Lo que dice Beeshyams sobre seguridad es importante, pero en mi opinión es irrelevante para la pregunta. Es bueno señalar o recordar a las personas que cada método de "enraizamiento suave" está explotando una vulnerabilidad de seguridad, y el malware podría usar la misma vulnerabilidad para instalar rootkits en su teléfono. Sin embargo, la vulnerabilidad está ahí, ya sea que la use o no. El riesgo de seguridad proviene de la posibilidad del método de rooting. Rootear su teléfono explotando la vulnerabilidad no lo hace más explotable, o peor.

Si su teléfono puede ser rooteado por una aplicación / exploit de rooteo, entonces es vulnerable al malware. Esto es cierto independientemente de si lo rooteas o qué método utilizas. No utilizar el exploit (haciendo una "raíz dura" en su lugar, o simplemente no enraizándose) no lo protegerá del malware, ni reducirá su exposición.

^{A petición de OP, algunos detalles del chat :}

Buena pregunta, pero difícil de responder: hay algunas cosas más que considerar.

1. no es solo "basado en la aplicación versus USB", e incluso su "Dificultad para desrootear" no es necesariamente culpa de "basado en la aplicación" en general, sino de una aplicación específica que causa esa dificultad.
2. Desde el punto de vista de la seguridad: si hay una aplicación que puede rootear mi dispositivo, ¿quién dice que otra aplicación no lo hace sin mi consentimiento? Todos sabemos que hay malware que hace exactamente eso (para integrarse como aplicación del sistema, para protegerse contra el restablecimiento de fábrica).
3. Sin embargo, si no existe dicha aplicación (y con la esperanza de que no se pueda hacer con una aplicación en este dispositivo / ROM), es mucho más difícil para ese malware. Si entonces hay un método fácil a través de USB, me siento un poco más seguro :) Es bastante improbable que alguna otra aplicación logre conectar un cable USB, descargar algo a mi computadora y ejecutar ese combo para hacer daño.

Por lo tanto, lo anterior podría contar como "basado en una aplicación contra", pero si tal aplicación ya existe para el dispositivo en cuestión, no hay mucho que podamos hacer al respecto. Incluso si decimos "es más seguro al revés", eso no nos protege contra el n. ° 2. Claro, podemos verificar eso antes de comprar un dispositivo, pero ¿quién dice que esa aplicación no aparece al día siguiente?

Gracias a AndrewT que publicó un enlace en el chat , teniendo este trabajo de investigación como referencia en una de las respuestas . Esta respuesta se basa completamente en este documento (mayo de 2015) y destaca aspectos comprensibles para el usuario común (tiene mucho material relacionado con la seguridad para los interesados)

• ¿Cuáles son las ventajas y desventajas aparte de las anteriores?

• Si un dispositivo tiene ambas opciones: rooteo basado en aplicaciones y rooting por métodos de desarrolladores, ¿cuál debo elegir?

Respuesta: Se trata de vulnerabilidad de malware. El uso de exploits de raíz es un riesgo de seguridad ENORME y que sobrepasa cualquier otra ventaja

¿Qué es la raíz blanda y la raíz dura?

• Soft Root: Root se obtiene directamente ejecutando una pieza de software (es decir, exploits raíz), ya sea instalando directamente en el dispositivo o requiriendo adbshell a través de una conexión de PC

• Hard Root: Root se obtiene flasheando su binario externamente a través de un paquete de actualización o ROM

Amenaza de malware: en general

• A pesar de ser legítimos, muchos métodos raíz convenientes con un solo clic operan explotando vulnerabilidades en el sistema Android. Si no se controla cuidadosamente, el autor del malware puede abusar de estas vulnerabilidades para obtener privilegios de root no autorizados.

• Como se describe en el Proyecto Android Malware Genome , 36.7% (de 1260) muestras de malware habían incrustado al menos un exploit root.

• Estas hazañas bien diseñadas no están bien protegidas, es extremadamente peligroso si caen en las manos equivocadas.

¿Quiénes son los principales proveedores de raíz y, en términos generales, cómo funciona?

¿Cuáles son los tipos de expolits de raíz?

El artículo cubre 78 hazañas estudiadas. En general, el orden de impacto (de mayor a menor ):

• Explotaciones de Kernel: debido a su posición privilegiada, apuntar a Linux Kernel es natural para lograr el control total sobre un dispositivo Android, por ejemplo, TowelRoot

• Exploits de la biblioteca: los exploits que se dirigen a las bibliotecas que utilizan los procesos del sistema Android o bibliotecas externas que se utilizan para admitir diferentes aplicaciones, por ejemplo, el exploit ZergRush, libsysutils utilizados por el demonio de Volume Manager

• Aplicación y marco de aplicación Explotaciones de la raíz de la capa de aplicación: exploits que apuntan a aplicaciones o servicios del sistema, en su mayoría incluyen lógicas vulnerables introducidas por setuidutilidades, aplicaciones del sistema o servicios. ejemplo es una setuidutilidad vulnerable que solo está presente en dispositivos XoomFE que tiene una vulnerabilidad de inyección de comandos

• Kernel o controladores específicos del proveedor : los proveedores pueden personalizar el kernel (por ejemplo, la rama del kernel de Linux personalizada de Qualcomm) o proporcionar controladores de dispositivo específicos del proveedor para varios periféricos (por ejemplo, cámara, sonido). Dicho código se ejecuta dentro del espacio del kernel y cuyo compromiso también puede conducir a un control total sobre el dispositivo.

En cuanto al número , los exploits son como en la figura a continuación

¿Qué tan difícil es poner tus manos en Exploit (Source o Binary)?

Muy fácil. Fácilmente disponible en la búsqueda de Google, lo que lo convierte en un camino fácil para los autores de malware para aprovechar tales exploits. Buscar en Google 73 exploits lleva a 68 de ellos disponibles: 46 con código fuente y 22 con binarios

¿Cómo funcionan estos exploits?

Requisitos principales para que funcionen los exploits (ordenados del más difícil al menos ) (la etiqueta de malware tiene muchas de estas instancias)

• Requerir interacciones del usuario: (6 de 78 estudiados)

  • Solicitar al usuario que descargue una aplicación e interrumpa manualmente la instalación
  • Solicitar al usuario que inicie la recuperación al menos una vez.
  • Solicitar al usuario que coloque manualmente el dispositivo en modo de "ahorro de batería".
  • Solicitar al usuario que abra una aplicación específica del proveedor y presione un botón

• Requerir adbshell a través de una conexión de PC: (17 de 78 estudiados). Para algunos exploits, adbse requiere una conexión de shell debido a las siguientes razones más comunes:

  • El exploit puede modificar con éxito una configuración en la local.propque se habilita la raíz adbsolo para shell.

  • El exploit necesita escribir en un archivo propiedad de shell de grupo y de escritura grupal (no de escritura mundial)

  • El exploit se dirige al proceso de adb daemon que requiere que el proceso de ataque se ejecute con el usuario de shell. Por ejemplo, el exploit Rage Against the Cage apunta a la vulnerabilidad de la comprobación faltante de adb daemon sobre el valor de retorno desetuid()

• Reinicio: (6 de 78 estudiados) Generalmente, muchos exploits de raíz requieren al menos un reinicio. Por ejemplo, un ataque de enlace simbólico permitiría a un atacante eliminar un archivo propiedad del sistema con un permiso débil, para configurar un enlace en la misma ubicación a un archivo protegido. Después de un reinicio, los scripts de inicio correspondientes intentarían cambiar el permiso del archivo original para que se pueda escribir en el mundo, lo que en realidad cambia el permiso del archivo vinculado.

• Ninguno o permiso: (44 de 78 estudiados) Los exploits en esta categoría no tienen requisitos estrictos, sin embargo, algunos de ellos pueden requerir ciertos permisos de Android, como READ LOGSpara que el propietario del proceso se coloque en cierto grupo de usuarios.

¿Pueden estas vulnerabilidades ser detectadas por el antivirus?

Dado que los exploits de raíz son muy sensibles y pueden ser aprovechados por varios malware de Android, se espera que el software antivirus en la plataforma de Android pueda identificar la mayoría de ellos, incluidos los implementados por los proveedores de root. En general, el resultado muestra que los productos de seguridad de última generación en la plataforma Android aún no pueden abordar las vulnerabilidades de raíz de manera efectiva

Se utilizaron 4 productos antivirus Android representativos para probar el proveedor más grande (nombre no revelado) que tiene 167 exploits. Debido a que los exploits originalmente descargados de la base de datos de proveedores han empaquetado el código de exploit real y han empleado un mecanismo de detección de manipulación, el estudio creó 3 versiones diferentes para cada exploit:

1. Exploit original obtenido directamente de los servidores de los proveedores, con el embalaje y la detección de manipulación activada.

2. Exploit descomprimido, que expondrá toda la lógica de explotación real a los productos antivirus.

3. Exploit re-empaquetado con detección de manipulación deshabilitada.

Los binarios de explotación diseñados por grandes proveedores de raíz son sorprendentemente "limpios" ya que todos los principales programas antivirus tienen dificultades para detectarlos, como se muestra en la tabla siguiente.

Conclusión

Sencillo. Manténgase alejado de los métodos de Soft Root a menos que sea capaz de lidiar con las consecuencias