Digital Forensics / Intermediate: artifact-specific offline analysis / Lesson 10

Reason about deletion and carving limits

Separate metadata state, surviving bytes, candidate boundaries, and the claims a synthetic search can support.

About 5 min readContent reviewed 2026-10-28

On this page

Lesson goals

Distinguish logical deletion from verified physical content state.
Explain false positives and missing context in signature-based extraction.

Do not infer a whole storage history from deleted

A deleted label describes a state under a particular application or filesystem model. It does not by itself prove that content remains recoverable, that bytes were overwritten, or that a person intentionally destroyed information. Storage reuse, device behavior, encryption, and collection scope can affect what material is available. Those mechanisms are platform-specific and not exercised here. The classroom model contains only invented metadata and byte arrays. It teaches the questions to ask without reading free space, mounting an image, accessing a device, or attempting actual recovery.

Separate namespace state from byte availability

The first program models a directory-like entry marked deleted while a separately defined content blob still exists in the fixture. It demonstrates that two modeled facts can coexist, not that any real deleted file is recoverable. A filename relationship may be lost even when some bytes remain, and surviving metadata can refer to content that no longer matches. Keep the object, relationship, and source scope explicit. Avoid reconstructing an original path or identity merely because a nearby string resembles a familiar name. The example performs no filesystem operation and makes no ext4 recovery claim.

python Keep synthetic metadata and content state distinct

entry = {"name":"lab-note.txt", "state":"deleted", "contentRef":"blob-3"}
blobs = {"blob-3": b"public classroom text"}
assert entry["state"] == "deleted"
assert entry["contentRef"] in blobs
assert blobs[entry["contentRef"]] == b"public classroom text"
print("modeled deletion and modeled bytes are separate facts")

Expected output

modeled deletion and modeled bytes are separate facts

The complete program checks declared in-memory objects. It does not delete or recover a file and accesses no filesystem metadata or device. The content relationship is supplied by the fixture, not discovered from evidence.

Treat a pattern match as a candidate

Carving reasoning looks for content patterns when ordinary metadata may be unavailable, but a pattern alone can occur accidentally or inside unrelated content. The second program finds a custom marker and extracts bytes only when its declared end marker is present. It is a tiny string exercise, not a file carver. It does not handle fragmentation, overlapping candidates, compression, nested formats, or partially overwritten content. Preserve the match offset and boundaries. A candidate’s readable payload does not establish original filename, timestamps, ownership, completeness, or relevance to the question.

python Inspect custom markers in created bytes

raw = b"noise<LAB>alpha</LAB>tail<LAB>unfinished"
start = raw.find(b"<LAB>")
end = raw.find(b"</LAB>", start + 5)
assert start == 5 and end > start
candidate = raw[start + 5:end]
assert candidate == b"alpha"
second = raw.find(b"<LAB>", end + 6)
assert second >= 0 and raw.find(b"</LAB>", second + 5) == -1
print("one bounded candidate and one incomplete marker found")

Expected output

one bounded candidate and one incomplete marker found

The complete program searches one fixed byte string and recognizes an incomplete second marker. It reads no disk and recovers no real file. The marker syntax is invented and carries no claim about an actual format or forensic tool.

Validate candidates without inventing missing material

For an approved real analysis, apply the relevant format’s structure and known-tool limitations to each candidate. Record truncation and uncertain boundaries rather than inserting convenient bytes. Keep candidate counts distinct from validated objects and unique files. Different offsets may overlap or represent repeated content, so deduplication needs a stated policy. A known test set can evaluate a tool’s behavior on defined scenarios, while results from one scenario do not certify every recovery claim. This course’s local examples do not run a forensic recovery product or test any real media.

State absence and recovery limits accurately

Failure to find a marker in the supplied bytes means that the selected search did not find that marker in that material. It does not establish that a file never existed or that deletion was secure. A found candidate likewise does not establish authorship or intent. Report scope, search rule, offsets, validation steps, failures, and missing metadata. Keep platform behavior and actual acquisition outside the claim unless separately verified. The strongest conclusion remains specific enough for another analyst to reproduce and challenge without assuming facts the fixture never supplied.

Common errors and fixes

Deleted is called securely erased

Why it happens: A logical label is treated as proof of physical content state.
How to fix it: Describe the platform-specific question and available material.
Prevent it next time: Separate deletion metadata from byte and device claims.

A marker match becomes a complete original file

Why it happens: Candidate extraction is confused with validated recovery and metadata.
How to fix it: Validate structure and retain uncertain boundaries and missing fields.
Prevent it next time: Count candidates separately from verified objects.

No hit proves no historical file

Why it happens: Search scope is expanded beyond the supplied bytes and rule.
How to fix it: Qualify the negative result and parser limitations.
Prevent it next time: Record input scope and unsupported recovery cases.

Check your understanding

1. A complete custom marker contains readable alpha. Which original metadata is established?

Show worked solution

None beyond the supplied offset and declared candidate bytes. Filename, path, timestamps, owner, and original application relationship are not recovered by this search. Report a bounded synthetic candidate and its validation limits rather than inventing a complete historical file.

2. Why keep the incomplete second marker in the result notes?