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
Facilidad de enraizamiento
No necesito una laptop o computadora
Menos
Basado en exploits, por lo que puede no funcionar si las actualizaciones del sistema operativo niegan los exploits
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.
Respuestas:
Hay algunas ventajas de rootear usando el proceso oficial.
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.
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.
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.
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.
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.
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.
fuente
A petición de OP, algunos detalles del chat :
Buena pregunta, pero difícil de responder: hay algunas cosas más que considerar.
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?
fuente
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)
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
adb
shell a través de una conexión de PCHard 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
setuid
utilidades, aplicaciones del sistema o servicios. ejemplo es unasetuid
utilidad vulnerable que solo está presente en dispositivos XoomFE que tiene una vulnerabilidad de inyección de comandosKernel 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)
Requerir
adb
shell a través de una conexión de PC: (17 de 78 estudiados). Para algunos exploits,adb
se 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.prop
que se habilita la raízadb
solo 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 de
setuid()
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 LOGS
para 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:
Exploit original obtenido directamente de los servidores de los proveedores, con el embalaje y la detección de manipulación activada.
Exploit descomprimido, que expondrá toda la lógica de explotación real a los productos antivirus.
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
fuente