EDR, dashcam & digital vehicle evidence - FSI-DI 2026 Australia

01 / In this resource

Abstract

This paper presents a forensic methodology for identifying post-claim deletion of dashcam footage from removable SD card media submitted in connection with a motor vehicle insurance claim. The central contribution is the formalisation of a before/after forensic image comparison approach for dashcam storage media in an insurance investigation context: two independently hash-verified forensic images of the same SD card are compared to determine what footage was present at an earlier point in time and what was subsequently removed.

In the case study presented, a before forensic image acquired on 1 December 2025 confirmed the presence of 12 dashcam recordings from the date of loss (20 July 2025), spanning the period 19:04 to 23:00 AEST. An after forensic image acquired on 31 March 2026 revealed that all 684 DCIM files on the card — comprising 71.46 GB of continuous loop footage — had been deleted in the intervening period. Filesystem artefact analysis confirmed that the card had been connected to an Apple macOS device on two documented occasions within the deletion window. The incident-day footage cannot be recovered from the card as submitted.

The paper formalises a reproducible before/after comparison methodology and demonstrates its application in a live case. It also shows the forensic value of operating system artefacts -specifically macOS resource fork files, FSEvents directory entries, and FAT32 directory corruption patterns - as supporting evidence of post-claim access events. Taken together, the findings support a practical recommendation: early forensic imaging of submitted dashcam media, with a hash-verified image acquired immediately on receipt and before the card is returned to the claimant, should be adopted as standard practice by motor insurers.

Keywords: dashcam forensics; digital evidence tampering; insurance fraud; FAT32; forensic image comparison; post-claim deletion; SD card forensics

02 / In this resource

1. Introduction

Dashboard cameras have become a routine feature in Australian motor vehicles. Affordable, unobtrusive, and increasingly required by insurers, they record continuously by overwriting the oldest footage as storage fills. For a claims investigator, a dashcam SD card submitted with a motor insurance claim is generally expected to either support the insured's account or not. The more difficult situation arises when the footage that should be there is missing altogether.

This paper addresses that situation.

In late 2025, we were engaged by a major Australian motor insurer to examine a dashcam SD card submitted in connection with a motor vehicle collision claim. The date of loss was 20 July 2025. A forensic image acquired on 1 December 2025 confirmed that 12 dashcam recordings from the night of the alleged collision were present on the card, spanning 19:04 to 23:00 AEST. When the card was later submitted for examination on 31 March 2026 and a second verified image was acquired, those recordings were no longer present. All 684 DCIM files on the card -comprising 71.46 GB of continuous loop footage - had been deleted in the intervening period.

The findings were consistent with the SD card having been removed from the vehicle, connected to an external computer, and used in a way that resulted in the footage being deleted. The recordings from the night of the incident had existed, had been preserved in a hash-verified forensic image, and were later absent from a second hash-verified image. During the interval between those two acquisitions, the card had been connected to an Apple macOS device on two documented occasions. In nearly three decades of combined forensic casework across law enforcement, crash investigation, and private practice, we have seen many matters involving efforts to conceal relevant digital evidence. What made this case significant was not the general concept of deletion, but the clarity with which the deletion could be identified and demonstrated.

The forensic approach applied in this examination - comparing two independently hash-verified forensic images of the same storage medium, acquired at different points in time, to identify what had been present and what was no longer present - is not new in the broader field of digital forensics. Before/after image comparison is well established in computer forensics [7, 8]. What is new here is its application to dashcam SD card media submitted in the context of an insurance claim, and the specific evidentiary framework it provides: not merely that footage is absent, but what was present, when it was present, when it disappeared, and what computing devices were responsible for the access events that bracket the deletion window.

Prior research in dashcam forensics has focused primarily on artefact analysis and acquisition methodology. Lallie [1] conducted the first systematic analysis of dashcam SD storage systems, identifying artefacts of forensic interest across seven devices and establishing foundational guidance for evidence preservation. Lallie's subsequent work [3] extended this into formal investigation guidelines covering acquisition, examination, and reporting. Lee et al. [2] proposed a metadata-driven analysis framework capable of integrating temporal, spatial, and behavioural data from dashcam recordings.

Alboqami et al. [9] and Daraghmi and Shawahna [4] have further developed forensic frameworks for dashcam evidence extraction and authentication. Collectively, this body of work has established robust methodology for examining dashcam footage that exists. It has not addressed the scenario in which footage has been deliberately removed after a claim was lodged — a scenario that, in our experience, represents a distinct and underappreciated fraud vector in the Australian motor insurance context.

The methodology described in this paper has two parts. The before/after image comparison establishes what was present and what has been removed - a direct and reproducible finding that does not depend on an inference about intent. The OS artefact analysis provides supporting chronology: when the card was connected to external devices, by which platform, and which files were accessed during those connections. Together, those components produce a more complete evidentiary account than either would in isolation. The broader point developed in Sections 5 and 6 is that this methodology is only available if a forensic image is acquired before the card is returned to the claimant, and that adopting this as standard insurer practice would be both practical and significant.

The remainder of this paper is structured as follows. Section 2 reviews the relevant literature across dashcam forensics, FAT32 filesystem analysis, and hash-based integrity verification. Section 3 describes the forensic methodology applied. Section 4 presents the case study in de-identified form. Section 5 discusses the evidentiary significance of the findings and their limitations. Section 6 sets out recommendations for insurers, legal practitioners, and law enforcement. Section 7 concludes.

03 / In this resource

2. Literature review

2.1. Dashcam forensics — the developing field

The forensic examination of dashcam devices is a relatively recent discipline, and the published literature reflects this. Lallie [1] conducted the first systematic analysis of dashcam SD storage systems as forensic artefact sources, examining seven dashcam devices to identify the prevalence and provenance of evidential data across six storage locations: NMEA files, configuration and diagnostic files, EXIF metadata, directory structures, filename structures, and imagery watermarks.

The study established that dashcams generate forensically rich artefacts well beyond their video recordings — temporal data, GPS coordinates, vehicular speed, and recording mode indicators are distributed across multiple storage locations and survive in recoverable form even after footage has been overwritten by loop recording. Lallie also identified a fundamental chain of custody problem with dashcam evidence: because footage is typically submitted online by the owner directly to a law enforcement agency or insurer, there is an unavoidable period during which the evidence is not under any custodial control.

This creates admissibility challenges that safeguards must be built into the submission process to address. The paper did not, however, address what happens when footage is not merely uncontrolled during submission but has been deliberately removed before submission — a distinction that is the subject of the present paper.

Lee et al. [2] extended the artefact analysis framework to a broader device set, classifying metadata across 14 dashcam models from 11 manufacturers and developing a normalised database schema for integrated forensic analysis. Their work demonstrated that FAT32 filesystem timestamps — including directory entry creation timestamps — could serve as a foundation for event reconstruction, and that cross-referencing metadata sources within a single device produces a richer forensic picture than visual footage analysis alone.

Lee et al. noted that dashcam firmware generally does not write embedded container metadata (CreateDate and ModifyDate fields are typically zeroed), meaning that the FAT32 filesystem and filename encoding are the primary timestamp sources available to an examiner. This observation is directly relevant to the present case, in which the firmware class of the subject dashcam produced MP4 files with zeroed embedded timestamps — a limitation that shifted the evidentiary burden entirely onto filesystem metadata and forensic image comparison.

Lallie's 2023 paper [3] represented the most comprehensive practitioner-oriented contribution to the field, providing the first formal investigation guidelines for dashcam evidence covering first response, device classification, acquisition methods, examination, analysis, and reporting. The paper provided detailed guidance on the particular challenges of dashcam acquisition — including the risk that connecting an SD card to a computer prior to imaging will write operating system artefacts to the card. This is an observation of particular forensic significance in the present case: macOS and Windows both write identifiable filesystem artefacts to removable media on connection, and these artefacts — rather than being a contamination risk — became key evidentiary items in establishing the timeline of post-claim access to the subject SD card.

2.2. Insurance fraud and dashcam evidence

The intersection of dashcam evidence and insurance fraud has received limited academic attention, despite its practical significance. Daraghmi and Shawahna [4] proposed an OCR-based framework for extracting temporal, spatial, and behavioural metadata from dashcam footage to support forensic investigations, noting that dashcam footage had been demonstrated to be effective evidence against staged 'crash for cash' insurance fraud. Giovannini et al. [5] examined the forensic value of dashcam analysis in fatal vehicle-pedestrian crash reconstruction, establishing that dashcam footage could materially alter liability findings in complex incidents. However, neither paper addressed the scenario in which footage is withheld or deleted before submission — the assumption in both is that footage, where it exists, is available for analysis.

The broader insurance fraud literature documents the scale of the problem. Morley, Ball, and Ormerod [6] examined how insurance fraud detection succeeds and fails across investigative disciplines, identifying the documentary and evidential challenges that allow fraudulent claims to proceed. While Australian-specific statistics on motor insurance fraud are less comprehensively published, the Insurance Fraud Bureau of Australia and state-level frameworks acknowledge motor fraud as a persistent and significant cost to the industry. The forensic literature has not yet caught up with the practical reality that dashcam media, rather than being a tool for detecting fraud, can itself become a target for evidence suppression by fraudulent claimants.

2.3. FAT32 filesystem forensics and hash-based integrity verification

The forensic properties of the FAT32 filesystem are well established in the broader digital forensics literature [8]. FAT32 — which remains the standard filesystem for removable flash media including SD cards — stores three timestamps per directory entry: created, modified, and accessed. It does not maintain a journal, and it does not log deletion events. When a file is deleted under FAT32, the first character of the directory entry filename is overwritten with a deletion marker (0xE5), and the cluster chain is returned to the free pool, but the file content remains in unallocated space until overwritten.

This characteristic makes FAT32 media partially recoverable after deletion — provided the clusters have not been overwritten — but it also means that the timing of deletion cannot be determined from filesystem metadata alone. In the present case, this limitation is addressed by the before/after image comparison methodology: because a verified forensic image was acquired prior to the deletion events, the question of whether footage existed is answered with certainty, even though the precise date of deletion cannot be pinpointed.

Hash-based integrity verification — the use of cryptographic hash functions to produce a unique digital fingerprint of a forensic image, allowing any subsequent modification to be detected — is a foundational principle of digital forensics practice and is mandated under standards including NIST Special Publication 800-86 [7]. The production of MD5 and SHA-1 hash values at the time of forensic image acquisition, and their verification prior to analysis, ensures that the examiner can demonstrate in court that the data analysed is an exact representation of the original evidence at the time of acquisition. In the present case, both forensic images — acquired on 1 December 2025 and 31 March 2026 respectively — were independently hash-verified, providing the evidentiary foundation for the before/after comparison.

2.4. The gap this paper addresses

The existing dashcam forensics literature has established a solid framework for extracting, authenticating, and presenting footage that exists. Lallie [1, 3] and Lee et al. [2] have shown where relevant artefacts reside, how they can be acquired without contamination, and how they can be presented in an evidentially sound way.

What the literature has not addressed is the situation in which a claimant, aware that dashcam footage may be adverse to their interests, removes the SD card from the vehicle, connects it to an external device, deletes the relevant footage, and later submits the card for examination as though the footage had never existed. That is the scenario examined in this paper. The gap is not merely theoretical. Without a forensic methodology capable of detecting post-claim deletion, an examiner presented with an empty DCIM folder has little basis to conclude anything beyond the absence of footage at the time of examination.

The before/after image comparison methodology described here addresses that problem directly and supports the adoption of early forensic imaging - acquiring a verified image of submitted media before it is returned to the claimant - as standard insurer practice when dashcam evidence is involved.

04 / In this resource

3. Methodology

3.1. Scope of examination

This examination was limited to forensic analysis of digital data extracted from the subject dashcam SD card and two independently acquired forensic images thereof. No physical vehicle inspection was conducted, and this paper does not address the underlying insurance claim or any assessment of liability. All findings presented are derived solely from the digital evidence as described. The Collision Sciences Australia EDR toolkit, which has been independently adopted in peer crash research including the 2024 University of Adelaide CASR programme [13], was not employed in this examination; the subject vehicle was not equipped with a compatible EDR.

3.2. Evidence items and chain of custody

Three items of evidence were examined in this investigation: the original dashcam SD card (SD-001), a before forensic image acquired on 1 December 2025 (IMG-001), and an after forensic image acquired on 31 March 2026 (IMG-002).

SD-001 was a Lexar microSD card with a total storage capacity of 121,942 MB (249,737,216 sectors × 512 bytes per sector), formatted with a FAT32 filesystem consistent with removable media dashcam firmware of this class. The card was received for examination in an intact condition with read-only examination applied throughout.

