Skip to content

Add Ford Sync Gen3 Bluetooth artifacts and Berla iVe export handling - #167

Merged
abrignoni merged 3 commits into
mainfrom
feat/berla-ive-sync-gen3
Aug 30, 2026
Merged

Add Ford Sync Gen3 Bluetooth artifacts and Berla iVe export handling#167
abrignoni merged 3 commits into
mainfrom
feat/berla-ive-sync-gen3

Conversation

@abrignoni

@abrignoni abrignoni commented Aug 30, 2026

Copy link
Copy Markdown
Owner

Adds Ford Sync Gen3 support, and a way to get at Berla iVe exports.

  • Bluetooth Phonebook, Call History and Paired Devices, from the extension-less btpbk and btpersist stores under BT/, numbered per paired handset.
  • Berla iVe Export Record from Vehicle.json, so a run against a .iVa reports the vehicle and its acquisitions instead of an empty report.
  • admin/scripts/unwrap_berla_iva.py lifts the nested source files zip out and checks it against the SHA-256 the export records.

CallType is decoded by matching row sets against the unit's own call tables, not assumed. Call times record no timezone and are taken as written.

abrignoni and others added 3 commits August 30, 2026 17:44
A .iVa is a ZIP whose payload is another ZIP, so the seekers cannot reach the
vehicle's files and a run against one produces an empty report.

admin/scripts/unwrap_berla_iva.py lifts DCASourceFilesUpload.zip out and checks it
against the SHA-256 the export records for it, in both Summary.json and Manifest.json,
refusing to continue if those disagree or the copy does not match.

berla_ive_export reads Vehicle.json, which sits uncompressed at the top of the export,
so a run against a .iVa reports the vehicle and one row per acquisition instead of
nothing, and names the unwrapping step. It validates the JSON shape and skips any
Vehicle.json that is not an iVe export. Counts in those rows are what iVe reported for
its own parse and are labelled as such.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Three artifacts from the two extension-less SQLite stores under BT/ on the Sync Gen3
user data partition, both numbered per paired handset in slots 1 to 12.

Contacts and calls come from btpbk. Calls read the Combined<N> tables, which are the
union of the InCall, DialCall and MissCall tables the unit keeps alongside them. The
CallType mapping is derived from the data: filtering Combined by each value gave a
row set identical to the correspondingly named table on both populated handsets, so
1 is received, 2 dialled, 4 missed. Other values are reported as stored.

The unit writes call times as six text components with no timezone recorded anywhere
in the store, so they are assembled as written and nothing is converted.

Paired devices come from btpersist, joined to DeviceOrder and HFPdeviceOrder for the
primary flags. That table holds current pairings only, a narrower set than the
devlog_*.txt files btDevices.py parses in the same directory.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
VLEAPP reads the files iVe carved out of the head unit's QNX6 volumes, not the raw
image the export also carries, and no filesystem type Sleuth Kit supports can walk
QNX6. That is not the only route: qnxprobe reads QNX6 superblocks directly and writes
the logical files to a zip.

Extracting the raw image that way and running these modules against the output gave
507 contacts, 126 calls and 2 paired devices, matching the run against the export's
own extracted files, with btpbk and btpersist byte-identical by SHA-256. The same
pass found a fourth QNX6 volume the export carried no extracted files for.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@abrignoni
abrignoni merged commit 9f8ae06 into main Aug 30, 2026
10 checks passed
@abrignoni
abrignoni deleted the feat/berla-ive-sync-gen3 branch August 30, 2026 22:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant