Block Hash Scan: Illegal File Triage Completed On Site

Key Takeaways

  • Block Hash Scan is a feature of MD-LIVE, an on-site triage solution that determines whether illegal files are present on a device without full data imaging.

  • Block Hash Scan divides a file into blocks and compares the hashes block by block. Because it reads only the blocks it needs, it can identify illegal files without reading the entire file.

  • The scan runs in two steps: a quick scan that picks out suspicious files, followed by a full scan that checks only those files in depth. Within the active hash set and the scan areas the product supports, suspicious files are not missed.

Introduction

The decision cannot wait for the lab

In digital forensics, investigators have to judge quickly whether a device is relevant to a case. In practice, the analysis results needed for that judgment become available only after the device is seized, imaged, and reviewed in the lab. This creates a gap between the moment a decision is needed and the moment the answer arrives.

Smartphone storage now exceeds 512GB, and a single device can hold tens of thousands of photos and videos. Imaging takes considerable time, and the wait time increases with every additional device. This leads to situations where devices of unclear relevance are seized in the field, increasing the burden on the examiners who handle them.

If an investigator could confirm at the scene, with the device connected, whether the target files are present, the decision-making process would change. Devices with a clear link to the case could be prioritized, and only those devices would go forward for analysis.

The limits of existing approaches in the field

Full-file hash comparison

The most common approach is to build a list of MD5 or SHA hash values and compare it against the hashes of the files on the device. The principle is simple, but a full-file hash requires reading every byte of a file from beginning to end, which is hard to sustain in the field.

For example, to calculate the MD5 hash of a 4GB video, the entire 4GB must be read. If a device contains 300GB of media files, it essentially means reading the full 300GB. This data is transferred from a smartphone connected via USB. Consequently, the scanning time increases in proportion to the amount of data stored on the device. Ultimately, it is a structure where all files must be read just to find a single target file.

Manual review

Another approach is to open the gallery and review the photos and videos by eye. With 12,000 photos, even one second per image adds up to 3 hours and 20 minutes, and the chance of missing something rises with the volume of material. When the material is illegally filmed content, viewing it is itself a burden on the investigator, and repeated manual review compounds that burden.

Identify without reading full file

The Block Hash Scan feature in MD-LIVE addresses the limits of these traditional methods. Instead of assigning one hash value to one file, Block Hash Scan divides a file into fixed-size blocks and calculates a hash for each block. Confirming whether a file is a target file therefore does not require reading the file in full. The scan reads the necessary blocks and compares them against a hash set prepared in advance.

As a result, identifying a 4GB video requires reading almost the same amount of data as a 40GB video. The primary advantage of the block hash approach is that the verification cost doesn't scale up linearly as files get larger.


How to use Block Hash in MD-LIVE

Connect, wait, and export results

To use Block Hash Scan, run MD-LIVE. The overall workflow consists of three steps: Connect Device, Scan Device, and Check Results.

Step

Screen

What investigator does

What MD-LIVE does

Step 1

Connect Device

Selects the operating system (OS) and connects the device over USB

Detects the device, checks the active hash set, and moves to the next step once the connection succeeds

Step 2

Scan Device

Monitors progress and stops the scan if needed

File collection → Detect suspicious files → Check suspicious files in depth, and displays progress

Step 3

Check Results

Reviews the detected results and exports

Reports the number of files examined, the number of files detected, the elapsed time, and the file list

Block Hash Scan Connect Device screen in MD-LIVE with an Android device selected

The scan starts automatically once the device is connected. While it runs, the number of files examined and the number of detections update in real time. Even if the investigator stops the scan or if the cable is disconnected and the task is interrupted, the list of files detected up to that point is retained.

MD-LIVE Block Hash Scan running with real-time file counts
Block Hash Scan progress while detecting suspicious files
Progress and real-time statistics for detecting suspicious files

When the scan finishes, summary cards show the number of files examined, the number of files detected, and the elapsed time. The detection list also becomes available for review. Reports can be exported in the following two formats:

  • Report (PDF, Excel): Saves the scan results as a document for the investigation record.

  • File list (MBR): Saves the detection list as a .mbr file. Re-importing that file into MD-LIVE carries the selection made in the field straight into detailed analysis.

Because the list does not have to be rebuilt between the scene and the lab, the triage result carries into the follow-up analysis.

MD-LIVE Block Hash Scan workflow from Connect Device to Check Results
The overall workflow from Connect Device to Scan Device to Check Results

Prepare block hash set before deployment

The scan uses a block hash set with the .mbh extension as its reference. Designate the folder containing illegal files as the ‘Scan folder path’, and set the destination folder for the calculated block hashes as the ‘Block hash set save path’. Clicking [Block Hash Set Creation] computes the block hash for each file in the scanned folder and generates a .mbh file in the specified save path. Once registered in MD-LIVE, investigators can select only the items relevant to the case.

Field environments assume offline use with no internet connection. Because hash sets cannot be downloaded or updated on-site, investigators need to prepare the required reference files before deployment.

Creating a block hash set (.mbh) for MD-LIVE Block Hash Scan
Block hash calculation in progress for an MD-LIVE hash set
Block hash set creation completed with hash calculation file count
Block hash set list registered in MD-LIVE
Block hash set creation & Block hash set list window

How Block Hash scan works

For an on-site triage tool to be effective, several conditions must be met at the same time. It must rapidly identify large files, efficiently scan the entire storage, avoid missing target files, and preserve the original data without modifications. Block Hash Scan satisfies these requirements as follows:

It does not read the entire file

When identifying illegal files by comparing full hashes, the primary factor determining scan time is total data volume. Inspecting 100 videos of 4GB each requires reading 400GB of data. In an architecture where a single hash is assigned per file, the hash value can only be calculated after reading every file down to its final byte.

With block hashing, the verification cost does not increase as file sizes grow. Because hashes are managed by dividing the file into multiple blocks, MD-LIVE only needs to read the specific blocks required to verify a target file. As file sizes increase, the performance gap between this method and full-hash scanning becomes significantly wider.

Detect suspicious files first, then Check suspicious files in depth

Block Hash Scan operates in two steps: ‘Detect suspicious files’ and ‘check suspicious files in depth'. First, detect suspicious files searches the storage area and picks out suspicious files. Then, check suspicious files in depth checks those files in depth.

By running the detailed scan only on suspicious files instead of the entire drive, overall processing costs are kept low. This sequential workflow, where check suspicious files in depth follows detect suspicious files, is also reflected in the progress bar.

Detect suspicious files applies broader evaluation criteria to establish a wide candidate pool for suspicious files. Files excluded at this first step are not examined again later, so files that match only in part are still passed to the next step. The purpose is to keep processing costs down without dropping target files.

False positives can occur. False negatives do not.

In a structure that reads only select blocks rather than the entire file, the verification criteria become relatively lenient. Block Hash Scan permits any resulting margin of error in only one direction.

Type

Occurrence

How to read the result

False positive: A file that is not a target is detected

Can occur

The detection list is treated as suspicious files that require follow-up review

False negative: A target file is not detected

Does not occur by design

Zero detections means no such file exists under those criteria

A file may appear suspicious because one of its blocks coincidentally matches a block in the hash set, but a target file is not missed. If a file is registered in the hash set, the blocks read from it match, so the file is not omitted from the detection list. The structure removes the possibility of omission at the cost of reviewing additional files that are not targets.

This is not merely a statistical tendency toward high detection rates, but a structural characteristic stemming from the comparison logic itself. Consequently, using the same hash set and scan scope will consistently lead to identical conclusions, regardless of when the inspection is performed.

In a field triage tool, this asymmetry holds significant practical importance. False positives can be filtered out during the investigator's manual review. False negatives, however, cannot even be detected. Once a device is ruled out from an investigation, it is unlikely to be re-examined. To trust a result that reports no suspicious files, detection reliability matters.

However, the boundary within which this premise holds must be clearly defined. The results are strictly based on the files registered in the active hash set, as well as the scan areas and file formats supported by the software. It does not imply that unlisted files or data outside the scan scope do not exist. The same applies if a scan is interrupted.

The overall reliability of a field triage result therefore depends not only on the method but on the hash set’s recency, its coverage, and whether the scan completed successfully.

The original data on the device is not altered

Original device data is not altered during the scanning process. While Android and iOS access device data through different mechanisms, the underlying principle remains the same: reading necessary files for identification.

MD-LIVE does not copy original detected files to the investigator's PC either. Instead, it gathers only the metadata needed for analysis, such as file paths and sizes. Because no separate copy of illegal files is created, there are no additional copies to manage, and the field output is the triage result alone.


Checklists in practice

