Diccionario de archivos generados por la herramienta mvt al analizar un bugreport

2025-08-272025-08-27

El presente documento contiene información sobre los archivos generados por la MVT a través del componente mvt-check bugreport. El objetivo de este diccionario, es que la persona analista tenga la facilidad de buscar información específica y conocer el formato en que la información del análisis forense es presentada.

Este recurso forma parte de un repositorio de documentación técnica que tiene como objetivo establecer una base de conocimientos probados, flexibles y accesibles para impulsar el análisis forense consentido en beneficio de la sociedad civil. Para organizar los contenidos, se utiliza el marco de referencia de documentación técnica Diataxis.

Este recurso en particular se enmarca dentro de la categoría de referencias, y contiene información sobre el análisis de bugreport generados por dispositivos Android mediante el comando mvt-android check-bugreport durante el uso de la herramienta MVT (Mobile Verification Toolkit), desarrollada y mantenida por el Laboratorio de Seguridad de Amnistía Internacional y perteneciente al MVT Project. Esto con el objetivo de que una persona analista conozca los archivos generados, cómo utilizarlos, donde buscar información específica y en qué formato la encontrará.

Para la recopilación de la información se tomó como base el la versión 2.6.0 de MVT.

La información generada por mvt-bugreport se puede agrupar en 4 categorías principales:

Detalles de la adquisición
Configuración del dispositivo
Información sobre registros y eventos del sistema
Procesos y aplicaciones

Detalles de la adquisición

info.json

Información contenida

Este archivo se encuentra en formato json y contiene información relacionada con el análisis realizado a un archivo bugreport. Contiene la siguiente información:

Ruta del archivo analizado.
Versión utilizada de MVT.
Fecha del análisis.
Lista de archivos de indicadores de compromiso.
Hash del bugreport analizado (SHA-256).

¿Por qué es importante?

Este archivo nos permite validar el análisis que se ha realizado, documentando que se tiene un registro del proceso de adquisición y los indicadores que se consideraron para hacer la comparación.

Esta información permite establecer una referencia del archivo analizado y la herramientas de indicadores utilizados utilizados en el análisis , esto facilita el proceso de custodia de la extracción forense.

Estructura del archivo:

{
    "target_path": "/ruta/del/archivo/bugreport.zip",
    "mvt_version": "2.6.1",
    "date": "YYYY-MM-DD hh:mm:ss",
    "ioc_files": [
        "/ruta/a/indicadores/pegasus.stix2",
        "/ruta/a/indicadores/predator.stix2",
        "/ruta/a/indicadores/rcs_lab.stix2",
        "... más indicadores utilizados ..."
    ],
    "hashes": [
        {
            "file_path": "/ruta/del/archivo/bugreport.zip",
            "sha256": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
        }
    ]
}

command.log

Información contenida

Este archivo se encuentra en texto plano con una extensión .log y contiene los registros detallados de la ejecución del comando mvt-android check-bugreport.

Su contenido enlista el análisis realizado sobre el bugreport, incluyendo la detección de indicadores de compromiso para identificar alertas de seguridad relacionadas con malware.

Los registros del archivo se presentan de manera estructurada con:

Marcas de tiempo
Nombres del módulo en ejecución
Tipo de mensaje (INFO, DEBUG, WARNING, ERROR)
Acción correspondiente del módulo (parseo del archivo, carga de IoCs, comparación, y resultado de la comparación).

Los tipos de mensaje corresponden de la siguiente manera:

INFO. Mensajes mostrados también en pantalla durante la ejecución.
DEBUG. Información no mostrada en pantalla pero asociada a una acción realizada durante el análisis por ejemplo la carga de un IoC o la revisión de un hash.
WARNING. Corresponde a alertas de actividad o información sospechosa que un analista debe verificar.
ERROR. Mensajes de error en alguna acción realizada durante el análisis, por ejemplo al cargar un archivo corrompido o un problema con la ejecución del código correspondiente.

¿Por qué es importante?

Permite generar un registro de las acciones realizadas durante el análisis. A través de este registro es posible verificar lo siguiente:

Que el análisis se realizó de manera correcta
Si hubo coincidencias con IoCs
Si se identificó información o actividad sospechosa.

Estructura del archivo:

Este archivo sigue un formato linea por linea con la siguiente estructura.

[TIMESTAMP] - [MÓDULO] - [NIVEL DE LOG] - [MENSAJE]  
...
2025-07-25 21:51:28,004 - mvt.android.cmd_check_bugreport - INFO - Parsing STIX2 indicators file at path /home/user/.local/share/mvt/indicators/raw.githubusercontent.com_AmnestyTech_investigations_master_2021-07-18_nso_pegasus.stix2
2025-07-25 21:51:28,082 - mvt.android.cmd_check_bugreport - DEBUG - Extracted 1549 indicators for collection with name "Pegasus"
...
2025-07-25 21:51:29,524 - mvt.android.cmd_check_bugreport - INFO - Loaded a total of 10747 unique indicators
2025-07-25 21:51:29,524 - mvt - INFO - Checking Android bug report at path: ./0caba18f-20a7-48d0-b9ba-724fdaa3ff85/bugreport.zip
...
2025-07-25 21:51:29,527 - mvt.android.modules.bugreport.accessibility - INFO - Running module Accessibility...
2025-07-25 21:51:30,794 - mvt.android.modules.bugreport.accessibility - INFO - Found installed accessibility service "com.samsung.accessibility/.assistantmenu.serviceframework.AssistantMenuService"
...
2025-07-25 21:51:30,797 - mvt.android.modules.bugreport.accessibility - INFO - Identified a total of 4 accessibility services
2025-07-25 21:51:30,822 - mvt.android.modules.bugreport.accessibility - INFO - The Accessibility module produced no detections!
...
2025-07-25 21:51:30,823 - mvt.android.modules.bugreport.activities - INFO - Running module Activities...
2025-07-25 21:51:32,156 - mvt.android.modules.bugreport.activities - INFO - Extracted 4312 package activities
2025-07-25 21:51:32,844 - mvt.android.modules.bugreport.activities - INFO - The Activities module produced no detections!
...
2025-07-25 21:51:51,292 - mvt.android.modules.bugreport.adb_state - INFO - Running module DumpsysADBState...
2025-07-25 21:51:52,196 - mvt.android.modules.bugreport.adb_state - INFO - Identified a total of 0 trusted ADB keys
2025-07-25 21:51:52,220 - mvt.android.modules.bugreport.adb_state - INFO - The DumpsysADBState module produced no detections!
2025-07-25 21:51:52,222 - mvt.android.modules.bugreport.fs_timestamps - INFO - Running module BugReportTimestamps...
2025-07-25 21:51:52,224 - mvt.android.modules.bugreport.fs_timestamps - INFO - Extracted a total of 239 filesystem timestamps from bugreport.
2025-07-25 21:51:52,225 - mvt.android.modules.bugreport.fs_timestamps - INFO - The BugReportTimestamps module does not support checking for indicators
2025-07-25 21:51:52,228 - mvt.android.modules.bugreport.tombstones - INFO - Running module Tombstones...
2025-07-25 21:51:53,552 - mvt.android.modules.bugreport.tombstones - INFO - Extracted a total of 64 tombstone files
2025-07-25 21:51:53,555 - mvt.android.modules.bugreport.tombstones - WARNING - Potentially suspicious crash in process 'Loc_hal_worker' running as UID '1000' in tombstone 'tombstone_13' at 2024-12-27 06:46:15.013046
2025-07-25 21:51:53,556 - mvt.android.modules.bugreport.tombstones - WARNING - Potentially suspicious crash in process 'LocApiMsgTask' running as UID '1000' in tombstone 'tombstone_13.pb' at 2024-12-27 06:46:15.013046
2025-07-25 21:51:53,557 - mvt.android.modules.bugreport.tombstones - WARNING - Potentially suspicious crash in process 'thermal@1.0-ser' running as UID '1000' in tombstone 'tombstone_14' at 2025-03-09 06:46:15.606938
2025-07-25 21:51:53,558 - mvt.android.modules.bugreport.tombstones - WARNING - Potentially suspicious crash in process 'POSIX timer 1' running as UID '1000' in tombstone 'tombstone_14.pb' at 2025-03-09 06:46:15.606938
2025-07-25 21:51:53,559 - mvt.android.modules.bugreport.tombstones - WARNING - Potentially suspicious crash in process 'HwBinder:1251_2' running as UID '1000' in tombstone 'tombstone_15' at 2025-03-30 06:46:15.306491
2025-07-25 21:51:53,560 - mvt.android.modules.bugreport.tombstones - WARNING - Potentially suspicious crash in process 'LocApiMsgTask' running as UID '1000' in tombstone 'tombstone_15.pb' at 2025-03-30 06:46:15.306491
2025-07-25 21:51:53,561 - mvt.android.modules.bugreport.tombstones - WARNING - Potentially suspicious crash in process 'Loc_hal_worker' running as UID '1000' in tombstone 'tombstone_17' at 2025-05-22 06:46:16.292957
2025-07-25 21:51:53,562 - mvt.android.modules.bugreport.tombstones - WARNING - Potentially suspicious crash in process 'LocApiMsgTask' running as UID '1000' in tombstone 'tombstone_17.pb' at 2025-05-22 06:46:16.292957
2025-07-25 21:51:53,623 - mvt.android.cmd_check_bugreport - INFO - Reference hash of the info.json file: "aee39fbcabf86848a4d806b7217b030f6240e5c62d02b12e330206c6a229c2b0"
2025-07-25 21:51:53,624 - mvt.android.cmd_check_bugreport - WARNING - [bold]NOTE: Detected indicators of compromise[/bold]. Only expert review can confirm if the detected indicators are signs of an attack.

Please seek reputable expert help if you have serious concerns about a possible spyware attack. Such support is available to human rights defenders and civil society through Amnesty International's Security Lab at https://securitylab.amnesty.org/get-help/?c=mvt
2025-07-25 21:51:53,625 - mvt - WARNING - The analysis of the Android bug report produced 13 detections!

Aprende más

Introduction to STIX

timeline.csv

Información contenida
Este archivo se encuentra en formato csv y almacena una línea de tiempo de la actividad del dispositivo. Esta actividad se obtiene de la ejecución de los módulos de análisis de MVT y se ordena por tiempo.

Cada línea del csv corresponde a:

Marca de tiempo (Device Local Timestamp).
Módulo ejecutado (Plugin).
Actividad identificada en el dispositivo (Event)
Descripción de la actividad identificada en el dispositivo (Description).

¿Por qué es importante?

Este archivo permite dar seguimiento a la actividad interna del dispositivo, pudiendo generar una idea amplia de cómo se comportó el dispositivo e identificar eventos relevantes.

Estructura del archivo

Este archivo sigue un formato línea por línea con la siguiente estructura.

"Device Local Timestamp","Plugin","Event","Description"
"1969-12-31 18:00:00","Packages","package_install","Install or update of package com.android.uwb.resources"
"1969-12-31 18:00:00","Packages","package_first_install","Install or update of package com.cr
unchyroll.crunchyroid"
"1969-12-31 18:00:00","Packages","package_last_update","Install or update of package com.goog
le.android.ext.services"
...
"2008-12-31 09:00:00","Packages","package_last_update","Install or update of package com.samsung.android.ardrawing"
"2008-12-31 09:00:00","Packages","package_install","Install or update of package com.samsung.android.ConnectivityUxOverlay"
...
"2019-01-19 02:53:42.000000","BugReportTimestamps","M---","FS/cache/recovery/last_log.1"
"2019-01-19 02:53:42.000000","BugReportTimestamps","M---","FS/cache/recovery/last_kmsg.1"
...
"2021-12-13 08:39:45.243000","Appops","Reject","com.google.android.as access to GET_USAGE_STATS: Reject"
"2021-12-13 08:39:46.277000","Appops","Access","com.android.providers.media access to READ_EXTERNAL_STORAGE: Access"
...
"2024-12-26 00:52:24.264000","Appops","Access","com.google.android.gms access to READ_CONTACTS: Access"
"2024-12-26 22:31:06.194000","Appops","Access","com.samsung.android.messaging access to WRITE_CALL_LOG: Access"
"2024-12-27 06:46:15.013046","Tombstones","Tombstone","Crash in 'Loc_hal_worker' process running as UID '1000' in file 'tombstone_13' Crash type 'SIGABRT' with code 'SI_QUEUE'"
"2024-12-27 06:46:15.013046","Tombstones","Tombstone","Crash in 'LocApiMsgTask' process running as UID '1000' in file 'tombstone_13.pb' Crash type 'SIGABRT' with code 'SI_QUEUE'"
"2024-12-27 06:46:16.000000","BugReportTimestamps","M---","FS/data/tombstones/tombstone_13"
"2024-12-27 06:46:16.000000","BugReportTimestamps","M---","FS/data/tombstones/tombstone_13.pb"
"2024-12-27 06:46:58.561000","Appops","Access","com.qti.snapdragon.qdcm_ff access to BLUETOOTH_CONNECT: Access"
"2024-12-27 06:47:03.100000","Appops","Reject","com.android.inputdevices access to NO_ISOLATED_STORAGE: Reject"
...
"2025-06-30 21:30:30.477000","Appops","Access","com.sec.android.app.launcher access to REQUEST_DELETE_PACKAGES: Access"
"2025-07-01","BatteryDaily","battery_daily","Recorded update of package com.google.android.apps.restore with vers 818758"
"2025-07-01","BatteryDaily","battery_daily","Recorded update of package com.google.android.apps.chromecast.app with vers 30503818"
"2025-07-01","BatteryDaily","battery_daily","Recorded update of package com.google.android.apps.tasks with vers 1885693"
...

