Skip to content

MVT bugreport output file dictionary

MVT bugreport output file dictionary

This document contains information about the files generated by MVT through the mvt-check bugreport component. The objective of this dictionary is to provide analysts with the ability to easily search for specific information and to understand the format in which the forensic analysis data is presented.

This resource is part of a technical documentation repository, whose goal is to establish a proven, flexible, and accessible knowledge base to strengthen consent-based forensic analysis in benefit of civil society. To organize the contents we use the technical documentation framework Diataxis.

This specific resource falls within the category of references, and contains information about the analysis of bugreports using MVT and specifically the mvt-android check-bugreport command. The purpose of this dictionary is to help analysts understands the files generated, how to use them, where to look for specific information, and in what format it can be found.

For the development of this resource we used version 2.6.0 of MVT.

The information generated by mvt-bugreport can be grouped into 4 main categories:

  • Acquisition details
  • Device configuration
  • Information on system logs and events
  • Processes and applications

Acquisition details

info.json

What is included in this file?

This file is in JSON format and contains information related to the analysis performed on the bugreport file. More specifically, it includes:

  • Path of the analyzed file.
  • Version of MVT used.
  • Date of the analysis.
  • List of indicator of compromise (IoC) files.
  • Hash of the analyzed bugreport (SHA-256).

Why is this important?

This file allows us to validate the analysis that has been performed, documenting the record of the acquisition process and the indicators that were considered for making the analysis.

It also provides useful information to support chain of custody by documenting version, hashes and logs related to the forensic examination.

File structure::

