Skip to content

Dictionary of files generated by MVT-android check-Androidqf

This document contains information about the files generated by the MVT through the mvt-check-androidqf. component. The objective of this dictionary is to provide specific information about the outputs of this module to facilitate consensual forensic analysis in civil society. Through this dictionary, you can understand what files are generated, why they can be helpful and where to look for specific information.

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 particular resource falls under the references category, and contains information on the analysis of acquisitions created with AndroidWF using the MVT tool (Mobile Verification Toolkit) and specifically the mvt-android check-andoridqf command. MVT is a toolkit, developed and maintained by the Amnesty International Security Lab and published here in the github repository of the MVT Project. The intent of this tool is in essence, to facilitate consensus forensic analysis of Android and iOS devices for the purpose of identifying traces of compromise.

This resource was last updated on November 18, 2025 and commit 339a1d0712c4cc051e880b8a777d2b8b6295e57b was used as the basis for information gathering.

The information generated by mvt-androidqf can be grouped into 5 main categories:

  • Acquisition details
  • Device configuration Logs and system events information * Processes and applications
  • Processes and applications
  • Backed up files

Each of the categories in turn contains specific files generated by the tool, which are listed in the index of contents below:

During the execution of the mvt-android check-andoridqf command, MVT also executes modules corresponding to mvt-android check-bugreport and mvt-android check-backup, as long as there is a bugreport.zip file and a backup.ab file inside the input folder containing the androidqf extraction.

In the supplementary reference material about files generated by the mvt tool when parsing a bugreport the output of the check-bugreport command and the resulting files are described. Below are the the module-specific references to the bugreport dictionary:.

