The Architecture: DCIM vs. PhotoData

To comprehend the 5005 artifact, one must understand the iOS bifurcated storage model. The DCIM directory serves as the ingest point for "Master" assets (full-resolution HEIC/JPGs). Parallel to this is the PhotoData directory, the operational brain of the library that stores lightweight resources required to render the UI.

The 5005.JPG resides in the Thumbnails/V2 directory. It is generated by the assetsd daemon during ingestion. Unlike the Master file, the 5005.JPG is a "clean" visual representation that typically lacks EXIF data like GPS or camera model.

Database Forensics: The Photos.sqlite Connection

The 5005 artifact is tracked in the Photos.sqlite database within the ZINTERNALRESOURCE table. This table tracks all files associated with an asset except the original master.

Forensic examiners can validate these files using specific "Recipe IDs":

Recipe ID	Asset Type	Description
65743	Photo	Associated with the 5005.JPG or 5003.JPG thumbnail for standard photos.
131081	Video	Associated with the 5005.JPG poster frame for video assets.

A notable anomaly is that these resources often have a NULL value in the ZFILEID column, implying the system relies on the hardcoded path convention within the Thumbnails/V2 directory structure rather than a unique file ID.

The "Optimize iPhone Storage" Factor

When "Optimize iPhone Storage" is enabled, the system aggressively manages disk space by uploading the Master to iCloud and deleting the local copy in DCIM. However, the 5005.JPG is retained.

Forensic Reality: A device may appear sparse in the DCIM folder but contain thousands of 5005 thumbnails. Finding a 5005 without a corresponding Master does not necessarily mean the user deleted the photo; it often means it was offloaded. To distinguish between "Offloaded" and "Deleted," verify if the record exists in the ZGENERICASSET table with a flag indicating a "Cloud Master".

Advanced Analysis: Mutations and AirDrop

Mutations (Edits): When a user edits a photo, iOS saves the result in the Mutations directory. The system generates a specific 5005 thumbnail for this edited version. Finding a 5005 in the Mutations path proves the user edited the image, whereas a standard DCIM 5005 proves they captured or saved it.

AirDrop: When a file is received via AirDrop, a 5005 thumbnail is generated. If the user deletes the photo, the 5005 may persist. Critically, the timestamp of the AirDrop 5005 creation will match the time of transfer, not the time the photo was originally taken, allowing for precise timeline reconstruction.

Why ".=5005"?

The syntax .=5005 or IMG_xxxx.HEIC.=5005 is often an artifact of forensic reporting tools (like Cellebrite or Oxygen) trying to flatten the nested directory structure. The actual file on the file system is simply named 5005.JPG.

Close

The Fundamentals: Why "GPS" Isn't Enough

The foundation of modern mobile location is the Global Navigation Satellite System (GNSS). However, a standard GPS receiver faces a critical limitation: the "Cold Start." To calculate position, the receiver needs the Ephemeris (precise orbital data). Downloading this from the satellite at the standard 50 bits per second can take upwards of 12.5 minutes.

