The Cell Phone Inspection Protocol: What Trucking and Civil Litigators Need to Get Right Before the Device Is Touched

Lance Sloves
5 days ago
8 min read

In a trucking case, the driver's phone is often the single most contested piece of evidence in the file. Whether it was in use at the moment of impact, whether it was handled hands-free, whether the driver was streaming, texting, or navigating — these questions are answerable, but only if the device is preserved and imaged correctly, and only if the parties agree on how before anyone plugs in a cable.

The same is true in non-compete and trade secret litigation, employment disputes, and personal injury matters generally. The forensic question rarely turns on whether the data existed. It turns on whether the acquisition method was capable of capturing it, and whether the examiner can defend that method under Rule 702.

What follows is the framework Computer Forensic Services, Inc. uses when we draft or negotiate a cell phone inspection protocol — and the parts attorneys most often leave out.

Why a Written Protocol Exists at All

A stipulated protocol does three things that an informal agreement cannot:

It fixes the scope in advance. Data categories, date ranges, and custodians are defined before extraction, which keeps the inspection from becoming a fishing expedition and keeps privacy objections from becoming a motion.
It documents chain of custody. Intake condition, device identifiers, network isolation, and hash verification are recorded from the moment the device changes hands.
It survives challenge. A protocol signed by both experts and both counsel is exceptionally difficult to attack later. The party who wanted a different method had the opportunity to say so.

A workable protocol should conform to SWGDE guidelines and NIST SP 800-101 Rev. 1, and should state plainly that proposed capture methods may require modification based on device condition, OS version, and available extraction capability — with any modification made by written agreement among the parties' experts.

Acquisition Tiers: Full File System vs. Logical

This is where most protocols go wrong, and where opposing counsel most often gets away with producing less than they should.

Full File System (FFS) Extraction

An FFS extraction captures the complete file system of the device: system files, application databases, protobuf and plist artifacts, SQLite journals and write-ahead logs, cache directories, and deleted content where it remains recoverable in unallocated database pages.

This is the only acquisition tier that reliably answers the questions trucking litigation actually asks:

Was the screen on and unlocked at the time of impact?
Was a specific application in the foreground?
Was the device connected to a vehicle over Bluetooth or CarPlay/Android Auto?
Was a message drafted, sent, or read within the relevant window?
Was content deleted after the incident?

A physical image, where the device generation supports it, offers the same or greater completeness. For litigation purposes, physical and full file system acquisitions are the only forensically sufficient tiers. Everything below is a fallback, not a plan.

Logical and Advanced Logical Extraction

A logical extraction pulls what the device's own backup or API layer is willing to hand over: contacts, call logs, SMS/MMS, some media, and — with advanced logical — a subset of application data. It is fast, it is easy, and it is what gets produced when nobody in the room knows to ask for more.

What a logical extraction does not reliably contain:

Deleted messages recoverable from SQLite free pages and WAL files
KnowledgeC and biome data on iOS — the artifacts that establish device usage, screen state, app focus, and unlock events
Location and motion artifacts beyond what the user-facing map application exposes
Third-party application databases in their native form
System logs that establish device power state and connectivity

If a protocol permits a logical extraction as the primary method, it has quietly conceded the case's most probative artifacts. Draft the hierarchy explicitly: FFS preferred; advanced logical only where FFS is not achievable on the device and OS version; logical as a documented last resort, with the limitation disclosed in the report.

Third-Party Applications: Where the Evidence Actually Lives

Native SMS is no longer where people communicate. In practice, the relevant conversations in trucking and employment matters sit inside applications that never appear in a logical extraction in usable form:

Encrypted messaging (Signal, WhatsApp, Telegram, Wickr)
Employer and dispatch platforms (Samsara, Motive, KeepTruckin, Omnitracs driver apps)
Navigation and routing (Google Maps, Waze, Trucker Path)
Social and streaming (TikTok, YouTube, Instagram, Spotify)
Cloud storage and file sync (Dropbox, Google Drive, OneDrive)

These live as SQLite databases and protobuf blobs inside application containers. They are recovered from an FFS image, parsed with tools like MAGNET AXIOM, CELLEBRITE UFED / Physical Analyzer, and OXYGEN FORENSIC DETECTIVE, and — where a commercial parser does not yet support the app version — carved and interpreted manually with iLEAPP, ALEAPP, and VLEAPP.

A protocol should name the analysis tooling and should reserve the examiner's ability to use additional validated tools as warranted by the data. Application versions change monthly; parser support does not.

Cloud Collection: iCloud and Google Takeout

Device-side data is only half the picture. Modern phones offload aggressively, and a device replaced two months after the crash may hold nothing — while the account behind it holds everything.

Apple / iOS. iCloud backup (device-specific), iCloud-synced data, and iCloud downloads. In current practice, iPhone backups through iOS 18 are collectible from iCloud with the custodian's credentials and two-factor cooperation — meaning a device that was traded in, damaged, or lost after the incident is not necessarily a dead end. Where Advanced Data Protection has been enabled, end-to-end encryption limits what is retrievable without the custodian's participation, and the protocol should say so.

Google / Android. Google Android Backup, Google Takeout (device-specific), My Activity logs, and Google Drive synced content. Takeout is frequently the most valuable single collection in a trucking case, because Location History and Timeline data — where enabled — can independently corroborate or contradict the driver's account of speed, route, and stop duration.

