Forum rules

Please do not post questions about data recovery cases here (use this forum instead). This forum is for topics on finding new ways to recover data. Accessing firmware, writing programs, reading bits off the platter, recovering data from dust...

The Firmware of my Samsung EVO 840 250 GB does not initialize the SATA interface correctly anymore (but it works in SAFE Mode, so it is physically working), so I started to research it, and I want to provide you with the knowledge I got so far:http://www2.futureware.at/~philipp/ssd/ ... Manual.pdfI have found a few bugs and issues in the firmware and reported them to Samsung directly, so that they can fix them and provide a firmware update.But unfortunately I haven't found the root cause yet, so if anyone can provide any additional information, I would be happy.(And thanks a lot to everyone contributing to this forum, I was able to learn a lot here in the past few weeks!)

* Please analyze the firmware updating procedure. I would need a firmware change that has the first4 bytes changed to an endless loop, so that I can reliably debug the initialisation of the firmware. My current guess is that there is a 16 or 32 bit checksum at the end of the firmware header which protects the whole firmware. Please analyze the checksum algorithm and develop a tool to calculate the checksum for a firmware file and write the calculated checksum into the file.

CRC&ECDSA: Ah, yes, that makes sense to have digital signatures at the end of the firmware file after the partitions.The thing at 0x000001FC-0x000001FF in the firmware looked like a CRC to me too, what do you think?

Are you still working on a EXT0BB6Q case? EXT0CB6Q has been on the market for quite some time now ...And by the way, I would suggest to update EXT0BB6Q and older variants to EXT0CB6Q to make sure that seldomly used files are refreshed regularly and don't vanish.

The thing at 0x000001FC-0x000001FF in the firmware looked like a CRC to me too, what do you think?

The firmware does not check this value, SPI ROM too. Sometimes this value is CRC, sometimes something else.

Quote:

Are you still working on a EXT0BB6Q case? EXT0CB6Q has been on the market for quite some time now ...

I researched 840 EVO 2 years ago. At that date EXT0BB6Q has the latest. With regard to the transition to a newer firmware version. So far this has not been necessary. SSD that we come across, we have successfully restored when using this firmware.

Quote:

Anything else besides the private key you are interested in?

With regards to the structure of the firmware nothing else interested. I am interested in the description of the translation tables, service modules, etc. Also interesting technique for obtaining AES key to decrypt the user data. How to send a low-level commands to the NAND chips, for example Read Retry. It is interesting to find the software to work with damaged SSD.

You have a very interesting study. But it seems to me that you have chosen is not quite the right approach.You did not try to disassemble the firmware? There are a variety of convenient tools for this, for example IDA PRO + Hex Rays.

@fzabkar: Wrong guess, the ABS part is a I2C temperature sensor, not a SPI flash rom.I was trying to decode the the waveform as SPI for some time, when a friend had the idea that it might be a different protocol, and I2C was the only meaningful alternative the oscilloscope supported:I2CTime,Dir,ID,Data,ACKed,1.0870288E-01,Write,18,08 02,Y,1.0890320E-01,Write,18,00,Y,1.0903376E-01,Read,18,00 77,N,1.0923408E-01,Write,18,01 02 29,Y,1.0949680E-01,Write,18,04 05 50,Y,1.0975952E-01,Write,18,04,Y,1.0989008E-01,Read,18,05 50,N,1.1008976E-01,Write,18,02 05 00,Y,1.1035280E-01,Write,18,02,Y,1.1048336E-01,Read,18,05 00,N,1.1068304E-01,Write,18,03 04 B0,Y,1.1094608E-01,Write,18,03,Y,1.1107664E-01,Read,18,04 B0,N,

I found 3 very similar chips, and I am still working to figure out which one it actually is:http://www.ti.com/lit/ds/symlink/tmp275.pdf (this has 48h-4fh as device address)http://www.nxp.com/documents/data_sheet/LM75A.pdf (48h-4fh device address)http://ww1.microchip.com/downloads/en/D ... 25095A.pdf (18h-1fh device, address or 48h-4fh on request)I currently think that MCP9808 is the most likely candidate, since I saw 18h as device address.One imporant thing to notice is those temperature sensors are always located directly next to the flash chips, since they are temperature connected with the flash chips through a thick ground-plane-lane, so that they can react to the temperature as fast as possible.I took a look at some other Samsung SSD models, and they had very similar chips on their PCB layouts too, and they were also directly next to the flash chips.I think this is another reason for why there are 2 flash chips mounted directly in the same place on the opposite side of the PCB, in that it's easier to measure the temperature that way, to keep a short distance to the temperature sensor. So if you find a small chip with 8 pins that is very close to something that potentially gets hot, it could be a temperature sensor.

Most of the PHYs are mostly figured out now. The sectors can be read out directly from flash now. (But it still has a few performance and stability issues). Decryption and Reconstruction is still on the TODO list.I updated the documentation:http://www2.futureware.at/~philipp/ssd/ ... Manual.pdf

@sourcerer, it's a different SSD, but SanDisk's Ultra Plus (SDSSDHP / SDSSDH2, Marvell SS889175) has an extensive diag/debug console. The firmware update (update.flu) has detailed embedded documentation for the various commands. Might be worth a look ...

Now regarding the status register [2038000C]: When everything is ok, it has the value 0xFFFF0000. When you have read a sector it often gets the value 0x7FFF8000, which needs to be acknowledged by writing 0x7FFF8000 again (or more or less whichever value it had in it). When the register has the value 0x7FFF000 after any request, then the Channel seems to be dead.

Most likely the problem is that you submitted the next command without waiting for an interruption.

In your case, you use a CmdBufEntry value of 0xF. While processing the read command, the register 0x2038000C value is 0x7FFF8000. Upon completion of processing, the register 0x2038000C value must become 0xFFFF8000. Only after this it is possible to clear the interrupt.

By the way, the CmdBufEntry value from 0x01 to 0x0F is used by the command queue. During its manipulations with registers, a conflict with the queue handler is possible.Therefore, it is better to use a CmdBufEntry value equal to 0x00.

I finally found cheap JTAG adapters that you can use to interface with the Samsung SSDs: Search for "Altera USB Blaster". All the other adapters I tried did not work.

I have measured the voltages and connectivity applied to the BGA Flash chips by a slightly different PCB, which uses the same controller chip, and has the same BGA pattern:http://www2.futureware.at/~philipp/ssd/ ... Pinout.pdfTheoretically I could design an adapter board for it, would anyone be interested in it?

I am not going to pretend I know the science, but regular chips use charge pumps internally and a lot of charge is used up by the pumps themselves. As these new chips are more like 16 or 32 chips daisy chained together it is a lot of wasted power, so it is a way of boosting to program votage with a single boost.Not sure if readers are configurable enough in software/firmware or new hardware design is needed. I have most faith in VNR reader as that already has seperate i/o core voltage and has been able to be configured with firmware updates. possibly a different shield may be all thats needed.

Who is online

Users browsing this forum: No registered users and 3 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum