Skip to content

CH7: Timestamps and File Carving

Introduction

In the realm of criminal investigations, physical evidence often answers the "who" and the "what." Fingerprints identify a suspect; a recovered weapon identifies the means. However, in the digital world, the "when" is frequently the most critical element of the case. A text message threatening a victim is only incriminating if it was sent before the crime occurred. A GPS location placing a suspect at the scene is only relevant if the timestamp aligns with the moment the crime was committed.

Mobile devices are essentially relentless timekeepers. Every action—sending a message, connecting to Wi-Fi, snapping a photo, or even locking the screen—generates a temporal footprint. For a forensic examiner, the ability to interpret these footprints is the difference between a disjointed collection of data and a coherent, court-admissible narrative.

Furthermore, digital evidence is fragile. When files are "deleted" by a user, the data often remains on the physical storage medium, hidden from the operating system but visible to the forensic expert. This chapter explores the dual disciplines of Temporal Analysis (interpreting time) and File Carving (recovering "deleted" data based on raw binary structures), providing you with the skills to reconstruct events that a suspect believed were erased forever.

Learning Objectives

By the end of this chapter, you will be able to:

  • Define the critical role of timestamps in establishing accurate forensic timelines and verifying alibis.
  • Identify and Decode common epoch time formats used in mobile operating systems, including Unix, Windows FILETIME, Mac Absolute Time, and GPS Time.
  • Understand the fundamental concept of file carving and "data persistence" in unallocated space.
  • Locate file headers (magic numbers) and footers in hexadecimal format to identify file types without metadata.
  • Define "file offsets" and explain their function as digital addresses within a storage medium.
  • Perform manual data recovery by identifying start and end offsets and extracting binary data using a Hex Editor.

7.1 The Forensic Importance of Time

Time is the backbone of any investigation. Without an accurate timeline, evidence is merely a pile of disjointed facts. In mobile forensics, time serves three primary functions: Corroboration, Sequencing, and Normalization.

The "Alibi" and Corroboration

Suspects often provide alibis that rely heavily on time. A suspect might claim, "I was asleep at home when the robbery happened at 2:00 AM." If a forensic examination of their phone reveals a "step count" incrementing in the health app at 2:05 AM, or a text message sent at 2:10 AM, the digital timeline directly contradicts the physical alibi. Conversely, reliable timestamps can exonerate an innocent person by proving their device was active in a completely different location at the time of the crime.

Sequencing Events

Establishing the order of events (sequencing) is vital for proving intent. Consider a vehicular manslaughter case involving texting while driving.

  • Scenario A: The driver receives a text at 1:00:00 PM. The crash occurs at 1:00:05 PM. This suggests distraction.
  • Scenario B: The crash occurs at 1:00:00 PM. The driver sends a text "I just hit someone" at 1:00:05 PM.

In both scenarios, the data (a crash and a text) is identical. Only the precise sequence of timestamps reveals the truth.

The Problem with "Local Time"

Humans perceive time relative to their location (e.g., "3:00 PM Eastern Standard Time"). Computers, however, must function globally. If a suspect flies from New York (EST) to California (PST), their phone's clock updates visually. However, if the forensic tool captures the "local time" displayed on the screen, the investigation faces a crisis of ambiguity.

Forensic Standard: Always normalize timestamps to Coordinated Universal Time (UTC). UTC is the primary time standard by which the world regulates clocks and time. It does not observe Daylight Saving Time (DST) and provides a constant, unambiguous reference point. By converting all evidence to UTC, an investigator can merge data from a server in London, a phone in California, and a router in Japan into a single, flawless timeline.

7.2 Deep Dive into Digital Time (Epochs)

To a computer, "November 12, 2023" is a meaningless string of characters. Computers process time as mathematics, not calendar dates. They store time as a simple integer—a counter that ticks upward from a specific, arbitrary starting point in history.

This starting point is called an Epoch.

Think of an Epoch as a stopwatch that was started on a specific date in the past. Every file timestamp is simply the number of "ticks" (seconds, milliseconds, or nanoseconds) that have passed since that stopwatch began. To decode a timestamp, you must know three things:

  1. The Epoch Date: When did the stopwatch start?
  2. The Unit of Measure: Is it counting seconds, microseconds, or nanoseconds?
  3. The Endianness: In what order are the bytes stored (Big Endian vs. Little Endian)?