Samsung. Android is not one ecosystem. Samsung maintains its own proprietary backup path — Samsung Cloud device backup and Samsung account data — that runs parallel to Google Backup and often holds content Google's does not, including Samsung Messages, Samsung Notes, call logs, and device settings. Samsung Smart Switch backups may also exist locally on a computer or external drive the custodian used during a device transfer. Neither surfaces in a Google Takeout export. If the subject device is a Galaxy, the protocol should name Samsung Cloud and Smart Switch as separate collection targets, with separate credentials, rather than assuming "Android backup" covers it.

Practical requirements the protocol must address in advance:

Credentials. Apple ID and password, or Google account credentials, provided before the examination date.
Two-factor authentication. A designated individual, authorized to approve verification prompts, must be reachable during the collection window. Nothing derails an inspection faster than a 2FA prompt with no one to answer it.
Scope limitation. Only data associated with the subject device should be extracted. Say this in writing; it defuses most privacy objections before they are filed.
Preservation. Send the cloud preservation letter early. Google Location History has user-configurable auto-delete intervals as short as three months.

Cloud collections should be performed in a forensically sound manner with full logging and hash verification, exactly as device extractions are.

The Sources Trucking Protocols Forget: Dashcams and ELDs

A cell phone protocol that ignores the vehicle is only doing part of the job. Two sources are routinely lost because no one issued a hold in time.

Dashcam SD Cards

Most consumer and fleet dashcams record in a continuous loop to a removable SD card. Depending on card capacity and resolution, the overwrite window can be as short as a few hours. Event-triggered clips may be write-protected into a separate directory, but that protection is not guaranteed and is frequently overwhelmed.

Handle the card as evidence, not as media:

Image the card physically, at the card level, using a hardware write blocker — never mount it read-write, never "just copy the files off."
Hash the image (SHA-256) before analysis.
Carve unallocated space. Overwritten loop segments frequently leave recoverable fragments, and the file system metadata itself establishes recording continuity and gaps.
Preserve the embedded telemetry. Many units write GPS coordinates, speed, and accelerometer data into the video container or a parallel log file. That telemetry is often more valuable than the footage.

Some fleet systems (Samsara, Lytx, Motive) upload event clips to a vendor cloud. Those uploads have their own retention schedules and require a separate subpoena or preservation demand.

ELD Dashboards and Telematics

Electronic Logging Device data is not a single artifact. It is a device on the truck, a carrier-facing web dashboard, and a vendor-side database — each with different retention and different fidelity.

The carrier's ELD dashboard export is the starting point, not the ending point. Exports are summaries. Request the underlying event records, including edit and annotation history.
Edits matter. Under 49 CFR § 395.30, ELD systems must retain original records alongside edits, with driver certification of any change. A record showing "off duty" that was edited three days after the crash tells a story the summary export does not.
Duty status changes, engine on/off events, and unassigned driving segments should be requested by name.
Telematics beyond the ELD — hard braking, speed, fault codes, GPS breadcrumb intervals — often sits with the same vendor and is preserved under a different schedule.

Correlating ELD duty status against phone usage artifacts and dashcam telemetry is where a trucking case is usually won or lost. Any one source can be explained away. Three sources telling the same story cannot.

Extraction Verification, Reporting, and Return

The mechanics that make findings admissible are unglamorous and non-negotiable:

Network isolation on receipt. Airplane mode, Wi-Fi/Bluetooth/cellular disabled, Faraday enclosure where the device cannot be placed in airplane mode.
Documented device identifiers. IMEI, serial, OS version, ICCID, storage capacity, and device clock offset against a known accurate time source.
Hash verification. SHA-256 and/or MD5 on the resulting image, recorded in the extraction log alongside tool name, tool version, and extraction type achieved.
Analysis on the copy only. The original device data is never modified.
Production in agreed formats. UFDR reader files, AXIOM portable cases, or targeted PDF/Excel/HTML exports limited to the data categories the parties stipulated.
Resealing and return. Tamper-evident container, examiner's initials, date, updated chain of custody.

And one item counsel controls entirely: get the passcode in writing from the custodian before the device leaves their hands. Passcode bypass and brute-force capability exists in current tooling, but it consumes examination time and, on some device and OS combinations, is not guaranteed. A written passcode is free.

The Point

Digital evidence in a trucking case is not one artifact. It is a phone, an account, a memory card, and a fleet dashboard, each with its own retention clock running from the moment of the crash. The protocol you negotiate in month two determines what is still recoverable in month nine.

Get the acquisition tier right. Name the cloud sources. Preserve the SD card and the ELD event records before they cycle. Then let the correlation do the work.

Computer Forensic Services, Inc. has served civil litigation counsel from Dallas since 2002, working for both plaintiff and defense across Texas, Louisiana, Florida, Oklahoma, and New Mexico. Lance Sloves, CCE #282, is a court-qualified expert witness in digital forensics and mobile device examination.

If you are drafting or responding to a cell phone inspection protocol, call 214-306-6470 or visit cfsiusa.com. Early consultation costs nothing and preserves options that expire.

This article was drafted with AI assistance and reviewed, edited, and approved for publication by Lance Sloves, CCE #282. All technical content reflects CFSI's examination practice and the professional judgment of the author.

214.306.6470 info@cfsiusa.com