Configuración del dispositivo

getprop.json

La información de este archivo se obtiene mediante el módulo getprop y el artefacto getprop.

Información contenida

Este archivo se encuentra en formato json y contiene una lista de las propiedades del dispositivo que son extraídas de la sección SYSTEM PROPERTIES del dumpsys.

Estas propiedades del sistema son pares clave-valor de cadenas que se almacenan en el diccionario global build.prop o en archivos de descripción .sysprop, y proporcionan una forma conveniente de compartir configuraciones dentro del sistema.

La información se puede encontrar utilizando el siguiente formato:

[{prefix}.]{group}[.{subgroup}]*.{name}[.{type}]

Algunas propiedades aparecen con el prefijo ro, lo que indica que son propiedades de solo lectura, o que fueron asignadas luego del reinicio del dispositivo. Las propiedades con el prefijo persist se refieren a configuraciones resistentes al reinicio. Algunas propiedades no tendrán prefijo, por lo que inician directamente con el grupo al que pertenecen.

Los grupos más comunes son:

bluetooth, relacionado con Bluetooth
boot, sysprops de cmdline del kernel
build, sysprops que identifican una compilación
telephony, relacionado con la telefonía
audio, relacionado con el audio
graphics, relacionado con los gráficos
vold, relacionado con vold que gestiona el montaje de volúmenes físicos de almacenamiento externo

Para mayor detalle se puede revisar la lista de propiedades ya definidas en el código fuente de Android.

¿Por qué es importante?

Las propiedades brindan información importante sobre el hardware y el software del dispositivo, las cuales pueden ser alteradas por software malicioso para ocultar su presencia o para modificar el comportamiento del dispositivo de forma inadvertida.

Estructura del archivo:

[
    {
        "name": "DEVICE_PROVISIONED",
        "value": "1"
    },
    {
        "name": "aaudio.hw_burst_min_usec",
        "value": "2000"
    },
    {
        "name": "bluetooth.device.class_of_device",
        "value": "90,2,12"
    },
    {
        "name": "ro.boot.serialno",
        "value": "RF8T11XXXXX"
    },
    {
        "name": "ro.bootimage.build.date",
        "value": "Mon Mar 24 20:09:54 KST 2025"
    },
    {
        "name": "ro.hardware.chipname",
        "value": "SM8250"
    },
    {
        "name": "ro.product.system.model",
        "value": "SM-G780G"
    },
    {
        "name": "ro.build.selinux",
        "value": "1"
    }
]

Aprende más

Información sobre registros y eventos del sistema

dumpsys_adb_state.json

El contenido de este archivo se genera mediante el módulo adb_state. y el artefacto dumpsys_adb.

Información contenida

Este archivo se encuentra en formato json y contiene información de una conexión ADB la cual es extraída del servicio adb del dumpsys.

La información en el archivo se presenta de la siguiente manera:

connected_to_adb. Indica si el dispositivo tenía una conexión activa con ADB (true o false).
last_key_received. Cadena en formato hexadecimal que representa la última clave pública usada para emparejar el dispositivo con el host ADB.
keystore. Puede contener información sobre el almacén de claves utilizado para la autenticación, aunque en la mayoría de los casos aparece como null.
user_keys. Lista de claves públicas de usuario almacenadas en el dispositivo.

¿Por qué es importante?

El contenido de este archivo, permite al analista saber si el dispositivo ha sido conectado recientemente a un equipo mediante ADB, lo cual puede dar a conocer los intentos de extracción y análisis de información forense en un dispositivo móvil.

Esto es particularmente útil si se sospecha del uso de herramientas como UFED de Cellebrite o similares en detenciones arbitrarias o accesos físicos al dispositivo.

Una consideración de esta información es que esta información no necesariamente demuestra una intervención maliciosa, sino es un precedente de las conexiones recurrentes con ADB.

Estructura del archivo:

El archivo sigue una estructura de lista de objetos JSON tipo clave-valor

[
    {
        "connected_to_adb": "true",
        "last_key_received": "A0:4B:43:78:C0:B2:3D:A1:38:37:A0:B0:CE:E8:94:96",
        "keystore": null,
        "user_keys": []
    }
]

bugreport_timestamps.json

El contenido de este archivo se genera mediante el módulo fs_timestamps y el artefacto file_timestamps.

Información contenida

Este archivo se encuentra en formato json y contiene información asociada al sistema de archivos y puntos de montaje del sistema que se encuentran en la carpeta FS (File system) dentro del bugreport.

De manera más clara, si en el sistema de archivos existe /dirA/dirB/fileC esto se traduce como FS/dirA/dirB/fileC.

Es importante no confundir el sistema de archivos y puntos de montaje con los archivos generados por el usuario.

La información se presenta como una lista que contiene la ruta del archivo y su última fecha de modificación.

¿Por qué es importante?

La información de este archivo nos permite identificar cambios inusuales en el sistema de archivos y en los puntos de montaje, los cuales pueden ser indicios de actividad maliciosa. Por ejemplo, puede revelar señales de una escalada de privilegios, montajes no autorizados o accesos inusuales que podrían haberse originado por un escape de sandbox a través de descriptores de archivos asociados a hardware como la GPU. Además, esta información puede ayudar a rastrear fallos del sistema vinculados a otros registros como bugreports previos, crash logs o tombstones, facilitando así la reconstrucción de eventos sospechosos.