{
    "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

What is included in this file?

This file is in plain text format with a .log extension and contains the detailed records of the execution of the mvt-android check-bugreport command. It shows the output of the analysis performed on the bugreport, including any detection of indicators of compromise related to malware.

The records in the file are presented with the following structure:

  • Timestamps
  • Names of the module in execution
  • Message type (INFO, DEBUG, WARNING, ERROR)
  • Corresponding action of the module (parsing the file, loading IoCs, comparison, and result of the comparison).

The message types can be described as follows:

  • INFO. Messages also shown on screen during execution.
  • DEBUG. Information not shown on screen but associated with an action performed during the analysis, for example, loading an IoC or checking a hash.
  • WARNING. Corresponds to alerts of activity or suspicious information that an analyst should verify.
  • ERROR. Error messages in some action performed during the analysis, for example, when loading a corrupted file or an issue with executing the corresponding code.

Why is this important?

It presents record of the actions performed and findings from the analysis. Through this record, it is possible to verify the following:

  • That the analysis was performed correctly
  • If there was any match with known IoCs
  • If any suspicious information or activity was identified.

File structure::

This file follows the structure shown on top:

[TIMESTAMP] - [MODULE] - [LOG LEVEL] - [MESSAGE]  
...
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!

Learn more

timeline.csv

What is included in this file?

This file is in csv format and stores a timeline of the device’s activity. This activity is obtained from the execution of the MVT analysis modules and is ordered by time.

Each line of the csv corresponds to:

  • Device Local Timestamp
  • Executed module (Plugin)
  • Activity identified on the device (Event)
  • Description of the activity identified on the device (Description)

Why is this important? * This file can help gain a more clear understanding of the sequence of events and activities, giving a more clear idea of the device behaviors at different times.

File structure:

This file follows the structure shown on top:

"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"
...

Device configurations

getprop.json

The information on this file is generated by the getprop module and the artifact getprop.

What is included in this file?

This file is in json format and contains a list of the device properties extracted from the SYSTEM PROPERTIES section of dumpsys.

These system properties are string key-value pairs stored in the global build.prop dictionary or in .sysprop description files, providing a convenient way to share configurations within the system.

The information can be found using the following format:

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

Some properties appear with the ro prefix, indicating they are read-only properties or assigned after the device reboot. Properties with the persist prefix refer to settings that persist across reboots. Some properties have no prefix, starting directly with the group to which they belong.

The most common groups are:

  • bluetooth, related to Bluetooth
  • boot, kernel cmdline sysprops
  • build, sysprops identifying a build
  • telephony, related to telephony
  • audio, related to audio
  • graphics, related to graphics
  • vold, related to vold, which manages the mounting of physical external storage volumes

For more detail, you can review the list of properties already defined in the Android source code

Why is this important?

Properties provide important information about the device’s hardware and software, which can be altered by malicious software to hide its presence or to inadvertently modify the device’s behavior.

File structure::

[
    {
        "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"
    }
]

Learn more

Information on system logs and events

dumpsys_adb_state.json

The content of this file is generated using the adb_state module and the dumpsys_adb artifact.

What is included in this file?

This file is in json format and contains information about an ADB connection, which is extracted from the adb service in dumpsys.

The information in the file is presented as follows:

  • connected_to_adb. Indicates whether the device had an active connection to ADB (true or false).
  • last_key_received. A hexadecimal string representing the last public key used to pair the device with the ADB host.
  • keystore. May contain information about the key store used for authentication, although in most cases it appears as null.
  • user_keys. List of user public keys stored on the device.

Why is this important?

The content of this file allows the analyst to determine whether the device has been recently connected to a computer via ADB, which can reveal attempts to extract and analyze forensic information from a mobile device.

This is particularly useful if the use of tools like Cellebrite UFED or similar is suspected in cases of arbitrary detention or physical access to the device.

One consideration regarding this information is that it does not necessarily demonstrate malicious intervention; rather, it serves as a record of recurrent ADB connections.

File structure::

The file follows a structure of a list of key-value JSON objects.

[
    {
        "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

The content of this file is generated by the fs_timestamps module and the artifact file_timestamps.

What is included in this file?

This file is in json format and contains information related to the file system and system mount points located in the FS (File system) folder within the bugreport.

More concretely, if in the file system there is /dirA/dirB/fileC, this is represented as FS/dirA/dirB/fileC. It is important not to confuse the file system and mount points with user-generated files.

The information is presented as a list containing the file path and its last modification date.

Why is this important?

The information in this file allows us to identify unusual changes in the file system and mount points, which could be indicators of malicious activity. For example, it may reveal signs of privilege escalation, unauthorized mounts, or unusual accesses that could have originated from a sandbox escape through file descriptors associated with hardware like the GPU. Additionally, this information can help trace system failures linked to other records such as previous bugreports, crash logs, or tombstones, thereby facilitating the reconstruction of suspicious events.

File structure::

{
        "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"
    }
}

Learn more

dbinfo.json

The content of this file is generated by the dbinfo module and the dumpsys_dbinfo artifact.

What is included in this file?

This file is in json format and contains information about the databases used by the applications and services on the device. This information is extracted from the adb service of dumpsys.

Internally, Android uses SQLite databases that reside within each application. For example, the application com.example.myapp may contain a database named mydatabase.db located at /data/data/com.example.myapp/databases/mydatabase.db.

Each object in the file specifies an operation carried out on these databases, including:

  • Timestamp
  • Process identifier (pid)
  • Type of operation performed
  • Executed query
  • Database used

Why is this important?

This file is important for tracking queries executed on different application databases that may be considered critical, enabling the identification of potentially malicious patterns on the device.

File structure::

[
    {
        "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"
    }
]

Learn more

receivers.json

The content of this file is generated by the receivers module and the dympsys_receivers artifact.

What is included in this file?

This file is in json format and contains information about receivers and intents of applications and services on the device. This information is extracted from the package service of dumpsys. * In general terms, an intent is a message that can be used to request an action from another application or system component, and a receiver (or broadcast receiver) is a component that responds to system or application events. One issues the request, and the other listens or responds.

The information in the file is presented as follows:

  • intent. The broadcast or action request.
  • package_name. Name of the package (application or service) that contains the receiver.
  • receiver. Name of the class that handles the receiver.

Why is this important?

The information associated with intents and receivers allows us to identify whether a malicious application or service may be communicating or obtaining private or sensitive information through these mechanisms.

File structure::

{
    "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"
        }
    ]
}

Processes and applications

packages.json

The information on this file is generated by the packages module and the dumpsys_packages artifact.

What is included in this file?

This file is in json format and contains information about the applications installed on the device. This information is extracted from the package service of dumpsys.

The information in the file is presented as follows:

  • package_name: Name of the application package
  • uid: User identifier associated with the application
  • version_name: Version name of the application
  • version_code: Version code, including the minimum and target SDK
  • timestamp: Timestamp of the last update
  • first_install_time: Date and time of the first installation
  • last_update_time: Date and time of the last update
  • permissions: List of permissions associated with the application
  • requested_permissions: List of permissions requested by the application, although in recent versions it is deprecated and attention should only be given to permissions.

Within the permissions (permissions and requested_permissions) we can find:

  • name: Name of the requested permission
  • granted: Indicates whether the permission was granted (true) or denied (false)
  • type: Type of permission
  • declared for permissions declared in the application manifest.
  • install for permissions granted during installation
  • runtime for permissions requested at runtime

Why is this important?

The information in this file allows the analyst to know and map the installed applications, and diagnose whether they could be potentially malicious. For example: abusing dangerous or suspicious permissions, being installed at relevant dates identified in the diagnosis, being associated with suspicious execution processes through their uid, or identifying attack vectors such as the use of old, outdated, or vulnerable versions of applications.

