Data Recovery Case File · Milestone · The Repair That Would Have Finished It

Case 650: a funded repair that would have erased what the investigation was meant to protect — the boot loop and broken screen decoded as non-verdicts, the deleted-items request answered honestly, and Volume Thirteen closes on the question nobody owned

The six hundred and fiftieth case in this archive arrived through an advocate, and its facts assemble into something this library has been circling for thirteen volumes. "My client has a laptop which was investigated by the police's digital forensic unit because he was a victim of a crime. When the device was returned to him it was significantly damaged — it now has a broken screen and it's stuck in a boot loop. The police have said they will pay for a repair, but the manufacturer has said that repairing it will cause all the data held on the device to be wiped." The request that follows is a life's inventory: all emails, pictures, videos, audio, documents — and all deleted items still on the hard drive. Every institution in that paragraph is behaving correctly. The forensic unit examined a device to investigate harm done to him. The manufacturer gave an honest technical warning rather than a comfortable one. The advocate asked before authorising. And still, without one question being asked by somebody, the man who had already been the victim of a crime would have lost everything he owned digitally — to the remedy. That question is the whole subject of this milestone.

The decode: why the warning is true, what the symptoms don't mean, and what "all deleted items" honestly means

Why "repair will wipe the data" is exact rather than evasive: on a machine of this generation the storage is soldered to the mainboard and encrypted by a security chip on that same board. The standard remedy for a badly damaged machine is board replacement — and when the old board leaves, the storage and the keys leave with it, together, permanently. The manufacturer was not managing expectations; it was describing physics. It is worth saying plainly because it inverts most people's assumptions about repair: on modern hardware, a repair can be more destructive to data than the damage it fixes.

What the two symptoms actually say: neither is a verdict on the data. A broken screen is an output fault — the machine may be running perfectly behind a dark panel, and video can be taken elsewhere. A boot loop is a system-level failure: firmware or operating system unable to complete start-up, most often after physical damage disturbs something the boot chain expects. Neither symptom implicates storage, and both belong to the machine rather than to its contents — which is why the correct first move was never repair, and never resuscitation, but extraction.

The deleted-items request, answered honestly: his inventory ends with "all deleted items that are still on the hard drive," and it deserves a straight answer rather than a reassuring one. Live data — emails, photographs, video, audio, documents — recovers completely from a good extraction. Deleted data is a different matter on modern solid-state storage: when files are deleted, the system typically tells the drive those blocks are free, and the drive purges them as part of its own housekeeping — so deleted material on a modern encrypted SSD is frequently, genuinely gone, in a way it never was on the mechanical drives of a decade ago. Some deleted content still surfaces — items inside application databases, mail stores, caches and containers that hold their own history — and those are searched properly. But the honest position, stated in writing before any figure was agreed: expect the live estate in full, expect a partial and unpredictable yield from deletions, and be told which is which in the delivered manifest. Nobody in this man's position should be sold a certainty that the storage architecture cannot supply.

The order that saved it: extraction first, under written scope, with the device's custody documented — appropriate for anything that has been through an evidential chain — and only then the funded repair, proceeding with nothing left aboard to lose. The repair was never the enemy. The sequence was the only thing at stake.

On the bench

Nothing was authorised until the data question had been answered. The machine was assessed at board level per its construction, and access established to the storage that the boot loop had made unreachable but never endangered; decryption ran against the owner's own credential — the legitimate key, the only kind this archive turns — and a complete image was taken while the path was good. OSForensics then indexed the estate exactly as the inventory requested: mail stores parsed, photographs, video and audio gathered, documents extracted, and deleted-item recovery run across the image and inside the application containers that keep their own histories. Everything was compiled into a verified manifest — each item listed, hashed and checked as readable — with live data and recovered deletions clearly distinguished, so the advocate could see precisely what had been returned and what had not. Only then, with the estate verified and delivered, did the funded repair go ahead: the broken screen replaced, the boot loop resolved, the board exchanged if that is what it took — by then a matter of hardware, and nothing more.

The outcome — and the volume closes

The full live estate recovered, indexed and delivered under a verified manifest; deleted material recovered where the architecture allowed it and honestly accounted for where it did not; and the funded repair carried out afterwards, harmlessly. Free assessment, one fixed written figure including VAT, no recovery, no fee — the same terms as the six hundred and forty-nine cases before it. And Volume Thirteen closes on the pattern this case makes impossible to miss. At case 550 the archive celebrated a repair shop that knew not to touch a failing drive. At case 600 it celebrated two shops that tried, met their ceiling, and pointed past themselves. Here, at 650, nobody made a mistake at all: a forensic unit examined a device to investigate a crime committed against its owner; a manufacturer warned honestly that the repair would erase it; a police service offered to pay for that repair; an advocate asked a question before signing. Every actor performed their own role correctly — and the data question still belonged to nobody, because it was not any of their jobs. That is the gap this library has been documenting for six hundred and fifty cases: not villains, but a question that falls between well-meaning institutions and lands, always, on the person with the most to lose. So the rule this milestone leaves, for anyone whose device is about to be repaired, replaced, swapped, returned or restored by somebody else's process and somebody else's budget: ask where your data will be when it's finished. If nobody in the chain owns that question, it is yours — and it is best asked before the authorisation, not after the part has shipped. For a man who had already been on the wrong end of one loss, it turned out to be the only question that still mattered.

Our case files are drawn from genuine enquiries received by our laboratory over the past ten years, anonymised to protect client confidentiality. Each one describes the diagnostic and recovery procedure our engineers apply to that fault, using the equipment listed.