Before deployment

  • Create the block hash sets required for the case in advance and add them in MD-LIVE.

  • Keep .mbh files separated by case type so that only the hash set needed can be activated quickly.

  • Confirm before scanning that the intended hash set is active.

At the scene

  • Confirm that the connected device matches the OS selected in MD-LIVE.

  • Check the supported OS versions (Android: 12 or later / iOS: all versions) and the device connection requirements beforehand.

  • On iOS devices, check the auto-lock setting so that the device does not lock or lose the connection during the scan.

  • Keep the USB connection stable until the scan finishes.

If a scan is interrupted, the results up to that point remain available for review and export. A partial result should be interpreted separately from the result of a completed scan.

When reviewing results

The detection list should be treated as a subject for review rather than a final conclusion. Exporting the list as an .mbr file and continuing subsequent analysis in MD-LIVE offers the most efficient workflow.

Even when the detection count is zero, retaining a formal report is recommended. Because false negatives do not occur by design, a result of zero items can be used as a finding that no target files existed within the stated inspection criteria. Documenting the target device alongside the active hash set, scan scope, and completion status clearly substantiates 'what criteria were used for the inspection and what results were obtained.'


Conclusion

Block Hash Scan brings the decision earlier

With Block Hash Scan, investigators no longer need to image the full data of a 512GB smartphone and wait for analysis results simply to verify the presence of specific files. Block Hash Scan triages files by reading only the necessary blocks rather than entire files, performing detailed verification exclusively on those selected as suspicious.

The workflow from device connection to result export proceeds through three steps, ‘Connect Device’, ‘Scan Device’, and ‘Check Results’, preserving original device data without modification throughout the process. Results generated on-site can be saved as an .mbr file to continue follow-up analysis in the forensic lab.

Beyond simply reducing scan times, Block Hash Scan holds significance by enabling decisions previously restricted to the forensic lab to be made directly in the field. Investigators can triage targets based on concrete evidence, allowing forensic labs to allocate resources strictly to devices requiring actual review. Furthermore, it enables preliminary triage without requiring investigators to manually view psychologically burdensome materials, such as illegally filmed content.

Field triage goes beyond merely identifying a large volume of files. It empowers investigators to prioritize which devices require analysis within time constraints, backed by reliable evidence. Because target files are not missed within the stated scan criteria, both detection and non-detection results carry weight in the decision. Block Hash Scan is the technology built to execute these decisions faster and with greater consistency.

GMDSOFT Tech Letter Vol 22.Quick Share History Analysis Amid Expanding Device and OS Support

Quick Share is a wireless file transfer feature from Samsung and Google that allows users to quickly share files between devices via Wi-Fi and Bluetooth. First introduced as a Samsung-exclusive feature with the Galaxy S20, it was integrated with Google's Nearby Share in January 2024 and has since become the standard sharing solution across the Android ecosystem, supporting not only Samsung devices but also other Android devices, Windows PCs, and Chromebooks.

Quick Share is also compatible with Apple's AirDrop. Starting with the Pixel 10 series in November 2025, Google began rolling out two-way AirDrop compatibility to Android devices, and Samsung followed in March 2026 by officially adding AirDrop support to the Galaxy S26 series running One UI 8.5, beginning in South Korea.

As Quick Share expands its support across a wider range of devices and operating systems, its importance from a digital forensic perspective is increasing. Quick Share records are more than just a history of file transfers—they can act as key artifacts revealing a user's send/receive activity and the connections between devices. Information on shared files, connected devices, and the use of the 'Private Sharing' feature can be particularly valuable for identifying data leaks, the movement of evidence, or the transfer of materials between accomplices.

This article explains how to share data with iOS and Android devices using the Quick Share feature, and the information that can be collected from an Android device after sending or receiving content via Quick Share. The findings are based on data extracted from an Android 16 device via MD-NEXT v2.2.14 and analyzed via MD-RED v4.0.12.

How to Use Quick Share

To share content using Quick Share, both the sending and receiving devices must have Wi-Fi and Bluetooth enabled, and devices must be located within nearby range. To share content with Galaxy devices, you must be signed into a Samsung account. To share content with non-Galaxy devices, a Google account sign-in is required.

Sharing with Nearby Devices

Sending Content

  1. Select the content to share, then tap the Share button.

  2. Tap the Quick Share button.

  3. Select the user or device to share the content with. The available sharing targets may vary depending on the receiving device’s Nearby Sharing settings.

Galaxy sending steps: Share button in Gallery, Quick Share in the share sheet, and nearby device list
Quick Share - Sharing with Nearby Devices (Sending Device)

Receiving Content

When a Quick Share request is received, a sharing notification appears on the receiving device. The recipient can preview the type of content being shared and choose whether to ‘Accept’ or ‘Decline’ the request.

AirDrop receive request notification on an iPhone from a Galaxy device
Quick Share - Sharing with Nearby Devices (Receiving Device: iPhone)
Quick Share receive request and transfer complete notification on a Galaxy device
Quick Share - Sharing with Nearby Devices (Receiving Device: Galaxy)

Private Share

Private Share is a secure sharing mode available between Galaxy devices. It allows the sender to set an expiration time for shared files. By default, the expiration period is set to 2 days, and it can be extended up to 6 days, 23 hours, and 59 minutes. Recipients cannot take screenshots, save, or reshare the shared content, and the files are automatically deleted after expiration.

Sending Content

  1. Select the content to share, then tap [Turn on Private Sharing].

  2. Set the expiration date, then select the user to share the content with. The available sharing targets may vary depending on the receiving device’s Nearby Sharing settings.

Private sharing steps on the sending Galaxy device: turn on, set expiration, and expiration picker
Quick Share - Private Share Method (Sending Device)

Receiving Content

When a Private Share request is received, a notification appears on the receiving device. The recipient can preview the type of content being shared and choose whether to ‘Accept' or ‘Decline’ the request.

Private Share receive request, syncing, and transfer complete notification on the receiving Galaxy device
Quick Share - Private Share Method (Receiving Device)

Available Information from Mobile Devices

The linkShare.db file stores records of files sent and received through Quick Share, the target devices involved in sharing, and the sharing timestamps. The privacy_library_database.db file stores records of content sent and received through the ‘Private Share’ feature.

The table below summarizes the information above.

DB

Table

Available Information

linkShare.db

devices

Connected device name, timestamp

linkShare.db

transfer_file

List of sent files

linkShare.db

receiving_file

List of received files

privacy_library_database.db

FileLogCard

Records of files sent or received through Private Share

Summary

  1. Quick Share is a wireless file transfer feature jointly provided by Samsung and Google. It enables users to share data not only between Android devices, but also with devices running other operating systems, including Windows, iOS, and macOS. Support for iOS and macOS transfers is currently limited to certain devices and OS versions, but is gradually expanding.

  2. Quick Share supports both Nearby Device Sharing and Private Share. Records of these sharing activities are stored in linkShare.db and the Private Share-specific privacy_library_database.db. Analyzing these records can reveal details about sent and received content, target devices, and sharing timestamps.

Appendix

Quick Share Receiving Settings

The available sharing targets may vary depending on the receiving device’s Quick Share settings.

  • No one: No one can share content with the device.

  • Contacts: Only users saved in Contacts through a Samsung account can share content with the device.

  • Everyone: Anyone nearby can share content with the device.

For more information, please refer to https://www.samsung.com/us/support/answer/ANS10007268/ .

Supported File Types by Sharing Method

Quick Share supports different file types depending on the sharing method.

  • Sharing with nearby devices: No restrictions on shareable file types

  • Sharing using QR code or contacts: Some file types are not supported, such as exe, com, bat, cmd, vbs, reg, msi, etc.

  • Sharing using Private Share: The following file types are supported.

    • Image: jpeg, jpg, png, gif, bmp, webp, heic, dng

    • Video: webm, mp4, 3gp, 3g2, mkv

    • Audio: mp3, wav, ogg, m4a

    • Document: txt, pdf

File Transfer Limits by Sharing Method

Quick Share has different file count and size limits depending on the sharing method.

  • Nearby device sharing: No restrictions on file count or total transfer size.

  • QR code and contact sharing: Up to 1,000 files per transfer, with size limits of 10 GB per file and 10 GB per day.

  • Private Sharing: Up to 20 files and 200 MB per transfer.

GMDSOFT Tech Letter Vol 21.ChatGPT Q&A: 10 Key Questions

An OpenAI and NBER study found that nearly 80% of ChatGPT usage is centered on practical guidance, information seeking, and writing, with information seeking functioning much like web search. As search behavior shifts from keyword-based search to conversational AI, ChatGPT is becoming increasingly relevant in digital investigations. Because these interactions develop through natural-language dialogue, conversation histories can reveal not just what was searched, but how the user’s intent evolved, making them a valuable source of investigative insight.