To solve this, mobile devices use Assisted GPS (A-GPS). By leveraging the cellular connection, the device downloads the ephemeris data from an assistance server (like Google's SUPL), reducing the lock time from minutes to seconds.

Forensic Impact: MS-Based vs. MS-Assisted

Understanding the operating mode of the A-GPS system is critical for interpreting missing data.

Mode	Calculation Location	Forensic Implication
MS-Based (Mobile Station Based)	On Device	Standard for smartphones. Artifacts are stored locally in caches because the phone calculates its own position.
MS-Assisted (Mobile Station Assisted)	On Server	The phone captures a signal snapshot and uploads it. The server calculates the position. If the device loses cell connection, it may cease logging locations entirely.

Sensor Fusion and the Kalman Filter

Modern OSs use a "Sensor Fusion" engine to determine location, prioritizing sources based on power and accuracy. Sources include GNSS (3-15m accuracy), Wi-Fi Positioning (20-50m), and Cellular Multilateration (500m+).

Raw data is noisy. To present a smooth path, devices use the Kalman Filter. This recursive algorithm operates in a "Predict-Update" cycle. It predicts the next location based on velocity and accelerometer data (Dead Reckoning) and updates that prediction with new sensor measurements.

Forensic Insight: Coordinates found in databases like Cache.sqlite are often computed estimates, not raw sensor readings. A smooth path proves the algorithm worked, not necessarily that the GPS signal was perfect.

The "Teleportation" Artifact

A common anomaly we see is the "Grid Snap" or teleportation artifact. This happens when a device deep inside a building detects a single Wi-Fi router or Cell Tower. The device reports the registered location of the infrastructure as its own position.

Visual Indicator: If a device appears to "teleport" instantly to a location and hover there, check the Horizontal Accuracy. A high value (e.g., 65m or 500m) often indicates the device is merely in the service area of that infrastructure, not necessarily at that exact point.

iOS Location Artifacts

consolidated.db: Historically significant, this file acts as a cache for locationd, storing the locations of infrastructure (Cell/Wi-Fi) the device has detected.

cache_encryptedB.db: The modern crowd-sourcing cache. When the device has a solid GPS fix, it "harvests" nearby Wi-Fi and Cell IDs to report back to Apple. This file is encrypted and requires a Full File System extraction.

Cache.sqlite (The Crown Jewel): Managed by the routined process for "Significant Locations." It contains the ZRTCLLOCATIONMO table with raw breadcrumbs and the ZRTCLVISITMO table which aggregates points into "Visits".

Android: The Shift to On-Device Storage

Google has aggressively moved "Timeline" data from the cloud to the device. This data is now stored in LevelDB databases and serialized Protobuf files in paths like /data/data/com.google.android.gms/databases/.

• app_semanticlocation_rawsignal_db: Contains raw Wi-Fi scans and GPS coordinates in LevelDB format.
• app_semanticlocation_odlh_cache: Stores "Activity Segments" (Walking, Driving) in Protobuf format.

The Find My Network: Offline Finding

The Find My network decouples the "Locator" from the "Location Source," allowing devices to be found even when offline.

The Mechanism: The target device generates a P-224 Elliptic Curve key pair and beacons the Public Key via Bluetooth Low Energy (BLE). Nearby "Finder" devices encrypt their own location using this key and upload it to Apple.

The "Split Key" Payload: To fit the 28-byte key into a restricted BLE payload, Apple repurposes the Bluetooth MAC address to carry the first 6 bytes of the key, putting the remaining 22 bytes in the Manufacturer Data. This MAC address rotates every 15 minutes to prevent stalking.

Close

Introduction: Dynamic vs. Static Analysis

Pattern of Life analysis is dynamic. It establishes the "ground truth" of a user's physical and digital existence. In legal contexts, these artifacts are frequently utilized to corroborate alibis or place suspects at crime scenes. However, distinguishing between system-generated patterns and user-generated patterns is the central challenge. A device may download data or process locations without human interaction.

iOS: The Architecture of Habit

CoreDuet and KnowledgeC.db

While newer iOS versions use Biome, knowledgeC.db remains a vital source. The core table ZOBJECT contains raw event logs.

Column Name	Description
ZSTREAMNAME	The category of event (e.g., /app/inFocus, /device/isLocked).
ZSTARTDATE	Start time in Mac Absolute Time.
ZVALUESTRING	Contextual data like Bundle IDs.

Critical Streams:

• /app/inFocus: Records when an app is the primary element on the screen, proving active engagement.
• /device/isLocked & /device/isPluggedIn: Frames the user's day, indicating periods of interaction and charging habits.
• /audio/outputRoute: Can place a user in a vehicle (CarPlay) or on headphones.

The Biome Revolution: SEGB Files

Biome stores data in SEGB (Segmented Buffer) files, which are high-performance, append-only binary logs. Unlike SQLite, these require parsing custom headers. The SEGB v2 header is 32 bytes, starting with the "SEGB" magic signature and containing the entry count and creation time.

Key Biome Streams:

• Text Input (_DKEvent.Text.InputSession): Logs the session of typing, proving the user was actively composing.
• User Notifications (UserNotifications.stream): Captures the text of notifications pushed to the lock screen. Even if a message is deleted from the app, the notification log may persist.
• App Intents (App.Intents): Captures high-level intentions like "Start Workout" or "Navigate Home".

PowerLog: The Unintentional Surveillance

CurrentPowerlog.PLSQL is a diagnostic tool that inadvertently creates a minute-by-minute diary.

Table Name	Forensic Utility
PLApplicationAgent_EventForward_Application	Determines if an app was truly active or just refreshing in background.
PLScreenState_EventForward_ScreenState	Logs Screen On/Off status. The most basic indicator of user interaction.
PLBatteryAgent_EventBackward_Battery	Rapid depletion can indicate heavy usage like gaming or GPS.

Android: The Fragmented Narrative

UsageStats: The System Ledger

Located in /data/system/usagestats/, these logs track app visibility. Since Android 10, they use Protocol Buffers. Understanding event codes is non-negotiable:

• Code 1 (MOVE_TO_FOREGROUND): App became visible.
• Code 18 (KEYGUARD_HIDDEN): Device was unlocked.
• Code 10 (NOTIFICATION_SEEN): Notification shade pulled down.

Analysis Nuance: An app can move to the foreground without user input (e.g., receiving a call). Examiners must look for KEYGUARD_HIDDEN immediately preceding usage to confirm user interaction.

Digital Wellbeing: The User's Mirror

Digital Wellbeing collects granular usage data to help users manage screen time. The app_usage database contains a notifications table that uniquely tracks if a notification was posted versus tapped. This allows us to prove if a user ignored a message or interacted with it.

Activity Recognition

The Activity Recognition API classifies user movement. It can determine if a user is IN_VEHICLE, ON_BICYCLE, WALKING, RUNNING, or STILL. In a hit-and-run investigation, a transition from STILL to WALKING to IN_VEHICLE can corroborate movement independent of GPS.

Health and Biometrics

Health data provides the strongest link between the device and the human.

• iOS Steps & Flights: A cessation of steps followed by a device lock suggests sleep.
• Apple Watch: Provides "Wrist Detection." If a watch is "off wrist" during a crime, it complicates attempts to place the suspect at the scene using the watch's location.

Interpretative Framework: The "Zombie Phone"

A common defense is the "Zombie Phone" scenario—a device that appears active but was updating itself. To resolve this, compare PLScreenState (Screen On/Off) with the active process. If the screen is "Off" but data is moving, it is likely automated.

Case Study: State v. Nidjia Dean Nicks

In this case, the PoL analysis overturned a wrongful accusation. The suspect was accused of making threatening calls, but a "chip-off" extraction of the victim's phone revealed the device was not in a state to receive calls (powered off/disconnected) at the alleged times. The device's Pattern of Life refuted the witness testimony.

Conclusion

The future of mobile forensics lies in the ability to surgically extract these binary scraps—the SEGB headers and Protobuf payloads. We must maintain absolute technical precision in distinguishing the automated heartbeat of the operating system from the conscious actions of the user.

Close

A more "forensically sound" approach to digital forensics seems like these words should be flipped: "Verify, and then trust".

Understanding Validation vs. Verification

Validation and verification are often spoken by examiners as if they are the same thing. My thought process has always been, you validate the PROCESS and you verify the RESULTS. Those are two separate things.

Validation: Proving Your Process Works

Validation answers a fundamental question: Does the tool or method actually do what it claims to do?

This isn't just about the software/hardware, it's about your entire process. Whether you're using commercial acquistition tools such as Cellebrite, Magnet or UFDAE or open-source parsing tools such as ArtEX or any of the wonderful LEAPPS, validation is a MUST:

Think of validation as stress-testing your foundation. You wouldn't build a house without first confirming your concrete can bear the load. Similarly, you shouldn't present forensic findings without first proving your methodology is sound.

Verification: Confirming What You're Seeing

Verification addresses a different question: Is this action or thing actually what I think it is?

Here's where many examiners make mistakes. For example, an examiner sees the red "X" next to a text message in their commerical tool of choice and concludes that message was marked for deletion by the user. Another example, an examiner notices a timestamp and assumes it represents when an event occurred and that the timestamp is stored in the database in UTC. The examiner then converts the timestamp to their timezone. Lets say the examiner changed the timestamp to UTC-4. But, what if the artifact was actually stored in the database in local time? With the conversion to UTC-4, that timestamp is no longer accurate. That examienr is making an interpretation without understanding how the data is stored on the device. Your forensic tool is making interpretations, and interpretations can be wrong.

Real-World Application: The Deleted Message Example

Let's examine this common scenario further that illustrates why verification matters:

Your tool shows a text message with a red deletion indicator. Most examiners would document this as "deleted message recovered." But what if that's not accurate?

The verification process should look like this:

1. Locate the source data - Find the actual database or file containing this message
2. Examine the raw data - Open the SQLite database or binary file outside the commerical tool and make sure you see the entire picture. Commerical tools don't parse everything in a database or other data struture.
3. Understand the schema and flags of the database - Learn how the messaging app stores data.
4. Cross reference with test data - Create your own messages on a test device. Now, delete them and run various other scenarios, document and compare.

You might discover that the "X" actually indicates something entirely different. What if the artifact is actually from the Write Ahead Log (-Wal) and was just not written to the main database yet? Without verification, you could be presenting evidence incorrectly.

Building Your Verification Toolbox

Test Devices: A HUGE part of the process

One of the most valuable resources for the verification process is a collection of test devices. Here's how to build your inventory:

Sources for test devices:

• Evidence and property rooms (devices past their retention period)
• Local jails(phones that were confiscated)
• Department upgrades (older agency phones)
• Your old phone

Setting up your test environment:

• Use devices running the same OS versions as your cases IF you can.
• Install the same apps you commonly see on devices you examine. Install apps that you are interested in seeing how it stores data.
• Create controlled scenarios (send messages, make calls, install/delete stuff)
• Document everything meticulously

The Reverse Engineering Approach

When you encounter unfamiliar data structures/flags or surprising results, have a reverse engineering mindset:

1. Repeat the action - Perform the same behavior on your test device as what you expect the evidence device did.
2. Extract and compare - Extract the data using the same acquistition tools you use everyday in your lab. Dont' deviate initially from what you normally do.
3. Examine at the hex level - Look at the raw data in a hex viewer of choice when necessary
4. Map the relationships/joins - Understand how different artifacts connect or join in the data structure

This process transforms you from someone who just reports what the tool outputs, to someone who truly understands the evidence.

Courtroom Confidence: Why This Matters

When you testify, you're not just presenting what your tool reported, you're staking your professional reputation on the accuracy of your findings. Defense attorneys are increasingly sophisticated about digital evidence, and they will challenge your methodology. And guess what, THEY SHOULD!!! The results you provide have the ability to change a lot of lives. Our job is to get it right, so the attorneys, judge and jury can form their own opinions based on fact. We are not in the business of "forensically guessing" or "assuming".

Questions you need to answer confidently:

• How do you know this timestamp is accurate?
• What does this flag actually mean in the app's database?
• Could there be another explanation for this artifact?
• Have you tested this interpretation on other devices?

Examiners who follow the "verify, and then trust" approach can answer these questions because they've done the work to understand their evidence at a fundamental level.

Practical Implementation: A Verification Checklist

For every significant finding in your cases, ask yourself:

If you can't check all these boxes, you're not ready to trust that finding.

Here is a checklist created by the wonderful Jessica Hyde (Founder & Owner of Hexorida.com) and myself to start you thinking about this critical process. Peer Review Checklist

The Bottom Line: Your Job is Discovering TRUTH Through Data!

Remember this fundamental truth also: Your tools don't testify, you do.

When you take the witness stand, you're not just representing the output of a Cellebrite or Magnet report, you're presenting your professional analysis of digital evidence. That analysis must be built on a foundation of verified understanding, not assumed trust.

The "verify, and then trust" approach demands more work upfront, but it pays dividends in case quality, courtroom confidence, and professional credibility. In a field where the stakes are often someone's freedom or justice for victims, that extra effort isn't just worthwhile, it's an absolute MUST.

Validate your process. Verify your results. Then and only then, trust what you're presenting. Your cases, your testimony, and your professional reputation depend on getting this order right. Ask anyone on my forensics team at RCSD (Caitlin, Michael, Jordan, Brian or Trevor), and they'll tell you, this way is the only way!

Close

At IACIS's 35th anniversary training event in Orlando, FL, I had the chance to attend one of the most resourceful classes I’ve taken in a while. The AMDF course dives deep into mobile data structures and teaches you how to extract, examine, and interpret core data structre files directly, without relying on commercial tools at all.

We explored XML and binary Plists, ABX files, REALM databases, LevelDB, JSON, SEGB, and Protobuf. These are formats that store critical evidence in modern smartphones, but are often ignored or note fully supported by your commerical tools. Some some, we used Python to parse and extract data manually, building a real understanding of what the device is telling us through the individual data sources.

Why Go Beyond the GUI?

Many tools don’t support all (or even most) app data, especially when app developers use varying storage structures. Knowing how to go beyond the GUI isn’t just helpful, it’s essential. Too much evidence goes unnoticed simply because examiners didn’t know what to look for or where to look. Much of the "smoking gun" evidence is found in unsupported apps or unsupported data structures.

Critical Takeaways

• Understand the storage structure before trusting the tool’s interpretation.
• Use open source tools and scripts to verify and confirm your findings.
• Never assume the tool is parsing every relevant data store. Check for yourself. Every case is different. What if there's exculpatory evidence in the data that you miss?

Courses like AMDF are a reminder that no tool can replace examiner knowledge. It’s not just about acquisition, it’s about comprehension. If you’re relying solely on automated parsing, you’re doing yourself and your cases a disservice.

Level Up with Purpose

This course, and others like it (Data Structures course through Hexorida is also GREAT), should be part of every serious examiner’s training path in the beginning. They force you to get hands-on with the data, to ask questions, to test, and to verify. That’s how you move from being a user of tools to becoming a true forensic examiner.

If you’re serious about mastering mobile forensics, push yourself. Courses like these are how you grow beyond the basics and learn to uncover the story the device is truly telling.

Close