What survives a wipe, a reset and a reinstall

What does a wiping tool actually remove?

A wiping or cleaning utility overwrites or purges content inside a defined set of targets. Deletion by contrast is ordinarily a bookkeeping change that unlinks a file and leaves its content in place until something reuses the space.

The word “wiping” covers two quite different operations and litigators routinely receive reports that do not separate them. A privacy cleaner enumerates known locations — browser profiles, temporary directories, recent-item lists, some registry values — and clears them. A disk wiper overwrites a volume or a free-space region with patterned data. The first leaves most of the machine intact and is by far the more common finding; the second is a different event with different traces.

What both share is that they act on content and not on the operating system’s record of activity. A cleaner has no reason to rewrite the NTFS change journal, and a free-space overwrite has no effect on records held in allocated files. That asymmetry is the whole subject of this page: the bookkeeping usually outlives the books.

The bookkeeping usually outlives the books.

Four levels of destruction, and what each one leaves

Treating these as one thing produces bad questions in discovery and bad findings in reports. They are ordered by how much of the device they touch.

What survives a cleaning utility?

More than clients expect, and the reason is structural: a cleaner has a list, and the operating system writes to places that are not on it.

The filesystem’s own records

The USN change journal is one of the few sources that shows deletions as events rather than as absences. A cluster of delete records at one hour is a finding; an empty folder is not. Two limits belong in the same sentence. The journal is capped and rolls over, so on a busy volume it may cover days or weeks rather than months. And deleting the journal is a single administrative command — recreating it starts a fresh sequence, which is itself detectable from the sequence numbers.

The NTFS transaction log is finer grained and much shorter lived, often hours on an active workstation, because it is a small circular buffer. Where the timing lines up it can corroborate or contradict an $MFT timestamp independently, which is what a contested timeline needs. It is also the artifact most easily destroyed by leaving a machine running, which is why preservation timing is worth more than any later analysis technique.

Records of the cleaner itself

This is where reports most often overstate, so the distinctions matter. Installer entries, uninstall registry keys and application directories establish that the program was present. Prefetch, where the feature is enabled, supports an inference that a binary ran, and retains a bounded run count with a limited set of last-run times. ShimCache and Amcache record that a binary existed and that its metadata was queried — not that it executed, which is the single most common error in a wiping analysis. UserAssist records launches through the shell for a specific user, and survives uninstallation of the program.

One acquisition detail changes what ShimCache can say at all: the in-memory cache is written at shutdown, so an image taken from a running system may not contain the most recent entries. That has to be stated where the acquisition was live.

Historical copies and side channels

• Volume shadow copies are the closest thing a workstation has to a backup nobody thought to tamper with, and frequently hold an earlier version of a document. They are created and discarded by the system on its own schedule and under space pressure, so the available set is unpredictable and shrinking — and deleting them is easy and leaves its own trace.
• Security-product logs record paths of files that were scanned, so they sometimes retain the only surviving reference to a file that was created and deleted between other artifacts’ snapshots. They roll on size and may cover only weeks.
• SRUM keeps bytes sent and received per application per user in hourly buckets, over a rolling window commonly measured in weeks. It is often the only local record bearing on how much data left a machine, and a shadow copy sometimes holds an older version of the database covering a period the live one no longer does.
• Shellbags persist in the user hives long after the folder and its volume are gone, which is what makes them valuable. They are per-user, so an examination scoped to the wrong profile finds nothing, and they carry no volume serial number — so alone they cannot attribute a folder tree to a physical device.
• File slack and unallocated space hold fragments the filesystem never clears. Fragments recovered there are genuine evidence that data once existed on the volume, and are usually partial, undated, and unattributable to a user action.

What survives a factory reset or a reinstall?

On the device itself: less, and it depends heavily on which option was taken. A reset that only removes files behaves much like a fast format — structures are rebuilt, most of the volume’s previous content is not overwritten, and a physical image can still recover from unallocated space. A reset that overwrites the drive does not leave that. The $MFT survives a quick format for the same reason, and its records can establish that a file of a given name and size existed at a path when nothing else on the volume can.

Three things change the calculation and all three should be established before an opinion is written.

• Storage technology. On solid-state media, controller housekeeping can discard the content of deleted files with no user action at all. Absence of a recoverable file on an SSD is weak evidence that it was never there, and saying so is not a hedge — it is the accurate statement.
• Whether an image was taken. A logical copy of a reset machine collects the new file set and nothing else. Unallocated space, slack, journals and hives are captured by a physical acquisition and lost by a logical one. This decision is usually made in the first week of a matter and determines what can be answered two years later.
• Whether the reinstall was to the same volume. A new installation on the same physical disk overwrites progressively as it is used. The same machine imaged a week after the reinstall and a year after it are not comparable evidence.

