Data Recovery Case File · Formatted & Logical Faults · Halfway Is a State

A Volume Caught Between Two Conditions

His enquiry describes a conversion that stopped in the middle. An encrypted memory stick he decided to decrypt: "during the decryption my machine kept saying the memory stick needed a system repair. At about 50% the stick stopped decrypting, then I couldn't access it." Most encryption cases in this archive involve a setup that was interrupted. This is the reverse — an un-encryption that failed partway — and it produces a volume that is genuinely half one thing and half another. The data on both halves is intact, and the problem is that nothing currently knows where the boundary is.

The decode: what half-converted means, and the host that made it worse

How a decryption actually runs: not as a single operation. The system works through the volume in sequence, reading each region, decrypting it, and writing it back in the clear — while maintaining conversion metadata that records exactly how far it has got. That marker is what allows the process to be paused, resumed, and interrupted safely. Everything before the marker is plaintext; everything after it is still ciphertext; and the marker itself is the only thing that knows which is which.

What an interruption leaves: a volume where both halves are perfectly intact and the description of the boundary is unreliable. The system cannot mount it, because it does not know how to interpret a volume it cannot characterise. Nothing has been destroyed — the plaintext half is readable in principle, the encrypted half is recoverable with the key, and the job is establishing where one ends and the other begins.

Why his machine kept asking for a repair, and why that mattered: those prompts were the host encountering a volume in a state it could not parse. Each one was an offer to write to a volume mid-conversion — and accepting any of them would have written repair decisions across a boundary the tool did not understand. The prompts appearing repeatedly during the process was the warning sign; the conversion continuing through them was the problem.

The point worth carrying, and it applies broadly: a full-volume conversion should be run from a host that natively supports that encryption format, and never on the only copy of anything. Running a conversion through third-party support on a platform that does not implement the format natively adds a layer that can lose track of the conversion state — and a conversion is the single most dangerous moment in an encrypted volume's life, because for the duration of it the data exists in two forms at once.

What is needed to finish this: the key or password, which is required for the still-encrypted half regardless of anything else. Decrypting a volume requires the credential in the first place, so it should exist — and if it was a recovery key rather than a remembered password, that key is the thing to locate before anything else.

What must not happen: no repair, no format, and no attempt to resume or reverse the conversion on the original. Resuming a conversion whose metadata is inconsistent can write plaintext over ciphertext or the reverse, which does destroy data.

On the bench

No repair or format was permitted, since the host's repeated prompts were offers to write across a volume mid-conversion and a repair decision applied over that boundary is genuinely destructive. The stick was imaged write-blocked behind the DeepSpar USB Stabilizer 10Gb before any attempt. The conversion boundary and metadata state were established on the image — determining exactly how far decryption had progressed — and the two regions interpreted separately, the plaintext portion read directly and the remainder decrypted against the key. Files were validated by opening.

The outcome

The stick imaged before any attempt, the conversion boundary established and both regions interpreted separately. Free assessment, one fixed written figure including VAT; where a chip has to be removed, 50% of parts and labour is payable upfront with the balance only on success — otherwise no recovery, no fee. The decode, for anyone whose conversion stopped partway: nothing was destroyed. Decryption works through a volume in sequence, keeping a marker of how far it has reached — so an interruption leaves plaintext before the marker, ciphertext after it, and a boundary description nothing can currently trust. Refuse every repair prompt, and never resume the conversion on the original.

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.