macOS DFIR: Pairing Records, Backups and Scoping the Devices a Mac Trusts

Introduction

A Mac keeps a record of every device that ever trusted it, and that record is readable in minutes from a directory listing.

That matters at orientation rather than later, because the population of devices in a case changes the scope, the requests that need sending, and how any synced artifact should be read. A plan made for one machine, in a case that turned out to have four devices, is a plan made twice.

This section establishes which devices exist and what of theirs sits on this disk. What is inside their material is analysis, and the course returns to it properly in its own module.

A Mac is rarely the only device in a case, and it keeps a record of the others. This section establishes which devices exist and what of theirs is reachable, which is scoping rather than examination.

Read the left column as three things settled in minutes. The population of devices is the kind of fact that changes a collection plan, and a plan made without it is a plan for one machine in a case that had four.

The four is not hypothetical on a modern estate. A person with a work laptop usually has a phone, frequently a tablet, and often a personal machine that has touched the same accounts, and the referral will name whichever one somebody was looking at when they noticed a problem. Which device the referral names is a fact about who noticed rather than about where the activity was.

Doing it here rather than later is the whole point. Establishing that a phone was paired to this Mac is cheap on the first day and expensive on the twentieth, because the people who could confirm it, and the device itself, both become harder to reach as a case ages.

The asymmetry is worth stating plainly. Almost everything else in a macOS examination sits on a disk that is not changing, so it waits; a device population involves objects and people in the world, and those do not. That difference is why this question belongs at orientation even though the artifacts it reads are unremarkable. Importance and difficulty are unrelated here, which is exactly why the question gets skipped.

It also competes badly for attention at the start of a case. The referral describes something concrete and interesting, and a directory listing of pairing records describes nothing at all until somebody asks the right question of it later.

When somebody taps Trust on a phone connected to a Mac, the Mac keeps a file. Published description records these pairing records, historically called lockdown files, as created at that moment and stored on the host at a defined path, holding cryptographic keys that let the two talk.

# The directory the host keeps its pairing records in
% ls -la /Volumes/mercer-data/private/var/db/lockdown/

# Each record is a property list named for the device it pairs with

One directory, one file per trusted device, and the listing alone answers the population question without anything being opened.

Published description is also clear about how long they last. Apple's own guidance says trusted computers remain trusted unless the user changes which computers they trust or erases the device, so a pairing record is a record of a relationship that persists rather than a snapshot of one moment.

For an examiner that has a useful consequence and a limit. The useful part is that the record survives long after the connection, so a phone plugged in once a year ago is still represented. The contrast with the log store is worth drawing explicitly: that store discards by size within days, and these records sit on disk until somebody deliberately removes them, so the two ends of this module's retention spectrum are a week and indefinitely. The limit is that persistence works against dating: a record establishes that a trust relationship existed, and its file timestamps speak to when the record was written rather than to every occasion the two devices spoke.

So the honest reading of a pairing record is narrow and still useful. This Mac and that device established trust, at or before the time the record carries, and the relationship was not revoked. Anything more specific about when they were connected comes from other artifacts rather than from the record itself.

That is worth writing carefully because the temptation runs the other way. A file with a date on it invites being read as an event, and a pairing record is a standing arrangement rather than an occurrence, which is the same distinction this module drew between configuration and execution. Stated as a relationship it holds; stated as a connection it does not.

The supporting artifacts for a connection are elsewhere on the machine in any case. Attachment events, backup dates and log entries all speak to particular occasions, and a population established here is what tells you which of them to go looking for.

These files are not only evidence that a device was trusted. Published description records that forensic practitioners use them to authenticate to a locked device and produce a backup without the passcode, subject to the device being in the right state and not having rebooted since.

The locator above holds a first-contact listing. Work out which entries establish that another device exists and which are about something else entirely.

Several of the decoys are artifacts this module has already taught, which is the point. A record can be sound, relevant and still belong to a different question, and at orientation the question is only whether another device exists.

The capability side is what makes this sub unlike the rest of the module. Everywhere else, finding an artifact earlier or later changes only the order of the work; here, finding it earlier can change what evidence is still available to anybody, which is a different kind of urgency and worth feeling once.