IMG-001 was acquired on 1 December 2025 by R. Sfarjalani of Collision Sciences Australia using FTK Imager [10] in segmented raw format, producing 82 image segments. The image was acquired from the physical device and hash-verified at the time of acquisition, yielding MD5 and SHA-1 values that were confirmed to match prior to analysis. IMG-002 was acquired on 31 March 2026 by T. Allen of Collision Sciences Australia from the SD-001 physical device using FTK Imager. A hardware write-blocker was employed throughout the acquisition process in addition to FTK Imager's native software write-blocking, ensuring that no data was written to the original media during imaging. IMG-002 was independently hash-verified prior to analysis. Full hash values for both images are provided in Section 4.

Chain of custody documentation was maintained for both forensic images from the point of acquisition through to the completion of analysis. The original SD card (SD-001) was handled in read-only condition at all times during the examination conducted by the authors.

3.3. Before/after forensic image comparison

The primary forensic methodology applied in this examination was a before/after comparison of the two independently hash-verified forensic images of SD-001. Because both images represent bit-for-bit copies of the same physical device at different points in time, a systematic comparison of their filesystem contents identifies files and directory structures present in IMG-001 that are absent from IMG-002, and vice versa. Any discrepancy between the two images that cannot be attributed to loop-recording overwrite behaviour — that is, the normal dashcam mechanism of overwriting the oldest unprotected footage when the card is full — represents an event requiring forensic explanation.

Both forensic images were mounted in a read-only state for analysis. Filesystem content was enumerated from each mounted image using PowerShell's Get-ChildItem cmdlet, producing a complete listing of filenames, file sizes, and FAT32 directory entry timestamps for all files present in each image. The output of each enumeration was exported to a structured dataset, and the two datasets were compared programmatically to identify items present in one image but absent from the other. Where discrepancies were identified, they were manually verified within FTK Imager's interface to confirm accuracy and to inspect the relevant directory structures directly. This dual approach — scripted enumeration for completeness and systematic coverage, manual verification within FTK Imager for confirmatory inspection — was used throughout.

3.4. Filesystem artefact analysis

FAT32 does not maintain a transaction journal and does not log filesystem events, including deletion events [8]. Accordingly, the timestamp of a deletion cannot be determined from FAT32 metadata alone. To corroborate the timeline of post-claim access events — that is, to establish when the SD card was connected to external computing devices during the period between image acquisitions — the filesystem was examined for operating system artefacts written to the card during external connections.

Two categories of OS artefact were identified and analysed. The first were macOS-specific artefacts: the .fseventsd directory, .TemporaryItems directory, and resource fork files (._filename prefixed files) written by macOS when a FAT32 volume is mounted [11]. The .fseventsd directory is created by the macOS FSEvents subsystem, which logs filesystem events to a journal; its presence on a FAT32 volume confirms that the card was mounted by a macOS device.

Resource fork files (._*) are written individually to FAT32 volumes by macOS when files within a directory are accessed or browsed, because the macOS HFS+ resource fork mechanism cannot be stored natively in FAT32 directory entries. The presence of 18 resource fork files corresponding to event recording files in the EVENT\event_rec directory confirmed that each of those files had been individually accessed by a macOS device. The second category was a Windows-specific artefact: the System Volume Information folder, containing WPSettings.dat and IndexerVolumeGuid, which is created by Windows when a removable volume is mounted.

Each artefact was examined for its FAT32 directory entry timestamps, providing approximate connection dates.

3.5. FAT32 directory corruption analysis

The DCIM directory of IMG-002 was found to exhibit circular cluster chain corruption - a condition in which the FAT32 cluster chain for the directory enters a circular loop, causing recursive traversal errors when the directory is enumerated by standard filesystem tools. This pattern is consistent with a large-scale deletion or overwrite event affecting the FAT32 directory table rather than routine individual file deletion, and may indicate that a formatting or wiping operation was applied to the DCIM partition of the card. This finding was identified through direct examination of the FAT32 data structures in FTK Imager and corroborated by the complete absence of any directory entry data for the 684 files confirmed present in IMG-001.

3.6. Unallocated space recovery

Following the filesystem comparison and artefact analysis, a proprietary file recovery process developed by Collision Sciences Australia was applied to the unallocated space of SD-001 to determine whether any portion of the deleted footage could be recovered. A total of 512 MP4 files were recovered from unallocated space. All 512 recovered files exhibited zeroed embedded MP4 timestamps (CreateDate: 0000:00:00), consistent with the dashcam firmware class used by the subject device, which does not write embedded container metadata. Recovered file metadata was extracted using ExifTool v12.x [11] and container-level stream analysis was performed using FFprobe (FFmpeg) [12]. No recovered file was attributable to the date of loss or the claimed incident period on the basis of available metadata. Original filenames were not recoverable from the deleted FAT32 directory entries.

3.7. Tool summary

The following tools were employed in this examination:

• FTK Imager (Exterro Inc.) [10] — forensic image acquisition and verification, filesystem browsing, and manual examination

• PowerShell Get-ChildItem — scripted filesystem enumeration and file listing from mounted images
• ExifTool v12.x (Harvey, P.) [11] — embedded metadata extraction from recovered MP4 files
• FFprobe / FFmpeg [12] — container-level video stream analysis
• Hardware write-blocker — employed during all physical device acquisitions to prevent write-back to original media

05 / In this resource

4. Case study

4.1. Background and case referral

In late 2025, the authors were engaged by a major Australian motor insurer to conduct a forensic examination of a dashcam SD card submitted in connection with a motor vehicle collision claim. The date of loss was 20 July 2025. The subject vehicle was a 2005 Mercedes-Benz S430 — a vehicle of sufficient age that no Event Data Recorder data was available, and which was fitted with a single-channel front-facing dashcam as the primary source of potential incident footage. The claim related to an alleged collision at a residential street location in outer metropolitan Sydney, New South Wales, with the loss occurring during evening hours on the date of loss. The claim reserve was of modest value, consistent with a minor collision claim. For the purposes of this publication all identifying particulars — including registration, VIN, claim reference, and specific loss location — have been redacted in accordance with standard de-identification practice for case study research.

4.2. Device identification and filesystem characterisation

The subject SD card (SD-001) was a Lexar microSD device with a total capacity of 121,942 MB. The device was formatted with a FAT32 filesystem, consistent with the class of single-channel dashcam firmware that produced the recordings stored on the card. The dashcam firmware used a ch0_ filename prefix convention, with recording start and end times encoded directly in the filename in YYYYMMDDHHMMSS format — a characteristic documented by Lee et al. [2] as common across dashcam firmware of this class, and one that provided the primary timestamp source for footage analysis given that embedded MP4 container metadata was zeroed by the firmware at the time of recording.