Below we also list the modules executed by check-backup, which are detailed at the end of this resource.

  • System Logs and Events Information](#system-logs-and-events-information)
  • sms.json

acquisition-details

info.json

What is included in this file?

This file is in json format and contains information about the analysis, including:

  • Path of the parsed file.
  • Version of MVT used.
  • Date of analysis.
  • List of commitment indicator files.
  • Hash of the analyzed output folder (SHA-256).

Why is it important?

This file allows us to validate the analysis that has been performed, documenting that we have a record of the acquisition process and the indicators that were considered to make the comparison.

This information allows to establish a reference of the analyzed files and the indicators used in the analysis, which facilitates the chain fo custody custody process.

File structure

{
    "target_path":"/path/file/path/acquisition-with-androidqf",
    "mvt_version": "2.6.1",
    "date": "YYYYY-MM-DD hh:mm:ss",
    "ioc_files": [
        "/path/to/indicators/pegasus.stix2",
        "/path/to/indicators/predator.stix2",
        "/path/to/indicators/rcs_lab.stix2",
        "... more indicators used ..."
    ],
    "hashes": [
        {
            "file_path": "/path/path/from/file/acquisition-with-androidqf",
            "sha256": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
        }
    ]
}

command.log

What is included in this file?

This file is in plain text with a .log extension and contains detailed logs of the execution of the mvt-android check-androidqf command. This includes for example detections of indicators of compromise and errors with module execution.

The archive logs are presented in a structured manner with:

  • Timestamps
  • Running module names
  • Type of message (INFO, DEBUG, WARNING, ERROR)
  • Corresponding module action (file parsing, IoCs loading, comparison, and comparison result).

The message types correspond as follows:

  • INFO. Messages also displayed on the screen during execution.
  • DEBUG. Information not displayed on the screen but associated with an action performed during the analysis, for example the loading of an IoC or the revision of a hash.
  • WARNING* Corresponds to alerts of suspicious activity that an analyst must verify.
  • ERROR: Error messages in some action performed during the analysis, for example when loading a corrupted file or a problem with the execution of the corresponding module.

Why is it important?

It allows to generate a log of the actions performed during the analysis. Through this log it is possible to verify the following:

  • That the analysis was performed correctly
  • If there were coincidences with IoCs.
  • If suspicious information or activity was identified.

File structure:

This file follows a line-by-line format with the following structure.

[TIMESTAMP] - [MODULE] - [LOG LEVEL] - [MESSAGE] - [MESSAGE] - [MESSAGE] - [MESSAGE] - [MESSAGE] - [MESSAGE] - [MESSAGE] - [MESSAGE].
...
2025-01-17 17:06:14,035 - mvt.android.cmd_check_androidqf - 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-01-17 17:06:14,098 - mvt.android.cmd_check_androidqf - DEBUG - Extracted 1549 indicators for collection with name "Pegasus"
2025-01-17 17:06:14,812 - mvt.android.cmd_check_androidqf - DEBUG - Extracted 245 indicators for collection with name "mSpy"

Learn more

timeline.csv

What is included in this file?

This file is in csv format and stores a timeline of device activity. This activity is obtained from the execution of the different MVT modules and is sorted by time.

Each line of the csv corresponds to:

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

Why is it important?

This file allows to track the internal activity of the device, being able to generate a broad idea of how the device behaved and to identify relevant events.

File structure

This file follows a line-by-line format with the following structure.

"UTC Timestamp", "Plugin", "Event", "Description".
"2025-01-01 00:00:00", "Packages", "package_first_install", "com.example.app (system: False, third party: True)"
"2025-01-01 00:00:00", "Packages", "package_last_update", "com.system.module (system: True, third party: False)"
"2025-01-01 00:00:00", "Packages", "package_install", "com.example.newapp (system: False, third party: True)"

device-configuration

aqf_getprop.json

The information in this file is generated using the aqf_getprop module and the getprop artifact.

What is included in this file?

This file is in json format and contains a list of device properties that are extracted from the getprop.tx file generated during an extraction with AndoridQF.

These system properties are key-value pairs of strings that are stored in the global dictionary build.prop or in sysprop description files, and provide 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 are prefixed with ro, indicating that they are read-only properties, or were assigned after the device reset. Properties prefixed with persist refer to reset-resistant configurations. Some properties will have no prefix, so they start directly with the group to which they belong.

The most common groups are:

  • bluetooth, Bluetooth related.
  • boot, kernel cmdline sysprops
  • build, sysprops identifying a build
  • telephony, telephony related
  • audio, related to audio
  • graphics, graphics related
  • 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 it important?

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

File structure:

[
    {
        "name": "aaudio.hw_burst_min_usec",
        "value": "2000"
    },
    {
        "name": "bluetooth.device.class_of_device",
        "value": "90,2,12"
    },
    {
        "name": "apex.all.ready",
        "value": "true"
    }
]

aqf_settings.json

The information in this file is generated by the aqf_settings module and the settings artifact.

What is included in this file?

This file is in json format and contains information about the status of device settings in the namespaces system (UI and general behavior such as brightness, tone, rotation, etc.), secure (sensitive settings that require elevated permissions such as application verification, accessibility settings or ADB status) and global (parameters shared between users such as networks, location, roaming, global volumes, etc).

The information is presented in 3 blocks, first system settings, then secure settings and finally global settings. Each setting is presented as a key value pair in the structure:

{setting}:{level}]

The values have different meanings depending on the specific setting, in general it can be interpreted as follows:

  • 0 usually means disabled or off.
  • 1 usually means enabled or turned on.
  • Larger numbers can be levels such as screen brightness for example.
  • Some values are paths or system paths pointing to resources.

This information is extracted directly from the settings_global.txt, settings_secure.txt and settings_system.txt files generated during the AndoridQF extraction.

Why is it important?

It allows you to identify anomalous settings that could compromise the security, privacy or functionality of the device. Unusual default settings may signal intentional or accidental attempts to modify system behavior.

File structure: 