Estructura del archivo:

{
        "path": "FS/cache/recovery/last_log.8",
        "modified_time": "2019-03-27 23:48:02.000000"
    },
    {
        "path": "FS/cache/recovery/block.map",
        "modified_time": "2025-05-15 12:26:18.000000"
    },
    {
        "path": "FS/cache/recovery/last_history",
        "modified_time": "2019-04-19 07:40:26.000000"
    },
    {
        "path": "FS/cache/recovery/last_log.1",
        "modified_time": "2019-01-19 02:53:42.000000"
    },
    {
        "path": "FS/proc/3188/mountinfo",
        "modified_time": "2025-07-07 11:23:36.000000"
    },
    {
        "path": "FS/proc/3209/mountinfo",
        "modified_time": "2025-07-07 11:23:36.000000"
    },
    {
        "path": "FS/data/anr/anr_2025-07-05-06-49-16-315",
        "modified_time": "2025-07-05 06:49:18.000000"
    },
    {
        "path": "FS/data/log/bt/btsnooz_hci.log.last",
        "modified_time": "2025-07-07 11:22:20.000000"
    }
}

Aprende más

dbinfo.json

El contenido de este archivo se genera mediante el módulo dbinfo y el artefacto dumpsys_dbinfo.

Información contenida

Este archivo se encuentra en formato json y contiene información sobre las bases de datos utilizadas por las aplicaciones y servicios del dispositivo. Esta información es extraída del servicio adb del dumpsys.

Internamente Android utiliza bases de datos SQLite que se encuentran dentro de cada aplicación. Por ejemplo la aplicación com.example.myapp puede contener una base de datos llamada mydatabase.db que se encuentra en /data/data/com.example.myapp/databases/mydatabase.db .

Cada objeto del archivo especifica una operación realizada sobre estas bases de datos, incluyendo:

Marca de tiempo.
Identificador del proceso (pid).
Tipo de operación realizada.
La consulta (query) ejecutada.
Base de datos utilizada.

¿Por qué es importante?

Este archivo resulta importante para dar seguimiento a las consultas ejecutadas en diferentes bases de datos de aplicaciones que puedan considerarse críticas, permitiendo un rastreo de patrones que sean potencialmente maliciosos en el dispositivo.

Estructura del archivo:

[
    {
        "isodate": "2025-01-17 16:55:18.665",
        "pid": "0",
        "action": "executeForLong",
        "sql": "PRAGMA temp.page_size;",
        "path": "/data/user/0/com.sec.android.app.launcher/databases/Icon.db"
    },
    {
        "isodate": "2025-01-17 16:52:18.136",
        "pid": "7280",
        "action": "execute",
        "sql": "COMMIT;",
        "path": "/data/user/0/com.sec.android.app.launcher/databases/Icon.db"
    },
    {
        "isodate": "2025-01-17 16:52:18.133",
        "pid": "7280",
        "action": "executeForChangedRowCount",
        "sql": "DELETE FROM icon WHERE component_name LIKE ? || '/%' AND profile_id = ?",
        "path": "/data/user/0/com.sec.android.app.launcher/databases/Icon.db"
    }
]

Aprende más

Data and file storage overview | App data and files | Android Developers

receivers.json

La información de este archivo se genera mediante el módulo receivers y el artefacto dympsys_receivers.

Información contenida

Este archivo se encuentra en formato json y contiene información sobre receivers e intents de las aplicaciones y servicios en el dispositivo. Esta información es extraída del servicio package del dumpsys.

En términos generales un intent es un mensaje que se puede usar para solicitar una acción de otro componente de la aplicación o del sistema, y un receiver o broadcast receiver es un componente que responde a eventos del sistema o de la aplicación. Uno emite y el otro escucha o responde.

La información en el archivo se presenta de la siguiente manera:

intent. Emisión o solicitud de acción.
package_name. Nombre del paquete (aplicación o servicio) que contiene el receiver.
receiver. Nombre de la clase que maneja el receiver.

¿Por qué es importante?

La información asociada a intents y receivers nos permite identificar si una aplicación o servicio malicioso pudiera estar comunicándose u obteniendo información privada o sensible mediante estos métodos.

Estructura del archivo:

{
    "android.intent.action.SCREEN_OFF": [
        {
            "package_name": "com.facebook.katana",
            "receiver": "com.facebook.katana/com.facebook.notifications.tray.util.NotificationsClientSignalStaticBroadcastReceiver"
        },
        {
            "package_name": "com.zhiliaoapp.musically",
            "receiver": "com.zhiliaoapp.musically/com.ss.android.message.MessageReceiver"
        }
    ],
    "com.samsung.android.easysetup.batteryInfo": [
        {
            "package_name": "com.samsung.android.easysetup",
            "receiver": "com.samsung.android.easysetup/.BeaconBroadcastReceiver"
        }
    ]
}

Procesos y aplicaciones

packages.json

La información de este archivo se genera mediante el módulo packages y el artefacto dumpsys_packages.

Información contenida

Este archivo se encuentra en formato json y contiene información sobre las aplicaciones instaladas en el dispositivo. Esta información es extraída del servicio package del dumpsys.

La información en el archivo se presenta de la siguiente manera:

package_name: Nombre del paquete de la aplicación
uid: Identificador de usuario asociado a la aplicación
version_name: Nombre de la versión de la aplicación
version_code: Código de versión, incluyendo el SDK mínimo y el objetivo.
timestamp: Marca de tiempo de la última actualización
first_install_time: Fecha y hora de la primera instalación
last_update_time: Fecha y hora de la última actualización
permissions: Lista de permisos asociados a la aplicación
requested_permissions: Lista de permisos solicitados por la aplicación, aunque para versiones recientes ya está deprecado y solo hay que prestar atención a permissions.

Dentro de los permisos (permissions y requested_permissions) podemos encontrar:

name: Nombre del permiso solicitado.
granted: Indica si el permiso fue concedido (true) o denegado (false).
type: Tipo de permiso
declared para permisos declarados en el manifiesto de la aplicación.
install para permisos concedidos en la instalación
runtime para permisos solicitados en tiempo de ejecución

¿Por qué es importante?