Below are the most critical Epochs you will encounter in mobile forensics.

1. Unix Epoch (POSIX Time)

  • Origin Date: January 1, 1970, 00:00:00 UTC
  • Unit: Seconds (or Milliseconds)
  • Primary Usage: Android, Linux, iOS (internal system files), and most Internet servers.

This is the industry standard for mobile forensics. Because Android is built on the Linux kernel, almost every artifact on an Android device (SMS, call logs, app usage) is stored in Unix time.

  • Example: A raw value of 1672531200 represents Sunday, January 1, 2023 12:00:00 AM.

Note

While standard Unix time counts in seconds, many modern apps (like WhatsApp or Telegram) require higher precision and use Unix Milliseconds (1/1,000th of a second). If you see a timestamp that is 13 digits long instead of 10, it is likely Unix Milliseconds.

2. Windows FILETIME

  • Origin Date: January 1, 1601, 00:00:00 UTC
  • Unit: 100-Nanosecond Intervals
  • Primary Usage: Windows Phone, NTFS file systems, Microsoft Office documents, and artifacts synced from Windows PCs.

Why 1601? This year was chosen to make the math for the Gregorian calendar cycle (which repeats every 400 years) easier for early Microsoft engineers. Because this format counts in such tiny intervals (nanoseconds), the raw values are massive, typically 18 digits long. * Example: 133170528000000000

3. Mac Absolute Time (Cocoa Core Data)

  • Origin Date: January 1, 2001, 00:00:00 UTC
  • Unit: Seconds (often with decimal precision)
  • Primary Usage: iOS, macOS, Safari, and Apple-native applications (iMessage, Notes, Photos).

This is the standard for modern Apple devices. It is crucial not to confuse this with Unix time. If you interpret a Mac Absolute timestamp as a Unix timestamp, the date will be off by exactly 31 years (the difference between 1970 and 2001). * Example: A value of 694267200 represents Sunday, January 1, 2023.

4. Google Chrome / WebKit Time

  • Origin Date: January 1, 1601, 00:00:00 UTC
  • Unit: Microseconds
  • Primary Usage: Google Chrome history, WebKit browsers, and many Android web-based apps.

This format shares the same origin date as Windows FILETIME (1601) but counts in microseconds (millionths of a second) rather than nanoseconds. This is frequently found when analyzing web browser history on Android devices.

5. GPS Time

  • Origin Date: January 6, 1980, 00:00:00 UTC
  • Unit: Weeks and Seconds
  • Primary Usage: GPS chips, navigation logs, and geolocation metadata.

GPS time is unique because it does not adjust for "leap seconds." Over the decades, the Earth's rotation has slowed slightly, and UTC adds leap seconds to compensate. GPS time ignores these corrections. Consequently, raw GPS time is currently ahead of UTC by roughly 18 seconds. Forensic tools usually handle this conversion automatically, but manual verification requires subtracting these leap seconds to match UTC.

Comparison Table: Decoding the "Stopwatch"

Format Origin (Epoch) Resolution Common Device / OS
Unix / POSIX Jan 1, 1970 Seconds Android, Linux, General
Unix (Ms) Jan 1, 1970 Milliseconds Android Apps (WhatsApp)
Mac Absolute Jan 1, 2001 Seconds iOS (Modern), macOS
Windows FILETIME Jan 1, 1601 100-Nanosec Windows, MS Office, NTFS
Chrome / WebKit Jan 1, 1601 Microseconds Chrome, Android Web
GPS Time Jan 6, 1980 Weeks + Secs GPS Data, Exif Geotags

Forensic Tip: When you encounter a raw number in a database and don't know the format, look at the length of the number.

  • 9-10 digits: Likely Unix Seconds or Mac Absolute.
  • 13 digits: Likely Unix Milliseconds.
  • 17-18 digits: Likely Windows FILETIME or Chrome Time.

7.3 Tools & Techniques for Decoding Time

While it is theoretically possible to manually calculate a date from a raw timestamp using a calculator and the specific epoch formula, it is inefficient and prone to human error. In a high-stakes investigation, a simple math error could invalidate your timeline or lead to a wrongful conclusion. Therefore, forensic examiners rely on validated tools to perform these conversions instantly and accurately.