The card's directory structure comprised four primary directories: DCIM (continuous loop recordings), JPEG (still images), EVENT\event_rec (write-protected g-sensor and manually triggered event recordings), and System Volume Information (Windows OS artefact). The DCIM and JPEG directories displayed FAT32 epoch creation timestamps of 1 January 1980, consistent with creation by the dashcam firmware at initial card format time with the device's internal clock unset — behaviour Lallie [1] identified as normal for this class of device and a known source of timestamp ambiguity in dashcam forensics.

4.3. Forensic image verification

Both forensic images were independently hash-verified prior to analysis in accordance with the methodology described in Section 3.2. The verification results are presented in Table 1.

Table 1 — Forensic image verification

Parameter IMG-001 (before) IMG-002 (after)

Read table as text

Source data · PDF page 16

Acquired by	R. Sfarjalani, Collision Sciences Australia	T. Allen, Collision Sciences Australia
Acquisition date	1 December 2025	31 March 2026
Tool	FTK Imager (segmented raw)	FTK Imager (physical image)
Write-blocking	Software (FTK Imager)	Hardware + software (FTK Imager)
MD5	f5136ada225fc3aa3376e5d7121cf8a2	739f0e44bab54bbf1879b9ee5c7c29a1
SHA-1	d11405bf9037e7d2f2c2668e5ed44d32bc c5010d	a4c44b86d8811e00d16d925bc73431b2d b2e768f
Verification result	Verified — MD5 and SHA-1 confirmed	Verified — MD5 and SHA-1 confirmed

The verified hash values establish that the data examined is an accurate and unmodified representation of the SD card at each respective point in time. Any difference between the two images therefore reflects a change to the card's contents that occurred between 1 December 2025 and 31 March 2026.

4.4. Post-claim access events — filesystem artefact analysis

Filesystem artefact analysis of IMG-002, conducted in accordance with the methodology described in Section 3.4, identified that the SD card had been connected to external computing devices on at least three occasions following the date of loss. These connections are summarised in Table 2.

Table 2 — Post-claim external device connections

Date device type forensic evidence significance

13 October 2025 Windows PC System Volume Information

Read table as text

Source data · PDF page 17

Windows PC	System Volume Information (WPSettings.dat, IndexerVolumeGuid)
—	IMG-001 acquired and hash-verified
Apple macOS	.fseventsd and .TemporaryItems created on card root; EVENT file LastWriteTime anomaly
Apple macOS	._DCIM, ._JPEG root resource forks; 18 × ._ch0_* resource forks in EVENT\event_rec
—	IMG-002 acquired and hash-verified

First post-incident connection — prior to Before image acquisition

1 December 2025 IMG-001 acquired and hash-verified Forensic reference point (Before image)

5 December 2025 Second post-incident connection — 4 days after Before image acquisition

5 January 2026 Apple macOS ._DCIM, ._JPEG root resource forks;

Third post-incident connection — all 256 event files individually browsed

31 March 2026 — IMG-002 acquired and hash-verified Examination reference point (After image)

None of these external connections were disclosed at the time the claim was lodged. The Windows PC connection on 13 October 2025 occurred before the acquisition of IMG-001, which means any effect it may have had on the card's contents falls outside the before/after comparison. The two macOS connections on 5 December 2025 and 5 January 2026 occurred within the deletion window established by the comparison and are therefore of primary evidentiary significance.

4.5. Anomalous event file modification

One event recording file — ch0_20220726071441_20220726071809.mp4, created 26 July 2022 — was found to have a FAT32 LastWriteTime of 5 December 2025 at 21:49:28 AEST, some three years and four months after its creation date. All other event files in the EVENT\event_rec directory had LastWriteTime values within minutes of their respective creation dates. The .TemporaryItems directory — a macOS artefact created when a temporary file is written to a FAT32 volume during a read or copy operation — was created on the card at 21:49:16 AEST on 5 December 2025, twelve seconds before this file's anomalous LastWriteTime. This temporal correlation is consistent with macOS writing a temporary file to the card during a read or copy operation involving the subject event file during the first post-Before-image Mac connection. Whether the content of this file was altered cannot be determined from filesystem metadata analysis alone; binary-level comparison of the file between the two images would be required to resolve this question.

4.6. Before/after DCIM comparison — primary finding

The primary finding of this examination is presented in Table 3.

Table 3 — DCIM directory comparison

Parameter IMG-001 (1 dec 2025) IMG-002 (31 mar 2026)

Read table as text

Source data · PDF page 18

DCIM file count	684 files	0 files
Total DCIM data	71.46 GB	0 bytes
Date range of recordings	18 July 2022 – 23 July 2025	None
Recordings from date of loss	12 files present	None

Files deleted between images — 684 files / 71.46 GB

The DCIM folder in IMG-002 was entirely empty. All 684 files confirmed present in IMG-001 were absent from IMG-002. The deletion of these files occurred during the period between 1 December 2025 and 31 March 2026 — a period that encompasses both documented macOS connections.

4.7. Incident-day recordings

Of the 684 DCIM files confirmed present in IMG-001, 12 were recordings from 20 July 2025 — the date of loss. These recordings covered the period from 19:04 AEST to 23:00 AEST on that date, encompassing the claimed incident timeframe. The full file listing for these 12 recordings is presented in Table 4.

Table 4 — Incident-day recordings confirmed in IMG-001 and absent from IMG-002

Filename start (AEST)

End (AEST)

Size (mb) fs created

Read table as text

Source data · PDF page 19

ch0_20250720190413_20250720190712 .mp4	19:04:13	19:07:12	188.2	20/07/2025 19:04:16
ch0_20250720213941_20250720214130 .mp4	21:39:41	21:41:30	112.8	20/07/2025 20:39:40
ch0_20250720214037_20250720214104 .mp4	21:40:37	21:41:04	31.9	20/07/2025 20:40:44
ch0_20250720214140_20250720214242 .mp4	21:41:40	21:42:42	68.7	20/07/2025 20:41:44
ch0_20250720222507_20250720222549 .mp4	22:25:07	22:25:49	43.9	20/07/2025 21:25:06
ch0_20250720222603_20250720222853 .mp4	22:26:03	22:28:53	179.9	20/07/2025 21:26:08
ch0_20250720222918_20250720223200 .mp4	22:29:18	22:32:00	168.6	20/07/2025 21:29:18
ch0_20250720223218_20250720223222 .mp4	22:32:18	22:32:22	4.9	20/07/2025 21:32:18
ch0_20250720223314_20250720223612 .mp4	22:33:14	22:36:12	187.9	20/07/2025 21:33:20

