Deleted does not mean destroyed. Restored does not mean complete.

Content of the article

1. The photo that "came back"
2. Deletion is not a single event
3. SSD has changed the rules
4. The phone is not a small hard drive
5. Four meanings of the word restored
6. From bytes to story
7. The tool is not a witness
8. What a fair conclusion
9. Same picture, different sentence

Analytical journalistic essay

A photo appears on the monitor. It is sharp, colorful and complete at first glance. The forensic program marks it with a word deleted. A single sentence is enough in the room: "We recovered the deleted picture." Sounds accurate. Sounds definite. And in a few seconds he creates a story that the find itself may not contain at all.

Let's think of this scene as a model, not as a description of a specific case. There may actually be an image on the screen that the regular user interface was no longer showing. It may be the original file found thanks to preserved metadata. But it can also be a part of the file cut according to a typical JPEG header, a preview created by the operating system, a copy from the cache, an attachment saved by another application, a record from a backup, or a mixture of blocks that the tool connected to itself according to a technical rule.

All these results can be colloquially called "restored photography". However, they are not forensically interchangeable. They differ in origin, completeness, metadata, link to a specific application and whether we can even connect their presence with the actions of a certain person.

Digital forensics does not bring back the past. It creates a technically sound model of the past from what is left behind.

In its extensive scientific review of digital investigative methods, NIST summarizes two things that are difficult for the public imagination to fit into one sentence: the techniques used have a solid basis in computer science when properly applied, and at the same time, they have known limits. Not all clues can be found. Deleted data recovery may return only part of a file, add extraneous material, or join unrelated fragments. In addition, the meaning of the artifact can change with the version of the system, the application, and the parser.^[1]

And this is where another context begins. The real professional question is not: "Did we recover anything?" It reads: "What object have we found, how did it come to be, which of its properties have we directly observed, and where does inference begin?"

01 / Layered plotDeletion is not a single event

When a person presses Delete, they see a simple change: the item disappears. However, the computer does not have to perform a single physical act that could be described as data destruction. User action falls through several layers of the system, and each of them may retain a different trace.

At the top layer, the application can only remove an item from the list. The database can mark the row as deleted, move its contents to free space, or write the change to the journal. The file system can unlink the file name from the blocks that held its contents and mark the space as usable for further writing. The storage controller can remap logical addresses to other physical cells. And outside of the device, there can still be synchronized copies, backups, previews or data in the cloud.

With a classic file system, the first step is often not to overwrite the content, but to change the record: the record ceases to be active and its space becomes available for further use. As long as it is not overwritten, all or part of the content may be preserved. However, it depends on the specific system, erasure method, fragmentation, subsequent activity and media type. That's why professional practices explicitly count on searching for relevant deleted data in unallocated space as well as in various types of slack space — not because it has to be there, but because it can be there.^[1][2]

Another case is the basket. Moving to the trash can only be a change of location and addition of auxiliary metadata. Another is "permanent" deletion from the interface. Another is to remove it from the application database. And yet another is secure media sanitization, which aims to make target data impossible to access with a pre-considered level of effort. That's how NIST defines sanitization: not as the metaphysical absence of every bit, but as a state where data acquisition is practically infeasible for a given attack model.^[4]

"Deleted" describes a state at a certain layer of the system. It does not say by itself what happened in all the others.

This has one unpleasant consequence: you can't create a universal rule like "a deleted file is recoverable for seven days" or "once the trash is emptied, it's gone forever." Almost the entire technical context is missing in both sentences.

02 / Physical mediumSSD changed the rules — but not in one direction

A popular analogy is that deletion is like ripping out an item from the contents of a book: the chapter remains on the pages, only the pointer is lost. This is a useful tool for some magnetic disk situations. However, with modern flash storage, it begins to deceive.

