thd wrote:
Quote:
(1) That should be a given]
Should be, but as it turns out often is not. It seems that a lot of techs know how to run tools, but have little to no engineering background.
Quote:
(2) would be out as the controllers have firmware and I really doubt they would be transplantable.
Although not impossible, I'd be surprised if the controllers themselves had onboard flash. It's a mixed signal process then, and would typically be much cheaper in terms of silicon to either use a bit of the NAND or put a small bit of SPI NOR flash to hold firmware. So that being said, if a S4LN053X01-8030 really had failed, I can't imagine why replacing it with another identical working part would be a problem. Maybe they have something (serial number, encryption key, who knows what) stored in OTP on them, but that aside...
Quote:
(3) is less a last resort, but more likely as there is evidence of cases with these controllers solved by chip off.
So imagine the case where you have a NAND part where a bank has failed, but it's mostly readable. You dump that part, re-write the data to a good equivalent NAND and replace.
Quote:
vendors don't care about data recovery, their extent is if it fails in warranty period, they will replace it. Putting in avenues to recover data in the event of a fail kind of insinuates they will fail at some point and they never want to admit that. Plus it is extra work and code for no ROI.
I guess, but it's fairly little extra work to put in a read-only/diagnostic mode. Anyhow, as you say, they obviously don't care and are unlikely to change in that regard.
Quote:
Another problem is a controller does a lot more than send the data in to the NAND, and is needed to successfully read and write the data. If this failed and only option was a dump from JTAG, this is no better than chip off. data is not stored on the NANDS in any useable form
Right -- but think a little further here. The MEX is 3 Cortex M4 cores, APB/AHB, the NAND controllers, and whatever other peripherals -- and the firmware is available. Wiring up QEMU et. al. to emulate 3 cores and a small number of peripherals, and then attaching 8 virtual NAND devices containing the data extracted from a "chip off" dump is not an unreasonable way of doing reconstruction. Honestly, given sufficient skill to lift and reball the NAND BGAs for extraction, probably a much safer way to go as you don't risk further damage to the data once captured.
Anyhow, all of this is academic as what I really need is to get access to the data on this SSD right now.
I was going to answer each point but that would keep the whole thing "Acedemic" The problem with being Acedemic" is you never actually get to the recovery part - there is always some reasoning where this or that method is better or worse than some other method.
Plus you are making the mistake of thinking flash memory storage is just like any other electronics, and engineers would do what islogical or what makes sense.
There is flash memory on probably all controllers, and I am surprised you didnt just look around for any datasheets to have a look what flash controllers are: basically a mini-pc that runs code. I would be surprised if the WASN'T flash on a controller. The many tools from dodgy parts of the net such as flashboot.ru specifically are designed to update controllers.
I know these come in many configurations, but
Attachment:
arm.PNG [ 220.31 KiB | Viewed 11882 times ]
anyway, I will go into it a bit more..
point (1) - I guess if they started being engineers, they would stick to it and would be a more lucrative usage of their time.
Quote:
Should be, but as it turns out often is not. It seems that a lot of techs know how to run tools, but have little to no engineering background.
and yet they recover drives day in, day out... and engineers come here to find out how to do it.
I wont argue that a knowledge of at the very least, power and data circuits would be highly benificial, and I would love to understand them as well as @fzabkar that often helps with such.
point (2) many flash devices that look exactly the same (part numbers of flash, controller models, exact BOM) have different data/SA layouts, different XOR, etc. Just go to
http://www.flash-extractor.com/library/ and look at all the different variations.
point (3) maybe, but I thought you wanted data now, not in 3,6,9 months.. Plus I may agree give a sufficiently skilled coder, and someone that had access to the patient drives internal technical specifications and data structures. Or a least a way to discover all of it , which in that case you may as well do chip-off, as you would be dooinfg significant electronics work on the drive anyway. remember this is a black box with no specific documentation of the hardware, and of what the did to it software wise.
This is not a flame post BTW, but just my opinion of the situation. We have seen a lot of similar posts where someone who does have skill in electronic engineering will see a future solution, but I think I have only seen 2 cases where it has follwed through to a solution, and many many weeks of work at the very least from others before project dies.
anyway, enoug chit-chat, and good luck with your recovery as well.