Read table as text

Source data · PDF page 20

ch0_20250720225535_20250720225824 .mp4	22:55:35	22:58:24	174.5	20/07/2025 21:55:34
ch0_20250720225838_20250720225918 .mp4	22:58:38	22:59:18	42.3	20/07/2025 21:58:38
ch0_20250720225934_20250720230001 .mp4	22:59:34	23:00:01	31.9	20/07/2025 21:59:38

Note: The one-hour discrepancy between recording start times (as encoded in filenames) and filesystem creation timestamps is consistent with a dashcam real-time clock set to UTC rather than AEST (UTC+10:00), a limitation noted by Lallie [3] and Lee et al. [2] as a known source of timestamp ambiguity in dashcam forensics. It does not affect the forensic significance of the findings.

4.8. DCIM directory corruption

Examination of the DCIM directory structure in IMG-002 revealed circular cluster chain corruption in the FAT32 directory table, causing recursive traversal errors during enumeration. This pattern is consistent with a bulk deletion or formatting operation applied to the DCIM partition of the card rather than individual file-level deletion, and may indicate that a deliberate wiping operation was employed. This finding is discussed further in Section 5.

4.9. Unallocated space recovery findings

The proprietary recovery process described in Section 3.6 was applied to the unallocated space of SD-001. A total of 512 MP4 files were recovered, with a combined size of 46.9 GB and individual file sizes ranging from 2.2 MB to 229.0 MB (mean 96.7 MB). All 512 recovered files exhibited zeroed embedded timestamps, consistent with this firmware class. No recovered file was attributable to 20 July 2025 or the claimed incident period on the basis of available metadata. Original filenames were not recoverable from the deleted FAT32 directory entries. The incident-day recordings cannot be recovered from SD-001 as submitted.

06 / In this resource

5. Discussion

5.1. The before/after comparison as a primary forensic methodology

The central methodological contribution of this paper is the application of before/after forensic image comparison to dashcam SD card media submitted in an insurance investigation context. The approach is not novel in the broader field of digital forensics — comparing hash-verified forensic images of the same device acquired at different points in time is a well-established technique for detecting changes to digital evidence [7, 8]. What is novel is its application to a specific and previously undocumented fraud scenario: the deliberate post-claim deletion of dashcam footage from submitted storage media.

The evidentiary value of this methodology is straightforward. If a forensic image of a storage device is acquired and hash-verified at time T1, and a second forensic image of the same device is acquired and hash-verified at time T2, then any file present in T1 and absent from T2 was deleted during the interval between the two acquisitions. This conclusion does not depend on assumptions about intent, driving behaviour, or reconstruction of the physical event. It is a direct, reproducible, and tool-agnostic finding derived from the comparison of two verified datasets that can be replicated by any competent digital forensic examiner and explained to a non-technical audience without difficulty. In the present case, the T1 image confirmed 12 recordings from the date of loss were present on 1 December 2025. The T2 image confirmed they were gone on 31 March 2026.

This conclusion remains valid despite the limitations of FAT32. FAT32 does not log deletion events and the precise date of deletion cannot be determined from filesystem metadata alone [8]. In the present case, the deletion window spans approximately four months — from 1 December 2025 to 31 March 2026 — and cannot be narrowed further from the filesystem data. However, the width of the deletion window does not affect the core finding. The footage was present in the earlier image, verified at the time, and absent in the later image. The forensic question of when it was deleted is a separate matter from the forensic question of whether it was deleted, and it is the latter that is directly answerable and evidentially decisive.

5.2. Operating system artefacts as corroborative evidence

While the before/after comparison establishes the fact of deletion, the OS artefact analysis provides the evidentiary framework within which the deletion occurred. Three post-incident connections to external computing devices were identified from artefacts written to the card by those devices: a Windows PC connection on 13 October 2025, and two macOS connections on 5 December 2025 and 5 January 2026. The macOS connections are of primary significance because they fall within the deletion window — that is, they occurred after the Before image was acquired and before the After image was acquired.

The forensic value of OS artefacts written to FAT32 removable media is well recognised in the mobile device forensics literature, though it has not previously been documented in the context of dashcam evidence specifically. When a macOS device mounts a FAT32 volume, it writes a .fseventsd directory to the volume root — a directory used by the FSEvents subsystem to maintain a filesystem event journal [11]. It also writes .TemporaryItems to the root and, when individual files within a directory are accessed or browsed, creates resource fork files (._filename) alongside each accessed file. These artefacts are written by the operating system automatically, without any deliberate action by the user, and their presence is difficult to conceal without either explicitly deleting them — which would itself create a forensic artefact — or performing a complete format of the card.

In the present case, the 18 resource fork files found in EVENT\event_rec, each corresponding to one of the 256 write-protected event recordings, confirm that those files were individually accessed or browsed during the 5 January 2026 Mac connection. This is a significant finding in its own right: it indicates that whoever connected the card to the Mac on that date did not merely mount the card and disconnect it — they navigated into the event recording directory and examined the contents. This behaviour is consistent with a deliberate search of the card's contents prior to the deletion of the loop footage.

5.3. The DCIM directory corruption — deliberate wiping or an artefact of deletion?

The circular cluster chain corruption observed in the DCIM directory of IMG-002 requires careful interpretation. One possibility is that a bulk deletion operation affecting a large number of files produced corruption in the FAT32 directory table rather than leaving cleanly marked individual deletions. Another is that a more deliberate formatting or wiping action was applied to the DCIM partition of the card.

The recovery of 512 files from unallocated space is relevant here. If the entire card had been fully formatted and zeroed, recovery would be expected to yield little or nothing. The recovery of 512 intact MP4 files — although none attributable to the date of loss — suggests that the event was more consistent with large-scale deletion of directory contents than with complete media sanitisation. Regardless of the precise mechanism, the forensic outcome is the same: the incident-day footage is no longer recoverable from the card as submitted.

5.4. The significance of early forensic imaging

The most important procedural point arising from this examination is the role of the Before image. Without IMG-001 — a forensically verified snapshot of the card’s contents before the later access events — an examiner presented only with IMG-002 would have found an empty DCIM folder, 512 recovered but unattributed files, and no reliable basis for concluding that the relevant footage had ever existed. The OS artefacts would have raised legitimate questions about post-incident access, but not answered them definitively.