That dual nature has a practical consequence at orientation. A pairing record found on day one, on a case where a locked phone is also in evidence, is time-sensitive in a way nothing else in this module is, because the conditions under which it remains useful are lost the moment that phone restarts.

Raising that on day one is part of the examiner's job rather than somebody else's. Whoever is holding a seized phone needs to know that letting it power down forecloses an option, and they will not know it unless somebody who understands the pairing relationship tells them while it still matters.

That is an unusual position for an examiner to be in and worth recognizing. Most of this course is about reading what already happenedMost of this course is about reading what already happened; this is one of the few places where saying something on the first day changes what evidence will exist later.

It belongs in the notes as advice given rather than only as a fact established. Recording that the responder was told to keep a device powered, and when, separates an option that was preserved from one that was lost before anybody thought about it.

The pairing directory is protected, and the history of reaching it is a worked example of everything the setup sub covered. Published description records that macOS protects these files with access permissions, that a previously working method stopped working at a specific release, and that the workaround discussed at the time was disabling system integrity protection.

Read the third row as the answer rather than a consolation. Almost everything this section needs is readable from an image without weakening anything, and the live-machine difficulties are a live-machine problem.

That is worth knowing before somebody suggests otherwise under time pressure. The instinct to disable a protection on the analysis machine in order to read a subject's protected path is the exact error the setup sub warned about, and it is available here in a form that sounds authoritative because published discussion describes it.

The discussion is also old enough to be worth checking rather than following. It describes a specific release and a specific workaround, and this course's standing habit is to establish what the current system does rather than to inherit a method from a write-up, which applies as much to a technique that weakens your machine as to one that reads an artifact.

The safer route is almost always available in any case. If the material is on an image, the live-machine protections are not in play, and if the question genuinely requires a live machine then it requires a decision recorded at the time rather than a workaround found in a search result.

The recorded decision is what makes the difference defensible later. Weakening a protection with a stated reason, a time and a scope is an engineering judgment somebody can assess; the same change with no record is the configuration the setup sub described as indistinguishable from an attacker's.

Where a device was backed up to this Mac, the backup sits on this disk, and its catalog answers the scoping question without anything being decrypted or parsed.

# One directory per backed-up device, named for its identifier
% ls -1 "/Volumes/mercer-data/Users/d.mercer/Library/Application Support/\
    MobileSync/Backup/"

# The catalog files describe the device and the backup, before any content
% plutil -p .../Info.plist | grep -Ei 'Device Name|Product Version|Last Backup'

A device name, a system version and a date, read from a property list. That is the whole of what this sub needs from a backup, and it is available whether or not the backup is encrypted.

The catalog also tells you which device the directory belongs to, which matters because the directory itself is named for an identifier rather than for anything a human recognizes. Without reading the catalog a listing is a set of opaque strings; with it, the same listing is a list of named devices with dates.

That last point is the one that makes this worth doing at orientation rather than deferring. An encrypted backup nobody can open still tells you a named device existed, ran a particular system version, and was last backed up on a particular date, which is three facts a collection plan can act on without a single credential.

Where several device directories exist the listing is doing even more work. Each one is a device somebody would have to account for, and a machine with four of them is a machine whose examination was never going to be about one laptop. The listing costs one command and reframes the case.

The contents are a later module's work and the distinction is worth keeping. This section establishes that a backup of a named device exists and when it last ran; whether it holds anything relevant, and what encryption does to that, is analysis the course returns to properly.

Keeping that boundary is what makes this sub orientation rather than a compressed version of a later module. The catalog answers existence, identity and date, which is everything a collection plan needs; opening the backup itself answers questions nobody has asked yet, and doing it now would mean reading content before establishing whether it bears on anything. That ordering is the same one the first sub of this module set out, arriving in a different form.

Establishing the other devices early alters three things at once, which is why it belongs in orientation rather than in whichever module first needs it.

WHAT A DEVICE POPULATION CHANGES

  the scope        an examination of one machine, or of a person's devices
  the requests     a phone has an owner, a carrier and possibly a provider,
                     and each request has a lead time
  the attribution  artifacts that arrived by sync speak for an account rather
                     than for the machine holding them

  none of these can be fixed later at the same cost

