holy cow, tiamo strikes again
I had once a look at the firmware/updater of the Plextor but couldn't find where or how I can edit the DEVICE IDENTIFIER STRING... same with the SAMSUNG. so, tiamo, could you please share a little bit more about how this can be done?
EDIT:
hm. looking at the windows screenshot you were using arcconf.exe? is it possible to use this utility without an ADAPTEC HBA? the command would be "arcconf IMAGEUPDATE"? how to get ahold of the SSD's firmware?
thnx!
the arcconf is a helper program written by myself to flash the ssd attached to my adaptec raid card, it is not the official command line tools made by adaptec.
the firmware in plextor ssd has a simple structure.
the firmware is divided into two regions, boot code and user code,and user code is also divided into more small parts called as BIN.
boot code, user code, BIN contain a header followed by payload data and one byte payload checksum.
the header's length is 0x20
the first uint32 should be a fixed value 0x5a
the second uint32 is the total length
the third uint32 is the payload data length
after payload data, there is a one byte checksum, so the total length=payload_lenth+1
the last byte of header is the header's checksum
checksum is computed by summing the whole payload data byte by byte.
there is also a total code length uint32(both boot and user code) and an uint16 user code checksum at the end of the firmware. the checksum counts only user code(boot code is not included)
if you have a decrypted firmware file(yes, plextor encrypted the firmware in his firmware updater tools), you can see something like this
offset 0x0000-0x2000 is boot code
offset 0x2000-0xxxxxx is user code
AND offset 0x2060-0x2088 is the raw ATA model string returned by IDENTFY DEVICE command. we need modify this! but wait, remember the CHECKSUM.
offset 0x3fff8-ox3fffc is the total length of both boot and user code, and 0x3fffe is the user code's checksum.(total length of the firmware is 256kb)
--------- my m5p dump-------(for example)
first is the boot code
Code:
00000000 5A 00 00 00 0D 1C 00 00 0C 1C 00 00 20 00 00 00 Z........... ...
00000010 00 E0 01 00 00 E0 01 00 00 00 00 00 00 00 00 8D ................
then the user code
Code:
00002000 5A 00 00 00 49 01 00 00 48 01 00 00 20 20 00 00 Z...I...H... ..
00002010 00 00 00 04 00 00 00 04 00 00 00 00 00 00 00 35 ...............5
00002020 73 73 64 62 69 6E 76 32 4C 49 54 45 4F 4E 20 4C ssdbinv2LITEON L
00002030 43 53 31 32 38 4D 36 53 00 00 00 00 00 00 00 00 CS128M6S........
00002040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00002050 44 43 37 30 32 30 47 20 01 02 00 00 00 00 00 00 DC7020G ........
00002060 50 41 4C 50 20 45 53 53 20 44 50 28 45 4C 54 58 PALP ESS DP(ELTX
00002070 52 4F 50 20 2D 58 32 31 4D 38 50 35 6F 72 20 29 ROP -X21M8P5or )
00002080 20 20 20 20 20 20 20 20 2E 31 38 30 20 20 20 20 .180
looking at 0x2008, the length is 0x148(LE32), this is the first BIN in user code region
Code:
00002160 10 10 12 10 13 10 22 10 CA 5A 00 00 00 79 EC 01 ......"..Z...y..
00002170 00 78 EC 01 00 89 21 00 00 00 00 00 40 00 00 00 .x....!.....@...
00002180 40 00 00 00 00 00 00 00 4F @.......O
from 0x2020 to 0x2167(length 0x148) is the payload data, and 0x2168 is checksum(sum of those bytes in [0x2020, 0x2167], 0x148 bytes), yes, we need modify this byte too. and there is another BIN starting from 0x2169, length is 0x1ec78
Code:
0003FFF0 FF FF FF FF FF FF FF FF 07 C4 03 00 FF FF 8E FE ................
total user and boot code length is 0x03c407, and use code's checksum is 0xfe8e. we also need to modify the last uint16, sum of those bytes in [0x2000, 0x3c407)
summary, first we should modify model string at 0x2060, then regenerate a new BIN checksum and a new user code checksum
of course, first we need to decrypt the firmware file from the official updater released by plextor, modify the model string, regenerate the checksum, then encrypt the modified firmware file, and finally use the official flasher to upload it to ssd.
BUT BUT, actually the encryption algorithm used by plextor is a simple xor, but the key buffer generation is a boring process, i did not go deep in it.
we can use another simple approach by using a debugger.
put a breakpoint on official updater's decrypt routine, let it to decrypt the firmware first, after our breakpoint hits, dump the decrypted firmware from memory, we got the plaintext one, modify it, then flash by ourselves.
then, how to flash the decrypted firmware to ssd?
it is simple, just one ata command DOWNLOAD MICROCODE 92h.
first divide the firmware into 2kb block, then send those blocks to ssd by using feature 3(download with offset), finally send a zero length 92h with feature 7 and LBA-mid=0x4c, LBA-hi=0x41.(0x414c means update both boot and user code)
Code:
128 times
feature sector lba-low lba-mid lba-hi device command
3 4 0 offset0-7 offser8-15 0xa0 0x92
finally
7 0 0 0x4c 0x41 0xa0 0x92
please check ata command set spec for more info about DOWNLOAD MICROCODE.
and, one more thing
looking at firmware's offset 0x2050, there is a string like DC7020G, this is the ext firmware info, first 6 bytes is the hardware revision? m5p has two different values(DC7020 and BC7020) and the official firmware updater has two firmware files, one for DC, one for BC, you should flash the one matching with your ssd.
your ssd's current value is returned as additional production identifier in IDENTIFY DATA word170.
and you can use a vsc to retrieve it
Code:
output a sector buffer(0x200) to device first
uint8_t sectorBuffer[512]={0x0a, 0x07}
task file
feature sector lba-low lba-mid lba-hi device command
0xfc 1 0 0 0 0xa0 0xff
then read a sector from device
task file
feature sector lba-low lba-mid lba-hi device command
0xfd 1 0 0 0 0xa0 0xff
ext firmware info is the first 8 bytes of the output data