In this case, the Before image was acquired proactively by the insurer’s forensic team, and that decision proved critical. In our experience, that is not yet standard practice across the Australian motor insurance industry. More commonly, SD cards are received from claimants, examined in their submitted state, and returned without a forensic image having first been acquired. That creates a period of vulnerability during which a claimant who knows the footage may be adverse to their interests can remove the card, delete relevant footage, and later submit the media in a tampered state.

The procedural response is relatively simple. If insurers acquire a hash-verified forensic image of any dashcam SD card immediately upon receipt — before examination and before return to the claimant — the before/after comparison methodology described in this paper becomes available as a routine investigative tool. The cost of imaging is modest relative to the value of the claims it may help resolve. In the present case, the Before image was the foundation for the findings that followed.

5.5. Limitations of the before/after methodology

The before/after methodology is contingent on the availability of a Before image. Where no prior forensic image exists — which, as noted in Section 5.4, reflects the current situation in most Australian motor insurance examinations — the methodology is unavailable. An examiner presented only with a single image of the card at the time of examination can identify that footage is absent and can identify OS artefacts consistent with prior external connections, but cannot establish what was present before those connections occurred. The evidentiary value of the methodology is therefore entirely dependent on the procedural decision to image the card at first receipt.

A second limitation is temporal precision. FAT32 does not log deletion events, and the before/after comparison establishes only that deletion occurred within the interval between the two acquisitions — in this case, a window of approximately four months. The OS artefact analysis can narrow this window to the extent that dated connection events can be identified, but it cannot pinpoint the deletion itself. In cases where the deletion window is long and multiple connections are documented, it may not be possible to determine which connection event was responsible for the deletion.

Third, the methodology establishes that deletion occurred but does not, by itself, identify who performed it or attribute intent. In the present case, the before/after comparison confirms that 684 files were deleted between the two acquisition dates. The OS artefacts provide corroborating evidence of the access events within that window. Together, these findings are consistent with deliberate post-claim deletion, but the methodology does not produce direct evidence of the identity of the individual who connected the card to the external device or executed the deletion. That inference, where drawn, must be supported by other evidence in the broader investigation.

Finally, the recovery findings in this case demonstrate a limitation inherent to the dashcam firmware class examined. Because the subject device produced MP4 files with zeroed embedded timestamps, recovered files from unallocated space could not be attributed to the date of loss on the basis of container metadata alone. On devices that write GPS coordinates, real-time clock data, or other identifiers into the MP4 container, recovery from unallocated space may yield files that can be attributed to a specific recording period. The generalisation of the methodology to such devices would require adaptation of the recovery and attribution workflow.

5.6. Limitations of the OS artefact analysis

The OS artefact framework described in this paper is based on macOS and Windows artefact signatures. The artefacts produced when Linux, Android, or iOS devices mount a FAT32 volume have not been examined in this study. Given the prevalence of Android-based devices and the increasing use of mobile phones as file management tools for removable media, the absence of an Android artefact profile is a meaningful gap. Future work should characterise the filesystem artefacts written by each of these platforms to FAT32 media, and assess their utility as connection indicators in a dashcam forensics context.

The FAT32 directory entry timestamps used to date connection events in this examination have a resolution of two seconds for the LastWriteTime field and one second for the CreationTime field, and are subject to the timezone and clock accuracy of the host device at the time of writing. Where a host device has an incorrectly set system clock — a condition that is not uncommon in older hardware — the connection dates derived from artefact timestamps may be inaccurate. In the present case, the timestamps were internally consistent and corroborated by multiple artefact sources, but this limitation should be acknowledged when artefact timestamps are relied upon as sole indicators of connection timing.

The presence of macOS artefacts on the card establishes that a macOS device was connected, but does not identify the specific device, user account, or individual responsible for the connection. The .fseventsd journal written to the FAT32 volume by macOS is a truncated log that does not preserve the full event history that would be available on the host device’s internal HFS+ or APFS volume. Attribution of the connection to a specific host device would require examination of that device — in particular, its own FSEvents logs, Spotlight index, and USB connection history — which was outside the scope of the present examination.

Finally, the anomalous LastWriteTime on the single event file examined in Section 4.5 raises the possibility of file content modification that could not be resolved from filesystem metadata alone. Binary-level comparison of that file between IMG-001 and IMG-002 would be required to determine whether the content changed during the December 2025 Mac connection. That comparison was not performed in the present examination and represents a discrete avenue for further analysis in this matter.

07 / In this resource

6. Recommendations

6.1. Early forensic imaging as standard insurer protocol

The single most consequential procedural change available to Australian motor insurers in relation to dashcam evidence is the adoption of mandatory early forensic imaging - the acquisition of a hash-verified forensic image of any dashcam SD card immediately upon receipt, before any examination is conducted and before the card is returned to the claimant. As this case demonstrates, that step transforms dashcam media from a claimant-controlled item, vulnerable to later tampering, into a preserved evidential record with a defensible chain of custody.

Implementing this protocol does not require significant additional resources. Forensic image acquisition from an SD card using FTK Imager or equivalent tooling takes approximately 30 minutes for a card of the size examined in this study. The resulting image can be stored securely and retained for the duration of the claim investigation. Relative to the value of a single fraudulent motor insurance claim, the cost in time, storage, and equipment is modest. In the present case, the Before image was the evidentiary foundation for every significant finding.

The minimum standard recommended for dashcam SD card evidence is as follows: upon receipt of any dashcam SD card submitted in connection with a motor insurance claim, a qualified forensic examiner should acquire a bit-for-bit forensic image of the card using a write-blocking device and hash-verified imaging tool before any other examination is conducted. The image should be retained in a secure, access-controlled environment for the duration of the claim and any subsequent legal proceedings. The original card should be returned to the claimant only after the forensic image has been verified. Where the card is to be examined before return, examination should be conducted on the image rather than the original media.

6.2. Chain of custody requirements for submitted dashcam media

Current practice in the Australian motor insurance industry does not consistently apply formal chain of custody protocols to dashcam media submitted by claimants. The present case shows why that matters. A dashcam SD card that passes through the hands of a claimant, repairer, loss assessor, and claims handler before reaching a forensic examiner carries an uncontrolled custody history that is difficult to reconstruct later.

Insurers should adopt a formal chain of custody protocol for dashcam media from the point of first receipt, consistent with the principles established in NIST SP 800-86 [7] and the acquisition guidelines described by Lallie [3]. At a minimum, this should include documented receipt with date, time, and condition of the media; tamper-evident packaging from the point of receipt; access logging for any person who handles the media before forensic imaging; and written disclosure by the claimant of any connection of the media to an external computing device following the date of loss. In the present case, three post-incident connections to external devices occurred and none were disclosed at lodgement. A formal disclosure requirement would not prevent tampering, but it would make later non-disclosure more significant.

