Apple 1TB NVMe (MZ-KPU1T0T/0A6)

[thd]

I'll apologize in advance if this forum (Flash storage, SSD) isn't the right place to ask this question. I did look and didn't see another one that stuck out as obviously better though.

I have one of these that suddenly decided it was time to become unresponsive (e.g. it no longer enumerates on PCIe). Just to save time for anyone who is interested and may not be aware, it uses one of the Samsung S4LN053X01-8030 (MEX) controllers. I've had a read over the info that Philipp Gühring put together, which is outstanding. I do EE and embedded design, I'm just in a situation where I'm away from home for a while (e.g. no tools) and not in a position where I can effectively deal with this myself right now, but just need to get it fixed. As an aside, it's somewhat astounding to me that the manufacturers don't provide recovery mode firmware loads that one can inject via JTAG that'll do nothing other than allow someone to dump the contents of the device for purposes like these.

I'm asking here because I've not had the best of luck so far with the labs I've spoken with. Basically, I'm looking for a lab that's done successful recovery on one or more of these already and has the following capabilities:

(1) Can/will do PCB electrical diagnostics as a first step (e.g. verify that all of the power supply voltages are correct and that the crystal is running)
(2) If the controller is shot, can do BGA lift + replace in house
(3) As a last resort, if they can't get any further, can lift / reball / image the 8x NAND parts, etc.

Basically this one may need more than "I plugged it into Deepspar and couldn't read it, so it's unrecoverable".

One of the labs I spoke with said that this would likely need to go to one of the labs in Russia or China, along with the standard caveats that could apply there.

Anyhow, any thoughts/ideas/info here are certainly appreciated.

[HaQue]

(1) That should be a given
(2) would be out as the controllers have firmware and I really doubt they would be transplantable.
(3) is less a last resort, but more likely as there is evidence of cases with these controllers solved by chip off.

SSDs of this size can take a significant amount of time to recover.

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.
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

[thd]

(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.

(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...

(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.

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.

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.

[pcimage]

I have done a few of these SSD’s with that controller.

A right royal PITA and super time-consuming, and thus very expensive.

Results are not usually 100% perfect but pretty good.

[HaQue]

(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.

(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...

(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.

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.

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

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.

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.

[thd]

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

Flash memory controllers, and flash memory itself, are/is just regular electronics. They're just (in this case at least) multicore microcontrollers with w/ a handful of SERDES, a DDR interface, a bunch NAND controllers, and some GPIOs on them. You're right, I should have looked at a few of them and I'd see that flash is present on a bunch of them. I guess for the volume they're made it, it makes sense.

Understanding the theory of operation of any of these things can only be of help to anyone trying to recover data from them.

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.

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.

Right, I'm not trying to put anyone down or discredit them. If you have a job where there's potentially only one shot to get it right, you want to have confidence that you're giving it to the most knowledgeable and experienced person out there for that job.

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.

Fair point and duly noted. This is where the experience with the recovery target part is most useful.

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.

I do want the data back. I'm not insinuating that a science project is the way to go here, I'm just surprised that a tool like this hasn't been developed. Emulators and simulators are used for all other parts of silicon design (e.g. software is running in co-design on a part long before it's been taped out). It seems like for data recovery, being able to bring a virtual controller online and then selectively enabled/disable parts of it could be useful. I guess with that said, some of the chip off recovery software is just short circuiting that process anyhow.

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.

Yeah absolutely not taken as any sort of a flame. If anything, informative. I can completely understand your statement regarding proposed vs. existing solutions. I have neither the time nor inclination to write a flash controller emulator (esp. for a 6 year old design) right now. I just need the data and to get on with life.

Before handing off the job to someone who is completely unknown to you though, you want to have a very clear understanding of their capabilities and also a general "plan of attack" for the recovery. If you get and subscribe to those two things, then you can have reasonable comfort that you're in good hands. The worst scenario to end up in is where expectations were misaligned on either or both sides and you end up with permanent loss of your data.

This is just about being as careful as possible.

[Blizzard]

...Before handing off the job to someone who is completely unknown to you though, you want to have a very clear understanding of their capabilities and also a general "plan of attack" for the recovery. If you get and subscribe to those two things, then you can have reasonable comfort that you're in good hands. The worst scenario to end up in is where expectations were misaligned on either or both sides and you end up with permanent loss of your data. This is just about being as careful as possible.

I see you are in the US, have you considered Ace Data Recovery in Texas?

[thd]

I see you are in the US, have you considered Ace Data Recovery in Texas?

At your suggestion, I did try to give them a call. They won't let their engineers talk to the customers, but I was told that if I call back tomorrow that I can talk to their general manager. I'm wary of companies who claim special capabilities but provide no further details.

On their web page, they state that devices they do data recovery on can be returned to Apple for warranty claims. That would seem to suggest that they only employ non-invasive methods.

Anyhow, we'll see where it goes.

[HaQue]

I do want the data back. I'm not insinuating that a science project is the way to go here, I'm just surprised that a tool like this hasn't been developed. Emulators and simulators are used for all other parts of silicon design (e.g. software is running in co-design on a part long before it's been taped out). It seems like for data recovery, being able to bring a virtual controller online and then selectively enabled/disable parts of it could be useful. I guess with that said, some of the chip off recovery software is just short circuiting that process anyhow.

Yes you are right, the flash recovery software emulates the controller, well not strictly, but reverses it to produce an image. a good portion is simply XOR, some manipulation of blocks, anipulation of pages inside the blocks but there is also reading from the NAND now that is a major consideration. read retry, undocumented commands etc.

Most of this is done by modifying based on prior knowledge or data analysis, as we dont get insight into controllers. Remember, controllers are not just ARM, but custom cores of many types, so data recovery companies have a swath of different systems to analyse. There is not really a benifit to create an emulator in the strict sense of the word, when you can create an image by an algorithm to reverse what the controller did, plus you can use the same tool with many algorithms to cater for many controller vendors, instead of creating a heap of different emulators.

I am not surprised enginners are not faced to customers, if you look at it from their point of view, this can be undesirable for many reasons. one reason: Many engineers I know would be happy to talk in length about their work - not desirable for a company!

On their web page, they state that devices they do data recovery on can be returned to Apple for warranty claims. That would seem to suggest that they only employ non-invasive methods.

Or it could suggest that Apple trust them enough that even though they have performed work on the drive that would otherwise void the warranty if done by other parties, in their case Apple will still honor the warranty... knowing that they can trust that before the drive entered their lab it was in fact faulty and ACE did not kill a good drive. As far as I am aware, they are a very decent lab.

[Blizzard]

...As far as I am aware, they are a very decent lab.

I have referred a number of NVME SSD cases to Ace. At least 3 people reported back that Ace recovered their data. None have reported that they didn't, but we don't outsource so we have only referred the customers. They don't really have any reason to report back to us. One of the people that reported back had an Apple/Samsung 512GB and they said it took 3 months but they received an email update every week. The other 2 were a quick turnaround.
Also, there is thread on this forum where Luke from Recovery Force said he sent a bricked Sandforce based SSD to 3 labs that claimed they could recover it (Seagate, Drivesavers, Ontrack) and they all failed. He sent it to Ace and they recovered it.

[lcoughey]

I'd probably outsource more with ACE if their costs weren't so high. But, they are very good at what they do and worth their cost.

[thd]

So I talked to ACE, and unfortunately, they don't have support for this drive.