Obtuve Sony Xperia M4 Aqua con un cargador de arranque bloqueado, Android 6.01 y el parche de seguridad del 1 de julio de 2016, pero no la verdad de DM. Me gustaría congelar algunas aplicaciones de fábrica a través del pm disablecomando ADB (o de cualquier otra forma posible). Intenté ejecutar su pm disable package.namepero el sucomando no se reconoce por alguna razón.
Soy un novato de Linux pero tengo Android Studio con SDK y NDK instalado en una máquina lubuntu (también lo tengo en una máquina con Windows 7).
¿Alguien puede explicarme los pasos a seguir para obtener acceso al shell raíz con el exploit Dirty COW (o de cualquier otra forma) para poder congelar aplicaciones?
La razón por la que el comando no funciona para usted es porque "su" es un binario que se instala al rootear su dispositivo. Sin una raíz adecuada, no tiene el comando "su".
Para usar el exploit Dirty COW, debe compilar el binario para la arquitectura de su dispositivo.
Dirígete a https://github.com/timwr/CVE-2016-5195 y descarga o clona los archivos.
(Opcional) Si no conoce la arquitectura de su dispositivo, en el teléfono, instale la aplicación "Droid Hardware Info" de Play Store, ábrala y deslícese hacia la izquierda para acceder a la pestaña Sistema. Junto a la etiqueta "Conjuntos de instrucciones" estará su arquitectura compatible.
En su computadora, abra una terminal y navegue hasta donde están los archivos Dirty COW (extráigalos si es necesario). Luego simplemente escriba make (insert architecture here). Esto creará dos archivos binarios dentro de la carpeta libs/(your_architecture)/llamada dirtycow& run-as. Alternativamente, si tiene habilitada la depuración de USB, simplemente conecte el dispositivo y escriba make roote insertará los archivos binarios en su dispositivo en /data/local/tmp, luego automatice algunos comandos ADB para explotar y otorgarle un shell raíz limitado .
Si no ve el ícono de usuario de la terminal como #y en su lugar ve un $, entonces el exploit no funcionó en algún momento. Dado que los archivos todavía están en el dispositivo, sugeriría intentar parchear manualmente run-asusando adb shelly escribiendo lo siguiente...
chmod 777 /data/local/tmp/*
dirtycow /data/local/tmp/run-as /system/bin/run-as
/system/bin/run-as
Si esto no le solicita que sea usuario raíz (#), entonces el exploit no funcionará para su dispositivo de esta manera y tendrá que investigar un poco por qué no. Si esto sucede, intente abrir un problema en el repositorio de Github, todavía está bastante activo, por lo que debería tener una respuesta en breve.
Para complementar la respuesta de therealjayvi , tenga en cuenta que la compilación y el uso de CVE-2016-5195 de timwr también requieren la instalación de ADB y NDK, antes de make [architecture]y make root, y que esto debe hacerse desde un entorno Linux.
Se asumió que todos los requisitos previos se obtuvieron antes de hacer esto, los requisitos previos se pueden haber agregado después del comentario, o se sabía poco o nada sobre el exploit CVE-2016-5195 de la persona que hizo el comentario.
De todos modos, todo esto se puede hacer a través de: primero, estar en Linux (Ubuntu, Debian, Mint, ext.) y suponiendo que adbestá en su lista de repositorios aptcomo suele ser por defecto, pero no todo el tiempo. Si sudono está presente, use su.
sudo apt-get install android-tools-adb
Obtenga la última descarga de Linux desde aquí , luego extraiga y ejecute:
export PATH=$PATH:/root/directory/of/ndk/
Es posible que deba volver a ejecutar exportsi cierra la terminal actual, ya que no puedo encontrar una solución que permanezca.
Una vez que todo esté hecho, puedes seguir la forma de hacerlo de @therealjayvi.
Dirty COW en Marshmallow no puede hacer nada debido a las restricciones de SELinux.
La respuesta de therealjayvi es una buena explicación de 'cómo compilar la prueba de concepto Dirty COW'. Pero no puede ni siquiera lsla carpeta actual donde se ejecuta.
/data/local/tmp$ run-as
/data/local/tmp# ls
opendir failed, permission denied
ls, puede escribir sobre ese archivo con cualquier otro archivo, binario, apk, cualquier cosa y se comportará como si fuera el original. llame al original por comando/nombre./systempartición o cualquier otra partición bootcuya firma se verifique mediante el 'arranque verificado de Android', el dispositivo no se iniciará cuando reinicia ya que el arranque verificado fallará cuando se modifique el hash raíz de la partición. Eso es lo que @MetNP trató de transmitir con su declaración, supongo.
esQmo_
pm hide package_namey no requiere root.markonioninioni
esQmo_
markonioninioni
izzy
esQmo_
markonioninioni