{
    "system": {
        "SEM_VIBRATION_FORCE_TOUCH_INTENSITY": "4",
        "SEM_VIBRATION_NOTIFICATION_INTENSITY": "5",
        "SMLDM_BEARER": "0",
        "SOFTWARE_UPDATE_LAST_CHECKED_DATE": "1736527562578",
        "SOFTWARE_UPDATE_WIFI_ONLY2": "1",
        "SOUNDALIVE_AUDIO_PATH": "0",
        "TIME_DIFFERENCE": "445",
        "VIB_FEEDBACK_MAGNITUDE": "2",
        "VIB_RECVCALL_MAGNITUDE": "5",
        "acc_last_status_logging": "1736780772300",
    },
    "secure": {
        "accessibility_allow_diagonal_scrolling": "1",
        "accessibility_button_mode": "1",
        "accessibility_button_target_component": "accessibility_change_magnification_size": "3",
        "accessibility_display_magnification_enabled": "0",
        "accessibility_display_magnification_scale": "2.0",
        "accessibility_enabled": "0",
        "accessibility_magnification_activated": "0",
        "accessibility_magnification_capability": "3",
        "accessibility_magnification_mode": "2",
        "accessibility_shortcut_dialog_shown": "1",
        "accessibility_shortcut_target_service":
    },
    "global": {
        "contacts_move_simcontacts_not_now": "0",
        "phenotype_boot_count": "131",
        "phenotype_flags": "_boot_Phenotype_flags": "",
        "activity_starts_starts_logging_enabled": "1",
        "adb_allowed_connection_time": "604800000",
        "adb_enabled": "1",
        "adb_wifi_enabled": "0",
        "add_users_when_locked": "0",
        "airplane_mode_on": "0",
        "airplane_mode_radios": "cell,bluetooth,uwb,wifi,wimax",
        "airplane_mode_toggleable_radios": "bluetooth,wifi",
    }
}

Learn more

mounts.json

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

What is included in this file?

This file is in json format and contains information about partitions and system directories mounted on a device in the user space and kernel space. The information is compiled from the mounts.json file generated during an extraction with AndoridQF.

The module is responsible for identifying suspicious configurations on /system, /vendor, /product and /system_ext mount points such as read and write access mode, noatime or nodiratime timestamps. It is also responsible for formatting each mount point as follows:

  • device: mounted partition or volume, in android the most common ones are:
    • Physical storage partitions
      • /dev/block/sdX: Physical storage device (eMMC/UFS) exposed as sd by the kernel.
      • /dev/block/mmcblk: eMMC storage device exposed as mmcblk.
      • /dev/block/dm-X: Device managed by device-mapper (encrypted, verity or logical partitions).
      • /dev/block/by-name/: Symbolic links pointing to real partitions by name e.g. system, vendor userdata.
    • virtual kernel volume in RAM
      • proc: Virtual interface to get kernel and process information.
      • sysfs: Exposes device, driver and kernel parameter information.
      • selinuxfs: Displays SELinux policies, states and labels.
      • tracefs: Virtual system for kernel tracing and debugging tools.
      • pstore: Stores persistent kernel crash logs.
      • bpf: Exposes interfaces for eBPF programs loaded in the kernel.
    • User space
      • /dev/fuse: FUSE interface used by Android to mount emulated storage p.j /storage/emulated.
    • Internal kernel control interfaces.
      • none: Identifier indicating that the mount does not come from a real device.
      • binder: Android's internal IPC system for inter-process communication.
    • APEX files mounted as loopback
      • /dev/block/loopX: Loop devices used to mount APEX packages as if they were real partitions.
  • mount point: Path to the root folder of the storage where the information is accessed, in android they are usually the following:
    • /system: Contains the main operating system.
    • /vendor: Includes components and drivers provided by the hardware manufacturer such as HALs, firmware and vendor-specific binaries.
    • /product: Stores manufacturer's customizations of system functions and device-specific applications.
    • /data: User data area and app storage.
    • /cache: Temporary space used for update files and transient system data.
    • /metadata: Contains critical information needed for AVB, encryption and system validations.
    • /mnt/media_rw/: Mount point for removable or adopted storage e.g. SD card. SD card.
    • /storage/emulated: Emulated view of user's internal storage.
    • /proc: Virtual system that exposes kernel and process information (not real storage).
    • /sys: Virtual system that exposes information about kernel devices and drivers.
    • /mnt/user/0/emulated: Specific view of emulated storage for user 0.
  • filesystem_type: File system type, in android they are the following:
    • ext4: Linux file system used on internal partitions.
    • f2fs: File system optimized for flash storage.
    • erofs: Optimized read-only file system.
    • vfat: FAT32 file system used for SD cards and external storage.
    • sdfat: Extended implementation of FAT/exFAT.
    • tmpfs: Temporary RAM file system used for volatile directories e.g. /dev, /run, /apex.
    • proc: Virtual file system that exposes kernel and process information.
    • sysfs: Virtual system that displays hardware information, drivers and kernel drivers.
    • selinuxfs: Virtual system that exposes SELinux parameters and status on the device.
    • functionfs: System used for USB gadget interfaces when Android acts as a USB device.
    • incremental-fs: System designed to install or run apps "on demand" while they are still downloading.
    • binder: Android's internal IPC communication system.
    • cgroup: Virtual system based on control groups to manage resources per process e.g. CPU, memory. CPU, memory.
    • fuse: User space file system used for emulated storage.
  • mount_options
    • access modes
      • ro: read only
      • rw: read and write
    • security labels
      • seclabel: Enables and applies SELinux labels to the file system.
      • nodev: Prevent device files from being used on that partition.
      • nosuid: Locks binaries with set-UID/set-GID to prevent escalation.
      • noexec: Prevent executing files from that partition.
      • hidepid=invisible: Hide processes from other users in * /proc *.
      • user_xattr: Allows user-defined extended attributes.
      • acl: Allows more detailed access control lists than rwx.
      • inlinecrypt: Uses inline encryption supported by hardware/FS (Android).
      • usrquota: Enables per-user quotas.
      • grpquota: Enables group quotas.
    • timestamps
      • lazytime: Defer writing timestamps to storage to improve performance.
      • relatime: Updates access times only if necessary.
      • noatitime: Disables access time update.
    • related users or groups
      • uid=0: Mount owner (root).
      • gid=1000: Android base group (system or media_rw).
      • user_id=0: Primary Android system user.
      • group_id=0: Primary group of the root user.
  • is_system_partition: Boolean value indicating whether the partition is /system or /sys.
  • is_read_write: Boolean value indicating if the partition has read and write access.