This article focuses on ChatGPT as a leading generative AI application and addresses practical questions in a Q&A format. This article is based on findings extracted with MD-NEXT v2.2.13 from devices running Android 14, using Full Filesystem with MD-PLUG and Android Live extraction methods and analyzed via MD-RED v4.0.10.

App Data Storage Structure and Extraction

This section examines how ChatGPT app data is stored on Android device and available information for extraction.

1. Can I extract data through mobile forensics even though it is stored on the server?

Yes. ChatGPT conversation records can be analysis through mobile forensic examination. When chat history is synchronized, the corresponding data is stored on the device, making the synchronized data recoverable through mobile forensic analysis.

2. Do the available analysis results vary depending on the extraction method?

Yes. The available artifacts vary by the extraction method. The available results can be summarized as follows:

Extraction Method

Available Information

Backup

  • ChatGPT account

  • Chat List

  • Text conversation records within chatrooms

Full Filesystem

  • All 3 items available for extraction via the Backup extraction method

  • Image files within chatrooms

3. How is the data stored?

The data is stored in DB format under /data/com.openai.chatgpt/databases.

Note: ChatGPT Data Storage Format on iOS
On iOS, ChatGPT data is stored in JSON format. The corresponding JSON files are located at /var/mobile/Applications/com.openai.chat/Library/Application Support/conversations-v3{device UUID}.

4. Can user-generated images or attached files be identified?

User-generated images are retained as cache files, which are stored at /data/com.openai.chatgpt/cache/coil3_disk_cache.

The filenames of attached files, including .pdf, .xml, and .doc, can be identified; however, the actual files cannot be analyzed.


Artifact Analysis by User Behavior

This section examines the data that can be identified based on ChatGPT usage scenarios.

5. Can I find conversation records created without logging in?

Yes. Conversation records will be stored on the device even without logging in. Because conversation records are stored in an SQLite database, chats conducted while not logged in are available for analysis.

6. Are all conversations synchronized after login?

No. Logging in automatically synchronizes only the 20 most recent conversations, and the contents are not synchronized unless each one is opened individually.
To synchronize older chats, you must scroll through the chat list to trigger additional synchronization.

Note: iOS Chat Synchronization Scope
On iOS devices, the 18 most recent conversations are synchronized after login.
Unlike Android, contents are saved in bulk as JSON files even if the user does not open each chatroom.
To synchronize additional conversations beyond the 18 most recent chatroom, scroll through the chat list.

ChatGPT Android app chat list screen
Chat List

7. What range of data is stored when entering each chatroom?

When you enter a chatroom, the full text content is synchronized at once, and the entire conversation is recorded in the database. No additional scrolling is required after entering the chatroom to synchronize the data.

For image files, if the image has not been loaded on the device, the original file is not stored and therefore cannot be analyzed. If the image has been loaded properly, a cache file (coil3_disk_cache) is created, allowing the image to be analyzed.

ChatGPT chatroom with an image that has not loaded
Image not loading

8. If a chatroom is deleted, can I still recover the data?

Yes, but only under limited conditions. When a chatroom is deleted, the related database records are marked as deleted. If those deleted records have not yet been cleaned up, the data may still be identified. However, once the deleted records have been cleaned up, data cannot be recovered.

Note: Deletion of Chatroom on iOS
On iOS devices, deleting a chatroom immediately removes the related JSON files, and the data cannot be recovered.

9. If the user logs out from the device, does the data disappear?

Yes. When the user logs out, all conversation data (.db) stored on the device is deleted.

10. Can I find conversations from ‘Temporary Chat’?

No. Temporary chat conversations cannot be examined because they are not stored locally on the device and are not synchronized.

Temporary Chat
Temporary Chat is a separate conversation mode in ChatGPT that does not appear in chat history, does not create memories, and is not used for model training. Conversations conducted in this mode are neither saved in chat history nor stored locally on the device in DB or JSON format. In addition, they are not synchronized between PC and mobile devices, which significantly limits extraction.

ChatGPT Temporary Chat mode screen
Temporary Chat

GMDSOFT Tech Letter Vol20.Health App Data Analysis

From iOS 8 and later versions, Apple has provided a built-in Health app that automatically tracks and stores a wide range of physical activities, including step count, distance traveled, heart rate, flights climbed, and workout records. Health app data is aggregated across all devices linked to the same Apple Account, including iPhone and Apple Watch. The physical activity and health data recorded in the Health app can serve as evidence to verify subject statements and reconstruct behavioral timelines during an investigation.

This article aims to introduce Apple’s Health app and the available information in the app. The findings are based on data extracted from iOS 26 device and watchOS 26 via MD-NEXT v2.2.13 and analyzed via MD-RED v4.0.10.

Table of Contents


1.iOS Health App Overview

1.1. Types of Recorded Health Data

Data from all devices connected to the same Apple Account is aggregated in the Health app. When an Apple Watch is paired with an iPhone, step count and distance data are automatically recorded in the iOS Health app, without additional configuration. Tap the    icon in the bottom right corner of the app to see the categories of data that can be recorded in the Health app. For more details, refer to https://support.apple.com/guide/iphone/view-your-health-data-iphe3d379c32/26/ios/26

The table below summarizes the key data that may be recorded in iPhone and Apple Watch, and how they serve during investigation.

Category Key Data Examples Data on iPhone Data on Apple Watch Investigative Application
Activity Steps, distance traveled, flights climbed O O Verify movement during a specific timeframe; estimate whether stairs were used indoors
Heart Heart rate, HRV, ECG – O Estimate physical exertion or stress from sudden heart rate spike; identify abnormal physiological responses
Respiratory Respiratory rate – O Reference for sleep state and physiological responses
Sleep Sleep duration O
(based on schedule)
O Verify whether the subject was actually asleep during the timeframe in question
Mobility Gait stability, walking speed O O Cross-check claims of physical injury
Hearing Environmental noise exposure – O Indirectly infer surrounding environment (e.g., high-noise locations)
Cycle Tracking Menstrual cycle, ovulation records O O Supplementary reference for statements regarding physical condition

Data Recording Method

Health app data can be collected automatically through the sensors built into iPhone and Apple Watch, or input manually by the user. To manually input the data, follow the steps below.

  1. Open the Health app and tap Steps.

  2. Then tap the icon to manually input the data.
  3. When finished, tap    icon to save.
Manual Input of Health Data

Health Data Sharing

The health data sharing feature has been available since iOS 15 and watchOS 8. Sharing is limited to users who have added each other as contacts, and shared data is continuously synchronized.

Follow the steps below to share the health data. For more details, refer to the Apple support page https://support.apple.com/guide/iphone/view-your-health-data-iphe3d379c32/26/ios/26

1.In the Health app, go to the ‘Sharing’ tab.

2.Tap [Share with Someone].

3.Search for and select a person from the contacts list.

4.Select the health data categories to share, then tap [Share].

Health Data Sharing

2.Available Information

2.1. Device Information & Data Entry Method

The healthdb.sqlite contains the device information, initial Health app setup timestamp, and manual and automatic data entry flag. Any manually input records may suggest potential data manipulation.

Table Available Information
sources Device name
source_devices
  • Model name
  • OS version
  • Initial Health app pairing timestamp
  • Value indicating whether data was input manually or automatically

2.2 User Profile & Health Records

The healthdb_secure.sqlite file contains the user’s personal information, the start and end timestamps of health data recording, health data entries, and location records.

Table Available Information
samples
  • User name, gender, date of birth, and other user information
  • Data type
  • Recording start/end timestamps
quantity_samples
  • Health data value

2.3 Shared Health Data from Other Users

Health data shared by another user is stored in /private/var/mobile/Library/Health/Profiles/{SharedAccoundInternalID}/.

The healthdb.sqlite and healthdb_secure.sqlite files at this path follow the same structure as the primary Health database. Records of health data sharing requests are stored in /private/var/mobile/Library/Health/Client/HealthApp.sqlite.

Path File Available Information
/private/var/mobile/Library/Health/Profiles/{Shared Account Internal ID}/
  • healthdb.sqlite
  • healthdb_secure.sqlite
Health data shared by other users
/private/var/mobile/Library/Health/Client/ HealthApp.sqlite
  • Account information of the sharing requester and the target recipient
  • Timestamp of the sharing request and acceptance
  • Current health data sharing status

 