Read the rows as three consequences, of which the third is the one that catches people. An artifact synced from another device sits on this disk looking exactly like local activity, and knowing the population is what makes that question askable at all.

Later work on synced and shared material assumes a population is already known. Coming to it without one means doing this listing then instead, on a case where the requests that depend on it have not been sent and the devices have had weeks to change.

The three consequences also explain why this is orientation rather than a cross-device topic. None of them is about reading another device's data, which is the later module's subject; all of them are about what this examination should be shaped like, which is what an orientation module exists to settle.

An examiner without the population does not misread the artifact so much as never reach the question. A file is present, it looks local, and nothing prompts anybody to ask whether it originated somewhere else, which is how a synced document becomes evidence of local activity in a report.

The cost of that error is high because it is invisible in both directions. The report does not say the file was local, it simply does not say otherwise, and a reader without the population has no way to know the question was ever open.

The requests line is the one with a clock on it. Devices get wiped, sold and reissued, and a phone identified on the first day is a phone somebody can be asked to produce while it still exists in the state the case cares about.

The attribution line has no clock on it and is the one that quietly damages reports. Nothing forces an examiner to confront it, the artifact sits there looking local, and the error surfaces only if somebody downstream happens to know the population and asks where a file came from.

The output of this section is a short list, and writing it explicitly is what turns it from something the examiner knows into something the examination did.

Read the third row as the one a reader will check. A population that lists only what was examined tells nobody whether anything was left out, which is the same problem the honest-limits sub raised about absence.

An excluded device is also frequently the right decision rather than a gap. A family member's phone paired to a shared machine is not automatically in scope, and saying that it was identified and excluded, with the reason, is a stronger position than either examining it or leaving it unmentioned.

Writing exclusions down also protects the examination from scope creep in the other direction. A population with reasons attached is a boundary somebody agreed to, and an examiner asked later why a device was not looked at has an answer that was recorded before the question arose rather than constructed after it.

That is the same discipline the rest of this module applies to limits, arriving in the one place where the limit is a choice rather than a property of the evidence. Everywhere else the examination could not reach something; here it could and decided not to, and only a recorded reason tells those two apart.

The population is also the last thing this module establishes before the course proper begins, and it is deliberately the widest. Everything from here narrows: which artifacts, which stores, which questions. Starting from the full set of devices and working inward is the opposite of starting from the referral's one machine and discovering the others when an artifact refuses to make sense, which is how most cases acquire their second device.

This list is also what the later work picks up. The cross-device work in this course begins by assuming a population has been established, and a case that never established one arrives there with the question still open and the evidence colder.

The list also gives a reviewer something concrete to check early. Population is one of the few things in an examination that can be verified independently and cheaply, because the artifacts are small and the reading is a listing rather than an interpretation.

A reviewer who can confirm the population in five minutes has confirmed the foundation of the scope, which is worth more than checking any individual finding. Foundations are cheap to check and expensive to get wrong, which is the argument for checking them first. Everything downstream inherits the assumption that these were the devices, and that assumption is either written down and checkable or it is nowhere. The listing takes minutes and the assumption lasts the whole case.

Every Mac that has ever had a phone plugged into it holds these records, and looking at your own is the fastest way to see how much a machine remembers about devices that are not it.

A Mac keeps a record of the devices that trusted it. Published description records pairing records, historically called lockdown files, as created when a user taps Trust and stored on the host at a defined path, holding the cryptographic keys the two use to talk, and Apple's own guidance says trusted computers remain trusted unless the user changes which computers they trust or erases the device. Those records are also a capability: published description records practitioners using them to authenticate to a locked device and produce a backup without the passcode, subject to the device's state and its not having rebooted. Reaching them on a live machine runs into the access and integrity refusals this module already covered, and published discussion records a method that stopped working at a release and a workaround of disabling integrity protection; from a mounted image neither applies, because the protection belonged to a running system. Backup catalog files name the device, its system version and the date of the last backup before anything is decrypted.