Data Recovery Case File · Solid State & Flash · The Decrypter Is the Device
On a Hardware-Encrypted Stick the Controller Is Not Just a Route to the Data
This enquiry describes a failure with a complication the owner has already spotted. A teacher's memory stick holding around 28GB of work, which stopped without warning and "doesn't light up at all, almost as if the battery has died" — and which is encrypted because of the work it holds. Hardware encryption puts the controller in the path twice: it is how the memory is reached, and it is what makes the memory mean anything.
| Media | Hardware-encrypted USB memory stick holding approximately 28GB — no indication on connection; controller performing both access and decryption |
| Reported situation | Encrypted memory stick used for professional work · device ceasing to function without warning · no indication on connection to any host · approximately 28GB of documents held · content not backed up recently · recovery sought |
| Fault class | No enumeration and no indication with hardware encryption in use — power stage or controller failure; decryption dependent on controller-held key material |
| Equipment used | Encryption implementation established as hardware or software before prospects were stated · board examined at component level under magnification before any power · power stage assessed on a controlled bench supply with draw measured · controller function restored where the fault proved to be at the power stage · realistic position stated where key material was controller-resident and unrecoverable |
The decode: the two kinds of encryption, and why the difference decides this
What the absence of any indication establishes first: the device is not powering. An indicator lights as soon as power reaches the board, before anything else happens, so nothing at all places the fault at the power stage or immediately after it.
Why that is ordinarily a good finding on a flash device: the memory holds its content without power and is not implicated by a power-stage failure. A stick that will not power has memory in exactly the state it was left in.
Why encryption complicates that, and this is the substance: there are two quite different implementations, and they behave oppositely here. Software encryption is applied by the computer before data reaches the stick; hardware encryption is performed by the stick's own controller.
What software encryption would mean: the stick is an ordinary device holding encrypted files. Reading the memory directly yields the encrypted content, which the owner's own password or key then opens — so a dead controller is an obstacle to access and nothing more.
What hardware encryption means instead: the controller encrypts on the way in and decrypts on the way out, using key material held within it. Reading the memory past a failed controller yields data nothing else can interpret.
Why that inverts the usual approach: the standard route on a dead flash device is to bypass the controller and read the memory directly. On a hardware-encrypted stick, bypassing the controller is bypassing the only thing that can make sense of what is read.
What follows for the work: the objective becomes restoring the controller rather than going around it. A power-stage fault repaired at component level brings the whole device back, decrypting as it always did — which is why the board is examined before anything else.
Why the reported symptom is encouraging in that light: no indication points at power rather than at the controller itself. Power-stage components are among the most repairable parts of these devices, and a controller that never received power is not a controller that has failed.
What the honest position is if the controller itself has failed: where key material lives only within it, the content cannot be recovered. That should be said plainly rather than discovered late, and it is the reason to establish which implementation is in use before anything is quoted.
What is worth checking meanwhile, and costs nothing: whether the encryption was managed by an employer. Managed deployments often escrow key material centrally, which changes the position entirely — and, separately, whether any of the 28GB exists on a school system already.
On the bench
The encryption implementation was established as hardware or software before prospects were stated — software encryption being applied by the host so the memory holds encrypted files openable with the owner's key, whereas hardware encryption is performed by the stick's controller using key material held within it, so reading past a failed controller yields uninterpretable data and inverts the usual bypass approach. Absence of any indication places the fault at the power stage. Board examination preceded any power.
The outcome
The encryption implementation established before prospects were stated, the board examined at component level before any power, and controller function restored where the fault proved to be at the power stage. 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: hardware encryption puts the controller in the path twice. Bypassing it is the usual route on a dead stick, and here bypassing it would discard the only thing that can interpret what is read.
An encrypted memory stick that has stopped working
Find out which kind of encryption it uses before anyone quotes, because it changes everything. If the encryption was applied by your computer, the stick is an ordinary device holding encrypted files, and reading its memory directly still gives you something your password opens. If the stick encrypts in its own controller, then bypassing that controller — the usual route on a dead flash device — discards the only thing that can decrypt what's read, so the work becomes repairing it instead. No light at all is encouraging here, since it points at power rather than the controller. Ask your employer about escrowed keys.
Establish which encryption it uses — call Manchester Data Recovery on 0161 871 0788; implementation established before prospects are stated, board examined before any power, controller restored where the fault is at the power stage.
Request a quote online →
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.