In-depth technology research: finding new ways to recover data, accessing firmware, writing programs, reading bits off the platter, recovering data from dust.
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...
November 12th, 2019, 15:43
I recently bought some DELL branded SAS disks (ST2000NM0023) for my homelab, but one arrived defective. Since I also wanted to tinker around with custom firmware (in the hopes of enabling some DELL disabled features (?) I used the defective one as a sort of guinea pig. Tried flashing the DELL lod to it without removing the DELL header, big mistake. But my overall goal still stands. I want to be able to reflash these DELL disks to retail ones. I hooked up a flash programmer to a second disk and read out the flash successfully, and I'm currently trying to make sense of it all.
The firmware from the Disk seems to have two headers at the beginning, which is the first thing I don't understand. I've tried mapping out the different areas. From my understanding, the Offsets apply from the beginning of the current header, correct?
What I now want to do is to be able to use the stock Seagate LOD and use the correct bits and pieces to create a rom that will fit on the SPI flash and also work. From what I can tell this is not an F3 disk (although I am not sure as I can't find that much information on the topic), so some of the tools don't work or throw errors. I don't know if I am allowed to attack a the Seagate LOD or even the DELL ROM dump so I'll leave it until someone tells me otherwise
Is there anyone here who has done anything similar already? Just so I know. I think one of the main issues is that the drives are all currently on GE09 and I cannot find that firmware anywhere to download, so there's no way for me to compare the LOD to the actual contents of the flash. One thing I have notices is that the flash chip seems to be virtually empty after approx. 512 bytes, with only occasional blocks of zeroes.
November 13th, 2019, 2:26
Tool for explore ROM:https://yadi.sk/d/uCjFT6nUhr_-Qw
Tool for edit loader:https://yadi.sk/d/7HwS4BBh3Vj0Bg
Megalodon E007 aka "stock" firmware:https://yadi.sk/d/zli2OX1e7Hbm6A
Factory loader may not flash DELL disks. Then "refinement" is required.
November 13th, 2019, 11:14
Thank you very much for your response!
So what you're suggesting is that I modify the stock loader (the .lod file?) with bits from the ROM (the SPI flash dump?) so that the disk accepts it via normal seaflash_firmware flash?
The disks themselves can be flashed by seaflash as I managed to procure a copy of the DELL GE0F firmware for them and it flashed fine with it.
November 13th, 2019, 12:23
Add to previous post:
The factory LOD indeed will not flash on the DELL disk, if that's what you meant. Sorry, I must have mixed up the flash utility with loader.
I think the factory .lod file checks for compatible firmware IDs. What's interesting to me though is that I was able to send the DELL .fwh with the DELL header (which you obviously shouldn't do) WITHOUT it performing any check, thus bricking the experimental disk.
So I think that the factory Seagate .lod is check for firmware versions and because mine is GE09 (well it used to be, now it is GE0F) it refuses to flash.
November 13th, 2019, 15:49
Seaflash has several command line options. It can either use an explicit family, model and file name, or it can consult a configuration file.
Sflash.exe internal docs:http://www.users.on.net/~fzabkar/sf_usage.txt
The configuration file is usually encrypted, but I have written a decrypting tool for the earlier versions:http://www.hddoracle.com/download/file.php?id=3698
Sample file (decrypted):http://www.users.on.net/~fzabkar/dell_fw_cfg.txt
The file's structure is explained in the SeaChest docs:http://support.seagate.com/seachest/SeaChest_Combo_UserGuides.html
Decoding Seagate firmware update configuration files:http://www.hddoracle.com/viewtopic.php?f=22&t=1820
November 13th, 2019, 17:39
Your posts are what I base most of my (limited) knowledge on!
Yes I saw the configuration file thread, the thing is that the archive doesn't include one, unfortunately!
If I understand those docs correctly, I should be able to create my own...?
Edit: But I should also be able to tell seaflash to flash the firmware to the disk by using the command line options you mentioned?
November 13th, 2019, 18:11
I can only speak about SATA updates, but I would expect there to be a BAT file which contains a SeaFlash command line. That should tell you what the updater is looking for. Dell's fwh header also has some information regarding the payload components.
Can you upload the update package?
BTW, it is usually a bad idea to cross-flash between OEM and retail firmware versions. The update package usually contains ROM segments and SA overlays, so it does not completely overwrite the existing firmware. This means that the new components may not necessarily be compatible with the existing ones. In fact I have seen people brick their drives by doing what you are trying to do.
November 13th, 2019, 19:22
Oh I am aware that I could brick it, that's why I used a drive with a defective motor to experiment on first
If that works the way I want it to I can test it on another drive that works and if it bricks it, so be it. It's mostly just to see if it could be done honestly, and maybe someone could get some use out of the information I could find.
Sure, I'll upload the Seagate one as I downloaded it from them, a DELL update package for the same drive and I'll also attach the ROM dump I took of the SPI flash on the drive. I've also attached the DELL firmware (GE0F.lod) that was so hard to come by, maybe it can be useful for someone!
I've also noticed that F3Romexplorer gives me some checksum/crc errors when opening the rom dump and LODedit does the same when I open the lod.
- Dell GS15 update package.zip
- Dell GS15 update package
- (5.44 MiB) Downloaded 419 times
- Description file?
- (305 Bytes) Downloaded 367 times
- ST2000nm0023 rom dump ge09 dell.zip
- GE09 rom dump
- (344.09 KiB) Downloaded 362 times
- Dell GE0F update
- (857.96 KiB) Downloaded 366 times
- Seagate lod
- (2.46 MiB) Downloaded 385 times
November 14th, 2019, 2:48
As you say, there is no BAT or CFS file to control the firmware download. The Dell payload has a 0x100 byte header which must be stripped off to convert it to LOD format for SeaTools or SeaChest.
You can use @E123's tools to parse the LOD files and the ROM dump. The ROM CRC errors are probably OK -- even working ROMs have these errors. I think Seagate's programmers are just sloppy. Just to be sure, you should dump the ROM several times and compare the dumps. You also need to be mindful of the ROM's Vcc. The latest drives use 1.8V ROMs. Earlier ones could be 2.5V or 3.3V. You can verify the Vcc (pin #8) by measuring it.
November 14th, 2019, 3:37
You can ignore CRC errors in ROM. For some modules, the CRC is not provided. For others - the flasher when updating the firmware did not count the CRC. So it is not checked when loading by the disk itself. If the disk spins platters - 100% all the necessary CRC are correct.
Now about the updates. On Seagate, I have not yet encountered a vendor-dependent "hardware". But there is a mechanism for checking the compatibility of updates. It is located inside the disk firmware.
If the "stock" firmware is not load into the OEM disk, or vice versa, then you need to disable the verification mechanism inside the disk. Or correct the loader so that it passes the "friend or foe" test.
On SATA, it was possible to do without editing the code.
On SAS in both cases it is necessary to make changes to the code.
But I do not exclude that there is a simpler mechanism.
If the firmware signed, you 99.999% do nothing.
November 14th, 2019, 4:59
@fzabkar I've dumped the ROM multiple times, no differences in the dumps (I wanted to be sure as well) also I lucked out and the flash is 3.3v, I am able to read and write to it just fine.
Yeah I can remove the DELL header but it won't flash since it doesn't pass verification. Just one thing baffles me: how come I cannot flash the ROM with the DELL header removed, aka, a proper lod, but the disk accepted the ROM WITH the Dell header, therefor bricking itself? I read out the SPI and the DELL header was included! For all intents and purposes, it shouldn't have worked. I read out the ROM of a second drive (the one I attached) and surprise! no DELL header so I definitely know it's not intended.
@E123 Ahhh that's good to know then! Do you have any ideas about how I could correct the loader? As I said to @fzabkar for some reason the disk let me write garbage data to it before , albeit using the fwupload command of my LSI HBA, so not actually using seachest or anything. I guess it's similar to ATA flashing? I have tried this again with the normal loader but this time it would not allow me to do it for some reason.
Would it not be possible to use the ROM dump I have, combine it with modules from the LOD and then write it back to the disk with the SPI flasher? I don't think the firmware is signed to be honest, I think the F3 programs you linkes shouldn't have worked if that was the case.
EDIT: I guess one way to get rid of the verification mechanism could be to edit the official DELL GE0F loader, then flash that one, since the disk will accept it, and then flash the Seagate one?
November 14th, 2019, 5:19
The code you need, that checks the downloaded content, is on the platters. Get it, disassemble and determine what your disk expects. And... for this it is not at all necessary to be able to read the service area. You can search for a loader with the same version of the f/w as on your disk.
I already gave you a fishing rod. Believe me, you have everything in order not to remain hungry.
November 14th, 2019, 12:41
I've been looking around for a few hours now but I can't figure out how to dump the ROM contents from the platters. Wouldn't I need a TTL connection to the processor on the disk's motherboard for that? Unfortunately, that's not an option as I don't have an external SAS to USB adapter, only the drive bays in my server. I've also been looking into reading the service area, also none the wiser.
I suspect I need Direct I/O access to read that code from the disk?
I've extracted all the sections from my rom dump and the loader though, so that's something. I was actually doing it manually, until I saw your tools you made
November 14th, 2019, 15:08
I should probably clarify that my main goal (besides just pure experimentation) is to enable APM and other disabled features on the drive. If there's another easier way, do let me know
Would that be possible over TTL for example?
I've also just tried to flash one of the drives with SeaTools on Windows and it says in green text "Firmware download: Pass!" but the firmware didn't actually update
November 14th, 2019, 23:48
Each of the overlays has a header which contains the build date/time stamp. Perhaps that is what the SAS firmware is baulking at?
November 15th, 2019, 5:36
I can definitely recognise the build string in the stock firmware (E007, same as FW version) whereas the dell one uses a different one (E80F, different from fw version)
Thank you and I'll check it out more!
The E8 is consistant between both DELL fw's I have, the second byte, 0F and 09 respectively seem to line up with the numbers in the FW revision 0F is from the GE0F firmware and 09 from the GE09
November 15th, 2019, 16:33
These are the headers for overlay 05h.
Offset(h) 00 02 04 06 08 0A 0C 0E
000001C0 7178 3707 0000 0000 0064 0001 0500 4A00 qx7.............
000001D0 0000 0200 1621 0200 2209 07E0 0922 1620
000001E0 0000 0000 4000 0200 0000 0000 0000 0000
000001F0 0000 0000 0000 0000 0000 0000 0000 65CE
Offset(h) 00 02 04 06 08 0A 0C 0E
001239C0 7178 3707 0000 0000 0064 0001 0500 4A00 qx7.............
001239D0 0000 0200 1621 0200 0501 0FE8 0105 1620
001239E0 0000 0000 4000 0200 0000 0000 0000 0000
001239F0 0000 0000 0000 0000 0000 0000 0000 82EB
Offset(h) 00 02 04 06 08 0A 0C 0E
00123AC0 7178 3707 0000 0000 0064 0001 0500 4A00 qx7.............
00123AD0 0000 0200 1621 0200 0304 158A 0403 1720
00123AE0 0000 0000 4000 0200 0000 0000 0000 0000
00123AF0 0000 0000 0000 0000 0000 0000 0000 7A48
This is what I have managed to find out about the header structure:
Type ovlyhdr Field = 1
sig As ULong
unknown1 As ULong
unknown2 As UByte
family As UByte
unknown3 As UShort
fileid As UShort
filtyp As UShort
filsiz As ULong
unknown4 As ULong
relhi As UShort ' not sure about order
rello As UShort ' not sure about order
bcdmonth As UByte
bcdday As UByte
bcdyear As UShort
unknown5 As ULong
filsizplushdr As ULong
firmver1( 1 To 4 ) As UByte ' usually 0x00000000
unknown6 As ULong
firmver2( 1 To 4 ) As UByte ' usually 0x00000000
unknown7 As ULong
unknown8 As ULong
unknown9 As UShort
hdrcksm As UShort
Powered by phpBB © phpBB Group.