Why is it important?

The mount points allows you to identify the storage areas mounted on the device, their origin and how they are configured. With this information it is possible to know the permissions with which the partitions were mounted, the associated users and in some cases the SELinux security labels applied.

This is useful for identification of mounts that may be suspicious of malicious activity on the device, for example, a system partition such as /system, /vendor, /product partitions whose mount is usually read-only could be mounted with write permissions or lack security labels potentially indicating malicious activity.

Example of file contents

{
        "device":"/dev/block/mmcblk0p63",
        "mount_point":"/",
        "filesystem_type": "ext4",
        "mount_options": "ro,seclabel,relatime,discard",
        "options_list": [
            "ro",
            "seclabel",
            "relatime",
            "discard"
        ],
        "is_system_partition": false,
        "is_read_write": false.
    }
  {
        "device": "tmpfs",
        "mount_point":"/dev",
        "filesystem_type": "tmpfs",
        "mount_options": "rw,seclabel,nosuid,relatime,size=1812632k,nr_inodes=453158,mode=755",
        "options_list": [
            }, "rw",
            "seclabel",
            "nosuid",
            "relatime",
            "size=1812632k",
            "nr_inodes=453158",
            "mode=755"
        ],
        "is_system_partition": false,
        "is_read_write": true.
    },
    {
        "device": "devpts",
        "mount_point":"/dev/pts",
        "filesystem_type": "devpts",
        "mount_options": "rw,seclabel,relatime,mode=600,ptmxmode=000",
        "options_list": [
            "rw",
            "seclabel",
            "relatime",
            "mode=600",
            "ptmxmode=000"
        ],
        "is_system_partition": false,
        "is_read_write": true.
    },

Learn more:

Processes and applications

aqf_packages.json

The information in this file is generated by the aqf_packages module.

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 packages.json file generated during an AndroidQF acquisition.

The information in this file is presented as follows:

  • name: Application package name.
  • files: Path of the corresponding APK file with its respective hashes and certificate information.
  • installer: From which application was installed.
  • uid: The associated running PID.
  • disabled: Indicates if the application is disabled.
  • system: Indicates if the package belongs to the system.
  • third party: Indicates if it is a third party application.

Why is it important?

The contents of this file include information to identify installed applications and their status on the device. This helps analysts assess whether there are risky or malicious applications, what permissions they have and which ones can compromise security.

File structure:

{
        "name": "com.samsung.android.arzone",
        "files": [
            {
                "path":"/data/app/ARZone/ARZone.apk",
                "local_name": "",
                "md5": "947b59f40de694e2359c007abe0c0191",
                "sha1": "508d9207ca6218bf599171c13f8141c37e97f580",
                "sha256": "76f972c04be51d0cad7980df85f76219eebfc0f770001e8ef02b4fa9a180f9d4",
                "sha512": "3b34c13fb1150df1b347f0cc0913f55d17abe2be96354a64e2ed8369fdce5b2fb10c5748deb7a66409153b766d84039fa01b0a1ced1bf2ccb62ab5368b38599a",
                "error": "",
                "verified_certificate": true,
                "certificate": {
                    "Md5": "d087e72912fba064cafa78dc34aea839",
                    "Sha1": "9ca5170f381919dfe0446fcdab18b19a143b3163",
                    "Sha256": "34df0e7a9f1cf1892e45c056b4973cd81ccf148a4050d11aea4ac5a65f900a42",
                    "ValidFrom": "2011-06-22T12:25:12Z",
                    "ValidTo": "2038-11-07T12:25:12Z",
                    "Issuer": "C=KR, ST=South Korea, L=Suwon City, O=Samsung Corporation, OU=DMC, CN=Samsung Cert",
                    "Subject": "C=KR, ST=South Korea, L=Suwon City, O=Samsung Corporation, OU=DMC, CN=Samsung Cert",
                    "SignatureAlgorithm": "SHA1-RSA",
                    "SerialNumber": 15134792569865480918
                },
                "certificate_error": "",
                "trusted_certificate": true
            }
        ],
        "installer": "null",
        "uid": 10295,
        "disabled": false,
        "system": false,
        "third_party": true
    }

root_binaries.py

The information in this file is generated by the root_binaries module.

What is included in this file?

This file is in json format and contains a list of binaries related to rooting on the device extracted from the root_binaries.json file generated during an extraction with AndoridQF.

This module is responsible for extracting the binaries to identify suspected rooting binaries and their traces. The format applied is as follows:

  • path: Path to the rooting binary found.
  • binary_name: Name of the binary, it can be the following:
    • su
    • busybox
    • supersu
    • Superuser.apk
    • KingoUser.apk
    • SuperSu.apk
    • magisk
    • magiskhide
    • magiskinit
    • magiskpolicy
  • desciption: Description of the rooting binary, can be the following:
    • su: SuperUser binary
    • busybox: BusyBox utilities
    • supersu: SuperSU root management
    • Superuser.apk: Superuser app
    • KingoUser.apk: KingRoot app
    • SuperSu.apk: SuperSU app
    • magisk: Magisk root framework
    • magiskhide: Magisk hide utility
    • magiskinit: Magisk init binary
    • magiskpolicy: Magisk policy binary

Why is it important?

This file detects rooting tools, which can be an indication of unauthorized access and privilege escalation that may expose vulnerabilities. It also allows the analyst to identify suspicious binaries that may have been installed without the user's knowledge and helps determine if the device has been tampered with.

Example of file contents

    {
        "path":"/system/xbin/su",
        "binary_name": "su",
        "description": "SuperUser binary"
    },
    {
        "path": "/system/bin/su",
        "binary_name": "su",
        "description": "SuperUser binary"
    },
    {
        "path": "/system/bin/busybox",
        "binary_name": "busybox",
        "description": "BusyBox utilities"
    },
    {
        "path": "/data/local/tmp/magisk",
        "binary_name": "magisk",
        "description": "magisk root framework"
    }

backed-up files

aqf_files.json

The information in this file is generated by the files module.

What is included in this file?

This file is in json format and contains information about the files and their metadata in the paths /sdcard, /system, /data, etc., on the device. This information is extracted from the files.json file generated during AndroidQF acquisition.

Each entry includes a file with its metadata such as: full file path, size, timestamp (indicates last file modification and last file access), file permissions, owner identifier, error messages and hashes sha1, sha256, sha512, md5 if pre-computed.

The information in this file is presented as follows:

  • path: File path
  • size: Size of the file in bytes
  • mode: File permissions (read, write or execute in unix format)
  • user_id: Identifier of the owner user
  • user_name: Owner's user name
  • group_id: Identifier of the owner group
  • group_name: Name of the owner group
  • changed_time: Date and time at which the file metadata was changed*
  • modified_time:Date and time when the file content was modified
  • access_time: Date and time of the last access to the file
  • error: Error log during file reading
  • context: SELinux security tag
  • Hashses: Calculated values of the hashes associated with each file

Why is it important?

This file has relevance to identify files of interest in a forensic investigation, including potential files used by attackers to compromise a device.

File structure:

        "path":"/sdcard/Android/.Trash/com.sec.android.app.myfiles/.nomedia",
        "size": 62,
        "mode":"-rw-rw----",
        "user_id": 10276,
        "user_name": "",
        "group_id": 1023,
        "group_name": "",
        "changed_time": "2025-07-28 03:46:55.000000",
        "modified_time": "2025-07-28 03:46:55.000000",
        "access_time": "2024-05-05 13:35:15.000000",
        "error": "",
        "context": "u:object_r:fuse:s0",
        "sha1": "",
        "sha256": "",
        "sha512": "",
        "md5": ""
    },
    {
        "path": "/sdcard/Android/.Trash/com.sec.android.app.myfiles/0d2b854e-bc86-4478-b0a9-6802f21ba015/1753640873997/storage/emulated/0/Android/media/com.whatsapp/WhatsApp/Media/WhatsApp Images/.!%#@$/IMG-20250727-WA0000.jpg",
        "size": 130802,
        "mode":"-rw-rw----",
        "user_id": 10276,
        "user_name": "",
        "group_id": 1023,
        "group_name": "",
        "changed_time": "2025-07-28 03:46:55.000000",
        "modified_time": "2025-07-27 12:06:02.000000",
        "access_time": "2025-07-27 12:06:02.000000",
        "error": "",
        "context": "u:object_r:fuse:s0",
        "sha1": "",
        "sha256": "",
        "sha512": "",
        "md5": ""
    }

sms.json

The information in this file is generated by the backup module sms and the backup helper helpers and parser backup.

What is included in this file?

The file is in json format and contains information about SMS and MMS messages received and stored on the mobile device. This information is extracted from the backup.ab file generated during an extraction with AndroidQF.

The backup SMS and MMS message information is searched and decrypted (if necessary) in order to decompress this backup, parse dates, detect links and homologate formats.

The information in this file is presented as follows:

  • address: phone number or address that sent or received the message.
  • body: Content of the message in plain text.
  • date: Unix format timestamp of the time of reception.
  • date_sent**: Time stamp in Unix format of when the message was sent. If the value is 0, it means that the message was received.
  • status**: Status code of the message:
      • 1: Unknown or no information.
    • 0: Complete
    • 64: Pending sending
    • 128: Draft
  • type:Message type
    • 1: Received
    • 2: Sent
    • 3: Draft
    • 4: Outgoing
  • recipients: List of message recipients.
  • read: Indicator of whether the message was read (1) or unread (0).
  • isodate: Date in ISO format, for easier understanding.
  • direction: Direction of the message (if it was sent or received).
    • sent: Sent
    • received: Received
  • links: List of links identified within the message body.

Why is it important?

The content of this file includes information that allows you to track conversations and communications that indicate risk or attempted attacks with malicious content that indicate an attack vector such as phishing.

File structure

[
    {
        "address": "12345",
        "body": "Reactivate your application to continue enjoying the service. If you have any problems, we ask you to reinstall it from https://example.com/reactivacion",
        "date": "1597872498518",
        "date_sent": "1597872496000",
        "status":"-1",
        "type": "1",
        "recipients": ["12345"],
        "read": "1",
        "isodate": "2025-01-01 00:00:00:00.000",
        "direction": "sent",
        "links": ["https://example.com/reactivacion"]
    },
    {
        "address": "54321",
        "body": "This is a sample message related to verifying your account.",
        "date": "1601498392068",
        "date_sent": "1601498390000",
        "status":"-1",
        "type": "1",
        "recipients": ["54321"],
        "read": "0",
        "isodate": "2025-01-01 00:00:00.000",
        "direction": "sent"
    }
]