macOS Forensics: First-Contact Commands and What Each One Entitles You to Say

Introduction

The first commands you run on a macOS examination are not lookups. Each one is a claim about the machine, and each has a way of returning something that looks right and is not.

The log query that excludes most of the log unless asked. The version command that describes the workstation you are sitting at rather than the volume you attached. The listing that reports what the filesystem shows rather than what is there.

This section is about what each command entitles you to say. The syntax is in the cheatsheets; the judgment is here.

Every command in this section answers one question about the machine, and every one of them has a way of returning something that looks like an answer and is not.

Three commands, and the narrow claim each one actually supports.

Read the right-hand column as the sentence you could defend if somebody asked, rather than the sentence the output invites.

Read the right column as the narrower claim in each case. None of these commands is unreliable; each answers a question slightly different from the one an examiner assumes they asked.

That gap is small enough to be invisible in the moment and large enough to matter in a report. The version of the machine, the contents of a log and the contents of a directory are all things a reader will take at face value, and none of them carries any indication of which question actually produced it.

On a platform that changes annually the risk compounds, because a command whose behavior an examiner learned two releases ago may answer differently now. Checking what a command does on the release in front of you, rather than recalling what it used to do, is the same discipline this module applied to retention and to the log store.

This section is not a reference. The command syntax lives in the course's cheatsheets, and what lives here is the discipline of knowing what each one establishes before its output goes anywhere near a finding.

The distinction matters more on this platform than on most. A macOS examination is conducted largely from a terminal against a mounted volume, so the boundary between the evidence and the examiner's own machine is a path argument rather than a physical separation, and a missing argument silently crosses it.

Every trap in this section has the same shape as the rest of the module. Nothing errors, nothing warns, and the output is well-formed and confident. What differs is only which question was answered. Which makes the habit of naming the question, before reading the answer, the only defense available.

The unified log is the largest record on a Mac, and the default query does not show you most of it. Published description is explicit: the ordinary invocation outputs system logs in chronological order but excludes info and debug messages by default, and including them requires asking.

# The default. Looks complete, and omits the majority of the store.
% log show --archive mercer.logarchive --predicate 'process == "launchd"'

# What you almost always meant
% log show --archive mercer.logarchive --info --debug \
    --predicate 'process == "launchd"'

Two commands, one store, and very different amounts of it. The first returns rows, sorts correctly and gives every appearance of having searched the log.

That is the module's own shape arriving in the tooling. An examiner who runs the first and finds nothing has established that the default level holds nothing, which is a considerably narrower claim than the one they will write down.

The practical rule is to make the flags the default in your own habits rather than remembering them when something looks wrong. A query that returns too much can be narrowed by a predicate, and a query that quietly returned a fraction of the store gives no signal that narrowing is what happened.

It also changes how a negative result gets recorded. Nothing found at the default level is a sentence somebody can check; nothing found is a claim about the log that the command never made. The first sentence is one an opposing examiner can test; the second is one they can simply contradict by running the query properly.

The same care applies to the predicate as to the level. A search restricted to one process name finds only entries that process emitted under exactly that name, and a subsystem that logs under several will be partly invisible to it. Negative results from a narrow predicate are the weakest kind of absence in this whole course. Widening the predicate before concluding anything costs one more query. Two queries and a comparison is a method; one query and a conclusion is a guess with a command behind it.

The log is also the store where this matters most, because it is the largest and the one examiners lean on hardest. A conclusion that something did not happen, resting on a log query, is one of the commonest findings in macOS work and one of the easiest to produce wrongly. Getting it right costs two flags and a wider predicate, and getting it wrong is invisible until somebody else runs the query.

The same reasoning applies to every store this course covers, not only the log. Each has a default view that is narrower than the store, and each will answer a narrow question confidently when a wide one was intended. The log is simply the one where the gap between the two is largest.

A command run on an analysis workstation answers about the analysis workstation unless something points it elsewhere, and the output looks identical either way.

The examiner above holds output from a first-contact session. Two of the four commands describe the wrong machine, and nothing in the output says so.

The general rule is worth stating rather than learning case by case. A command reads the running system by default, so establishing which system each one addressed is part of recording the result, and a session mixing both without saying which is which produces notes nobody can rely on later.