La información de este archivo permite al analista conocer y mapear las aplicaciones instaladas. De estas es posible identificar información asociada para diagnosticar si pudieran ser potencialmente maliciosas, por ejemplo, abusar de permisos peligrosos o sospechosos, haberse instalado en fechas relevantes identificadas en el diagnóstico , asociarse a procesos de ejecución sospechosa mediante su uid o identificar vectores de ataque como el uso de aplicaciones viejas, desactualizadas o de versiones vulnerables.

Estructura del archivo:

[
    {
        "package_name": "com.whatsapp",
        "uid": "10365",
        "version_name": "2.25.18.80",
        "version_code": "251880000 minSdk=21 targetSdk=35",
        "timestamp": "2025-06-26 03:25:25",
        "first_install_time": "1969-12-31 18:00:00",
        "last_update_time": "2025-06-26 03:25:44",
        "permissions": [
            {
                "name": "com.whatsapp.permission.BROADCAST",
                "type": "declared"
            },
            {
                "name": "com.whatsapp.permission.MAPS_RECEIVE",
                "type": "declared"
            },
           {
                "name": "com.google.android.finsky.permission.BIND_GET_INSTALL_REFERRER_SERVICE",
                "granted": true,
                "type": "install"
            },
            {
                "name": "android.permission.USE_CREDENTIALS",
                "granted": true,
                "type": "install"
            },
            {
                "name": "android.permission.POST_NOTIFICATIONS",
                "granted": true,
                "type": "runtime"
            },
            {
                "name": "android.permission.READ_CALL_LOG",
                "granted": false,
                "type": "runtime"
            },
            {
                "name": "android.permission.ACCESS_FINE_LOCATION",
                "granted": true,
                "type": "runtime"
            },
            {
                "name": "android.permission.NEARBY_WIFI_DEVICES",
                "granted": false,
                "type": "runtime"
            },
            {
                "name": "android.permission.RECEIVE_SMS",
                "granted": false,
                "type": "runtime"
            },
            {
                "name": "android.permission.BLUETOOTH_CONNECT",
                "granted": false,
                "type": "runtime"
            }
        ],
        "requested_permissions": []
    }
]

Aprende más

Permisos en Android

activities.json

La información de este archivo se genera mediante el módulo activities y el artefacto dumpsys_package_activities.

Información contenida

Este archivo se encuentra en formato json y contiene información sobre los intents y activities asociadas a cada aplicación instalada en el dispositivo. Esta información es extraída del servicio package del dumpsys.

En términos generales un intent es un mensaje que se puede usar para solicitar una acción de otro componente de la aplicación o del sistema, y un activity es un componente que responde como punto de entrada principal de una aplicación, esto es el equivalente a un main en algunos lenguajes de programación o a una ventana en entornos gráficos. Uno emite acciones a otras aplicaciones y el otro es con lo que la persona usuaria interactúa.

La información en el archivo se presenta de la siguiente manera:

intent. Emisión o solicitud de acción.
package_name. Nombre del paquete (aplicación o servicio) asociado al activity.
activity: Nombre de la clase que maneja el activity.

¿Por qué es importante?

La información asociada a intents y receivers nos permite identificar si una aplicación o servicio malicioso pudiera estar comunicándose u obteniendo información privada o sensible mediante estos métodos.
Los intents permiten identificar si una aplicación está enviando información o solicitudes de acciones a otra aplicación, mientras que el activity nos permite identificar desde donde se emitió el intent.

Esto es útil para identificar cómo es que interactúan las aplicaciones entre sí o que tipo de servicios están expuestos en algunas componentes de las aplicaciones, de esta manera, se puede detectar intents y activities que podrían ser utilizados de manera maliciosa en segundo plano.

Estructura del archivo:

[
    {
        "intent": "com.google.android.gms.autofill.ACTION_SETTINGS",
        "package_name": "com.google.android.gms",
        "activity": "com.google.android.gms/.autofill.ui.AutofillSettingsPrivacyHubActivity"
    },
    {
        "intent": "android.settings.FINGERPRINT_SETUP",
        "package_name": "com.android.settings",
        "activity": "com.android.settings/.biometrics.fingerprint.SetupFingerprintEnrollIntroduction"
    },
    {
        "intent": "com.samsung.android.samsungaccount.action.REQUEST_SA_CONSENT_AGREEMENT_SUW",
        "package_name": "com.osp.app.signin",
        "activity": "com.osp.app.signin/com.samsung.android.samsungaccount.authentication.ui.tnc.view.TncReAgreementView"
    }
]

Aprende más

appops.json

La información de este archivo se genera mediante el módulo appops y el artefacto dumpsys_appos.

Información contenida

Este archivo se encuentra en formato json y contiene información sobre las operaciones asociadas a permisos de las aplicaciones instaladas en el dispositivo. Esta información es extraída del servicio appos del dumpsys.

La información en el archivo se presenta de la siguiente manera:

package_name. Nombre del paquete (aplicación o servicio).
permissions: Lista de permisos asociados a la aplicación.
- name: Nombre del permiso solicitado por el paquete.
- entries: Historial de operaciones sobre el permiso.
  - access: Estado del permiso
    - allow. Se permitió el acceso al permiso.
    - ignore. No se permitió el acceso al permiso.
    - deny. Arroja una SecurityException al solicitar el acceso al permiso.
    - default. Comportamiento por defecto del permiso.
    - foreground. Se permitió el acceso al permiso pero solo si la aplicación está en segundo plano.
  - type: Categoría de la operación. Esta se compone del estado actual de la operación y de una bandera asociada al contexto de ejecución de la operación. El estado de la operación se refiere a si fue realizada en primer plano, segundo plano, etc. Y el contexto de ejecución se refiere a si la operación se ejecutó por la aplicación directamente, por una aplicación externa confiable, por una aplicación no-verificada, etc. Estas se concatenan mediante un guión medio. No se incluye en todos los registros.
    - Los valores para el estado de la operación pueden ser los siguientes:
      - pers. La operación pertenece a un proceso persistente (por ejemplo, servicios del sistema que no deben morir).
      - top. La operación corresponde a la app que está actualmente en primer plano (visible para el usuario).
      - fgsvcl. La operación pertenece a un servicio en primer plano que accede a la ubicación.
      - fgsvc. La operación pertenece a un servicio en primer plano (foreground service).
      - fg. La operación está en primer plano (actividad visible o componente en uso).
      - bg. La operación está en segundo plano.
      - cch. La operación está en la caché, es decir, el proceso no se está ejecutando activamente.
      - gone. La operación no tiene procesos activos (no existe actualmente).
      - unknown. Estado desconocido o no categorizado.
    - Los valores para la bandera de contexto de la operación pueden ser los siguientes:
      - s. La operación fue ejecutada directamente por la propia aplicación (contexto propio).
      - tp. La operación fue ejecutada por una aplicación confiable actuando como proxy para otra aplicación.
      - up. La operación fue ejecutada por una aplicación no confiable actuando como proxy para otra aplicación.
      - tpd. La operación fue ejecutada en nombre de esta aplicación por un proxy confiable.
      - upd. La operación fue ejecutada en nombre de esta aplicación por un proxy no confiable.
      - unknown. Contexto de operación desconocido.
  - timestamp: Marca de tiempo en que se registró la operación. No se incluye en todos los registros.
