All times are UTC - 5 hours [ DST ]


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 new topic Reply to topic  [ 21 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Samsung Evo 840 SSD
PostPosted: October 10th, 2016, 17:01 
Offline

Joined: August 13th, 2016, 17:10
Posts: 39
Location: Vienna, Austria
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!)


Top
 Profile  
 
 Post subject: Re: Samsung Evo 840 SSD
PostPosted: October 10th, 2016, 17:20 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 9297
Location: Australia
Nice work! I might be able to help with the identification of some of the ICs, but I can't help with the firmware.

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Samsung Evo 840 SSD
PostPosted: October 10th, 2016, 19:11 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 9297
Location: Australia
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

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Samsung Evo 840 SSD
PostPosted: October 11th, 2016, 6:33 
Offline

Joined: May 12th, 2015, 5:37
Posts: 5
Location: Rostov-on-Don, Russia
Interesting article, I liked it.

Quote:
* 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.


Top
 Profile  
 
 Post subject: Re: Samsung Evo 840 SSD
PostPosted: October 11th, 2016, 8:28 
Offline

Joined: August 13th, 2016, 17:10
Posts: 39
Location: Vienna, Austria
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?


Top
 Profile  
 
 Post subject: Re: Samsung Evo 840 SSD
PostPosted: October 12th, 2016, 6:39 
Offline

Joined: May 12th, 2015, 5:37
Posts: 5
Location: Rostov-on-Don, Russia
Quote:
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.


Top
 Profile  
 
 Post subject: Re: Samsung Evo 840 SSD
PostPosted: November 16th, 2016, 18:12 
Offline

Joined: August 13th, 2016, 17:10
Posts: 39
Location: Vienna, Austria
@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.


Top
 Profile  
 
 Post subject: Re: Samsung Evo 840 SSD
PostPosted: November 16th, 2016, 19:07 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 9297
Location: Australia
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.

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Samsung Evo 840 SSD
PostPosted: April 25th, 2017, 18:03 
Offline

Joined: August 13th, 2016, 17:10
Posts: 39
Location: Vienna, Austria
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


Top
 Profile  
 
 Post subject: Re: Samsung Evo 840 SSD
PostPosted: April 26th, 2017, 10:37 
Offline
User avatar

Joined: September 29th, 2005, 12:02
Posts: 3061
Location: Chicago
You might want to put all the memory dumps you have to a separate archive

_________________
https://www.linkedin.com/in/artemrubtsov/


Top
 Profile  
 
 Post subject: Re: Samsung Evo 840 SSD
PostPosted: April 26th, 2017, 15:29 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 9297
Location: Australia
@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 102 times

_________________
A backup a day keeps DR away.
Top
 Profile  
 
 Post subject: Re: Samsung Evo 840 SSD
PostPosted: April 27th, 2017, 3:45 
Offline

Joined: August 13th, 2016, 17:10
Posts: 39
Location: Vienna, Austria
@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.


Top
 Profile  
 
 Post subject: Re: Samsung Evo 840 SSD
PostPosted: April 27th, 2017, 6:19 
Offline

Joined: May 12th, 2015, 5:37
Posts: 5
Location: Rostov-on-Don, Russia
Quote:
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.


Top
 Profile  
 
 Post subject: Re: Samsung Evo 840 SSD
PostPosted: June 10th, 2017, 18:28 
Offline

Joined: August 13th, 2016, 17:10
Posts: 39
Location: Vienna, Austria
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.


Top
 Profile  
 
 Post subject: Re: Samsung Evo 840 SSD
PostPosted: June 10th, 2017, 19:55 
Offline
User avatar

Joined: December 4th, 2012, 1:35
Posts: 2832
Location: Adelaide, Australia
I am interested in adapter board for sure.
Great work


Top
 Profile  
 
 Post subject: Re: Samsung Evo 840 SSD
PostPosted: June 10th, 2017, 23:07 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 9297
Location: Australia
What do the 12V pins do?

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Samsung Evo 840 SSD
PostPosted: June 11th, 2017, 9:38 
Offline
User avatar

Joined: December 4th, 2012, 1:35
Posts: 2832
Location: Adelaide, Australia
Is the Package BGA-316 ?

Attachment:
BGA316_pinout.png
BGA316_pinout.png [ 78.75 KiB | Viewed 501 times ]


Attachment:
BGA316_img.jpg
BGA316_img.jpg [ 13.66 KiB | Viewed 501 times ]


Top
 Profile  
 
 Post subject: Re: Samsung Evo 840 SSD
PostPosted: June 11th, 2017, 9:54 
Offline
User avatar

Joined: December 4th, 2012, 1:35
Posts: 2832
Location: Adelaide, Australia
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.


Top
 Profile  
 
 Post subject: Re: Samsung Evo 840 SSD
PostPosted: June 11th, 2017, 15:07 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 9297
Location: Australia
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.

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Samsung Evo 840 SSD
PostPosted: June 11th, 2017, 21:41 
Offline
User avatar

Joined: December 4th, 2012, 1:35
Posts: 2832
Location: Adelaide, Australia
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 21 posts ]  Go to page 1, 2  Next

All times are UTC - 5 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 3 guests


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

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group