3.Summary

    1. The Apple Health app tracks users’ physical activity and biometric data. Data is collected automatically or entered manually via iPhone and Apple Watch, and the recorded data can be used to verify statements made by subjects under investigation and to reconstruct behavioral timelines.

    2. Apple Health app data is stored in the healthdb.sqlite and healthdb_secure.sqlite files located under /private/var/mobile/Library/Health/.

    3. The healthdb.sqlite file contains the device information associated with recorded entries, the timestamp of the initial Health app setup, the manual/automatic data entry flag, and more.

    4. The healthdb_secure.sqlite file stores the user’s personal information, the type and actual values of recorded health data, and the start and end timestamps of each recorded entry.

    5. Health data shared by other users is stored in the healthdb.sqlite and healthdb_secure.sqlite files under /private/var/mobile/Library/Health/Profiles/{Shared Account Internal ID}/, while records of sharing requests are logged in the HealthApp.sqlite file located under /private/var/mobile/Library/Health/Client/.

 

 

GMDSOFT Tech Letter Vol19.App Artifact Analysis: Text Input Records

Text entered on a mobile device can be stored and managed by keyboard apps to improve features such as auto-completion and data learning. Therefore, not only messenger apps that contain large volumes of messages, but also keyboard apps that store keyboard text artifacts are forensically significant sources of evidence during investigations.

Text input methods on mobile devices vary by language. Some languages, such as English, allow direct text entry without conversion, while others require a conversion process before finalizing the input. Japanese is a prime example of the latter. Japanese users typically input text in romaji (Latin alphabet) or hiragana, then convert it to hiragana, katakana, or kanji and confirm their final input. For languages with conversion processes like Japanese, keyboard apps can retain various text input records, including initial input, suggested conversions, and final confirmed text.

This article aims to explore the available information from keyboard apps from Android and iOS, focusing primarily on Japanese input records. The findings are based on data extracted from Android 12.0 and iOS 16.7 devices via MD-NEXT v2.2.12 and analyzed via MD-RED v4.0.8.

Table of Contents


1.Keyboard Input Process

Japanese uses three writing systems, hiragana, katakana, and kanji. It is characterized by multiple kanji characters that share the same pronunciation but convey different meanings, as well as individual kanji that can be read in multiple ways. Because of these complexities, Japanese input requires users to first enter text in romaji or hiragana, then select from suggested words (to hiragana, katakana, or kanji) presented by the keyboard app to determine the final text.

General Japanese Input Process for Typing “kyo”

2.Available Information by Keyboard App

2.1 Android

Gboard

Gboard is a keyboard app developed by Google that supports multiple languages and integrates features such as Google Translate and Google Search.

The input text records and the timestamp of entry are stored in the history.db file located under the /.mozc directory. Within this file, both the input text and the corresponding input timestamp are stored in an encrypted Protocol Buffer format.

Input Records Available in Gboard

Wnn Keyboard Lab

Wnn Keyboard Lab is a keyboard app installed on many Android devices manufactured by Japanese vendors. It stores input records using the OpenWnn structure, an open-source input framework developed by Japanese manufacturer Omron.

Text input records are stored in njuserl.a and njuserw.a files under the /files/discet/master directory.

ⓘ

OpenWnn

OpenWnn is an open-source Japanese input method editor developed by Omron. It provides core functions required for Japanese text input, including romaji input, kana conversion, kanji candidate prediction, and user dictionary-based learning.

 

Samsung Keyboard

Samsung Keyboard is the default keyboard app preinstalled on Samsung mobile devices. Similar to Wnn Keyboard Lab, Samsung Keyboard uses the OpenWnn structure, resulting in a similar data storage format. Japanese text input records are stored in njuserl.a and njuserl_uniq.a files under the /app_omrondb/dicset/master directory.

Simeji Keyboard

Simeji Keyboard is a third-party keyboard app that supports a wide range of emojis and theme customization features. Text input records are stored in the following locations.

  • /database

  • /file/dat

Text input content and the timestamp of the last input can be identified in the SimejiProvider.db file located under the /database directory.

SimejiProvider.db

In addition, plaintext records of input text and the package name of the application in which the text was entered are stored in the fcloud.dat file under the /files/dat directory. The dad_info.dat file, stored in the same path, records the time at which a text input field was displayed. These records may be created even when no text is entered, as long as a keyboard appears on the screen.

fcloud.dat
dad_info.dat

The following table summarizes the information above.

File path File Available Information
/databases SimejiProvider.db
  • Text input records
  • Timestamp of last input
/files/dat fcloud.dat
  • Text input records and suggested words
  • App package name where the text was entered
dad_info.dat
  • Timestamp when the keyboard was displayed on the screen
  • (Recorded even without actual user input)

2.1 iOS

Default Keyboard

For the default keyboard built into the iPhone, keyboard input records are stored in plaintext in the following files under the /private/var/Mobile/Library/Keyboard directory.

  • LexicalLearning_ja_JP.db

  • DynamicPhraseLexicon_ja_JP.db

LexicalLearning_ja_JP.db & DynamicBigramPhraseLexicon_ja_JP.db

Biome

The Biome directory is known to store system logs such as user activity data, device usage information, application execution records, and Siri-related events. Text input records on iOS devices are also stored under the /private/var/mobile/Library/Biome.

Under the /restricted/Keyboard.TokenFrequency/local directory, numerically named file contains records saved by session. These data are serialized and stored in SEGB format.

Under the /public/TextInputSession/local directory, numerically named file stores keyboard usage logs, and the application package name. These data are serialized in SEGB format.

ⓘ

SEGB

SEGB is a proprietary binary storage format used by iOS to record user actions and system events. This format is primarily observed within the Biome directories on iOS devices.

ⓘ

Records by language

Input records for other languages are also stored in separate databases organized by language in the private/var/Mobile/Library/Keyboard directory. These databases contain word input records and last converted timestamp. The internal database structure remains consistent across all languages.

2.3 Available Information by Keyboard App

App Save Path File Available Information
Android Gboard /.mozc history.db
  • Text input records
  • Timestamp of the last text input
Wnn Keyboard Lab /files/dicset/master • njuserl.a
• njuserw.a
  • Text input records
  • Suggested words
Samsung Keyboard /app_omrondb/dicset/master • njuserl.a
• njuserl_uniq.a
  • Text input records
Simeji Keyboard /database SimejiProvider.db
  • Text input records
  • Timestamp of the last text input
/files/dat fcloud.dat
  • Text input records
  • Suggested words
  • Package name of the app…
dad_info.dat
  • Timestamp when the keyboard was displayed…
  • (Recorded even when no text is entered)
iOS Default Keyboard /private/var/Mobile/Library/Keyboard • LexicalLearning_ja_JP.db
• DynamicPhraseLexicon_ja_JP.db
  • Text input records
Biome /restricted/Keyboard.TokenFrequency/loca Numerically named file
  • Text input records
/public/TextInputSession/local Numerically named file
  • Keyboard usage logs
  • Package name of the app…

3.Summary

    1. Text entered on a mobile device can be stored and managed by keyboard apps to improve features such as auto-completion and data learning.

    2. Japanese users typically input romaji or hiragana first, then convert it to katakana or kanji to finalize their text entry.

    3. The Android Gboard app stores text input records and the timestamp of the last text entry in the history.db file located at /.mozc.

    4. The Android Wnn Keyboard Lab app stores text input records using the OpenWnn structure. These records are saved in the njuserl.a and njuserw.a files at /files/dicset/master.

    5. The Android Samsung Keyboard app stores text input records in the njuserl.a and njuserl_uniq.a files at /app_omrondb/dicset/master.

    6. The Android Simeji Keyboard app stores text input records and the timestamp of the last text entry in the SimejiProvider.db file at /database. Additionally, the fcloud.dat and dad_info.dat files in /files/dat store text input records, suggested words, the package names of apps in which text was entered, and the timestamp when the keyboard was displayed on screen.

    7. The iOS default keyboard app stores text input records at /private/var/Mobile/Library/Keyboard.

    8. The iOS default keyboard app stores text input history, keyboard usage logs, and the package names of apps where text was entered at /private/var/mobile/Library/Biome.

 

GMDSOFT Tech Letter Vol18.Analyzing Recent App Traces: Task Snapshots

The ‘Recent Apps’ feature allows users to conveniently browse and relaunch recently used apps, and it has been available since Android 5.0 and later versions. Starting with Android 8.0, a new internal infrastructure called ‘task snapshots’ was introduced to store app screen captures and metadata displayed in the ‘Recent Apps’.

This article aims to introduce the ‘’Recent Apps’’ feature available on Android devices, and explain the concept of task snapshots, which save its traces. The findings are based on data extracted from the device with Android 11 using MD-NEXT v2.2.8, and analyzed with MD-RED v4.0.5

Table of Contents


1.Recent Apps

Tap at the bottom-left of the home screen to access the ‘Recent Apps’. Swipe left or right to browse through the apps running in the background. You can reopen a specific app or swipe it upward to remove it from the ‘Recent Apps’. Up to 50 apps can be open in the background, and when the limit is exceeded, the oldest apps will be removed from the ‘Recent Apps’.

