2 procedures of usb flash driver data recovery. We know the basic principle of flash drive data recovery is to work out the data mix (the data allocation algorithm) applied to the target flash chip. Basically there are two procedures:
1. Using algorithm analyzer utilities to remove the data mix manually by studying the data spreading variables locate in the service are of the chip;
2. directly apply algorithms from another controller with the same model. Unlike procedure 2 requires more basic knowledge on data structure and more user intervention, following procedure 1 needs a few clicks in a data recovery job as long as the algorithm you are working on is included in the algorithm database of the tool. And that’s why vendors of flash data recovery tools (including SalvationDATA) try their best to include the algorithm database in their products. The algorithm database, in a few cases, helps users to finish the data recovery quick and easy; but most of the time it is of no use at all.
In order to explain this matter of fact clearly, we will need to have a close look in the flash drive:
1. USB connector
2. USB mass storage controller
3. Test points
4. Flash memory chip
5. Crystal oscillator
6. LED
7. Write-protect switch (Optional)
8. Space for second flash memory chip (Optional)
Essential components we need to know
There are typically four parts to a flash drive:
Male type-A USB connector – provides an interface to the host computer.
USB mass storage controller – implements the USB host controller. The controller contains a small microcontroller with a small amount of on-chip ROM and RAM, where the data mix algorithm stored.
NAND flash memory chip – stores user data.
Crystal oscillator – produces the device’s main 12 MHz clock signal and controls the device’s data output through a phase-locked loop.
To make it easier for you to understand what they do, we can compare a flash drive with the PC which is well-known to all:
All the other parts of the flash drive can be considered as a PC and the flash chip can be considered as the hard drive installed in the PC. The controller chip and the microcode stored in it will be something similar to the operating system install on the PC. As we know, different OS can be installed by the PC vendor even for the same PC mode, so it is for the same reason that the same model of the controller will contain totally different data mix algorithm; and data created using one OS (Windows XP for example) cannot be accessed by using another OS (Linux for example).
And now let’s go back to the point of view we brought forward at the beginning: directly apply algorithms in the database which are collected from another controller with the same model is of no use at all. We now understand controller chips of the same model and ID may contain totally different algorithm, that’s why users may get nothing even they happened to find an identical controller in the database; what’s more, unlike the OS we used for the comparison, there are countless known and unknown data mix algorithms of flash drives now being used in flash drive products, it is impossible for the manufacturers to add all the controllers you need to the database since there are too many of them, not to mention the new controllers keep coming out; users will find out there are just limited controllers included in the database, and without the ability to carry out procedure 1 flash recovery, once the target controller is not included in the database, users can’t do nothing but give it up.
.jpg)