File structure::

[
    {
        "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": []
    }
]

Learn more

activities.json

The information in this file is generated by the activities module and the dumpsys_package_activities artifact.

What is included in this file?

This file is in json format and contains information about the intents and activities associated with each application installed on the device. This information is extracted from the package service of dumpsys.

In general terms an intent is a message that can be used to request an action from another component of the application or the system, and an activity is a component that responds as the main entry point of an application. This is the equivalent of a main in some programming languages or of a window in graphical environments. One issues actions to other applications and the other is what the user interacts with.

The information in the file is presented as follows:

  • intent. Issuance or request of action.
  • package_name. Name of the package (application or service) associated with the activity.
  • activity: Name of the class that handles the activity.

Why is this important?

The information associated with intents and receivers allows us to identify whether a malicious application or service could be communicating or obtaining private or sensitive information through these methods. The intents allow identifying whether an application sends information or requests for actions to another application, while the activity allows us to identify from where the intent was issued.

This is useful to identify how applications interact with each other or what type of services are exposed in some components of the applications. In this way, it is possible to detect intents and activities that could be used maliciously in the background.

File structure::

[
    {
        "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"
    }
]

Learn more

appops.json

The information in this file is generated by the appops module and the dumpsys_appos artifact.

What is included in this file?

This file is in json format and contains information about the operations associated with permissions of the applications installed on the device. This information is extracted from the appops service of dumpsys.

The information in the file is presented as follows:

This file is in json format and contains information about the operations associated with permissions of the applications installed on the device. This information is extracted from the appops service of dumpsys.

The information in the file is presented as follows:

  • package_name. Name of the package (application or service).
  • permissions: List of permissions associated with the application.
    • name: Name of the permission requested by the package.
    • entries: History of operations on the permission.
      • access: Status of the permission
        • allow. Access to the permission was allowed.
        • ignore. Access to the permission was not allowed.
        • deny. Throws a SecurityException when requesting access to the permission.
        • default. Default behavior of the permission.
        • foreground. Access to the permission was allowed but only if the application is in the background.
      • type: Category of the operation. This is composed of the current state of the operation and of a flag associated with the execution context of the operation. The state of the operation refers to whether it was performed in the foreground, background, etc. And the execution context refers to whether the operation was executed directly by the application, by a trusted external application, by an unverified application, etc. These are concatenated with a hyphen. Not included in all records.
        • The values for the state of the operation can be the following:
          • pers. The operation belongs to a persistent process (for example, system services that should not die).
          • top. The operation corresponds to the app that is currently in the foreground (visible to the user).
          • fgsvcl. The operation belongs to a foreground service that accesses location.
          • fgsvc. The operation belongs to a foreground service.
          • fg. The operation is in the foreground (visible activity or component in use).
          • bg. The operation is in the background.
          • cch. The operation is in cache, that is, the process is not actively running.
          • gone. The operation has no active processes (does not currently exist).
          • unknown. Unknown or uncategorized state.
        • The values for the operation context flag can be the following:
          • s. The operation was executed directly by the application itself (own context).
          • tp. The operation was executed by a trusted application acting as a proxy for another application.
          • up. The operation was executed by an untrusted application acting as a proxy for another application.
          • tpd. The operation was executed on behalf of this application by a trusted proxy.
          • upd. The operation was executed on behalf of this application by an untrusted proxy.
          • unknown. Unknown operation context.
      • timestamp: Timestamp when the operation was recorded. Not included in all records.
  • uid: User identifier associated with the application.

Why is this important?

The apps operations allow us to precisely identify which applications have requested specific permissions and under what conditions and execution context these are being requested.

This is useful to identify whether an application is running in trusted contexts or untrusted contexts when requesting a permission, that is, to identify if an application is using another application as a proxy in order to request a permission, and to verify the way in which this operation was carried out, for example, if this permission request came from another application as a proxy in the background or running from cache.

Identifying risky contexts of permission requests in apps operations allows recognizing repetitive patterns of suspicious permission requests that let us evaluate in depth whether the context in which the operation is executed is legitimate or is linked to the abuse of permissions and privileges, revealing malicious behavior related to malware.

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.

File structure::

{
    "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"
}

Learn more

accessibility.json

The information in this file is generated by the accessibility module and the dumpsys_accesibility artifact.

What is included in this file?

This file is in json format and contains information about the active accessibility services related to an application on the device. This information is extracted from the accessibility service of dumpsys.