Learn more

ⓘ

Background Apps

An application that is still running and active on the device, even though it is not currently visible on the screen.

 

1.1 Take Snapshot

A task snapshot is an internal Android infrastructure used to store the screen displayed in the ‘Recent Apps’ feature. It refers to the app screen when it is switched to the background. The app screen is saved in both high-resolution and low-resolution.

Learn more

2.Available Information

Under /system_ce/{User ID}/snapshots/, Android stores a set of three files for each screen displayed in the ‘Recent Apps’ list. If a user swipes an app away from the ‘Recent Apps’, the corresponding files are also deleted.

• {Task ID}. jpg

• {Task ID}_reduced.jpg

• {Task ID}.proto

The name of each file is assigned a unique numerical Task ID, and this ID increases sequentially according to the order in which apps transition to the background. Even if an app already shown in ‘Recent Apps’ is launched again and then switched back to the background, its previously assigned Task ID does not change.

Task snapshot file list
ⓘ

Although Task IDs generally increase as apps transition to the background, the numbers may not appear in consecutive order. This can occur when a user swipes an app away from the ‘Recent Apps’, or when Task IDs are assigned to background apps that do not appear in the ‘Recent Apps’ list.

 

2.1 Last Screen of the Recent App

You can identify the last screen displayed in a recent app from the two snapshot image files: {Task ID}.jpg and {Task ID}_reduced.jpg. The {Task ID}_reduced.jpg file is a lower-resolution version and has a smaller file size compared to {Task ID}.jpg

2.2 Timestamp of Background Transition

You can identify the timestamp of an app’s transition to the background in the {Task ID}.proto file, which stores the snapshot’s metadata. The modified, accessed, and changed timestamps (MAC Times) of the {Task ID}.proto file also reflect the moment when the app was switched to the background.

Decoded protocol buffer (.proto) file
MAC Times of the protocol buffer (.proto) file

The modified and changed timestamp of {Task ID}.jpg and {Task ID}_reduced.jpg represent the timestamp when the app transitioned to the background. These timestamps are updated each time the app is switched to the background. The accessed timestamp of these files indicates the first time the app was transitioned to the background.

MAC Times of JPG file

 

ⓘ

Protocol Buffer File

A protocol buffer file is a file format developed by Google for efficiently storing and transmitting structured data.

2.3 Others

The /system_ce/{User ID}/snapshots/ directory may also contain screens, such as alarm screens, Galaxy default app searches, network list screens, and others.

Other Screens

Meanwhile, the {Task ID}.xml files stored under /system_ce/{User ID}/recent_tasks/ provide a record of app usage history that complements the snapshot artifacts.

 

2.4 Summary of Available Information

Item Description
{Task ID}.jpg
  • Last screen displayed in the ‘Recent Apps’
  • The modified and changed timestamps represent the moment the app transitioned to the background.
{Task ID}_reduced.jpg
  • Low-resolution version of the last screen displayed in the ‘Recent Apps’
  • The modified and changed timestamps represent the moment the app transitioned to the background.
{Task ID}.proto • File containing metadata and state information for the task snapshot.
Others
  • Screens such as alarm views, default app search screens, and network list screens may also be stored under /system_ce/{User ID}/snapshots/.
  • App usage history is recorded in the {Task ID}_task.xml file stored under /system_ce/{User ID}/recent_tasks/.

3.Summary

  1. Android devices provide a ‘Recent Apps’ feature that allows users to view recently used apps and relaunch them easily.

  2. Task snapshots serve as Android’s internal infrastructure for storing the screens and metadata of recently used apps.

  3. For each screen shown in the ‘Recent Apps’, a set of three files, {task ID}.jpg, {task ID}_reduced.jpg, and {task ID}.proto, is stored under /system_ce/{User ID}/snapshots/.

  4. The {task ID}.jpg and {task ID}_reduced.jpg files contain the last displayed screen of the app. The modified and changed timestamps indicate the moment the app transitioned to the background, while the accessed time reflects the first time the app transitioned to the background.

  5. The {Task ID}.proto file records metadata, including the timestamp of the background transition. Its modified, accessed, and changed timestamps also correspond to the time the app was transitioned to the background.

  6. In addition to recent app screens, this directory may also contain images such as alarm screens or other system-generated snapshots. App usage history can be found in the {Task ID}.xml file stored under /system_ce/{User ID}/recent_tasks/.

 

 

GMDSOFT Tech Letter Vol17.Detecting Hotspot Connection Evidence on Suspect Devices

There is suspicion that the subject participated in criminal activity through a hotspot connection. Is it possible to verify the device’s hotspot connection activity through mobile forensic analysis?

Hotspot connections represent more than simple network activity. They can serve as evidence that two devices were in close physical proximity.

iOS hotspot feature requires manual authentication for the initial connection, but automatically reconnects when the same device comes within range thereafter. This means the presence of automatic connection records indicates that the user previously entered the password manually, and suggests the possibility that both devices were used together in the same location at the time of an incident.

This article aims to explain how to connect to a personal hotspot on iOS devices and provide key information available to identify the connection history. The findings are based on the data extracted from iOS 16.7 device using MD-NEXT v2.2.8 and analyzed via MD-RED v4.0.4.

ⓘ

A hotspot allows a mobile device to share its cellular data connection with another device, providing internet access when Wi-Fi is unavailable.

For a hotspot connection, both the providing device and the receiving device must be within approximately 10 meters of each other.

Table of Contents


1.How to Set Up a Personal Hotspot

When a Wi-Fi network is unavailable, you can share your iPhone’s cellular data connection by enabling a Personal Hotspot. To enable a hotspot, configure devices as follows.

Learn more


1.1 Hotspot Providing Device

Go to ‘Settings’ > ‘Personal Hotspot’ or ‘Settings’ > ‘Cellular’ > ‘Personal Hotspot’ and enable ‘Allow Others to Join’ option. To use this hotspot, other users must enter the password set in the providing device.

 

1.2 Hotspot Receiving Device

Go to ‘Settings’ > ‘Wi-Fi’ and select a personal hotspot of Device B. A personal hotspot is displayed with the icon next to it. If a personal hotspot is successfully connected, the icon is displayed on the top-right corner of the device screen.


2.Hotspot Connection History on Receiving Device (A)

The hotspot connection history on the receiving device is stored in the following source files:

• /private/var/preferences/com.apple.wifi.known-networks.plist

• /private/var/preferences/SystemConfiguration/com.apple.wifi-private-mac-networks.plist

• /var/mobile/Library/Preferences/com.apple.networkserviceproxy.plist

The following information is available in the fils : 

• Start timestamp of initial connection

• Start timestamp of automatic an manual hotspot connection

• Start timestamp of the nth connection

• Start/end timestamp of the last connection

The following sections describe typical scenarios in which this information can be identified and analyzed. Device A refers to the device that received the hotspot connection, and Device B refers to the device that provided it.

ⓘ

The name of the hotspot used by the receiving device is also available for analysis. IF the device name is changed, the name of the providing device may differ from the name it had when the hotspot connection was made.

 

2.1 Case 1 : Device A Connects to Device B’s hotspot (1st session)

This scenario is when Device A connects to Device B’s personal hotspot. If it is the initial connection, the password set on the providing Device B is required to enable the connection.

The following information is available :

• The AddedAt key in the com.apple.wifi.known-networks.plist file and the AddedAt key in the com.apple.wifi-private-mac-networks.plist file record the timestamp when the hotspot was initially connected.

• The NSPServiceStatusMAnagerInfo key in the com.apple.networkserviceproxy.plist file contains blob-processed Plist data with detailed hotspot connection information. In each NS.time key, under PrivacyProxyNetworkStatusTimeNetworkStartTime andPrivacyProxyNetworkStatusTimeNetworkEndTime keys, you cna find the timestamp the hotspot was connected and disconnected. The timestamp is recorded in CFAbsoluteTime format.

ⓘ

CFAbsoluteTime (Core Foundation Absolute Time) is Apple’s timestamp format, which uses January 1, 2001, 00:00:00 UTC as its reference point. By converting a CFAbsoluteTime value to Gregorian date, you can determine the corresponding year, month, day, and hour.

 

The following table summarizes the information above.

Source File Key Description
/var/mobile/Library/Preferences/com.apple.networkserviceproxy.plist
  • NSPServiceStatusManagerInfo
  • PrivacyProxyNetworkStatusTimeNetworkEndTime
  • NS.time
End timestamp of connection

 

/private/var/preferences/com.apple.wifi.known-networks.plist

 

/private/var/preferences/SystemConfiguration/com.apple.wifi-private-mac-networks.plist

 

/var/mobile/Library/Preferences/com.apple.networkserviceproxy.plist

 

