6 votos

¿Cómo identificar la aplicación/proceso que remonta las particiones R/W, crea archivos y cambia los permisos de los archivos?

Tengo un dispositivo rooteado, con derechos de superusuario concedidos a unas pocas aplicaciones en las que confío. A menudo he encontrado mi /system o /vendor partición montada de lectura/escritura, y algunos archivos chmod a 0777 . Del mismo modo, se crean/eliminan directorios/archivos con nombres aleatorios (por ejemplo /sdcard/.a03Degpoif ), .nomedia se crean dentro de ellos para ocultar su contenido de la galería, etc.

logcat / dmesg no contiene rastros de que todo esto ocurra en el fondo. Esto no sucede periódicamente, pero de manera chapucera, la conectividad a Internet tampoco es una condición. He probado a deshabilitar/desinstalar aplicaciones, buscando cualquier proceso sospechoso que se esté ejecutando, pero no he podido identificar al culpable o culpables.

¿Hay alguna manera de averiguar quién está haciendo esto?

5voto

Jack Wade Puntos 231

Nota _: La siguiente solución requiere un dispositivo rooteado. El kernel debe ser construido con AUDIT_WATCH , preferiblemente AUDIT_TREE ._

Lo único bueno que hizo Google fue elegir el flexible y configurable kernel de Linux para Android, no ir por algo como un núcleo lisiado y tratando de manejar todo desde el espacio de usuario, incluyendo la ejecución de un kernel de Linux ( 1 ) .

El núcleo de Linux Sistema de auditoría permite registrar las llamadas al sistema o los cambios en el sistema de archivos realizados por un proceso. En nuestro caso necesitamos identificar los procesos que están escribiendo en /sdcard o /system y haciendo syscalls mount y chmod .

Las distribuciones de Linux tienen un servicio auditd que se comunica con el kernel para obtener información sobre eventos relacionados con la seguridad. En Android ya tenemos logd no es tan configurable como auditd pero suficiente para un control básico. logd cubre principalmente la funcionalidad de su homólogo de escritorio syslogd pero también incluye klogd y parcialmente auditd para obtener los registros del subsistema SELinux del kernel.

Podemos añadir algunas reglas más utilizando auditctl para informar también de los acontecimientos que nos interesan. Puede utilizar auditctl desde un entorno Linux mínimo en su dispositivo Android, o compilar el binario desde el código fuente (debe construirse con --con el brazo / --con-aarch64 cualquiera que sea la arquitectura de sus dispositivos), o consiga uno precompilado aquí .

Ahora cree archivos de reglas en /etc o donde quieras:

# /etc/audit-start.rules

# enable auditing, won't work in PID namespace
# won't work if permanently disabled with kernel parameter "audit=0"
-e 1

# delete previous rules (though there are none on Android)
-D

# increase the buffers to avoid failure
# no. of event to be queued, waiting for logd to read them
-b 10000

# disable rate limit (msgs/sec) to avoid failure
-r 0

# this determines how long to wait in burst of events
--backlog_wait_time 0

# set failure mode to dmesg
-f 1

# define filesystem rules, whatever file/directory you want to watch
-w /system -p wa -k FILESYSTEM_AUDIT

# define syscall rules, see all syscalls with 'ausyscall --dump' or
# here: github.com/linux-audit/audit-userspace/blob/master/lib/aarch64_table.h
-a always,exit -S fchmod -S fchmodat -k CHMOD_AUDIT
-a always,exit -S mount -k MOUNT_AUDIT

# /etc/audit-stop.rules

# clear on exit, restore Android default values
-e 0
-D
-b 64
-r 5
--backlog_wait_time 18000

Aplicar las normas:

~# auditctl -R /etc/audit-start.rules

Ahora haga los cambios; monte /system R/W, escribir/borrar algo allí y cambiar los permisos del archivo.

En función de logd puede obtener audit registrar en uno o más de los diferentes registros ( 2 ) incluyendo events buffer ( 3 ) de logcat y main buffer ( 4 ) :