An SSD does not present a simple "this logical block lies in this physical cell" map to the operating system. A controller with an address translation layer works between them. Due to the limitations of NAND flash, it uses remapping, rewriting, wear leveling, and block cleaning. In addition, part of the physical capacity may not be user-addressable with normal commands. Therefore, NIST specifically notes that with modern media, the physical capacity may exceed the capacity visible to users, and that data may be propagated to multiple locations.^[4]

The TRIM command allows the operating system to tell the SSD that certain logical blocks are no longer needed. But this is not the same as a precisely timed physical wipe. The controller may later include the data in garbage collection; from a normal read perspective, blocks may start returning zeros or become unavailable. What remains in the physical layer and what can realistically be acquired by a particular method depends on the device, firmware, encryption, power status, and acquisition path.

A historical study by Wei and colleagues in 2011 showed why procedures taken from hard drives could not be automatically transferred to SSDs of the time: due to internal mapping, older copies could remain out of logical view, and some implementations of erase commands did not behave as expected.^[3] This work is important as a demonstration of an architectural problem, not as a table for estimating today's devices. The specific numbers from the tested disks of fifteen years old cannot be passed off as the characteristics of a current phone or SSD.

Modern encryption adds another paradox. The bytes may still exist on the physical media, but are virtually inaccessible without the appropriate key. On Apple devices with Data Protection, each file or file range is protected by its own key wrapped in another hierarchy of keys; quickly removing the higher key can make files cryptographically inaccessible without having to gradually rewrite the entire flash.^[8]

This reverses the original intuition. With the old disc, we mainly asked whether the content had been overwritten. In a modern device, we must also ask if there is a path from the physical cells through the controller, file system, and keys to a readable artifact. Presence, addressability and readability are three different properties.

03 / Mobile ecosystemThe phone is not a small hard drive

On the phone, a significant part of important data is not located as separate documents with a name, path and icon. It is stored in application databases, configuration files, logs, caches, database logs, and repositories managed by the operating system. Therefore, a "deleted message" may not be a file. It can be a line, several linked tables, a record in a WAL file, an attachment in another path and a preview in the cache.

SQLite, used in countless applications, self-documents that normal deletion of content usually does not mean immediate deletion of the original bytes; the space is marked for further use. Command VACUUM rebuilds the database and can remove traces of deleted content from it, while the mode secure_delete changes the way released content is overwritten. At the same time, there may be a rollback journal, or WAL, in which additional versions of database pages are stored.^[5]

Therefore, even the sentence "VACUUM will remove traces" does not mean "there is no longer any associated trace on the entire phone". It describes the behavior of a specific database. A copy of the same content can survive in the file system, another database, backup, notification, search index, attachment, or synchronized account.

This is where encryption comes in. Android since version 7 supports file-based encryption, and devices listed with Android 10 and above must use it; files can be protected with different keys and user data is divided into storage available before and after the user is unlocked, among other things.^[7] For iOS and iPadOS, access to content is tied to a hierarchy of per-file keys, protection classes, Secure Enclave, and device state.^[8] The result of the acquisition can therefore dramatically depend on whether the phone is currently on, unlocked, rebooted, what method is available, and what the particular combination of hardware and system allows.

The same principle applies more broadly. A photo could be automatically downloaded, a message restored from a backup, browser history synced, a thumbnail created when browsing a remote album, and a contact transferred when migrating. The physical location of an artifact corresponds to where it was found. It does not necessarily correspond to the place where it originated, nor to the person who initiated it.

04 / Result languageFour Meanings of the Word "Restored"

The word "recovery" obscures differences that should remain visible in the laboratory. NIST describes three common families of techniques: recovery based on file system metadata, carving according to characteristic file structures, and recovery of deleted records within application formats such as databases.^[1] In practice, it is useful to add a fourth category: a derived copy, which is not the original object, but its technical descendant.

1. File restored by metadata

If usable file system structures remain, the contents can sometimes be linked with the original name, path, and other data. This is contextually richer than the carving itself. Even here, however, the name of the account or directory does not automatically show the author of the content, knowledge of the file, or the exact moment of deletion. Timestamps can have different meanings, change by copying, and be affected by time zone or application behavior.