2.2 Case 2 : Device A Connects from the hotspot (1st session)

In this case, Device A loses its connection to Device B’s hotpot. Hotspot connections can be lost when :

• The user manually disconnects from the hotspot.

• The device switches to a different Wi-Fi network.

• The device moves too far from the hotspot providing device.

• The hotspot provider changes the hotspot password.

When a connection is terminated, the end timestamp can be found in the com.apple.networkserviceproxy.plist file.

Source File Key Description
com.apple.wifi.known-networks.plist JoinedBySystemAt Start timestamp of automatic connection
JoinedByUserAt Start timestamp of manual connection
com.apple.wifi-private-mac-networks.plist lastJoined Starttimestamp of the most recent connection

 

/var/mobile/Library/Preferences/com.apple.networkserviceproxy.plist

2.3 Case 3 : Device A Connects to Device B’s hotspot (2nd session)

In this case, Device A temporarily loses connection and then reconnects to Device B’s hotspot. There are two possible reconnection scenarios.

• Automatic connection: The device automatically reconnects when it comes within range of the hotspot. For this condition, the providing device must not have changed the password, and the ‘Allow Others to Join’ option must be enabled.

• Manual connection: The user actively selects and reconnects to the hotspot. Since the password was saved during the first connection, re-authentication is not required.

The JoinedBySystemAt key within the com.apple.wifi.known-networks.plist file records the start timestamp of the automatic connection. Upon manual reconnection, the JoinedByUserAt key is updated with the corresponding start timestmap of connection.

The lastJoined key in the com.apple.wifi-private-mac-networks.plist file records the start timestamp of the last connection, updating with each session (2nd, 3rd, nth session).

The table below summarizes the information above.

Source File Key Description
com.apple.wifi.known-networks.plist JoinedBySystemAt Start timestamp of automatic connection
com.apple.wifi.known-networks.plist JoinedByUserAt Start timestamp of manual connection
com.apple.wifi-private-mac-networks.plist lastJoined Starttimestamp of the most recent connection

 

JoinedBySystemAt and JoinedByUserAt keys in com.apple.wifi.known-networks.plist
lastJoined key in com.apple.wifi-private-mac-networks.plist

2.4 Case 4 : Device A disconnects from the hotspot (2nd session)

In this case, the device disconnects from the hotspot after having successfully reconnected. To determine when the hotspot connection was terminated, refer to UpdatedAt key in com.apple.wifi.known-networks.plist file and lastUpdated key in com.apple.sifi-private-mac-networks.plist file.

ⓘ

These timestmaps may update after actual disconnection occurs. They do not represent precise disconnection timestamps and should be used only as reference data for hotspot network logs.

2.5 Case 5 : Device A disconnects from the hotspot (multiple times)

In this case, the device repeatedly connects to and disconnects from the hotspot. In each session, the same information described in Case 3: Device A reconnects to Device B’s hotspot (2nd session) can be found.

When hotspot connections and disconnections occur two or more times, the start and end timestamps for all sessions except the last one are recorded in the NS.timekey under the
PrivacyProxyNetworkStatusTimeNetworkStartTime and PrivacyProxyNetworkStatusTimeNetworkEndTime keys in the com.apple.networkserviceproxy.plist file.

For example, if four sessions occurred, the start and end timestmaps for sessions 1 through 3 can be identified in the source file. While the las (4th) session’s connection start and end timestmaps cannot be verified, you can refer to the recording of previous connection and disconnection timestamps to trace hotspot connection history.

ⓘ

A session refers to a single connection unit from the moment a hotspot connection is initiated until it is terminated.

The table below summarized the information above.

Source File Key Description
com.apple.networkserviceproxy.plist
  • PrivacyProxyNetworkStatusTimeNetworkStartTime
  • PrivacyProxyNetworkStatusTimeNetworkEndTime
NS.time
  • Start timestamp of $n^{th}$ session
  • End timestamp of $n^{th}$ session
*When a connection is established and terminated more than twice, start and end timestamp of the last connection are not recorded.

/var/mobile/Library/Preferences/com.apple.networkserviceproxy.plist

3. Summary of Available Information

Source File Key Description
/private/var/preferences/com.apple.wifi.known-networks.plist
  • AddedAt
  • UpdatedAt
  • JoinedBySystemAt
  • JoinedByUserAt
  • Start timestamp of initial connection
  • End timestampof connection (may be updated later)
  • Start timestampof automatic reconnection
  • Start timestamp of manual reconnection
/private/var/preferences/SystemConfiguration/com.apple.wifi-private-mac-networks.plist
  • addedAt
  • lastUpdatedAt
  • lastJoined
  • Start timestamp of initial connection
  • End timestamp of connection (may be updated later)
  • Start timestamp of last connection
/var/mobile/Library/Preferences/com.apple.networkserviceproxy.plist
  • PrivacyProxyNetworkStatusTimeNetworkStartTime
  • PrivacyProxyNetworkStatusTimeNetworkEndTime
  • Start timestamp of nth connection
  • End timestamp of nth connection
*When a connection is established and terminated more than twice, start and end timestamp of the last connection are not recorded.

4.Appendix: Information Available on Providing Device (B)

The device that provided the hotspot also stores records of hotspot connection activity.If deleted records are present in the ZTIMESTMAP key of the ZPROCESS table in the /private/var/wireless/Library/Databases/DataUsage.sqlite file, it suggest that the hotspot provider enabled the ‘Allow Others to Join’ option.

/private/var/wireless/Library/Databases/DataUsage.sqlite
ⓘ

Records are not always created every time the hotspot is enabled.
However, when records are present, the timestamp indicates when the hotspot was enabled and can be used as reference data.

5.Summary

  • • Hotspot connection records suggest the physical proximity of the providing and receiving devices.
  • • Connecting to a hotspot requires entering the hotspot password on the initial connection. If a device automatically connects to a specific hotspot, it suggests a prior connection between the two devices.

  • • On the receiving device, hotspot connection records are found in the following source files
    •   ◦ com.apple.wifi.known-networks.plist

    •   ◦ com.apple.wifi-private-mac-networks.plist

    •   ◦ com.apple.networkserviceproxy.plist

  • • On the providing device, if deleted records of the ZTIMESTMAP key in the ZPROCESS table of the DataUsage.sqlite file exist, it indicates that a hotspot connection occurred.

 

GMDSOFT Tech Letter Vol16.Analysis of AI Editing Traces on Galaxy and iPhone

AI features, such as translation and photo editing, are rapidly expanding across mobile devices. In particular, AI-driven photo editing features, such as object removal and natural background generation, are now commonly available in default gallery apps, no longer requiring third-party applications.

At the same time, this advancement has also posed new challenges in digital investigations. Photos edited with AI can be difficult to distinguish from the original, potentially causing confusion when verifying the authenticity of digital evidence. For this reason, identifying whether a photo has been altered and securing traces of such edits are becoming important in forensic analysis.

This article explains the AI photo editing features available on major smartphone manufacturers, Samsung Galaxy and Apple iPhone. The findings are based on the data extracted from an Android 15 device running One UI 7.0 and an iOS 18.5 device, extracted using MD-NEXT v2.2.5 and analyzed with MD-RED4 v4.0.1.

Table of Contents


1.Galaxy AI Photo Editing Features

Samsung first introduced the Galaxy AI, a collection of AI features integrated into its devices, with the launch of the Galaxy S24 series. Galaxy AI was later expanded to earlier models through the One UI 6.1 update. Among these features, ‘Photo Assist’ empowers photo editing with AI functionality. The key features of Photo Assist are outlined below. For more details, refer to Samsung’s official website.

Learn more


1.1 Sketch to Image

This feature allows you to transform simple sketches drawn over a photo into realistic objects.
To use this feature, open the Gallery app, select a photo > Tap the Photo Assist Save iconicon > Select the Sketch to Image icon and draw a sketch.

AI will automatically convert it to a realistic object that matches the context of the photo.

Generative Edit

This feature allows you to move, delete, or resize a person or object in a photo. When an object is removed or repositioned, AI automatically fills the empty area to seamlessly match the surrounding background.

To use this feature, open the Gallery app, select a photo > Tap the Photo Assist Save iconicon > Select or outline the target object to adjust its size or to remove it.

Portrait Studio

This feature allows you to apply various artistic effects, such as watercolor or sketch styles, to portrait photos. It is available only for photos recognized as portraits.

To use this feature, open the Gallery app, select a photo > Tap the Photo Assist Save iconicon > Choose the desired effect to apply to the photo. If there is more than one person, select the person you want to apply the effect to.


1.2 iPhone AI photo Editing Features

Apple rolled out ‘Apple Intelligence’ starting with iOS 18.1, compatible with devices featuring the A17 Pro chip or later. In the Photos app, Apple Intelligence includes the ‘Clean Up’ feature, which removes distracting objects from a photo.

 

