What a Full File System extraction actually contains, and why most of it is never examined

Ask someone outside the field what is on a seized phone and they will say messages, photos and contacts. Ask an examiner and they will pause, because the honest answer is that nobody entirely knows, and finding out is the job.

A Full File System extraction is a copy of the device’s file system as the operating system sees it. Not a curated export, not the subset an application agrees to hand over through a backup interface. The whole tree.

It is worth walking through what is actually in there, because the shape of the data explains almost everything about where examination time goes.

Four layers, in descending order of attention

The layer everyone thinks about. Messages, call logs, contacts, the camera roll. It is genuinely important, it is what the case usually turns on, and it is a small fraction of the extraction by volume. It is also the part every tool decodes well, because it is the part every tool was built for first.

Application storage. Each installed application keeps its own state: databases of messages and their metadata, caches of profile pictures, drafts, notification history, search history, location breadcrumbs, sync state. A phone with sixty applications on it has sixty of these, in sixty layouts, in several formats, some of them versioned and some of them not.

This layer is where the interesting evidence increasingly sits, and it is where coverage is most uneven. An examiner’s tool will decode the storage of the applications the vendor implemented, and the rest is a directory listing.

System traces. The operating system records a remarkable amount about itself in the ordinary course of working: which applications ran and when, which networks the device joined, when it was powered on, which accounts are configured, what was recently opened. None of it was designed as evidence. Much of it is very good evidence, because it is difficult to curate and it corroborates or contradicts the human account.

Sediment. Thumbnail caches, temporary files, write-ahead logs that still hold rows deleted from the main database, unallocated space with the remains of records that were removed. This is the layer where deleted content is recovered, and it is also where the examiner has to be most careful, because a recovered row and a live row have different evidential weight and must never be presented as though they were the same.

The volume problem is not really a volume problem

A modern flagship phone will produce an extraction in the tens or low hundreds of gigabytes. But storage is cheap and reading is fast, so raw size is not the constraint.

The constraint is that the useful content is scattered across a large number of formats, most of which are undocumented, several of which change between releases of the application that wrote them, and none of which were designed for anyone but the application itself to read.

That is why the meaningful question is not how big an extraction is. It is what proportion of it any tool has an opinion about. Everything else is present, readable in principle, and unusable in practice.

Where the hours go

Watch an experienced examiner work through an extraction and the time distribution is not what an outsider expects.

Very little of it is reading messages. A great deal of it is working out which parts of the extraction are worth reading at all, then getting those parts into a state where reading them is possible. Opening an unfamiliar database, working out what its tables mean, discovering that timestamps are stored in an unusual epoch, realising that the message body is in one table and the participant in another with no obvious join. That is the work.

It is also skilled work that produces nothing durable. The understanding an examiner builds about one application’s storage layout on Tuesday lives in their head, or at best in a personal notes file, and it has to be rebuilt by the next person who meets the same application in another service six months later.

The part that never gets examined

Every laboratory has an informal rule about how far to go. It is rarely written down and it is usually sensible: examine what the tool decoded, examine anything the investigator specifically asked about, and note the remainder as not analysed.

The result is a consistent, invisible reduction in scope. Not a failure of diligence, and not something a case review would flag, because the report accurately describes what was examined. But the effect across a caseload is that a large fraction of seized data is never looked at by anybody, and the fraction is largest in exactly the applications a vendor found commercially uninteresting.

What would change the picture

Three things would move this, in order of how much difference they make.

The first is coverage that does not depend on somebody else’s release schedule. If an unfamiliar application can be structured on the day the case needs it, the informal scope rule stops removing the same categories of evidence every time.

The second is search that works on meaning rather than only on strings. Most of an extraction is unreadable because nobody has a reason to open it. A question asked across the whole seal at once finds the reason.

The third is verification that is cheap enough to actually perform. An examiner who has to spend an afternoon confirming where a finding came from will confirm fewer findings. One who can do it in a click will confirm all of them, which is what the courtroom is entitled to expect.

That last one matters more than it sounds. Making evidence review faster is only useful if it does not also make it shallower, and the only defence against that is making the check so cheap that skipping it saves nothing.