2. File carved from unallocated space

File carving looks for typical headers, footers, or internal structure of a known format without relying on the original file metadata. It can find valuable content, but often loses its name, path, and relationship to other objects. If the file is fragmented or partially overwritten, the result may be incomplete; in extreme cases, it may contain parts of different original objects. NIST cites the risk of missing data and combining unrelated material as known limitations to recovery.^[1]

3. Deleted database record

A record can carry a contact identifier, message text, a deletion flag, or a time value. However, its meaning depends on the correct recognition of the scheme of a particular version of the application. The number can be a time in seconds, milliseconds, local time, or an internal order. The value may belong to another row after a partial override. A parser that once matched the application version may interpret the same fields incorrectly after an update.

4. Preview, cache or synchronized copy

A thumbnail can outlive the original while looking like a smaller, more convincing version of it. The cache can be created by automatic loading, preloading or synchronization. Such a finding may prove that a certain system component processed the content. It does not have to prove that a person consciously opened it, created it, or even saw it. This depends on the mechanism of the particular application and the supporting tracks.

The photo didn't make the difference. It was created by the path it took to get to the screen.

05 / Epistemic boundaryThere are several bridges from bytes to humans

Digital discovery starts quite low: a particular sequence of bytes exists in a particular acquisition source. The software can recognize a JPEG structure, SQLite record, plist, log or time value from it. Only then comes the question of what this artifact means as an event — and only finally, whether the event can be associated with man, knowledge, and intention.

These levels are easily merged in a normal narrative. "There was an image in the browser cache" becomes "the user visited the page". "There was a message entry in the database" will change to "the owner of the phone wrote the message". "The file was in the account directory" will change to "the account owner saved it there". Either of these conclusions can be correct. However, none is contained only in the first sentence.

For a photograph, for example, one can directly describe that a certain sequence of bytes corresponds to a decodable JPEG and was found at a given offset. Dimensions, any internal metadata and degree of completeness can be provided. If a file record is missing, it is not fair to automatically fill in the original name or path. If the camera model is listed inside the EXIF, this is information stored in the file — not indisputable confirmation that this particular device and specific person took the picture. Metadata can be changed, deleted and transferred by copying.

With time, the boundary is even sharper. A single number can represent object creation in the application, file modification, synchronization, import, server time, or the moment the system created the preview. Only documentation, testing of the same version of the application and comparison with other traces allow to determine what the given field actually represents.

This reticence does not weaken the proof. On the contrary, it shows where he is strong. A finding can very convincingly demonstrate the existence of certain content in a particular layer of the system, even if it does not prove the author. Other times, a combination of database record, application log, network communication, system event, and user interaction can create a much stronger conclusion. What matters is not the number of colored items in the report, but whether they together explain the same mechanism and whether there are reasonable alternatives.

06 / AutomationThe tool is not a witness. He is a translator.

Forensic software can process a volume of data in hours that would take a person months to sift through manually. It recognizes formats, reconstructs databases, groups communications, normalizes times and assembles timelines. But it is this power that creates the illusion that the item in the graphical interface is a direct imprint of reality.

It isn't. It is the result of algorithm, parser rule, signature database, settings and tool version. Two programs may name the same bytes differently, one may miss the artifact and the other load it, the third may misinterpret the changed application schema. A tool upgrade may acquire additional items from the same acquisition; however, a new result does not mean that new data has appeared in the evidence image in the meantime. The ability to recognize them has changed.

SWGDE therefore recommends validating significant artifacts whenever feasible: comparing the sample between multiple tools, tracing the raw location, and manually checking that the content is decoded correctly. Contradictions should not be hidden, but explained and documented. The same document notes that the timeline produced by the tool is usually just a slice of the detected and parsed data, not a complete list of everything that happened on the device.^[6]