Clean Up

To use the ‘Clean Up’ feature, open the Photos app and select a photo to edit > Tap the Save iconicon at the bottom of the screen > Select the Clean Up icon> Tap or brush over the area you want to remove, and the selected object will be erased from the photo. Once finished, tap [Done] in the upper-right corner to apply the effect.

Note that if you brush over the sensitive details, such as faces, tattoos, or ID numbers, they may be blurred with a pixelated effect. For more information, refer to Apple’s official website.

Learn more


1.3 Available Editing Artifacts

Device Gallery/Photo App

On Galaxy, edited photos are saved as separate copies in the Gallery. A watermark ‘AI-generated content’ appears at the bottom-left corner of the edited photo, indicating that an AI effect has been applied.

On iPhone, edits are applied directly to the original photo. Unlike on Galaxy, edited versions are not saved separately in the Photos app. As a result, it is difficult to visually distinguish edited photos within the Photos app.

Alternatively, you can check whether a photo has been edited by tapping the Save iconicon to enter edit mode. If the [Revert] button appears in the upper-right corner, it indicates that the photo has been edited using the Clean Up feature or other basic editing tools such as crop or filters.

#image_title

On iPhone, edits are applied directly to the original photo. Unlike on Galaxy, edited versions are not saved separately in the Photos app. As a result, it is difficult to visually distinguish edited photos within the Photos app.

Alternatively, you can check whether a photo has been edited by tapping the icon to enter edit mode. If the [Revert] button appears in the upper-right corner, it indicates that the photo has been edited using the Clean Up feature or other basic editing tools such as crop or filters.

ℹTap the Edit Save icon icon > [Revert] > ‘Revert to Original’ to restore the original photo.

 

Metadata

On Galaxy, the edited photo’s Hex data contains metadata in JSON format (key:value format). Within this metadata, the value assigned to the genAIType key indicates which Photo Assist feature was used during editing.

genAIType Type of Photo Assist Feature
1 Generative Edit
2 Portrait Studio
4 Sketch to Image

 

On iPhone, the hex data of an edited photo contains the string ‘Apple Photos Clean Up.’ If this string is found in the hex data, it indicates the Clean Up feature has been applied to the photo.

 

File Name and Save Path

On Galaxy, edited photos are saved in the same path as the original. For photos taken directly with the device camera, both the original and edited files share the same naming format, YYYYMMDD_HHmmss.{extension}. Therefore, it is difficult to distinguish between the edited photo and the original based solely on the file name or save path.

• Save path of original: /var/mobile/Media/DCIM/{sezuence number]APPLE/[IMG_sequence number].{extension}

• Save path of edited photo: /var/mobile/Media/PhotoData/Mutations/DCIM/{sequence number}APPLE/[IMG_sequence number]/Adjustments/FullSizeRender.{extension}

Other Artifacts

On Galaxy, edited records are stored in the media.db file located at /data/com.samsung.android.providers.media/databases. When the Photo Assist feature is used, the files table in this database contains a key named sef_file_types.

On iPhone, the Adjustments.plist file is available in the save path where edited photos are stored (/var/mobile/Media/PhotoData/Mutations/DCIM/{sequence number}APPLE). In this Plist file, refer to adjustmentTimestamp, adjustmentRenderTypes, and adjustmentData keys to find the timestamp the photo was edited, whether the Clean Up feature was used, and the area of the photo where the AI effect was applied.

Summary of Artifacts Left by AI Photo Editing Features

Location Galaxy iPhone
Device Gallery/Photo App O △
Metadata O O
File Name and Save Path X △
Others O (DB file) O (Plist file)

O: Distinguishable / X: Not Distinguishable / △: Detectable, but similar traces may also appear when using non-AI editing features


1.4 Summary

  1. The latest Galaxy and iPhone models support AI-powered photo editing features within their default Gallery (Photos) app.

  2. On Galaxy, the traces of AI photo editing (Photo Assist) can be identified through the Gallery app, the metadata of the edited file, and the media.db file.

  3. On iPhone, the traces of AI photo editing (Clean Up) can be identified through the Photos app, metadata, and the Adjustment.plist file.

 

 

GMDSOFT Tech Letter Vol15.Analyzing Anti-Forensic Traces Left by Location Spoofing Apps

Location information is a vital piece of digital evidence used to map a subject’s movements and validate alibis. Location spoofing apps compromise the integrity of data by hiding real travel routes or fabricating alibis. For instance, there have been cases where suspects used a spoofing app to simulate being away from a crime scene, while simultaneously taking multiple photos to support their false claim.

Such practices fall under anti-forensic techniques, specifically the category of data modification. By altering or fabricating data, location spoofing undermines the reliability of digital evidence and complicates forensic analysis.

This article aims to introduce the main features of three widely used location spoofing apps: Fake GPS Location, GPS Emulator, and Fly GPS. It also explains the types of forensic artifacts that can be recovered during analysis. The findings are based on devices with Android 12, using Fake GPS Location v90.0, GPS Emulator v3.02, and Fly GPS v7 (free versions).

Index


1.Location Spoofing App

A location spoofing app works by feeding the system with fake coordinates generated by the app instead of real GPS signals. As a result, the device appears to be in a different location. This section explains the key features supported by three common spoofing apps: Fake GPS Location, GPS Emulator, and Fly GPS.

ⓘ
To use an installed spoofing app, go to Settings > Developer options > Select mock location app, and assign the app.

1.1 Fake GPS Location

Location Search

Use the search bar at the top of the screen to enter an address. Once entered, the Save icon icon moves to the corresponding location.

Virtual Location Setup

Run the app and swipe across the map to move to the desired location. Tap on the map, and the Save iconmarker will shift to that point. Select [Start Fake GPS] to set the device’s coordinates to the desired location. Fake GPS Location only supports setting a fixed location.

Favorites

After setting a location, tap the Save iconicon at the bottom-right corner to save it as a favorite. You can view all saved favorites by tapping the Save iconicon. Selecting a favorite will reposition the map to that location. Fake GPS Location does not provide an option to delete saved favorites.


1.2 GPS Emulator

Location Search

Tap the Save iconicon at the top-right corner and enter an address in the search bar to move to that location.

Virtual Location Setup

GPS Emulator offers two options, one that allows users to set a fixed virtual location and the other to simulate travel routes.

•Fixed Location: Swipe the map to the desired point and tap the Save iconicon at the bottom of the screen. The Save iconmarker will appear at that point, and the device will use it as the virtual location. Tap the Save iconicon to stop spoofing.

•Movement Path: Select the Save icon
icon at the top-left corner > New route to configure paths manually or automatically.

    ・Manual: Swipe the map to set a start and end point. You can connect the points with a straight line.

    ・ Auto: Generate a path that follows roads or sidewalks, simulating travel routes.

Favorites

Tap the Save iconicon at the bottom-right corner to save a fixed location as a favorite. Go to Save icon
icon at the top-left corner > Bookmarks > Locations & Routes to view the saved favorites.

Location Spoofing History

Go to Save icon icon at the top-left corner > Bookmarks > History to view the records of spoofed locations. Tap the Save iconicon to remove entries from the list.


1.3 Fly GPS

Location Search

Tap the Save iconicon at the top-right corner and enter an address in the search bar to move to that location.

Virtual Location Setup

Fly GPS offers two options: Fixed Location Mode for setting a static spot, and Move Location Mode for simulating movement routes as if a user is physically moving.

• Fixed Location Mode: Swipe the map and tap the desired location. A marker Save iconwith a popup menu will appear. Select the popup menu > GPS Service Run > Fixed Location Mode to set the virtual coordinates.

• Move Location Mode: Begin by setting a start point the same way as in Fixed Location Mode. Select the popup menu > GPS Service Run > Move Location Mode. Once the start point is set, use the gray directional pad displayed in the bottom-right corner to simulate movement along a path.

Favorites

Select the popup menu > Add to favorites to save the location. Go to Favorites at the top-right of the screen to view the saved favorites. You can reuse the saved items and display them again on the map. Fly GPS support deletion in favorites.

Location Spoofing History

Go to at the top-left corner > History to view the timestamp and location details of spoofed positions. Fly GPS does not support deletion in history.


1.4 Summary of Key Features by App

The main features provided by each app can be summarized as follows:

• Fake GPS Location: In the free version, only location search and favorites are supported. It is limited to setting a single fixed location.

• GPS Emulator: Offers the most comprehensive feature set, including location search, favorites, fixed location, movement path, and location spoofing history. It supports both manual and automatic options (based on roads and sidewalks) for virtual location setup, allowing for more precise manipulation.

