Switch to full style
In-depth technology research: finding new ways to recover data, accessing firmware, writing programs, reading bits off the platter, recovering data from dust.

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...
Post a reply

Samsung Evo 840 SSD

October 10th, 2016, 17:01

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.pdf
I 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!)

Re: Samsung Evo 840 SSD

October 10th, 2016, 17:20

Nice work! I might be able to help with the identification of some of the ICs, but I can't help with the firmware.

Re: Samsung Evo 840 SSD

October 10th, 2016, 19:11

The mystery components appear to be marked especially for Samsung.

JS4TAA appears to be a 5V STEF4S electronic fuse manufactured by STMicroelectronics. "JS4" appear to be the important characters in the part number.

GUILL is a TPS62130D2 synchronous step-down DC-DC converter manufactured by Texas Instruments.

AKE40D appears to be a multiple-output switchmode DC-DC converter, probably with integrated power sequencing. "AKE" appear to be the important characters in the part number.

I'm guessing that the ABS part is an SPI flash memory.

The following thread confirms the identity of the JS4 device.

Samsung 840 EVO 512GB - burned - pls need advice:
./viewtopic.php?f=10&t=31458

Re: Samsung Evo 840 SSD

October 11th, 2016, 6:33

Interesting article, I liked it.

* Please analyze the firmware updating procedure. I would need a firmware change that has the first
4 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.


A small gift for you:
Firmware dump EXT0BB6Q:
0x00000100 - 0x000001AF: Firmware allocation table
0x000FF15C - 0x000FFFD3: CRC16 table for dump
0x000FFFD4 - 0x000FFFD7: CRC32 value for dump
0x000FFFD8 - 0x000FFFFF: ECDSA signature, algorithm secp160r1.

If you can find the private key for this algorithm, write to me. I, in turn, will share something with you.
Good luck to you.

Sorry for my English.

Re: Samsung Evo 840 SSD

October 11th, 2016, 8:28

Yes, I figured out the Firmware allocation table already:
http://www2.futureware.at/~philipp/ssd/ ... Q.dec.html
(The only thing missing there are the additional dynamic mappings like e.g. that P21 is also mapped to 0x00000000 on mex1)

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.

Anything else besides the private key you are interested in?

Re: Samsung Evo 840 SSD

October 12th, 2016, 6:39

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.

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.

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.

Re: Samsung Evo 840 SSD

November 16th, 2016, 18:12

@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:
I2C
Time,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.

Re: Samsung Evo 840 SSD

November 16th, 2016, 19:07

sourcerer wrote:@fzabkar: Wrong guess, the ABS part is a I2C temperature sensor, not a SPI flash rom.

Nice work and thanks for the correction.

Re: Samsung Evo 840 SSD

April 25th, 2017, 18:03

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

Re: Samsung Evo 840 SSD

April 26th, 2017, 10:37

You might want to put all the memory dumps you have to a separate archive

Re: Samsung Evo 840 SSD

April 26th, 2017, 15:29

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

SanDisk Ultra+ SSD Manual Firmware update version X2316RL:
https://kb.sandisk.com/app/answers/deta ... on-x2316rl

http://downloads.sandisk.com/downloads/ ... 2-128G.iso
Attachments
update_flu.rar
(51.06 KiB) Downloaded 158 times

Re: Samsung Evo 840 SSD

April 27th, 2017, 3:45

@Doomer: Ok, I will put them in an archive.
@fzabkar: Thanks, it helped a bit, but they have quite different names and concepts compared to Samsung.

Re: Samsung Evo 840 SSD

April 27th, 2017, 6:19

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.

See how this is done in the SSD firmware:
Code:
void WaitAndClearInterrupt(int aBank, int aCmdBufEntry)
{
  int Offset;    // r0@1
  int Bit;    // r2@1

  Offset = ((aBank & 3) << 0x10) + 0x20380000;
  Bit = 1 << aCmdBufEntry;
  while ( !(Bit & (*(_DWORD *)(Offset + 0xC) >> 0x10)) )
  {
    if ( (unsigned __int16)*(_DWORD *)(Offset + 0xC) & (unsigned __int16)Bit )
      *(_DWORD *)(Offset + 0xC) = *(_DWORD *)(Offset + 0xC) & 0xFFFF0000 | (unsigned __int16)Bit;
  }
}


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.

Re: Samsung Evo 840 SSD

June 10th, 2017, 18:28

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.pdf
Theoretically I could design an adapter board for it, would anyone be interested in it?

As usual, I updated my documentation.

Re: Samsung Evo 840 SSD

June 10th, 2017, 19:55

I am interested in adapter board for sure.
Great work

Re: Samsung Evo 840 SSD

June 10th, 2017, 23:07

What do the 12V pins do?

Re: Samsung Evo 840 SSD

June 11th, 2017, 9:38

Is the Package BGA-316 ?

BGA316_pinout.png


BGA316_img.jpg
BGA316_img.jpg (13.66 KiB) Viewed 2118 times

Re: Samsung Evo 840 SSD

June 11th, 2017, 9:54

cant edit post now...

It is in the JEDEC standard. VPP 12v-24v. Chips can use internal or common shared external boost converter for programming.

Re: Samsung Evo 840 SSD

June 11th, 2017, 15:07

HaQue wrote:It is in the JEDEC standard. VPP 12v-24v. Chips can use internal or common shared external boost converter for programming.

Thanks, I thought that might have been the case, but it seemed like a retrograde step as this is how it was done more than 20 years ago.

Re: Samsung Evo 840 SSD

June 11th, 2017, 21:41

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.
Post a reply