There is a habit that removes the problem rather than managing it. Changing into the mounted volume at the start of a session, and writing paths relative to it, makes every subsequent command visibly addressed at the evidence, and anything accidentally pointed at the workstation stands out in the transcript rather than blending in.

The examiner above is worth working slowly for that reason. The two wrong answers are not obviously wrong; they are the right answers to questions nobody meant to ask. That is the hardest kind of output to catch, because reviewing your own notes shows you plausible values rather than obvious errors.

The cost of getting it wrong is not merely an incorrect note. A system version read from the wrong machine decides which techniques an examiner believes apply, so the error propagates into what they look for rather than stopping at a single wrong line.

It is also the easiest of the three traps to close permanently. Establishing the target once, at the start of a session, and working relative to it means the question never arises again for the rest of the examination. The other two traps have to be handled every time they come up, which is why this one is worth closing structurally.

Structural fixes are worth preferring generally in this work. A discipline that depends on remembering will fail on the day the examination is rushed, and the days an examination is rushed are the days its findings matter most. Building the fix into how a session starts costs one command at the beginning and nothing thereafter.

Reading a subject's log from an image means presenting it as an archive, and a hand-assembled one is rejected until it carries a specific marker. Published description records the assembly: copy the two source directories into a bundle and add a version key to the bundle's information file, without which the system will not recognize it.

# The two directories that hold the store
% cp -R /Volumes/mercer-data/private/var/db/uuidtext \
       /Volumes/mercer-data/private/var/db/diagnostics mercer.logarchive

# Without this, the archive is not recognized
% /usr/libexec/PlistBuddy -c "Add :OSArchiveVersion integer 4" \
    mercer.logarchive/Info.plist

The refusal is the useful part. An unrecognized archive fails loudly, which is the opposite of most failures in this module and worth appreciating while it lasts.

Where a live collection is possible, published description notes the collection command requires root privileges and produces the bundle directly, with the caveat that a reboot may cost some entries. Which route was used belongs in the notes, because the two produce different coverage.

The difference between them is worth understanding rather than treating as a preference. A live collection takes what the running system holds at that moment, including anything about to be discarded; an archive assembled from an image takes what survived to the point of acquisition. Where both exist they should agree, and where they do not the gap is itself informative about what happened between the two.

The assembly is also a change you are making rather than a reading you are taking. The bundle is built on your workstation from copies, so nothing on the evidence moves, and saying that explicitly in the notes forecloses a question somebody will otherwise ask. Copies on your workstation, original untouched, is one clause and it answers the whole objection.

Where the archive will not build at all, that is worth recording as well. A log store too damaged or incomplete to assemble is a fact about the evidence, and it belongs alongside the acquisition notes rather than being retried quietly until something works. On a case where the log was going to answer the central question, that fact changes the plan rather than delaying it.

A mounted evidence volume carries its own metadata stores rather than relying on the analysis machine. Published description records that each mounted volume carries a Spotlight index directory, and that per-file attributes survive on the files themselves as extended attributes as well as inside that index.

Two stores the volume brings with it, and the check that becomes possible.

Read the convergence on the right as the point: two independently written copies are worth more than either alone.

Read the rows as the volume arriving with its own memory. The where-from attribute in particular is the download provenance this course returns to repeatedly, and it is readable at first contact rather than requiring any specialist tooling.

It is also a reason to be careful with what your own machine does to a mounted volume. Indexing, previewing and searching are all operations that can write, which is why the mount discipline from earlier in this module is the precondition for anything in this section.

It is also why the where-from attribute is worth reaching for early. Provenance established before anything is opened is provenance nobody can suggest your handling produced, and on a case that turns on how something arrived, that ordering is worth the minute it costs.

The two copies of those attributes are also worth reading against each other rather than picking one. Agreement between the file's own attribute and the volume's index is corroboration from two places the same writing operation touched at different moments, and disagreement is a question worth following.

The index is also the volume's own rather than a product of your examination, which is what makes it usable at all. An index your machine built while examining the evidence would describe your handling; one that arrived with the volume describes the subject's. Keeping those apart is the same distinction the whole module has been drawing between the evidence and the machine you are working on. An examiner who cannot say which of the two an artifact came from has an artifact they cannot use.