• Fly GPS: Supports location search, favorites, fixed location, movement path, and location spoofing history. One distinctive feature is that location spoofing history cannot be deleted, which can provide valuable forensic evidence.

The summary of key features by app can be summarized as follows:

Fake GPS Location GPS Emulator Fly GPS
Location Search O O O
Fixed Location O O O
Movement Path X O O
Location Spoofing History X O O
Favorites O O O

2.Available Information

2.1 Location Search

Location search is a common feature in location spoofing apps. It stores location search history data, which can be used to verify user behavior, such as manually searching for a specific address to change device coordinates. However, location search data is only stored in specific location spoofing apps. Apps like Fake GPS Location and Fly GPS support this feature, but does not retain location search history.

The save paths and target files containing location search data for each app are summarized below.

App Save path Target file
Fake GPS Location Data is not saved
GPS Emulator /data/com.rosteam.gpsemulator/shared_prefs/ com.rosteam.gpsemulator_preferences.xml
Fly GPS Data is not saved

2.2 Location Spoofing History

Location spoofing history records coordinates and related data. GPS Emulator and Fly GPS support this feature. In GPS Emulator, spoofing history can be deleted within the app, removing corresponding entries from the target file. Fly GPS does not support deleting spoofing history, making it valuable for forensic analysis.

The save paths and target files containing location spoofing history data for each app are summarized below.

App Save path Target file Notes
Fake GPS Location Feature is not supported
GPS Emulator /data/com.rosteam.gpsemulator/shared_prefs/ com.rosteam.gpsemulator_preferences.xml If history is deleted from the app, data is also deleted.
Fly GPS /data/com.fly.gps/databases FLYGPS_DATABASE Delete feature is not available

2.3 Movement Route

Location spoofing apps allow users to simulate movements. GPS Emulator and Fly GPS offer this feature. In GPS Emulator, you can manually or automatically manipulate the movement route. In Fly GPS, you can navigate the arrow icons after setting a start point.

The save paths and target files containing movement route data for each app are summarized below.

App Save path Target file Available information
Fake GPS Location Feature is not supported
GPS Emulator /data/com.rosteam.gpsemulator/shared_prefs/ com.rosteam.gpsemulator_preferences.xml Latitude/longitude, speed, fixed/variable status
Fly GPS Data is not saved

2.4 Favorites

Favorites allow you to bookmark frequently used locations for quick access, eliminating the need to repeatedly enter addresses. This feature is supported by all three apps, enabling faster and more convenient spoofing of recurring locations.

The save paths and target files containing favorites data for each app are summarized below.

App Save path Target file Available information
Fake GPS Location /data/com.hopefactory2021.fakegpslocation/files/io.paperdb/ favorites.pt
favorites_coordinates.pt
Name of favorite
Latitude/longitude of favorited item
GPS Emulator /data/com.rosteam.gpsemulator/shared_prefs/ com.rosteam.gpsemulator_preferences.xml
Fly GPS /data/com.fly.gps/databases/ FLYGPS_DATABASE

3. Summary

Location spoofing is an anti-forensic practice that disrupts investigations by concealing or altering digital evidence. It falls under the category of data modification, in which data is manipulated to hinder forensic analysis.

Typical features of location spoofing apps include location search, fixed location spoofing, movement path simulation, and favorites.

All three apps store data when the favorites feature is used.

Among them, GPS Emulator retains the most extensive data, including search records, location spoofing history, and movement paths. Fly GPS is particularly noteworthy because spoofing history cannot be deleted, making it especially useful for forensic analysis.

 

GMDSOFT Tech Letter Vol14.Data Analysis Using WhatsApp Backup Feature

WhatsApp is one of the most widely used mobile messaging applications globally, with over 2 billion users across 180 countries. It protects user communications with end-to-end encryption to prevent third parties from reading them, and offers convenient features that allow users to automatically backup their data regularly or store end-to-end encrypted backups.

In particular, WhatsApp’s chat backup feature can be used to collect chat data when the app data area is inaccessible on a mobile device. The backup files generated via this chat backup feature are stored in the media area, making them easier to obtain. These files may also contain deleted records by the user, which can serve as crucial evidence in investigations.

This article aims to explain WhatsApp’s built-in backup features, compare the original DB and backup DB, and highlight the available information in the backup file. It is based on data extracted from WhatsApp v2.25.12.74 for Android.


WhatsApp Backup Feature

WhatsApp provides two different methods for backup: the Automatic Backup feature, which generates a chat backup at a specified interval, and the End-to-End Encrypted Backup feature, which applies end-to-end encryption when generating a chat backup.

Automatic Backup

You can select the time interval for backup: daily, weekly, monthly, or only when you tap ‘Automatic backups’ to initiate backup.

  1. Select the three-dot menu icon and go to ‘Settings’ > ‘Chats’.

  1. Select ‘Automatic backups’ and choose the backup interval.

End-to-End Encrypted Backup

You can create an end-to-end encrypted chat backup.

  1. Select three-dot menu icon and go to ‘Settings’ > ‘Chats’.

  1. Go to ‘Chat backup’ > ‘End-to-end encrypted backup’ and tap [Turn on].

  1. Tap [Use 64-digit encryption key instead] > [Generate your 64-digit key]. Make sure to save the key securely. Then, tap [Continue].

  1. Select [I Saved My 64-digit Key] > [Create] to start the backup process. Wait until the ‘Backing up messages’ progress message disappears.

WhatsApp Chat DB Comparison: Original VS Backup

Backup File and Decryption Key Save Location

WhatsApp stores its backup DB in different formats depending on the selected backup method.

• When using the ‘Automatic backup’ feature, the chat DB are encrypted in .crypt14 format and stored in the media area.

• When using the ‘End-to-end encrypted backup’ feature, the chat DB are encrypted in .crypt15 format and stored in the media area.

• If a user has used WhatsApp multi-account, separate backup files can be created for each account, and a backup DB is generated per each account.

The table below summarizes the information above:

Target Prerequisite DB Save Location (Based on Android 11) Decryption Key Save Location
msgstore.db Chatroom DB saved by default /data/com.whatsapp/databases –
msgstore.db.crypt14 Generated upon automatic backup /media/0/Android/media/com.whatsapp/WhatsApp/Databases/ /data/com.whatsapp/files/key
msgstore.db.crypt15 Generated upon end-to-end encrypted backup /media/0/Android/media/com.whatsapp/WhatsApp/Databases/ /data/com.whatsapp/files/encrypted_backup.key
*when multi-account is in use:
/media/0/Android/media/com.whatsapp/WhatsApp/accounts/[number]/Databases/msgstore.db.crypt15
• [number] can be incremented sequentially from 1001.
*when multi-account is in use:
/data/com.whatsapp/accounts/[number]/files/encrypted_backup.key

When a new account is created following multi-account deregistration, the folder name under the ‘account’ folder increases sequentially by 1.

❗️

WhatsApp Multiple Account Feature

When two accounts are registered on the same Android device, you can switch between accounts to use them. Since each account requires verification with a different phone number, this feature is only available on devices with dual SIM support or with a separate phone number. To learn more about the multi-account feature, please refer to the Appendix or WhatsApp official website.

Available Information

You can find the following information in both original DB (msgstore.db) and the backup DB (msgstore.db.crypt15):

• Active records in chatroom

• Deleted records in chatroom (In backup files, some deleted record may not be available.)

The original DB and backup DB have the same structure, with similar retention period and available information. Both active records and deleted records from the original DB can be found in the backup files. However, some deleted records may not be available for analysis as they are automatically cleaned up by the system during the backup process.

Target Available Information Backup storage period End-to-End Encryption
msgstore.db Chatroom and message data Same –
msgstore.db.crypt15 Active and deleted records in msgstore.db (Some deleted records may not be found.) O

Summary

  1. WhatsApp backup DB files are stored in the media area, so you can utilize the backup feature to extract WhatsApp data alongside the Full Filesystem and ADB extraction methods.
  2. The ‘End-to-end encrypted backup’ feature generates a backup DB encrypted in .crypt15 format. You can use the 64 keys generated during the backup process to decrypt these files.
  3. You can analyze active and deleted records of the original DB (msgstore.db) in the end-to-end encrypted backup (msgstore.db.crypt15). However, some deleted records may not be available for analysis if they were cleaned up during the backup process.

Appendix

How to Create Multi-Account

  1. Select three-dot menu icon > ‘Settings’ > ‘Account’ > ‘Add account’.

  1. Select [Agree and continue], then enter a different phone number.

  1. Enter the verification code sent via SMS or call, then complete your profile setup.

How to Switch Account

Select three-dot menu icon > ‘Switch accounts’ to switch between accounts. This option is available only when multiple accounts are registered.

For more details, visit the official WhatsApp website.