In general terms, an accessibility service is a component of an application that runs background tasks and can observe the events happening in the interface and perform some action for the user in order to assist people with disabilities. For example, screen readers, system high-contrast color controls, microphone listening for voice commands, etc., which can be abused by attackers.

The information in the file is presented as follows:

  • package_name: Name of the package (application or service).
  • service: Name of the class that handles the accessibility service.

Why is this important?

This file allows us to identify if an application makes use of an accessibility service. This is useful to identify the full name of the service class and determine whether its use has malicious objectives.

File structure::

[
    {
        "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)"
    }
]

Learn more

tombstones.json

The information in this file is generated by the tombstones module, the tombstone_crashes artifact and the proto/tombstone.

What is included in this file?

This file is in json format and contains information about the crash logs of an application or service. This information is extracted from the tombstone.pb files located in the FS/data/tombstones folder within the bugreport.

This file contains detailed information about the processes involved, the error signals triggered at the time of the crash, binaries associated with the crash, and the general environment in which the crash occurred.

The information in the file is presented as follows:

  • file_name: Name of the file, for example tombstone_xx.
  • file_timestamp: Timestamp of the file’s last modification in YYYY-MM-DD hh-mm-ss.ms format.
  • build_fingerprint: Build identifier of the Android running at the time of the crash.
  • revision: Version of the file format.
  • arch: System architecture where the crash occurred.
  • timestamp: Timestamp when the crash occurred in YYYY-MM-DD hh-mm-ss.ms format.
  • process_uptime: Time in seconds that the crashed process had been running.
  • command_line: Command or process that caused the crash.
  • pid: Unique identifier of the process that caused the crash.
  • tid: Thread identifier where the crash occurred (may match the pid if it was the main thread).
  • process_name: Name of the crashed process.
  • binary_path: Path of the binary executed at the time of the crash.
  • selinux_label: SELinux context label u:r:domain:s0:category associated with the crashed process, composed of:
    • u: SELinux user grouping processes under the same security rule space.
    • r: SELinux role connecting the user to domains. In Android’s SELinux policy, the role is present for standard SELinux format compatibility.
    • domain: SELinux type or domain. This part of the context identifies the crashed process or service. The domains that may appear here come from the active SELinux policy on the device, where domains are defined in specific .te files for system services, user applications, HAL, or critical processes.
    • security level: Corresponds to the multi-level security or multi-category security component and includes only the base security level and sometimes additional categories that differentiate instances of crashed processes under the same domain. The simplest level is s0, present in most system processes. Additional categories may be included mainly for user applications.
  • uid: User ID associated with the execution of the process.
  • signal_info: Signal sent from or to the system that caused the crash.
  • code: Specific code indicating how the signal was generated. Possible values:
    • 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: Signal associated with the code. Possible values:
    • SI_USER: Signal sent manually from user space (i.e., by a program or the user). Usually does not indicate a system error, but the process was externally terminated by someone or another program.
    • SI_KERNEL: Signal generated directly by the kernel. Usually associated with severe memory or hardware failures detected at the lowest system level.
    • SI_QUEUE: Signal including additional information sent between processes. Used for advanced communication, e.g., in multithreaded programs or message queues. Not related to errors but for process coordination events.
    • SI_TIMER: Signal sent by the kernel when a timer expires. Timers control operation durations, sample thread states, or trigger automatic system tasks. May indicate a process was terminated due to a timer. Can include system watchdogs or memory sampling processes.
    • SI_MESGQ: Signal generated when a message arrives in a POSIX message queue (a communication mechanism in Unix-like systems). Used instead of pipes, sockets, or binders. Normally triggers when activity occurs in the queue, but can cause problems if sending and receiving are not synchronized.
    • SI_ASYNCIO: Signal sent by the kernel when an asynchronous I/O operation finishes. If no handler exists, the application may terminate unexpectedly.
    • SI_SIGIO: Signal related to file or socket I/O operations. Occurs when a file descriptor is set to notify events or an error happens on the descriptor.
    • SI_TKILL: Signal used to terminate a specific thread (not the whole process). Normally generated by the program, its runtime environment (e.g., Dalvik/ART), or internal libraries.
    • SI_DETHREAD: Internal signal used when threads are detached from a multithreaded process. Happens if the main thread dies or explicit termination of a thread group is requested.
  • name: Signal name. Possible values:
    • SIGILL: Invalid instruction execution.
    • SIGTRAP: Breakpoint triggered. Useful to identify debugging or interference with process flow.
    • SIGABRT: Forced termination by the process upon detecting a critical failure. May be related to induced errors.
    • SIGBUS: Invalid memory bus access.
    • SIGFPE: Arithmetic error like division by zero.
    • SIGSEGV: Illegal memory access, associated with buffer overflows.
    • SIGSTKFLT: Stack execution failure.
    • SIGSTOP: Complete pause of a process with no capture of process information.
  • number: POSIX signal number that caused the crash. Possible values:
    • 4 = SIGILL
    • 5 = SIGTRAP
    • 6 = SIGABRT
    • 7 = SIGBUS
    • 8 = SIGFPE
    • 11 = SIGSEGV
    • 16 = SIGSTKFLT
    • 19 = SIGSTOP
  • cause: Textual string explaining the cause of the crash if explicitly recorded. May be empty or null.
  • extra: Reserved fields for additional data.

