Data Recovery Case File · Solid State & Flash · What Actually Happens Next

USB Not Recognised: What Chip-Level Recovery Involves

Her enquiry did the whole Windows-side elimination without being asked. "My SanDisk memory stick is not being read on my laptop. It is not visible on the device. I have tried going through Device Manager and Disk Management, but it is not there. I would need to recover some files on this device." Checking both is the complete check — Device Manager lists devices on the USB bus whether or not they carry usable storage, and Disk Management lists storage the system recognises as a disk — so absence from both means the stick is not answering electrically at all. There is nothing further to test at home, and no more cables or ports will change it. Which makes this the right case to describe something this archive normally summarises in a sentence: what chip-level recovery actually involves, step by step, for someone who has already established that it is where her case is going.

The decode: what chip-level recovery actually involves

Step one — confirm the controller really is silent. Before anything invasive, the stick is brought up behind hardware that can manage an unstable device: a controller that responds even intermittently changes the route completely and makes everything below unnecessary. This is always tested first.

Step two — establish how the device is built. Flash drives come in two constructions, and they lead to different work. Some contain a discrete NAND package soldered to a small board alongside a separate controller chip; others are monolithic, with memory and controller combined in a single moulded block. The first allows the memory package to be desoldered and read directly in a programmer. The second has nothing to remove, so the read is taken through internal technological pads — test points beneath the surface, laid out by the manufacturer, located and probed against a database of known layouts.

Step three — read the raw memory. What comes off at this point is not files, and it is not even recognisable as a filesystem. It is the physical contents of the memory: pages and blocks in the order the controller happened to write them, including its own bookkeeping, spare areas and error-correction data.

Step four — undo what the controller did. This is the substance of the work, and it is why chip-level recovery takes time. The controller scrambled the data as it wrote it, so the scrambling pattern has to be identified and reversed. It applied error correction, so the coding scheme must be determined and used to repair bit errors — which is also what recovers data from marginal cells. And it distributed data across the memory according to its own wear-levelling scheme, maintaining a translation map between logical addresses and physical locations; that map must be reconstructed in software from the fragments and metadata present in the dump, because without it the pages are in the wrong order.

Step five — rebuild and verify. With the translation reconstructed, a coherent image emerges and the filesystem can be rebuilt from it, returning folders and filenames. Every file is then verified by opening rather than counted.

What can go wrong, honestly: the controller may be an unfamiliar variant whose scrambling and layout have to be worked out rather than looked up, which takes longer. Worn memory yields blocks that error correction cannot repair, which costs individual files. And a monolith physically damaged through the die itself is beyond reach. None of those is common, and all of them are identified during assessment rather than discovered at the end.

On the bench

An enumeration attempt ran first behind the DeepSpar USB Stabilizer 10Gb, confirming what her own testing had established. The device's construction was then identified, and the memory read accordingly — probed on the PC-3000 Flash Spider Board where the build was monolithic, with the pinout confirmed against the Rusolut VNR database. Reconstruction followed the sequence above: scrambling identified and reversed, the error-correction scheme determined and applied, and the translation layer rebuilt until the pages resolved into a coherent image. The filesystem was reconstructed from it, and her files were verified by opening before delivery on fresh media.

The outcome

The memory read at chip level past a silent controller, reconstructed in software and the files verified and delivered. 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. What her complete elimination earned: checking both Device Manager and Disk Management is the full Windows-side test, and absence from both means the controller is not answering — so no further port, cable or computer will help, and repeated attempts add nothing. From there the work is chip-level, and it is not a matter of plugging the memory in somewhere else: the raw contents are read where they lie, then descrambled, error-corrected, reordered from a rebuilt translation map, and finally reassembled into a filesystem. That is why it takes time, and why the memory behind a dead controller is usually still entirely readable.

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.