uid: Identificador de usuario asociado a la aplicación.

¿Por qué es importante?

Las apps operations permiten identificar con precisión qué aplicaciones han solicitado permisos específicos y bajo qué condiciones y contexto de ejecución se están solicitando estas.

Esto es útil para identificar si una aplicación se ejecuta en contextos de confiables (trusted context) o contextos no confiables (untrusted context) al solicitar un permiso, es decir, identificar si una aplicación está usando a otra aplicación como proxy para poder solicitar un permiso y verificar la forma en que esta operación se llevó a cabo, por ejemplo, si esta solicitud de permiso vino desde otra aplicación como proxy en segundo plano o ejecutándose desde cache.

Identificar contextos riesgosos de solicitud de permisos en apps operations, permite reconocer patrones de solicitud de permisos repetitivos que sean sospechosos y que nos permitan evaluar a profundidad si el contexto en que se ejecuta la operación es legítimo o está vinculado al abuso de permisos y privilegios revelando algún comportamiento malicioso relacionado con malware.

Estructura del archivo:

{
    "package_name": "com.samsung.android.provider.filterprovider",
    "permissions": [
        {
            "name": "MANAGE_EXTERNAL_STORAGE",
            "entries": [
                {
                    "access": "Reject",
                    "type": "pers-s",
                    "timestamp": "2024-12-01 19:47:10.776000"
                }
            ],
            "access": "default"
        },
        {
            "name": "BLUETOOTH_CONNECT",
            "entries": [
                {
                    "access": "Access",
                    "type": "pers-s",
                    "timestamp": "2024-12-11 06:41:14.035000"
                }
            ],
            "access": "allow"
        }
    ],
    "uid": "1000"
}

Aprende más

accessibility.json

La información de este archivo se genera mediante el módulo accessibility y el artefacto dumpsys_accesibility.

Información contenida

Este archivo se encuentra en formato json y contiene información sobre los servicios de accesibilidad activos relacionados a una aplicación del dispositivo. Esta información es extraída del servicio accessibility del dumpsys.

En términos generales un servicio de accesibilidad es un componente de una aplicación que ejecuta tareas en segundo plano y que puede observar los eventos que están sucediendo en la interfaz y realizar alguna acción por el usuario con la finalidad de asistir a personas con discapacidades. Por ejemplo lectores de pantalla en voz alta, control de colores de contraste del sistema, escucha del micrófono para comandos de voz, etc, y que pueden ser abusados o utilizados de manera maliciosa.

La información en el archivo se presenta de la siguiente manera:

package_name: Nombre del paquete (aplicación o servicio).
service: Nombre de la clase que maneja el servicio de accesibilidad.

¿Por qué es importante?

Este archivo nos permite identificar si una aplicación hace uso de un servicio de accesibilidad. Esto es útil para identificar el nombre completo de la clase del servicio y atribuir si su uso tiene objetivos maliciosos.

Estructura del archivo:

[
    {
        "package_name": "com.google.android.apps.accessibility.voiceaccess",
        "service": "com.google.android.apps.accessibility.voiceaccess/.JustSpeakService  (A11yTool)"
    },
    {
        "package_name": "com.microsoft.appmanager",
        "service": "com.microsoft.appmanager/com.microsoft.mmx.screenmirroringsrc.accessibility.ScreenMirroringAccessibilityService"
    },
    {
        "package_name": "com.samsung.accessibility",
        "service": "com.samsung.accessibility/.universalswitch.UniversalSwitchService  (A11yTool)"
    },
    {
        "package_name": "com.samsung.accessibility",
        "service": "com.samsung.accessibility/.assistantmenu.serviceframework.AssistantMenuService  (A11yTool)"
    },
    {
        "package_name": "com.samsung.android.accessibility.talkback",
        "service": "com.samsung.android.accessibility.talkback/com.samsung.android.marvin.talkback.TalkBackService  (A11yTool)"
    }
]

Aprende más

AccessibilityService on Android

tombstones.json

La información de este archivo se genera mediante el módulo tombstones, el artefacto tombstone_crashes y el parser proto/tombstone.

Información contenida

Este archivo se encuentra en formato json y contiene información sobre los registros de fallas de una aplicación o servicio. Esta información es extraída de los archivos tombstone.pb que se encuentran en la carpeta FS/data/tombstones dentro del bugreport.

Este archivo contiene información detallada sobre los procesos involucrados, las señales de errores que se activaron al momento de la falla, binarios asociados en el fallo y el entorno en general en el que se generó la falla.

La información en el archivo se presenta de la siguiente manera:

