Quote:
If you have two USB-Sticks of the same model
Therein lies the rub.
USB sticks "models" wont really help. for example, verbatim store'n'go have looked the same for many years. inside it is a crap shoot. every single revision of firmware (which wont show up even if vendors specified models) change things. Another example: Strontium drives commonly bought at newsagents. these use repurposed things like microsd cards, sd cards, emmc soldered to the board where they wire directly to NAND - I assume there was a controller problem in the SD/microSD/emmc. When I buy these for my research pool, I usually buy 3 or four as I knowthey will all be different inside!
I have over 700 in my research pool and very few duplicate chip/controller configurations
when you get customer drives in, it is extremely rare to get one with the same parameters you have had in before.
sure there are similar drives around but the experience comes in knowing what parameters to change to get your patient 100% dialled in.
a good indication is to go to FE site and flick through the library. you will start to see the MANY combinations of parameters making up a drive.
and each step of the recovery has its own nuances.
example of a (incomplete by far) list:
1. figure out whats in your hand.
- often chips have no markings
- monoliths are not marked well, same pin config but who knows what inside.
- is it real or counterfeit? sounds like it should be a minimal concern but a bigger one than you think.
- chip IDs, but parameters can be different (DDR, SDR, WL versions, power modifications needed, etc etc)
- how many crystals, finding extra pinouts
- chips with 1.8v core, chips with different pin config, chips with other reading issues
- what is the controller (there are some weird ones out there)
- many different chip types - BGA 100, 224, 316, 272, LGAxx, tsop48, wide tsop48, tsop52, emmc (variety of) SD, MicroSD, etc
2. read the chip.
- is the dump correct? how do you know?
- is it DDR read with SDR parameter or visa versa?
- does it have too many bit errors - can we do anything to make it better.. what?
- were the reading paramers right?
3. get raw dump into a disk image..
- what layout is it? is ecc known / xor? / BCH?
- algorithm?
- does it need pages cut? blocks cut? before image or after?
- are any block missing?
- are there block numbers or need to create translation table
- inversion, pages rotated in blocks, and a whole slew of things here, and more being developed and found often
- video hard to recover, different file systems have quirks, etc etc.
4. other:
- space.. things are getting big. storage is not a trivial concern
- transfer times of dumps / recovered files / support from people is a factor
- time. ecc correction on large dumps, saving images after reversing takes hours and in some cases like SSD can take several days to save an image. It gets you down when your customers are stressed and waiting and nothing you can do to speed up recovering.
- working on a single case can blow your "intended hourly $ income rate" as customer payment probably wont cover a good number of jobs. hard to do many flash cases at once. Unlike hard disks where you might have a heap of the hooked up to various recovery tools, unless you have multiple technicians, this is going to be not as easy to do as the device/chip on a machine is a small portion of recovery time but tech eyes on the PC screen is a large %
- SO MANY different combo's of controller/flash
-vendors of flash tools working hard but basically need to reverse engineer all new stuff. no service manuals from the flash vendors!
I could go on but hope you get the picture.