Analysis of Dell FW update for SK hynix SC300 (SH87810AA

[fzabkar]

Analysis of Dell FW update for SK hynix SC300 SSD (SH87810AA controller)

Here is a firmware update for an SC300 SSD based on an SK Hynix SH87810AA controller, probably a rebranded LAMD controller.

SK Hynix SC300 M.2 Solid State Drive Firmware Update:
https://www.dell.com/support/home/en-au/drivers/driversdetails?driverid=754y5
https://dl.dell.com/FOLDER04141057M/2/SK%20Hynix%20SC300%20M.2%20Solid%20State%20Drive%20Firmware%20Update_ZPE.exe

"This package provides the firmware for SK Hynix SC300 M.2 2280 128GB/256GB/512GB, Revision 20101P00 ..."

I extracted the firmware payload file, 20101P00.ALL.bin. It consists of 36-byte records. The first 32 bytes are data while the last 4 bytes appear to be some kind of checksum or ECC. Can anyone identify the ECC/checksum algorithm?

Code:

Offset(h) 00       04       08       0C       10       14       18       1C       20

00000000  CEFAFECA 31050135 60EC1A00 05000000 32303130 31503030 3C9A0600 01000000 38936205  ÎúþÊ1..5`ì......20101P00<š......8“b.
00000024  0C000000 08000000 76000000 040201AD EE14A742 60010000 30323031 50313030 46086B06  ........v.......î.§B`...0201P100F.k.
00000048  00000000 00000000 00000000 00000000 00000000 00000000 01000000 0C000000 3DF60701  ................................=ö..
0000006C  08000000 76000000 040202AD 5A15A744 605F0500 30323031 50313030 00000000 5C328302  ....v.......Z.§D`_..0201P100....\2ƒ.
00000090  00000000 00000000 00000000 00000000 00000000 01000000 0C000000 08000000 2A388803  ................................*8ˆ.
000000B4  76000000 040201AD 5A14AB42 60BD0A00 30323031 50313030 00000000 00000000 28DFAE02  v.......Z.«B`½..0201P100........(ß®.
000000D8  00000000 00000000 00000000 00000000 01000000 0C000000 08000000 76000000 ADACE700  ............................v....¬ç.
000000FC  040202AD 5C15AB44 601D1000 30323031 50313030 00000000 00000000 00000000 BAB6B700  ....\.«D`...0201P100............º¶·.
00000120  00000000 00000000 00000000 01000000 0C000000 08000000 76000000 040204AD 0D834707  ........................v........ƒG.
00000144  5E16AB46 607F1500 30323031 50313030 00000000 00000000 00000000 00000000 63F1B902  ^.«F`...0201P100................cñ¹.
00000168  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000  ....................................
0000018C  4453534C 4D524148 607C0000 2E44724A D47B0000 80000000 D47B0000 8FB54A77 7E47CF06  DSSLMRAH`|...DrJÔ{..€...Ô{...µJw~GÏ.
000001B0  44010000 607C0000 44010000 8746E3A4 C8B90000 C07D0000 C8B90000 A989C1B3 4FF0F000  D...`|..D...‡Fã¤È¹..À}..ȹ..©‰Á³Oðð.
000001D4  BCBA0000 A0370100 BCBA0000 9624BC0A 08820100 60F20100 08820100 20EDBAF7 80EF4602  ¼º.. 7..¼º..–$¼..‚..`ò...‚.. íº÷€ïF.
                                                                                  ^^^^^^^^
                                                                                  checksum

The structure is most evident in text records.

Code:

Offset(h) 00       04       08       0C       10       14       18       1C       20

000C0138  20666561 74757265 200A0025 2D387320 3A205B63 685D205B 6469655D 205B626C 005E1800   feature ..%-8s : [ch] [die] [bl.^..
000C015C  6F636B5D 20777269 74652061 20646566 65637420 6D61726B 20287573 6520666F 927A5B06  ock] write a defect mark (use fo’z[.
000C0180  72206D2D 6C697374 290A0025 2D387320 3C616464 723E3A20 72656164 20726567 1DEC4607  r m-list)..%-8s <addr>: read reg.ìF.
000C01A4  69737465 72206174 20676976 656E2061 64647265 73732868 65782066 6F726D61 4E35BF03  ister at given address(hex formaN5¿.
000C01C8  74292E0A 00252D38 73203C61 6464723E 203C7661 6C3E3A20 77726974 65207265 76230405  t)...%-8s <addr> <val>: write rev#..
000C01EC  67697374 65722061 74206769 76656E20 61646472 65737328 68657829 20776974 EBC2D205  gister at given address(hex) witëÂÒ.
000C0210  68206769 76656E20 76616C28 68657829 2E0A0025 2D387320 3A207377 69746368 D628D302  h given val(hex)...%-8s : switchÖ(Ó.
000C0234  20554152 5420746F 20686F73 74204152 4D2E0A00 252D3873 203C6275 663E3C64 F7FC0402   UART to host ARM...%-8s <buf><d÷ü..
000C0258  6174613E 3C6E6279 74653E3A 2066696C 6C204275 66666572 20776974 68206461 911A5D06  ata><nbyte>: fill Buffer with da‘.].
                                                                                  ^^^^^^^^
                                                                                  checksum

Attachments

20101P00.ALL.bin.7z

(500.31 KiB) Downloaded 103 times

[fzabkar]

Is it possible that SK hynix is "ruggedising" its firmware by injecting a 27-bit ECC after each block of 32 bytes? Is this ECC actually written to NAND, or is it stripped out after downloading to SDRAM?

I expect that the ECC bytes are stripped out before the firmware is committed to NAND. The payload appears to contain a header that defines 5 firmware packages, and this header is also error-checked in the same way.