file_name: Nombre del archivo, por ejemplo tombstone_xx.
file_timestamp: Marca de tiempo de la última modificación del archivo en formato YYYY-MM-DD hh-mm-ss.ms.
build_fingerprint: Identificador de compilación del Android que estaba corriendo al momento de la falla.
revision: Versión del formato del archivo.
arch: Arquitectura del sistema donde ocurrió el fallo.
timestamp: Marca de tiempo en la que ocurrió la falla en formato YYYY-MM-DD hh-mm-ss.ms.
process_uptime: Tiempo en segundos que llevaba en ejecución el proceso que falló.
command_line: Comando o proceso que generó la falla.
pid: Identificador único del proceso que causó el crash.
tid: Identificador del hilo donde ocurrió el crash (puede coincidir con el pid si fue el hilo principal).
process_name: Nombre del proceso que falló.
binary_path: Ruta del binario ejecutado al momento del fallo.
selinux_label: Etiqueta de contexto SELinux u:r:dominio:s0:categoría asociada al proceso que falló. Compuesta por:
- u: Usuario SELinux que agrupa procesos bajo un mismo espacio de reglas de seguridad.
- r: Rol SELinux que conecta al usuario con los dominios. En el caso de la política SELinux de android, el rol está presente para la compatibilidad con el formato estándar de SELinux.
- dominio: Tipo o dominio SELinux. Esta parte del contexto identifica el proceso o servicio que falló. Los dominios que pueden aparecer en este campo provienen de la política SELinux activa del dispositivo, donde, dentro de esta política, los dominios se definen en archivos .te especfiicos para servicios del sistema, aplicaciones de usuario, en el HAL o en un proceso crítico.
- Nivel de seguridad: Corresponde al componente multi level security o multi category security e incluye únicamente el nivel base de seguridad y en algunas ocasiones categorías adicionales que permiten diferenciar instancias de procesos fallidos bajo un mismo dominio. El nivel más simple es s0, que es el valor base presente en la mayoría de procesos del sistema, cuando se requiere un aislamiento adicional, principalmente en aplicaciones de usuario, el nivel puede incluir categorías adicionales.
uid: ID de usuario asociado a la ejecución del procesos.
signal_info: Señal enviada desde o al sistema al provocar la falla.
code: Código específico que indica cómo se generó la señal. Pueden ser los siguientes:
- 0 \= SI_USER
- 128 \= SI_KERNEL
- -1 \= SI_QUEUE
- -2 \= SI_TIMER
- -3 \= SI_MESGQ
- -4 \= SI_ASYNCIO
- -5 \= SI_SIGIO
- -6 \= SI_TKILL
- -7 \= SI_DETHREAD
code_name: Señal asociada al código. Pueden ser los siguientes:
- SI_USER: Señal enviada manualmente desde el espacio de usuario (es decir, por un programa o por el propio usuario). Normalmente no indica un error del sistema, sino que el proceso fue terminado de forma externa por alguien o por otro programa.
- SI_KERNEL: Señal generada directamente por el kernel.Suele estar asociada a fallos graves de memoria o hardware que se detectan en el nivel más bajo del sistema.
- SI_QUEUE: Señal que incluye información adicional y se envía entre procesos. Sirve para comunicación avanzada, por ejemplo, en programas multihilo o cuando se usan colas de señales. No está relacionada con errores, sino con eventos de coordinación entre procesos. Generalmente utilizada para notificar de un proceso a otro con más contexto que solo la señal.
- SI_TIMER: Señal que el kernel envía cuando expira un temporizador. Los temporizadores se usan para controlar que ciertas operaciones no duren demasiado, para muestrear el estado de los hilos o para activar tareas automáticas del sistema. En este caso, la señal puede significar que un proceso terminó porque un temporizador lo forzó. Algunos de estos temporizadores pueden ser watchdogs del sistema o procesos de sampling de memoria.
- SI_MESGQ: Señal generada cuando llega un mensaje a una cola de mensajes POSIX (un mecanismo de comunicación entre procesos en sistemas tipo Unix). Este sistema se usa en lugar de pipes, sockets o binders. La señal normalmente se activa cuando hay actividad en la cola, pero puede ocasionar problemas si el envío y la recepción no están bien sincronizados.
- SI_ASYNCIO: Señal enviada por el kernel al finalizar una operación de entrada/salida asíncrona (Asynchronous I/O). Si el programa no tiene un manejador adecuado para esta señal, o si este falla, la aplicación puede terminar de forma inesperada.
- SI_SIGIO: Señal relacionada con operaciones de entrada/salida en archivos o sockets. Sucede cuando un descriptor de archivo está configurado para notificar eventos mediante señales o cuando ocurre un error en dicho descriptor.
- SI_TKILL: Señal usada para terminar un hilo específico (y no todo el proceso). Normalmente la genera el propio programa, su entorno de ejecución (por ejemplo Dalvik/ART) o alguna de sus librerías internas.
- SI_DETHREAD: Señal interna usada por el sistema cuando se “desacoplan” hilos de un proceso multihilo. Esto ocurre si el hilo principal muere o si se solicita explícitamente terminar un grupo de hilos asociados.
name: Nombre de la señal. Pueden ser las siguientes:
- SIGILL: Ejecución de una instrucción no válida.
- SIGTRAP: Activación de un breakpoint. Útil para identificar depuración o interferencia con el flujo de un proceso.
- SIGABRT: Terminación forzada por el propio proceso al detectar un fallo crítico. Puede relacionarse con errores provocados.
- SIGBUS: Acceso inválido al bus de memoria.
- SIGFPE: Error aritmético como división por cero.
- SIGSEGV: Acceso ilegal a la memoria. Asociado a desbordamientos de buffer.
- SIGSTKFLT: Fallo en la pila de ejecución.
- SIGSTOP: Pausa total de un proceso sin posibilidad de capturar información sobre el proceso.
number: Número de la señal POSIX que provocó la falla. Pueden ser los siguientes:
- 4 \= SIGILL
- 5 \= SIGTRAP
- 6 \= SIGABRT
- 7 \= SIGBUS
- 8 \= SIGFPE
- 11 \= SIGSEGV
- 16 \= SIGSTKFLT
- 19 \= SIGSTOP
cause: Cadena textual que explica la causa del fallo si fue registrada explícitamente. Puede estar vacía o nula.
extra: Campos reservados para datos adicionales.

¿Por qué es importante?

Los tombstones permiten identificar los fallos críticos de aplicaciones o procesos, incluyendo detalles esenciales como la señal que provocó el fallo, el proceso implicado, el tiempo del evento y la línea o comando activo al momento de la falla.

Esto es útil para detectar los procesos, servicios o aplicaciones que están fallando o que están provocando fallos en el sistema. De esta manera, se puede determinar si los procesos que están generando fallos son anormales del sistema, si el contexto de seguridad y ejecución demuestra un comportamiento inusual o no autorizado y si las señales indican alguna posible explotación del sistema o algún fallo provocado por otro proceso que indique un comportamiento malicioso.

Estructura del archivo:

{
        "file_name": "tombstone_05",
        "file_timestamp": "2025-01-01 00:00:00.000000",
        "build_fingerprint": "phone/r8qxx/r8q:13/TP1A.220624.014/G780GXXSCEXI1:user/release-keys",
        "revision": 10,
        "arch": "arm64",
        "timestamp": "2025-01-01 00:00:00.173266",
        "process_uptime": 1,
        "command_line": [
            "lowi-server"
        ],
        "pid": 17292,
        "tid": 17293,
        "process_name": "lowi-server",
        "binary_path": "lowi-server",
        "selinux_label": null,
        "uid": 1021,
        "signal_info": {
            "code": -1,
            "code_name": "SI_QUEUE",
            "name": "SIGABRT",
            "number": 6
        },
        "cause": null,
        "extra": null
    },

Aprende más

battery_daily.json

La información de este archivo se genera mediante el módulo battery_daily y el artefacto dumpsys_battery_daily.

Información contenida
Este archivo se encuentra en formato json y contiene información sobre los registros update relacionados con una aplicación. Esta información es extraída del servicio batterystats del dumpsys.

El action en este archivo hace referencia a un evento update registrado por el servicio batterystats que indica el rango de fechas en que una aplicación fue actualizada y que versión es la que quedó registrada después de la actualización.

¿Por qué es importante?

La información del battery_daily permite identificar las actualizaciones de aplicaciones instaladas en un dispositivo sobre el rango de fechas en la que se cambió de una versión a otra y registrando la versión de aplicación asignada después de esta actualización.

Esto es útil para identificar aplicaciones que han cambiado de versión de manera frecuente e inusual. De esta manera, es posible que se determine si una actualización puede relacionarse en periodos específicos de tiempo y fechas que coincidan con comportamientos o actividades sospechosas en el dispositivo y que puedan ser indicadores de presencia de malware.

Estructura del archivo:

[
    {
        "action": "update",
        "from": "2025-01-16",
        "to": "2025-01-17",
        "package_name": "com.instagram.android",
        "vers": "376704533"
    },
    {
        "action": "update",
        "from": "2025-01-14",
        "to": "2025-01-15",
        "package_name": "com.facebook.katana",
        "vers": "458034716"
    }
]

battery_history.json

La información de este archivo se genera mediante el módulo battery_history y el artefacto dumpsys_battery_history.

Información contenida

Este archivo se encuentra en formato json y contiene información sobre los registros event relacionados con una aplicación instalada y su servicio. Esta información es extraída del servicio batterystats del dumpsys.

Un event es un registro que indica una acción ejecutada por una aplicación y el servicio específico que realizó el cambio. El event representa el inicio o fin de una acción programada de una aplicación sobre el dispositivo, la activación o desactivación de un método de una aplicación que mantiene un dispositivo activo y los cambios de estados que tiene una aplicación al pasar de primer a segundo plano.

La información en el archivo se presenta de la siguiente manera:

time_elapsed: Tiempo transcurrido desde el inicio del registro del historial hasta que ocurrió el evento en milisegundos.
event: Acción registrada como evento de una aplicación, pueden ser
start_job: El evento que indica que una aplicación inició un trabajo o tarea programada.
end_job: El evento que indica que una aplicación finalizó un trabajo o tarea programada.
wake: El evento que indica que una aplicación activó un wake lock para evitar que el dispositivo o el procesador entren en suspensión.
start_top: El evento que indica que una aplicación pasó a primer plano y se volvió visible para el usuario.
end_top: El evento que indica que una aplicación dejó de estar en primer plano y pasó a segundo plano.
uid: Identificador de usuario asociado a la aplicación.
package_name: Nombre del paquete.
service: Nombre completo del servicio o componente específico que ejecutó la acción.

¿Por qué es importante?

La información del battery_history permite identificar los eventos ejecutados por aplicaciones instaladas en un dispositivo, como el inicio o finalización de trabajos programados, el paso de una aplicación a primer o segundo plano, o la activación de mecanismos para mantener el dispositivo despierto.

Estructura del archivo:

{
    "time_elapsed": "+493ms",
    "event": "end_job",
    "uid": "u0a234",
    "package_name": "com.android.vending",
    "service": "com.android.vending/com.google.android.finsky.scheduler.process.backgroundimpl.PhoneskyJobServiceBackground"
}

platform_compact.json

La información de este archivo se genera mediante el módulo platform_compat y el artefacto dumpsys_platform_compat.

Información contenida

Este archivo se encuentra en formato json y contiene información sobre los registros de packages_name identificados con cambios de tipo DOWNSCALED. Esta información es extraída del servicio platform_compat del dumpsys para identificar aplicaciones desinstaladas.

El servicio platform_compat es un administrador de configuraciones de compatibilidad entre aplicaciones y los cambios internos que tiene el sistema Android, si la versión de Android es incompatible con alguna función de una aplicación, el servicio platform_compat puede activar o desactivar ese cambio en el sistema de forma individual por aplicacion para que esta siga activa para el usuario o el sistema.

platform_compat es capaz de identificar cada uno de los cambios y ajustes de compatibilidad dentro del sistema Android mediante un ChangeId. Así mismo, es capaz de proveer información extra sobre estos cambios mediante el campo name el cual hace referencia al nombre descriptivo del cambio, la etiqueta overridable que indica si el sistema puede habilitar o deshabilitar funciones para aplicaciones específicas y la lista rawOverrides, que contiene los paquetes que tienen un ajuste personalizado para un cambio en el sistema operativo.

El archivo generado provee una lista de paquetes identificados mediante el changeId 168419799 asociado a la política DOWNSCALED, y dentro de esta lista identifica la sección rawOverrides para encontrar aplicaciones desinstaladas.

¿Por qué es importante?
La información del platform_compat permite identificar aplicaciones desinstaladas lo cual nos permite conocer si una aplicación maliciosa se desinstalo previo al análisis.

Estructura del archivo:

{
        "package_name": "com.example.app"
    },
    {
        "package_name": "com.example.app"
    },
    {
        "package_name": "com.example.app"
    },
    {
        "package_name": "com.example.app"
    },
    {
        "package_name": "com.example.app"

Aprende más

Comentarios

¿Tienes comentarios o sugerencias sobre este recurso? Puedes utilizar la función de comentar que se muestra a continuación para dejarnos tus ideas o apreciaciones. Por favor asegúrate de seguir nuestro código de conducta. La función de comentarios enlaza directamente a la sección de Discussions de Github, donde también puedes participar en las discusiones de forma directa, si lo prefieres.