The hash has a separate role. A cryptographic fingerprint is great for verifying that the parsed copy has remained bitwise, or that two objects have identical content. NIST ranks it among the basic mechanisms of integrity and preservation of digital evidence.^[10] But Hash doesn't say that the acquisition captured everything that was technically available. It does not validate the parser. It does not demonstrate the importance of the time field. And it no longer authorizes the leap from a file to a person's intention.

We can perfectly prove that we haven't changed the copy — and still be wrong about what its contents mean.

Moreover, digital errors are often not random. If a parser confuses the meaning of a certain field, it can repeat the same mistake consistently across hundreds of entries. The result then appears systematic, clear and convincing. Therefore, SWGDE places its trust in error mitigation: proven methods, testing, knowledge of limitations, human review, and correct interpretation — not just the reputation of the tool or the fact that "the report was generated without error."^[9]

07 / The language of certaintyWhat does an honest forensic conclusion sound like

The difference between an accurate and exaggerated claim often does not look dramatic. It consists of several words that separate observation from inference. However, it is these words that determine whether the report describes the data or adds a story that the data itself does not carry.

The second sentence is not "careful". It is richer in information. It tells by which method the object was found, where it was located, what is missing and which conclusion is not supported. At the same time, he does not deny that the image itself can be significant for the case.

The last line is especially important. The absence of a find is not automatically evidence of destruction. The data could have been overwritten by normal traffic, remained outside the acquisition scope, been encrypted, stored remotely, not supported by the parser, or never existed on the device. Likewise the presence of an artifact is not automatically evidence of conscious action. It could have been created automatically, by synchronization, by restoring a backup, or by the activity of another component.

Both sentences have the same structure: a technical state is not the same as a human story.

1. Name the object. Full file, fragment, database row, preview, cache, backup or log are not synonyms.
2. Name the source. Active File System, Unallocated Space, WAL, Cloud Export, and Sync Copy have different provenances.
3. Name the method. Logical extraction, full-file-system acquisition, carving and manual parsing provide a different view.
4. Name the gap. Missing path, unknown time meaning, unverified application version or inability to determine origin are all part of the result.

Forensic accuracy is not a competition for the toughest sentence. It is the ability to assign to each statement just the degree of certainty that its supports allow.

08 / Back to the pictureSame photo. Another sentence.

Let's go back to the room from the beginning. The same picture is always on the monitor. It is just as sharp, just as colorful and just as compelling to the human eye. Only the description below it has changed.

At the beginning it read: "We have recovered the deleted photo." After adding context, it might read: "Image data matching JPEG was detected in unallocated space. The file can be rendered, but its original directory entry was not found. We do not know the original name or path. The find may be the original file, a copy of it, or a derived object; the available data alone does not determine who created it, who saw it, or who caused the original link to die."

The second formulation is less cinematic. It does not contain the moment of triumphant "return of truth". But it contains something more valuable: the boundary between what has been found and what we still think about the find.

That doesn't mean we shouldn't trust digital footprints. It means trusting them exactly. An entire file with a verified path, consistent metadata, application logs, and supporting logs allows a different conclusion than an anonymous fragment. A single trace can be weak for determining the author and at the same time strong for proving the existence of the content. Uncertainty is not a switch that invalidates evidence. It is an indication of the reach of a particular statement.

The public likes to think that technology either recovers data or it doesn't. The reality is less clear cut. Something can survive without a name. A name can survive without content. A database record can survive without an attachment. The preview can survive without the original. Bytes can survive without a key. And several incomplete tracks can combine to create a more reliable image than a single perfect-looking file.

The hardest part of digital forensics doesn't start when the data is missing. It starts the moment we find something and have to resist the urge to fill in the rest.

So there is no past on the monitor. There is a technical remnant of it: sometimes almost whole, sometimes distorted, derived or taken out of context. The value of the analysis does not come from turning it into a compelling story. It comes about by showing exactly which parts of the story are supported by the data — and which are not.

Forensic honesty doesn't start with what we've been able to recover. It begins with what we refused to guess.