Decoding Tools

Several free and robust tools are standard in the mobile forensics industry. You should become proficient with at least one of the following:

  • DCode (Digital Detective)

    • Overview: DCode is one of the premier free tools for timestamp decoding in the forensic community. It is a standalone software application designed specifically for converting raw data values into human-readable dates.
    • Key Features:
      • Wide Format Support: It supports dozens of data types, including Unix, Windows FILETIME, HFS+, Mac Absolute, and even obscure formats like "Sony Ericsson" or "Symbian."
      • Time Zone Adjustment: A critical feature for validation. DCode allows you to input a raw value and immediately see what that time would look like in UTC, Local Time, or any specific Time Zone offset you choose.
      • Batch Processing: You can load a list of raw values to convert them simultaneously rather than one by one.

  • CyberChef (GCHQ)

    • Overview: Often called the "Cyber Swiss Army Knife," this web-based tool developed by GCHQ (the UK's intelligence agency) allows you to manipulate data in complex ways using a "recipe" based interface.
    • Key Features:
      • Drag-and-Drop Recipes: You build a workflow by dragging "operations" from the left panel. To decode a timestamp, you search for "From UNIX Timestamp" and drag it into your recipe.
      • Versatility: CyberChef is not limited to time. If you find a timestamp that is also encoded in Base64 or Hex, you can add a "From Base64" operation before the timestamp decoding operation, allowing you to clean and decode data in a single step.
      • Live Preview: As you type or paste data into the "Input" box, the "Output" box updates in real-time.

Note

While it is indeed a "cyber swiss army knife", CyberChef does not offer as many options of decoding epoch timestamps as DCode or EpochConverter tool below. You are limited to only decoding UNIX and Windows FILETIME timestamps.

  • EpochConverter

    • Overview: A lightweight, web-based utility that is perfect for quick, "on-the-fly" validations when you don't have access to installed forensic software.
    • Key Features:
      • Instant Conversion: The homepage immediately displays the current Unix epoch time. You can paste any timestamp into the search bar to convert it instantly to a human-readable format (GMT and Local).
      • Batch Convert: It offers a specific "Batch Convert" tool where you can paste a column of mixed timestamps (e.g., from an Excel spreadsheet) and it will generate a clean table of converted dates.
      • Developer References: The site also provides the code snippets for how different programming languages (Python, Java, C++) handle time, which is excellent for understanding the "under the hood" mechanics.
      • Timestamp Options: The most noteable modern timestamps that you may decode with EpochConverter are UNIX, Windows FILETIME, WebKit/Chrome, and Cocoa Core (Mac Absolute Time).

Tip

If you need to decode more obscure or legacy timestamps, DCode is the best tool for the job that gives you many options.

  • Forensic Suites (Cellebrite / Magnet / Oxygen)

    • Overview: Modern commercial tools automatically parse timestamps during the ingestion phase. When you look at a "Chat View" in Cellebrite, the tool has already converted the raw SQL integer into a date for you.
    • Warning: Never blindly trust the automated tool. If a date looks suspicious (e.g., a text message dated 1969 or 2040), the tool may have misinterpreted the epoch. Always verify "impossible" dates by cross-referencing the raw hex/integer value with one of the manual tools listed above.

Activity

Try out this hands-on activity to decode various timestamps using EpochConverter and/or CyberChef.

Real-World Scenario: The "Alibi" Conflict

Consider a case involving a hit-and-run that occurred at 11:45 PM UTC.

  • Suspect's Statement: "I was asleep in bed from 10:00 PM until 7:00 AM. My phone was on the nightstand."
  • Forensic Artifact: You extract the database from the suspect's health application (health_data.db).
  • Analysis: You find a series of records with Unix timestamps ranging from 1698795600 to 1698796200.
  • Decoding: Using DCode, you translate these timestamps. They correspond to 11:40 PM UTC to 11:50 PM UTC.
  • Context: The associated column for "Step Count" shows 450 steps taken during this 10-minute window.
  • Conclusion: The digital timeline (steps taken at 11:45 PM) directly contradicts the physical alibi (asleep in bed). The suspect's phone was moving exactly when the crime occurred.

7.4 Introduction to File Carving

When a user "deletes" a file, or when a storage device is formatted, the data does not simply vanish. To understand why, we must understand how file systems manage space.

Imagine a massive library. To find a book, you look at the card catalog. The card tells you exactly which shelf (address) the book resides on.

  • The File System (FAT/MFT): This is the card catalog. It tracks where every file is located on the disk.
  • The Data: This is the book itself, sitting on the shelf.

When you delete a file on a computer or mobile device, the operating system does not go to the shelf and burn the book. Instead, it simply rips up the card in the catalog. It marks that shelf space as "Unallocated," effectively telling the system, "This space is now free to use for new books."

Until a new file is written onto that specific shelf (overwriting the old one), the original book (the data) sits there, fully intact, but invisible to the operating system's file browser.

Unallocated Space

Unallocated Space is the area of a storage medium that is not currently assigned to an active file. This is the "gold mine" of digital forensics. It is here that we find the remnants of deleted photos, text messages, and web history.

File Carving is the process of ignoring the "card catalog" entirely and walking through the library shelves one by one, looking for books. In technical terms, it is the recovery of files based on their content and structure (raw binary data) rather than their file system metadata.

Relevance to Digital Media Forensics

In the context of this course, file carving is particularly relevant to removable media and external storage. While modern internal phone storage is often encrypted (which scrambles the "books" on the shelf, making carving impossible without the key), you will frequently encounter the need for carving in these scenarios:

  1. microSD Cards: Many Android devices, drones, and dashcams use removable microSD cards for storage. These are rarely encrypted by default. If a suspect panics and "formats" their SD card to hide photos of a crime scene, the file system is reset, but the photos likely remain in the unallocated space, waiting to be carved.
  2. DCIM Folders: Digital cameras and older smartphones store images in a standard directory structure. Carving is highly effective here because media files (JPEGs, MP4s) have very distinct, recognizable binary signatures.
  3. SQLite "Free Lists": Even within the internal database of a modern app (like WhatsApp), when a message is deleted, it is often moved to a "free list" within the database file itself. Carving strictly within the .db file can recover these individual deleted messages.

In the next section, we will learn how to identify these files by looking at their raw "DNA"—their Hex Signatures.

7.5 The Anatomy of a File (Hex Signatures)

To the human eye, a file is an icon on a desktop. To the computer, a file is simply a stream of bytes. But how does the computer know that one stream of bytes is a photograph and another is a Word document?

It relies on File Signatures, often called "Magic Numbers."

These signatures are specific sequences of bytes located at the very beginning (Header) and very end (Footer) of a file. They act like bookends. When an operating system opens a file, it looks at the Header to determine which application to use. When it reads the file, it looks for the Footer to know where the data stops.

1. The Header (Start of File)

The Header is the digital "Hello." It announces the file type.

  • JPEG Image: FF D8
  • PNG Image: 89 50 4E 47
  • ZIP Archive (and Office Docs): 50 4B 03 04 (This stands for "PK", the initials of Phil Katz, the creator of the ZIP format).
  • PDF Document: 25 50 44 46 (%PDF)

Forensic Application: If a suspect changes a file extension from incriminating_photo.jpg to homework.doc to hide it, the operating system might be fooled, but a forensic tool (or examiner) looking at the Hex Header will see FF D8 and immediately know it is actually an image.

The Footer is the digital "Goodbye." It tells the system that the file is complete.

  • JPEG Image: FF D9
  • PNG Image: 49 45 4E 44 AE 42 60 82

Forensic Application: Carving relies entirely on finding these bookends. If we find a Header (FF D8) in unallocated space, we know a JPEG starts there. We then scan forward until we find the Footer (FF D9). Everything between those two points is the recovered image.

3. Offsets (Digital Addresses)

To carve manually, you must understand Offsets. An offset is simply an address. Just as every house on a street has a number (e.g., 100 Main St), every byte on a storage disk has a numbered position, starting at 0.

  • Hexadecimal Notation: Offsets are usually written in Hex (e.g., 0x1A4).
  • Usage: When you tell a forensic tool to "carve," you are essentially giving it coordinates: "Copy the data starting at Offset A and stop at Offset B."

7.6 Manual Carving Methodology

While automated tools like PhotoRec or Scalpel are powerful, they often produce thousands of false positives or "fragmented" files that cannot be opened. A manual carve is often required to recover a specific, high-value piece of evidence that automated tools missed.

Scenario: You are examining a raw physical dump of a microSD card. You suspect a specific JPEG image exists in the unallocated space.

Step 1: Identification (Finding the Header)

Open the raw dump in a Hex Editor (such as HxD or WinHex).

  • Action: Use the "Search" function to look for the JPEG Header signature: FF D8.
  • Result: The search highlights FF D8 at Offset 0x4A20 0000.
  • Note: Mark this as your Start Offset.

From the Start Offset, search forward for the JPEG Footer signature: FF D9.

  • Action: You scan through the data until you find the footer.
  • Result: You find FF D9 at Offset 0x4A3E B200.
  • Note: Mark this as your End Offset.

Step 3: Calculation (Doing the Math)

Before you extract the data, you must verify that what you found is actually a file. If the distance between your Header and Footer is only 5 bytes, it’s not a photo; it’s just random data that happens to look like a signature.

To do this, we calculate the Block Size.

The Formula: End Offset - Start Offset = File Size

The "Hex" Math: Doing subtraction with letters (A-F) in your head is difficult and prone to error. We will use the computer to do it for us.

  1. Open the Windows Calculator.
  2. Click the menu (three lines) and select Programmer Mode.
  3. Ensure the "HEX" option is selected on the left side.

The Calculation:

  • Type your End Offset: 4A3EB200
  • Press Minus (-)
  • Type your Start Offset: 4A200000
  • Press Equals (=)

The Result: The calculator displays: 1EB200 (in Hex).

Converting to Human-Readable Size: Now, while still in the calculator with 1EB200 displayed:

  1. Look at the display panel on the left/bottom.
  2. Find the "DEC" (Decimal) value.
  3. Result: 2,011,648 Bytes.

Is this reasonable?

  • 2,011,648 Bytes / 1024 = 1,964 KB
  • 1,964 KB / 1024 = 1.91 MB

Why do we divide by 1024?

You might be wondering why we don't divide by 1,000 like in the metric system (where 1,000 meters = 1 kilometer). Computers operate in Binary (Base 2), not Decimal (Base 10). Storage units are calculated in powers of 2.

  • $2^{10} = 1,024$

Therefore, a Kilobyte is actually 1,024 bytes, not 1,000. To get an accurate file size, you must always divide by 1024 to step up from Bytes -> KB -> MB.

Conclusion: A 1.91 MB file size is perfect for a standard smartphone photograph. This validates that your start and end points are likely correct.

Step 4: Extraction (The Carve)

Now that you have verified the math, you perform the physical extraction.

  1. Select Block: Nearly all hex editors will have some kind of option to "select a range". This will be slightly different for each tool, so you may need to research online exactly how to do it for your hex editor of choice.
  2. Input Range:
    • Start-offset: 0x4A200000
    • End-offset: 0x4A3EB200
  3. Copy: Copy the selected bytes into a new file.
  4. Save: Save the new file as carved_image.jpg.

Step 5: Verification

Attempt to open the new .jpg file.

  • Success: The image opens and is fully visible.
  • Corruption: If the bottom half of the image is grey or solid color, this indicates the file was fragmented. The data you carved was continuous, but the actual file jumped to a different part of the disk halfway through. Manual carving generally only works for contiguous (non-fragmented) files.

Activity

Practice your understanding of manual file carving with this simulated activity, before jumping into the real thing with your lab.

7.7 SQLite Carving

In mobile forensics, we rarely deal with loose files like JPEGs on a hard drive. Instead, we deal with Databases. Almost all mobile data (SMS, WhatsApp, Contacts, Call Logs) is stored in SQLite databases (.db or .sqlite files).

When a user deletes a text message, the database does not shrink. Instead, the specific "page" or "cell" containing that message is marked as part of a "Free List" (essentially, internal unallocated space within the file).

Carving Inside the File

Traditional file carving recovers a whole file from a disk. SQLite Carving recovers a deleted record from within a database file.

  • The Artifact: You are looking for a WAL File (Write-Ahead Log) or a Journal File. These are temporary files created by SQLite to track changes.
  • The Process:
    1. Often, a deleted message still exists in the .db-wal file even after it has been removed from the main .db file.
    2. Forensic tools (like the Forensic Browser for SQLite by Sanderson Forensics) have built-in "Carving" features that scan the Free List pages of a database.
    3. They look for the specific hex signatures of text strings (like valid UTF-8 characters) located in the unallocated blocks of the database.

Key Takeaway: Even if a suspect manually deletes a chat thread, the "vacuuming" (permanent cleanup) of the SQLite database rarely happens instantly. The data often persists in the Free List or the WAL file for days or weeks, waiting to be carved.

Note

We will cover this topic in more detail in Chapter 8, which focuses solely on SQLite Databases.

7.8 Real-World Scenario: The "Wiped" Evidence

To bring all these concepts together, let's look at a case study that demonstrates why manual file carving is often the difference between a cold case and a conviction.

The Case: Law enforcement is investigating a case of corporate espionage. A suspect, Mr. Vandelay, is accused of taking photos of confidential blueprints using his personal smartphone. When investigators seize the device, the photo gallery is empty. Mr. Vandelay claims he never took any photos.

The Anti-Forensics: Mr. Vandelay was thorough. He not only deleted the photos from his Gallery app but also went into the "Recently Deleted" folder and emptied it. In his mind, the evidence was gone forever.

The Forensic Reality: While the file system (the "card catalog") was wiped, the actual data (the "books") remained on the device's storage, waiting to be overwritten. Because the device was seized quickly and put in Airplane Mode, no new data had been written to those specific sectors.

The Investigation:

  1. Imaging: The examiner creates a physical image (bit-for-bit copy) of the device's external microSD card, where the camera app was set to save images.
  2. Automated Failure: The examiner runs a standard forensic tool. It finds thousands of "system" files but zero user photos. The tool relies on the file system, which is empty.
  3. Manual Carving: The examiner switches to a Hex Editor to view the raw physical data.
  4. The Hunt: Knowing that the device takes JPEG images, the examiner searches for the signature FF D8.
  5. Discovery: Deep in the unallocated space, the search hits a block starting with FF D8.
  6. Extraction: The examiner scrolls down, looking for the footer FF D9. They calculate the offset distance and find it is roughly 3.2 MB—a perfect size for a high-resolution photo.
  7. The Result: The data is carved and saved as evidence_001.jpg. When opened, it reveals a high-resolution image of the confidential blueprints, complete with metadata (Exif) showing the GPS coordinates of the victim's office and a timestamp matching the day of the theft.

Conclusion: Mr. Vandelay deleted the reference to the file, but he did not delete the physics of the magnetic storage. Manual carving bridged the gap that the automated software could not cross.

Chapter Summary & Key Takeaways

This chapter explored the two pillars of low-level data analysis: Time and Persistence.

We learned that "Time" in a digital sense is a mathematical construct, not a calendar date. Whether it is the Unix Epoch (1970) used by Android or Mac Absolute Time (2001) used by iOS, every action on a mobile device leaves a temporal footprint. The ability to decode these raw numbers and normalize them to UTC is what allows an investigator to build a defensible timeline of events.

We also demystified the concept of "Deletion." We discovered that digital storage is like a library; throwing away the card catalog does not burn the books. Through File Carving, we learned to ignore the file system entirely and look directly at the raw binary data. By identifying Hex Signatures (Headers and Footers), we can manually reconstruct evidence—images, documents, and database records—that the suspect believed was destroyed.

Key Takeaways

  • Normalize to UTC: Always convert local device time to Coordinated Universal Time (UTC) to prevent errors across time zones.
  • Know Your Epochs:
    • Unix: Seconds since Jan 1, 1970 (Android).
    • Mac Absolute: Seconds since Jan 1, 2001 (iOS).
    • Windows FILETIME: Nanoseconds since Jan 1, 1601.
  • Headers & Footers: Files are identified by their "Magic Numbers" (e.g., FF D8 for JPEG), not their file extension.
  • Unallocated Space is Not Empty: It is simply space that the operating system has marked as "available," but it often holds the most critical deleted evidence.

In the next chapter, we will take these concepts of data structure and apply them to the most common storage container in mobile forensics: SQLite Databases.