macOS and Linux keep a different but equally rich set of activity records — FSEvents, Spotlight metadata, the unified log, and quarantine attributes recording where a downloaded file came from. The method does not change with the platform; only which record answers the question does.

The records that were never on the device

This is the section that decides wiping matters, and it is the one most often reached last. No action taken on an endpoint removes a record held somewhere else.

• Cloud-tenant audit logs record file access, sharing, mailbox operations and administrative changes. Retention is governed by the tenant’s licensing and by record type, and the defaults have changed over time — confirm what the tenant actually retains rather than relying on a figure. Once the window closes, nothing on any endpoint reconstructs it.
• Endpoint agent telemetry is written off the device as it happens. Retention is a commercial term rather than a technical one and the hot searchable window is often short, so preservation means telling the vendor and the customer to hold and export before it closes.
• Sync-service logs and the provider-side history can show that a file existed, was modified, or was removed, on a timeline the local machine no longer holds.
• Identity provider sign-in logs and forwarded process-creation events survive because they left the device. Whether forwarding to a collector existed is a question worth asking at the first discovery conference, because it converts a short local window into usable evidence.

What does “nothing found” actually license you to say?

Very little, and this is where wiping opinions get into trouble in both directions. Three distinct findings get reported with the same words.

The general test to apply to every cited artifact in a wiping report: what retention did the system enforce, and did the examiner establish that window or assume it? An examiner who never looked at the log-size policy has drawn a boundary around the evidence without knowing where the boundary is.

Wiping traces and intent under Rule 37(e)

Rule 37(e) asks about loss of electronically stored information, whether reasonable steps were taken to preserve it, and — for the severest measures under 37(e)(2) — whether a party acted with intent to deprive another party of the information’s use. Wiping traces bear on that last question in a way ordinary deletion does not, which is exactly why they attract overreach.

The reported rulings are consistent about where the line falls, and it is not where examiners expect.

• Intent is not the examiner’s question. In U.S. Gypsum v. Lafarge North America the court held that a technical account of how information was damaged, lost or destroyed cannot shed light on intent without straying into improper speculation, and barred opinions on mental state from both sides’ examiners.
• Nor is the legal characterisation. In Mintel International Group v. Neergheen both experts were permitted to explain what happened to the documents on the computer and the USB drives, and precluded from opining whether the conduct amounted to spoliation or misappropriation. The U.S. Gypsum court went further and directed an expert to avoid the loaded word itself.
• Opinions about named wiping programs get struck on their own. In Nucor Corp. v. Bell both examiners satisfied Rule 702 generally, and the one exception was the plaintiff’s expert’s opinions on two named wiping programs.
• A late wiping finding needs a supplement, not a trial mention. In United States v. Dillingham cleaning-software testimony should have been excluded: it fell outside the expert notice and was not supported well enough, and the problem was compounded when counsel told the jury the logs of viewed images had been wiped by the software. Wiping artifacts are commonly found after the report is served, which is precisely why this is the most frequent late addition to a forensic examiner’s testimony.

What survives all four of those rulings is a narrow and durable kind of finding: this program was installed on this date; these execution artifacts record runs at these times; the change journal records deletion events in this window; this region of the volume is conspicuously clean where comparable regions are not; and the following records were preserved off the device. Each of those is checkable, none of them uses a word with a legal test inside it, and together they are more useful to counsel than a conclusion about intent that will not survive the motion.

Frequently asked questions

Related reading

• Forensic proof of spoliation under Rule 37(e)

  The rule's structure, what each subdivision requires, and which findings bear on reasonable steps rather than on intent.

• The artifact index

  Every artifact named on this page, with what it proves, what it cannot prove, how it is attacked, and how long it survives.

• Evidence preservation deadline check

  Which short-window artifacts are still likely to exist given when the conduct happened and when the device can be imaged.

• Employment and departing-employee matters

  Where wiping findings arise most often, and what the examination is actually asked to establish.

• The Daubert factors applied to forensic method

  Why a wiping opinion is a Rule 702(d) problem rather than a factor problem, and where the inference stops.

Attorney advertising / expert services. General information about evidence law and forensic practice, not legal advice, and not a substitute for checking the rules and case law of your own forum.