~# logcat -d -b events,main | grep _AUDIT

O en el núcleo de printk buffer ( 5 ) y logact 's kernel buffer ( 6 ) :

~# dmesg | grep _AUDIT
~# logcat -d -b kernel | grep _AUDIT

audit(0.0:16122): arch=c00000b7 syscall=40 success=yes exit=0 a0=7fcec5db38 a1=7fcec5db3f a2=0 a3=8021 items=1 ppid=761 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="busybox" exe="/data/data/com.mixplorer/files/busybox/busybox" subj=u:r:magisk:s0 key="MOUNT_AUDIT"
audit(0.0:16126): arch=c00000b7 syscall=53 success=yes exit=0 a0=ffffff9c a1=7b839180c0 a2=81a4 a3=0 items=1 ppid=11687 auid=4294967295 uid=10135 gid=10135 euid=10135 suid=10135 fsuid=10135 egid=10135 sgid=10135 fsgid=10135 tty=(none) ses=4294967295 comm="Thread-7" exe="/system/bin/app_process64" subj=u:r:untrusted_app:s0:c135,c256,c512,c768 key="CHMOD_AUDIT"
audit(0.0:16141): arch=c00000b7 syscall=35 success=yes exit=0 a0=ffffff9c a1=7bc22a3c40 a2=0 a3=7bdfbd3098 items=2 ppid=11687 auid=4294967295 uid=10135 gid=10135 euid=10135 suid=10135 fsuid=10135 egid=10135 sgid=10135 fsgid=10135 tty=(none) ses=4294967295 comm="pool-2-thread-1" exe="/system/bin/app_process64" subj=u:r:untrusted_app:s0:c135,c256,c512,c768 key="FILESYSTEM_AUDIT"

La primera línea muestra que algún proceso que se ejecuta como Root con el contexto SELinux de Magisk ha hecho syscall 40 ( mount ) y el comando muestra que es la aplicación MiXplorer (sólo como ejemplo, lo hice yo mismo). La segunda línea indica que la aplicación que se ejecuta con UID 10135 tiene chmod de algo.
La tercera línea muestra la misma aplicación (haciendo syscall 35 ) borró algo en /system partición.

Este es un caso de uso sencillo. Se pueden definir más reglas recursivas para tratar situaciones complejas, interpretando también otros campos del registro, como se explica aquí .

Para despejar las reglas:

~# auditctl -R /etc/audit-stop.rules

NOTA:

  • Para casos sencillos en los que el objetivo es sólo recibir una notificación de algunos cambios en el sistema de archivos (y no rastrear al autor), inotify se puede utilizar en su lugar, como se explica en esta respuesta .
  • Para marcar todos los procesos que se ejecutan antes del inicio de la auditoría como auditables por el kernel, pase audit=1 parámetro de arranque al kernel, ya sea editando cmdline en boot.img o utilizar fastboot -c opción.
  • Para guardar el registro de auditoría en un archivo, ejecute logcat en el fondo:

    logcat -s auditd -b events -f /data/media/0/auditd.log &

0 votos

¿así que mixplorer cambia los archivos /system y /vendor y crea carpetas aleatorias en /sdcard?

0 votos

@alecxs no esto era solo un ejemplo. Lo hice yo mismo usando MiXplorer. He utilizado este método en el pasado para identificar algunos procesos que estaban haciendo algo más complejo. El ejemplo simple es para facilitar la comprensión.

1 votos

¿Hay alguna manera de que los registros de auditoría se escriban en el almacenamiento en lugar de permanecer en la memoria? Por ejemplo, si tengo un directorio en el que se crean archivos aleatorios en un momento dado, no puedo prever cuándo se crearán, por lo que me gustaría que los registros se almacenaran para un acceso posterior a pesar de que se haya producido un reinicio en el medio.

PreguntAndroid.com

PreguntAndroid es una comunidad de usuarios de Android en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X