Why is this important?

Tombstones allow us to identify critical application or process crashes, including essential details such as the signal that caused the crash, the involved process, the event timestamp, and the active line or command at the time of the crash.

This is useful to detect processes, services, or applications that are failing or causing system crashes. In this way, it is possible to determine if the processes generating crashes are abnormal for the system, if the security and execution context shows unusual or unauthorized behavior, and if the signals indicate possible system exploitation or a crash caused by another process suggesting malicious behavior.

File structure::

{
        "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
    },

Learn more

battery_daily.json

The information in this file is generated by the battery_daily module and the dumpsys_battery_daily artifact.

What is included in this file?

This file is in json format and contains information about update records related to an application. This information is extracted from the batterystats service of dumpsys.

The action in this file refers to an update event recorded by the batterystats service indicating the date range in which an application was updated and which version was recorded after the update.

Why is this important?

The battery_daily information allows identifying updates of applications installed on a device over the date range in which the version changed and recording the application version assigned after this update.

This is useful to identify applications that have changed versions frequently and unusually. In this way, it is possible to determine if an update may relate to specific periods of time and dates that coincide with suspicious behaviors or activities on the device and that could be indicators of the presence of malware.

File structure::

[
    {
        "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

The information in this file is generated by the battery_history module and the dumpsys_battery_history artifact.

What is included in this file?

This file is in json format and contains information about event records related to an installed application and its service. This information is extracted from the batterystats service of dumpsys.

An event is a record indicating an action performed by an application and the specific service that executed the change. The event represents the start or end of a scheduled action of an application on the device, the activation or deactivation of a method of an application that keeps a device awake, and the state changes of an application when moving from foreground to background.

The information in the file is presented as follows:

  • time_elapsed: Time elapsed since the start of the history recording until the event occurred, in milliseconds.
  • event: Action recorded as an application event, which can be:
  • start_job: Event indicating that an application started a scheduled job or task.
  • end_job: Event indicating that an application finished a scheduled job or task.
  • wake: Event indicating that an application activated a wake lock to prevent the device or processor from sleeping.
  • start_top: Event indicating that an application moved to the foreground and became visible to the user.
  • end_top: Event indicating that an application left the foreground and moved to the background.
  • uid: User identifier associated with the application.
  • package_name: Name of the package.
  • service: Full name of the service or specific component that executed the action.

Why is this important?

The battery_history information allows identifying events executed by applications installed on a device, such as the start or end of scheduled jobs, the transition of an application to foreground or background, or the activation of mechanisms to keep the device awake.

File structure::

{
    "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

The information in this file is generated by the platform_compat module and the dumpsys_platform_compat artifact.

What is included in this file?

This file is in json format and contains information about packages_name records identified with changes of type DOWNSCALED. This information is extracted from the platform_compat service of dumpsys to identify uninstalled applications.

The platform_compat service is a manager of compatibility configurations between applications and the internal changes of the Android system. If the Android version is incompatible with a function of an application, the platform_compat service can enable or disable that change in the system individually per application so that it remains active for the user or system.

platform_compat is capable of identifying each of the changes and compatibility adjustments within the Android system through a ChangeId. It can also provide additional information about these changes through the name field, which refers to the descriptive name of the change, the overridable flag indicating whether the system can enable or disable functions for specific applications, and the rawOverrides list, which contains packages that have a customized adjustment for a change in the operating system.

The generated file provides a list of packages identified by changeId 168419799 associated with the DOWNSCALED policy, and within this list, it identifies the rawOverrides section to find uninstalled applications.

Why is this important?

The platform_compat information allows identifying uninstalled applications, which helps determine if a malicious application was uninstalled prior to the analysis.

File structure::

{
        "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"

Learn more

Comments

Do you have any comment or suggestion about this resource? You can use the comment function provided below to leave your ideas, corrections or thoughts. Please make sure to follow our code of conduct when leaving your comment. If you prefer, you can also participate in the discussion directly in the github repository.