WeChat stands as a remarkable phenomenon in the digital landscape, serving approximately 1 billion monthly active users – roughly one-fifth of global smartphone users. This “super-app” has transcended traditional messaging platforms by integrating numerous features into a single ecosystem, making it an essential part of daily digital life, particularly in Asian markets.
What sets WeChat apart is not just its massive user base, but its unique technical architecture. Unlike other messaging platforms such as WhatsApp or Facebook Messenger, WeChat implements a distinctive server-side approach where all communications route through servers in China, creating additional layers of complexity for forensic investigations.
The Challenge
For digital forensics investigators, WeChat’s sophisticated infrastructure presents unprecedented challenges. Its self-contained platform creates an intricate maze where critical evidence often resides in unexpected locations, significantly complicating the recovery process. Traditional forensic approaches frequently fall short when confronting WeChat’s unique data storage patterns.
Our Discovery
During a recent investigation, our team uncovered a significant finding: critical media files such as recorded voice messages in WeChat exist in locations completely different from their documented paths. This discovery challenges traditional forensic approaches and opens new possibilities for evidence recovery.
・ Investigation Efficiency: Streamlining the evidence recovery process
Conclusion
Through this groundbreaking case study, GMDSOFT has demonstrated how MD-RED and MD-NEXT can revolutionize WeChat forensic investigations by efficiently tracking file storage paths and reconstructing user activities. We understand the frustration investigators face when crucial evidence proves elusive, leading to unnecessary delays and complications. This drives our mission to provide optimized tools and comprehensive technical support that make investigations more efficient and effective. Our solution not only addresses the complex challenges of WeChat’s unique architecture but also sets a new standard for digital forensic investigations.
To discover how these innovative approaches and tools can transform your investigative capabilities, request our full tech letter for a complete analysis and implementation guide.
WeChat stands as a remarkable phenomenon in the digital landscape, serving approximately 1 billion monthly active users – roughly one-fifth of global smartphone users. This “super-app” has transcended traditional messaging platforms by integrating numerous features into a single ecosystem, making it an essential part of daily digital life, particularly in Asian markets.
What sets WeChat apart is not just its massive user base, but its unique technical architecture. Unlike other messaging platforms such as WhatsApp or Facebook Messenger, WeChat implements a distinctive server-side approach where all communications route through servers in China, creating additional layers of complexity for forensic investigations.
The Challenge
For digital forensics investigators, WeChat’s sophisticated infrastructure presents unprecedented challenges. Its self-contained platform creates an intricate maze where critical evidence often resides in unexpected locations, significantly complicating the recovery process. Traditional forensic approaches frequently fall short when confronting WeChat’s unique data storage patterns.
Our Discovery
During a recent investigation, our team uncovered a significant finding: critical media files such as recorded voice messages in WeChat exist in locations completely different from their documented paths. This discovery challenges traditional forensic approaches and opens new possibilities for evidence recovery.
・ Investigation Efficiency: Streamlining the evidence recovery process
Conclusion
Through this groundbreaking case study, GMDSOFT has demonstrated how MD-RED and MD-NEXT can revolutionize WeChat forensic investigations by efficiently tracking file storage paths and reconstructing user activities. We understand the frustration investigators face when crucial evidence proves elusive, leading to unnecessary delays and complications. This drives our mission to provide optimized tools and comprehensive technical support that make investigations more efficient and effective. Our solution not only addresses the complex challenges of WeChat’s unique architecture but also sets a new standard for digital forensic investigations.
To discover how these innovative approaches and tools can transform your investigative capabilities, request our full tech letter for a complete analysis and implementation guide.
When a joint operation dismantled a Cambodia-based scam syndicate, investigators uncovered the operation’s engine room: 80+ workstations running over 1,600 Viber accounts — each one a tool for cross-border fraud. What threatened to bury the case entirely was not the suspects, but the sheer scale of digital evidence left behind.
This is how MD-PCM turned an operationally unfeasible challenge into actionable intelligence.
The Growing Bottleneck in Transnational Cybercrime Investigations
Modern organized crime syndicates operate across jurisdictions by design. Fragmented infrastructure, encrypted messaging, and multiple identities per device are no longer edge cases — they are standard operating procedure for today’s threat actors.
For law enforcement agencies (LEAs), this creates a dual burden:
• Scale: Dozens to hundreds of seized devices requiring simultaneous triage
• Complexity: Encrypted messenger applications with multiple accounts per workstation, each requiring individual credential extraction
In international operations, time is evidence. Delays don’t just slow investigations — they allow syndicates to destroy remaining assets, warn co-conspirators, and render leads obsolete.
Case Highlight: The Viber Account Labyrinth
During a high-stakes international criminal investigation, investigators seized 80+ workstations from a Cambodia-based scam syndicate — each terminal running upwards of 20 distinct Viber accounts, totaling over 1,600 communication channels weaponized to orchestrate fraud across borders.
Manual processing was operationally unfeasible. The investigation demanded a solution that could deliver rapid triage without compromising forensic soundness — because in international cases, evidentiary admissibility is non-negotiable.
Strategic Deployment: MD-PCM & MD-RED
The investigative team deployed MD-PCM (PC Messenger Extraction Tool), delivering three critical capabilities that transformed the trajectory of the case.
1.Forensic Soundness via Portable Execution
MD-PCM runs directly from an external SSD — no installation required. By minimizing changes to the host system’s registry and file system, it preserves the integrity of the source device from the first interaction. In high-profile international cases where chain of custody is scrutinized at every stage, this isn’t a convenience feature. It’s a requirement.
*Supported environments: Windows, macOS and forensic images (E01, DD, and more)
2.Auto-Detection of Multi-Accounts and Multi-Messengers
Manually searching for numerous accounts across different messengers on a single PC is a primary cause of investigative delay. MD-PCM automatically detects installed messenger applications, user IDs, and credentials. This automation slashes extraction time and eliminates the risk of human error in identifying hidden profiles.
3.Precision Triage:EliminatingNon-Probative Data
In high-volume cases, indiscriminate data collection is its own liability. MD-PCM targets specific messenger artifacts and decryption, filtering out non-probative data before it ever reaches the analyst. The resulting curated dataset was seamlessly ingested into MD-RED, enabling investigators to decrypt communications, visualize network hierarchies, and map the syndicate’s operational structure — in hours, not weeks.
Outcome: From Digital Mountain to Dismantled Syndicate
By compressing the time-to-evidence from weeks to hours, MD-PCM allowed the task force to act while intelligence was still operationally relevant. The case stands as a direct example of how purpose-built forensic tooling — not general-purpose solutions — determines outcomes in large-scale international crime investigation.
Is Your Team Facing a High-Volume Evidence Challenge?
Whether you’re managing a single complex case or coordinating across multiple jurisdictions, the MD-Series is engineered to ensure that investigative complexity never becomes an obstruction to justice.
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.
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
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.
Open the Health app and tap Steps.
Then tap the icon to manually input the data.
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.
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.
Account information of the sharing requester and the target recipient
Timestamp of the sharing request and acceptance
Current health data sharing status
3.Summary
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.
Apple Health app data is stored in the healthdb.sqlite and healthdb_secure.sqlite files located under /private/var/mobile/Library/Health/.
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.
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.
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/.
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.
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.datdad_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.
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.
Text entered on a mobile device can be stored and managed by keyboard apps to improve features such as auto-completion and data learning.
Japanese users typically input romaji or hiragana first, then convert it to katakana or kanji to finalize their text entry.
The Android Gboard app stores text input records and the timestamp of the last text entry in the history.db file located at /.mozc.
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.
The Android Samsung Keyboard app stores text input records in the njuserl.a and njuserl_uniq.a files at /app_omrondb/dicset/master.
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.
The iOS default keyboard app stores text input records at /private/var/Mobile/Library/Keyboard.
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.
As Unmanned Aerial Vehicles (UAVs) become more integrated into critical infrastructure and daily life, their role in criminal activities—from unauthorized surveillance to smuggling—has surged. For digital forensic practitioners, this presents a multi-layered challenge. Unlike traditional mobile devices, drones are subject to extreme physical stress, proprietary encryption, and volatile data environments.
Standard software-based extraction often fails when a drone is severely damaged or when the firmware is locked. To build a solid case, investigators need more than just a tool; they need a comprehensive methodological approach.
Beyond Software: A Holistic Training Ecosystem
GMDSOFT is proud to offer the industry’s most advanced Drone Forensics Training Course. We believe that true proficiency in UAV forensics cannot be achieved in a classroom alone. It requires a seamless integration of field operations, hardware engineering, and sophisticated data analysis.
1.Real-World Field Intelligence
Our training begins at our dedicated flight range. By operating a diverse fleet of drones in a controlled environment, investigators generate live telemetry data, GPS logs, and multimedia files. This “Field-to-Lab” approach ensures that trainees understand the operational behavior of the aircraft before they ever attempt to analyze the data.
2.Advanced Hardware Recovery & Chip-off Mastery
When a drone is recovered from a crash site or intentionally destroyed, the logic board is often the only remaining source of truth. We provide specialized training in Chip-off forensics, teaching investigators how to physically desolder flash memory chips and extract raw data directly from the hardware—a critical skill when standard interfaces are non-functional.
In an era of rapid manufacturer updates, staying current is not optional—it is a requirement. Our curriculum provides hands-on practice with the latest physical extraction and decryption methodologies specifically designed for high-priority DJI models.
Participants will engage in deep-dive labs focused on:
• Phantom 4 Series: Advanced, Pro, Pro V2.0, and RTK
• Matrice Series: Matrice 600 Pro
• Mini 3 Pro
• Flight controllers:Mateksys, SpeedyBee, Holybro
Rather than just running a tool, you will learn the underlying decryption logic and extraction workflows that ensure access to critical flight logs and media, even when standard forensic methods fail.
4. AI-Driven Analysis: Precision Intelligence at Scale
Modern drone investigations often involve overwhelming amounts of data. This training introduces investigators to AI-based analytical deep dives within MD-DRONE. You will learn how to:
• Pinpoint critical evidence, such as deleted flight paths or unauthorized communication logs, with forensic precision.
• Accelerate the investigation timeline without compromising the integrity of the evidence.
Tailored to Your Mission
We recognize that a “one-size-fits-all” approach does not work for specialized law enforcement units. Whether your focus is on counter-terrorism, narcotics, or border security, GMDSOFT provides fully customizable training schedules. We align our curriculum with your team’s specific mission requirements and technical proficiency levels.
Conclusion: Future-Proofing Your Unit
The gap between drone technology and forensic capability is widening. GMDSOFT is the only global provider that closes this gap by combining real-world piloting, deep-tier hardware forensics, and industry-leading software analysis into one cohesive program.
Equip your team with the expertise to turn complex aerial data into courtroom-ready evidence.
In the realm of digital forensics and crime or accident reconstruction, the difference between a conviction and an acquittal often hinges on the ability to quantify the “unquantifiable.” For years, investigators have relied on subjective witness testimonies or rime-intensive manual frame-analysis to estimate vehicle speeds. However, in modern litigation, “fast” is merely an opinion—speed is a factual necessity.
With the latest update to MD-VIDEO AI, we are proud to introduce our Speed Estimation feature. This feature is designed to move beyond visual observation, providing investigators with a scientifically grounded methodology to extract velocity from standard CCTV, dashcam, and surveillance footage.
Bridging the Gap Between Visuals and Actionable Data
Forensic video analysis often suffers from low frame rates, poor lighting, and extreme motion blur. These factors make manual speed calculation not only time-consuming but also prone to human error. MD-VIDEO AI’s Speed Estimation addresses these challenges through Ground-Plane Speed Mapping, allowing for precise velocity calculation of any object moving across a fixed surface.
Critical Investigative Scenarios:
• Crime/Accident Reconstruction & Braking Analysis: Determining the exact speed at the moment of impact is vital. Our tool allows investigators to calculate velocity changes and braking points, providing a clear picture of the events leading to a collision.
• Pedestrian Safety & Negligence Determination: In pedestrian-involved incidents, the “avoidability” of the accident is a primary legal question. By analyzing speed data, forensic experts can determine if a driver was adhering to speed limits and whether they had sufficient time to react.
• Hit-and-Run Investigations & Establishing Intent: One of the most challenging aspects of a hit-and-run is proving “intent to flee.” By quantifying a suspect’s acceleration immediately following an impact, MD-VIDEO AI helps investigators provide evidence of deliberate evasion.
A Comprehensive Video Forensic Ecosystem: Supporting Global Identification
While speed provides the context of a crime, identification provides the subject. MD-VIDEO AI goes beyond quantification. Our industry-leading Number Plate Restoration engine works alongside our analytical tools to resolve high-speed motion blur that typically renders identifiers unreadable.
We are proud to announce that our AI models are currently supporting all 50 U.S. state number plate designs. Furthermore, our commitment to global justice means we provide comprehensive coverage for over 50 countries in Europe, Asia, Latin America and Africa with specialized vehicle classes, including motorcycles.
Conclusion: The Future of Evidence is Precise
The introduction of Speed Estimation marks a significant leap forward in video forensics. By integrating automated velocity calculation with high-fidelity number plate restoration, MD-VIDEO AI provides a unified environment where investigators can build cases based on hard data rather than estimates.
When every mile per hour—and every pixel—matters to the truth, trust the precision and integrity of MD-VIDEO AI.
Interested in integrating MD-VIDEO AI into your investigation workflow? Contact our Global Sales Team to schedule a technical briefing or request a trial license.
In the fast-paced world of digital forensics, the challenge isn’t just about collecting data—it’s about the speed of insight and the integrity of evidence. Investigators are constantly battling increasing encryption, massive data volumes, and the urgent need for real-time field decisions.
At GMDSOFT, we understand that every minute saved in the lab or the field is a step closer to justice. Our Q4 2025 updates are designed to alleviate these pressures by enhancing global compatibility and introducing groundbreaking field-triage capabilities.
Key Highlights of the Q4 Release:
📱 MD-NEXT: Expanded Mobile Coverage
• Broad Compatibility: Now supporting 200 new models from 27 different manufacturers.
• Security Bypass: Enhanced iOS backup password removal to streamline data extraction.
📈 MD-RED: Advanced App Analysis
• Social Media Intelligence: Added support for 12 Android and 6 iOS apps, including deep analysis of WhatsApp read receipts and timestamps.
• Modern Assets: Improved NFT log analysis and recovery of deleted files.
• Global Reach: Optimized WeChat decryption for iOS backup data.
🔍 MD-LIVE & MD-CLOUD
• Precision Search: Support for alphabetic ligatures and compatible character searches.
• Workflow Automation: New Auto Scroll Capture for Android.
• Compliance: Clear guidance for iCloud accounts that haven’t accepted updated Terms of Service.
🎥 MD-VIDEO AI: Global Plate Restoration
• AI Speed Estimation: A crucial tool for accident reconstruction and incident analysis.
• Global Expansion: Massive expansion of number plate restoration capabilities covering regions across the US (Delaware, D.C., Wyoming, etc.), Europe, and Asia-Pacific. We won’t stop until we provide seamless restoration support for every plate in the world.
The Power of Real-Time Decision Making: Block Hash
While our Q4 release brings immediate power to your lab, we are excited to share a glimpse of what’s coming next to the front lines. We are currently developing the ‘Block Hash’ feature—a strategic addition designed for the high-pressure environment of on-site investigations.
We recognize that field investigators often need to make split-second decisions regarding the seizure of devices. This powerful feature will allow for rapid scanning and immediate determination of evidentiary value. This upcoming innovation will ensure that your critical resources are focused exactly where they need to be, significantly reducing the time spent on non-relevant data during the initial triage phase. Stay tuned for this game-changing update in our upcoming feature.
Elevate Your Investigative Capabilities
The landscape of digital crime is evolving. Your tools should evolve faster. These updates are more than just features; they are a commitment to your mission of uncovering the truth.
Ready to streamline your investigations? Explore the full release note and see how these updates can transform your workflow.
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
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’.
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.
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) fileMAC 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
Android devices provide a ‘Recent Apps’ feature that allows users to view recently used apps and relaunch them easily.
Task snapshots serve as Android’s internal infrastructure for storing the screens and metadata of recently used apps.
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/.
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.
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.
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/.
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.
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.
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:
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.
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.
*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.
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.
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 
icon to manually input the data.
icon to save.
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’.