The attributes themselves are worth knowing by name before you need them. Published description lists last-used, date-added, used-dates, downloaded-date and where-from among those that survive on the file, and between them they carry arrival, first use and pattern of use without any specialist parsing at all. Three questions answered from attributes on the file itself is an unusually cheap result on this platform.

They are also durable in a way the index is not. An index can be rebuilt or damaged, and the attributes travel with the file, which means a file copied out of the evidence for closer work carries its provenance with it if the copy preserved extended attributes and loses it silently if it did not.

First contact is about establishing the shape of the machine rather than finding anything, and four or five commands settle most of it.

The five answers that scope everything after them.

Read the left column as questions rather than fields to fill, because each is answered from a different place and only one of them needs a person to hand you anything.

Read the rows as five questions, none of which requires a tool that is not already on the machine. Each one bounds what the later phases have to consider, which is why they come before anything interesting.

The fourth is the one most often skipped and it is the one the second sub of this module was about. A window measured at first contact and recorded with its date is worth more than the same figure recalled later, because the edge moves while the case runs.

None of the five is a finding and that is the point of doing them together. An examiner who runs all five in the first ten minutes has scoped the case; one who runs them as each becomes relevant has answered them at five different moments, against a machine and a log window that were not the same at each. Doing them together also produces a single dated record of the machine's shape, which is what the method section of a report is written from.

The five also make a useful handover document on their own. Somebody picking the case up needs exactly these answers before anything else is meaningful to them, and a case that recorded them at first contact can be handed over in a paragraph rather than an afternoon.

None of them takes longer than a command and a note, which is worth saying because the temptation at first contact is always to start looking for the thing the referral described. That instinct is the one the first sub of this module was written against, and it is no weaker for being at the keyboard rather than in the planning.

A command's output is only as useful as the record of how it was produced, and on a platform where the same command answers differently depending on what it was pointed at, that record is not optional.

Read the rows as three things a reader cannot reconstruct from the output alone. None of them is visible in the result, and all three change what the result means.

The flags line is the one that catches experienced people. A log query pasted into notes without its invocation looks like a record of the log, and six weeks later nobody can tell whether it searched the whole store or the default level, which means the negative result in it cannot be relied on and cannot be re-derived without going back to the evidence.

The target line has the same property in a different direction. Output showing a system version, an account list or a directory listing is identical whether it described the evidence or the workstation, so a note without the target is a note whose subject is unknown.

Capturing sessions rather than copying results is the practical form of this. A transcript carries the invocation, the target and the time without anybody having to remember to write them down, and it costs nothing to start one before the first command.

It also solves the problem of the command you ran three hours ago and can no longer reproduce. On an examination of any length the difficulty is rarely the analysis and frequently the reconstruction of what was already done, and a transcript turns that from recall into a search.

It also gives the examination something to hand a reviewer that is not the report. A transcript is the raw record of what was done, in order, and it is the only artifact that can settle a question about method after the fact without anybody having to trust a summary of it.

That is the note to end this sub on. Everything in this module has been about the difference between what a machine reports and what you are entitled to conclude from it, and the commands are where that difference is produced. A session recorded properly is the record of how carefully that line was held.

It is also the sub that makes the next one possible. Establishing which devices this Mac knows about is a listing and a property list, and both are commands run against a mounted volume, which means every trap in this section applies to them before anything in the next one does.

Every command in this section works on any Mac, and the traps are only convincing once you have watched your own machine produce the wrong answer confidently.

Every command at first contact answers one question and has a way of returning something plausible and wrong. Published description records that the ordinary log query excludes info and debug messages by default, so a search that found nothing established only that the default level holds nothing. A command addresses the running system unless pointed elsewhere, so the target belongs in the notes alongside the invocation. Reading a subject's log from an image means assembling an archive from the two source directories and adding a version key to the bundle's information file, without which the system will not recognize it, while the live collection command requires root and may lose entries across a reboot. Published description also records that each mounted volume carries its own index directory, and that per-file attributes including last-used, date-added, downloaded-date and where-from survive both on the files and inside that index.