6.3. Policy conditions and the duty to preserve digital evidence

The deletion of dashcam footage following the lodgement of an insurance claim raises questions that extend beyond forensic methodology and into the domain of policy conditions and evidence law. Australian insurance policies generally contain conditions requiring the insured to preserve and make available all evidence relevant to a claim. The extent to which these conditions expressly cover digital evidence stored on dashcam media varies between policies and has not, to our knowledge, been the subject of judicial consideration in Australia. Insurers should review their policy wording to ensure that the duty to preserve evidence is expressed in terms that clearly encompass digital evidence stored on dashcam and other vehicular recording devices, and that the consequences of breach — including the right to decline the claim — are clearly stated. Legal advice should be sought in relation to each jurisdiction's evidence preservation obligations before any policy changes are implemented.

6.4. Implications for law enforcement

The methodology described in this paper has direct application beyond the insurance context. Law enforcement agencies investigating motor vehicle incidents - including fatal crashes, hit-and-run offences, and staged collisions - routinely encounter dashcam devices as potential evidence sources. The same vulnerability identified in the present case applies in the criminal context: a suspect or witness who knows that dashcam footage is relevant may remove the SD card, delete the footage, and later present the card for examination in a tampered state.

Law enforcement agencies should consider adopting early forensic imaging protocols for dashcam media seized or submitted in connection with motor vehicle investigations, consistent with existing best practice for other forms of removable digital media. The investigation guidelines published by Lallie [3] provide a sound foundation for dashcam-specific acquisition procedures. In addition, the OS artefact framework described in Section 3.4 and demonstrated in Section 4.4 may assist investigators examining dashcam media for signs of prior tampering. The presence of macOS or Windows artefacts on dashcam SD card media warrants explanation, because such artefacts can only appear through external connection to a host device.

6.5. Recommendations for future research

The limitations identified in Section 5.6 suggest several directions for future research. The OS artefact signatures documented here are macOS-specific, and a study of the artefacts produced by Linux, Android, and iOS when mounting FAT32 dashcam media would improve the generalisability of the framework across investigation settings. The firmware examined in this study produced zeroed embedded timestamps throughout, which is common but not universal; future work should examine how the before/after methodology applies to newer devices that write GPS and timestamp metadata into MP4 container fields. There is also a practical case for tooling: an automated comparison utility capable of ingesting two hash-verified images and generating a structured difference report would make the methodology more accessible to investigators without specialist digital forensics training.

08 / In this resource

7. Conclusions

This paper has presented a forensic case study and reproducible methodology for identifying post-claim deletion of dashcam footage from SD card media submitted in connection with a motor insurance claim.

The examination established, to a forensic certainty, that 12 dashcam recordings from the date of loss - spanning 19:04 to 23:00 AEST on 20 July 2025 - were present on the card on 1 December 2025 and absent on 31 March 2026. A total of 684 DCIM files comprising 71.46 GB of loop footage were deleted during that period. Filesystem artefact analysis confirmed that the card was connected to an Apple macOS device on two documented occasions within the deletion window. The incident-day footage cannot be recovered from the card as submitted.

The case highlights a procedural gap. Dashcam SD card media submitted in connection with insurance claims or law enforcement investigations can be a target for evidence tampering, not merely a source of evidence, and the forensic literature has not previously addressed this scenario or set out a practical methodology for detecting it. The before/after image comparison approach described here addresses that gap in a way that is reproducible, tool-agnostic, and capable of being explained clearly to a non-technical audience.

This methodology depends on a forensic image being acquired before the card is returned to the claimant. The cost is modest and the evidentiary benefit can be substantial. Early forensic imaging of submitted dashcam media should therefore be adopted as standard practice by motor insurers and law enforcement agencies handling vehicular incident investigations.

Operating system artefacts written to FAT32 dashcam media during external connections -including macOS resource forks, FSEvents directories, and Windows System Volume Information folders - provide a useful and underutilised source of corroborative evidence. Their presence indicates external access, their timestamps constrain the timing of that access, and, in the case of resource forks, they may identify which files were accessed during a connection event. These artefacts should be examined routinely in any dashcam forensic investigation where post-incident tampering is suspected.

The methodology described in this paper can be reproduced using standard forensic tools available to a qualified examiner. We hope its publication encourages both the adoption of early imaging protocols by insurers and further research into the detection and prevention of dashcam evidence tampering in motor vehicle investigations.

09 / In this resource

References

[1] H.S. Lallie, Dashcam forensics: A preliminary analysis of 7 dashcam devices, Forensic Science International:

Digital Investigation 33 (2020) 200910. https://doi.org/10.1016/j.fsidi.2020.200910 [2] K. Lee, J.-H. Choi, J. Park, S. Lee, Your car is recording: Metadata-driven dashcam analysis system, Forensic Science International: Digital Investigation 38 (2021) 301131. https://doi.org/10.1016/j.fsidi.2021.301131 [3] H.S. Lallie, Dashcam forensic investigation guidelines, Forensic Science International: Digital Investigation 45 (2023) 301558. https://doi.org/10.1016/j.fsidi.2023.301558 [4] Y.-A. Daraghmi, I.

Shawahna, Digital forensic analysis of vehicular video sensors: Dashcams as a case, Sensors 23 (2023) 7548. https://doi.org/10.3390/s23177548 [5] E. Giovannini, A. Giorgetti, G. Pelletti, A. Giusti, M. Garagnani, J.P. Pascali, R. Fais, Importance of dashboard camera (Dash Cam) analysis in fatal vehicle-pedestrian crash reconstruction, Forensic Science, Medicine and Pathology 17 (2021) 379-387. https://doi.org/10.1007/s12024-021-00354-y [6] N.J. Morley, L.J. Ball, T.C. Ormerod, How the detection of insurance fraud succeeds and fails, Psychology, Crime and Law 12 (2006) 163-180. https://doi.org/10.1080/10683160512331316325 [7] K. Kent, S.

Chevalier, T. Grance, H. Dang, Guide to integrating forensic techniques into incident response, NIST Special Publication 800-86, National Institute of Standards and Technology, Gaithersburg, MD, 2006. https://doi.org/10.6028/NIST.SP.800-86 [8] B. Carrier, File System Forensic Analysis, Addison-Wesley Professional, Upper Saddle River, NJ, 2005. ISBN:

0-321-26817-2.

[9] S. Alboqami, H. Alkurdi, N. Hinnawi, E.U.H. Qazi, A. Almorjan, Digital forensic investigation framework for dashcam, in: S. Latifi (Ed.), ITNG 2023: 20th International Conference on Information Technology-New Generations, Advances in Intelligent Systems and Computing, vol. 1445, Springer, Cham, 2023, pp. 155-162. https://doi.org/10.1007/978-3-031-28332-1_18 [10] Exterro Inc., FTK Imager (Version 4.7), Exterro Inc., Portland, OR, 2024. Available:

https://www.exterro.com/digital-forensics-software/ftk-imager (accessed 3 April 2026). [11] Apple Inc., File System Events Programming Guide, Apple Developer Documentation, Cupertino, CA, 2013.

Available: https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/ FSEvents_ProgGuide/ (accessed 3 April 2026). [12] FFmpeg Project, FFprobe, FFmpeg Developers, 2024. Available: https://ffmpeg.org (accessed 3 April 2026). [13] M. Elsegood, O. Haller, G. Ponte, S. Doecke, A. Baraky, Collection and analysis of EDR data from crash-involved vehicles: 2024 summary report, CASR248, Centre for Automotive Safety Research, The University of Adelaide, Adelaide, December 2024. ISBN: 978-1-925971-81-1. Available: https://casr.adelaide.edu.au/publications/list (accessed 3 April 2026).

10 / In this resource

Author biographies

Tim Allen is Co-Founder and Director of Collision Sciences Australia and holds a Master of Cyber Security from the University of New South Wales Australian Defence Force Academy. He is a certified FBI Level 1 Cyber Investigator, Forensic Explorer Certified Examiner (FEXCE), Cellebrite Digital Evidence Examiner, and holds Berla Certified Vehicle System Forensic Technician (CVST) and Examiner (CVSE) certifications. Tim served for 30 years with the NSW Police Force, where he held roles as a Senior Crash and Major Incident Investigator and as an Electronic Evidence Specialist within the State Electronic Evidence Branch, Special Services Group. He has provided expert witness testimony in NSW criminal courts on matters involving digital and vehicle forensic evidence. Tim co-founded Collision Sciences Australia in 2019 and leads its forensic examination programme, with a specialist focus on vehicle data recovery, dashcam forensics, and digital evidence integrity in insurance and law enforcement contexts.

Rabih Sfarjalani is Co-Founder and Director of Operations at Collision Sciences Australia. He holds a Bachelor of Information Technology Systems Administration from Western Sydney University and a Post Graduate qualification in Cyber Security from the University of New South Wales Australian Defence Force Academy. He is a certified FBI Level 1 Cyber Investigator, IACIS Certified Forensic Computer Examiner (CFCE), Forensic Explorer Certified Examiner (FEXCE), Cellebrite Digital Evidence Examiner, and holds Berla CVST and CVSE certifications.

Rabih served for 13 years with the NSW Police Force, including six years as an Electronic Evidence Specialist within the State Electronic Evidence Branch and the State Technical Investigation Unit (STIU). He contributed to EDR data collection and analysis research conducted by the Centre for Automotive Safety Research at the University of Adelaide in 2024 [13]. Rabih has delivered technical presentations on vehicle data forensics to crash investigation units of the Queensland, New South Wales, Victoria, South Australia, Tasmania, and New Zealand Police, and to the Singapore Health Science Authority and the Australian Defence Force.

Collision Sciences Australia

Sydney, New South Wales, Australia tim@collisionsciences.com.au 3 April 2026

The editor

Forensic Science International: Digital Investigation Elsevier / DFRWS

Dear Editor,

We write to submit for your consideration the manuscript entitled Post-Claim Deletion of Dashcam Evidence: A Before/After Forensic Image Comparison Methodology for Detecting Storage Media Tampering in Motor Insurance Fraud Investigations, by Tim Allen and Rabih Sfarjalani of Collision Sciences Australia.

This paper presents a forensic case study and reproducible methodology for identifying post-claim deletion of dashcam footage from SD card media submitted in connection with a motor insurance claim. The central finding is straightforward: 12 dashcam recordings from the date of loss, independently hash-verified as present on the subject SD card on 1 December 2025, were absent when the card was examined again on 31 March 2026. In total, 684 files comprising 71.46 GB of loop footage had been deleted during a period in which the card was connected to external computing devices on two documented occasions. The incident-day footage cannot be recovered.

The paper formalises a before/after forensic image comparison methodology applied to dashcam storage media in an insurance investigation context, a scenario not previously addressed in the published literature. It also demonstrates the evidentiary value of operating system artefacts written to FAT32 dashcam media during external connections as supporting evidence of post-claim access events. More broadly, it argues that early forensic imaging of submitted dashcam media should be adopted as standard insurer practice because that single procedural step makes the methodology available as a routine investigative tool.

The submission reflects a practical issue we are increasingly encountering in forensic casework across the Australian motor insurance and law enforcement sectors: deliberate tampering with digital evidence, including dashcam media and vehicle electronic data, in connection with insurance claims. That trend is not yet well represented in the academic literature, and the practitioner community currently has little published methodology directed to its detection. This paper is intended to address that gap.

The authors bring combined practitioner experience of nearly 45 years across NSW Police Force electronic evidence examination, crash investigation, and private forensic practice. Both authors hold Berla CVST and CVSE certifications and have delivered technical training on vehicle data forensics to crash investigation units across six Australian state and territory police services, the New Zealand Police, and international agencies. Rabih Sfarjalani contributed to EDR research conducted by the Centre for Automotive Safety Research at the University of Adelaide (CASR248, 2024). Tim Allen has provided expert witness testimony in NSW criminal courts on matters involving digital and vehicle forensic evidence.

This manuscript has not been previously published and is not under consideration elsewhere. All identifying particulars of the subject claim, vehicle, insurer, and claimant have been redacted in accordance with standard case study de-identification practice. The methodology described is reproducible using standard forensic tools available to any qualified examiner, and the hash-verified forensic images on which the findings are based are retained and available for independent verification.

We believe the paper will be of direct value to the readership of Forensic Science International: Digital Investigation, particularly practitioners working at the intersection of vehicle forensics, digital evidence integrity, and insurance fraud investigation. We would welcome the opportunity to revise the manuscript in response to reviewer feedback.

Corresponding author: Tim Allen, Collision Sciences Australia Email: tim@collisionsciences.com.au

Yours sincerely,

Tim Allen

Co-Founder and Director, Collision Sciences Australia tim@collisionsciences.com.au

Rabih Sfarjalani

Co-Founder and Director of Operations, Collision Sciences Australia