Hi. This is my first post here, I guess. I apologize if I am in the wrong place. But I need help from people who have firmware experience.
I don't work with data recovery, but I have experience in electronics and people call me as a last resource.
A client needs to extract data from a dead HSGT SAS drive. He sent it to specialists, they said the board was dead, and they couldn't do anything. He even brought another identical working drive for them to tear apart if needed, because the data inside that one is precious to him. But didn't work.
So, he handed me 3 identical drives. For starters, I found a dead flash memory. I used another driver as a firmware donor, and, as I have no experience hacking HDD firmware, this is where I bumped:



This looks like a CRC or Checksum table. From 0x5010 to 0x5220, the first 4 bytes at left indicate the address inside the firmware, followed by a 12-byte string, or hash. I assume it's some kind of checksum calculation, after all, I found different information in three different firmware but the same 12-byte string:



As you can see, even with two different values, the line 0x5060 that points to this part of the code at 0x80B000 is the same in the 2 firmware.

At the address 0x5000, the string starts first, then, the address. I am guessing, this is the checksum of the checksum table.

That said, let's understand my doubt:



Those are the serial numbers from the HDD (PEG9HN5X20151700) and the serial numbers from the head device (0051408D7), which I know by reading the HDD stamps. But, when I edit, the HDD won't exactly work. It gets recognized but doesn't respond correctly to any SCSI command. The same happens when I change the firmware of working drives. sg_scan finds the drive, but I can't do anything. sdparm -al returns all parameters as it was, but I can't modify them.

I tried to replace the checksum of the line 0x50A0, to one that matches the working HDD, but, In this case, the HDD wasn't recognized at all.

I tried to run arm microcode from the firmware packs I downloaded from DELL and HP, but they don't have this table, or anything like a checksum calculator inside. I assume this is calculated at the factory.

My gold question is: Does anyone know how to calculate those CRCs? Or I'm gonna have to swap the disks between the drives?

Can you upload the ROMs?

Here is my ROM parsing tool:

https://www.hddoracle.com/viewtopic.php?p=23795#p23795

The tool still has some wrinkles, so don't automatically blame the ROM if something doesn't look right.

_________________
A backup a day keeps DR away.

Hello mate! I'm gonna read your post and try to use the tool! Thanks a lot!
And I post the ROM dumps tomorrow first thing, they are at my lab.

now this is what gonna end this story really bad.
For a 'last resort'.

I know the algo for those cs, but obviously, i didn't read it in the news last thursday, so this is not gonna be subject of disclosure on a forum.
If your client wants (really) the data, there probably is a solution, but it will cost some pennys for sure.
- dead flash memory: what does it mean?

you would not get anywhere just by calculating checksums.

sorry for the raw style, it is a bit late here...

_________________
Adatmentés - Data recovery

Ok, let's explain: Flash is the electronic component where firmware roms are recorded. In this case, the dead flash was a MX25U80, just like this: https://www.digikey.com/en/products/det ... 2G/6190487

As I said, I don't work with data recovery. But I did successfully, several times, plate swaps. And no, I don't like the idea.

I'm sure I will figure this out. With or without your help. I just asked here because, just in case, someone already walked through the path.

So, no need to be rude. If you don't want to help, feel free to not help. I just don't understand why forum people like to fight so much...

Some light reading ...

https://www.hddoracle.com/viewtopic.php?f=21&t=2549
https://www.hddoracle.com/viewtopic.php?f=59&t=3279

Please feel free to contribute.

_________________
A backup a day keeps DR away.

Very nice stuff, thanks!

Here, I managed to download from my PC at the lab the two ROM I read from the two living disks:

Thx for explaining what a flash memory is.



no fight here, of course. Feel free to kill drives in whatever way for no obvious reason.
What i tried is offering help in a gentle way, just before something irreversible happens.

_________________
Adatmentés - Data recovery

A parsing tool for HGST SAS/SATA firmware updates:

https://www.hddoracle.com/viewtopic.php?f=59&t=2990

_________________
A backup a day keeps DR away.

Hi, fzabkar. I learned a lot with your tool. And I also learned that, unlike car electronics, almost nobody in HDD electronics world uses soldering and eprom reading tools to work directly with the hardware. I only found a dozen firmware dumps read directly from flash memory. Luckily, one of them helped me.
FIY, the ROM files I sent you (awaiting approval) were directly read from the flash memory.

I'm going to test new approaches today, I keep you posted. Thanks.

My ROM parsing tool has several bugs. HGST changes the ROM structure slightly over time, so I need to keep patching my tool to account for the changes.

_________________
A backup a day keeps DR away.

My code has been updated. It still doesn't parse the HIN1 and HIN2 modules correctly (because I don't know how to account for all the variations).

https://www.hddoracle.com/download/file.php?id=10254

_________________
A backup a day keeps DR away.

I want to thank you, fzabkar, for your help!! After a couple of weeks, I did manage to figure out how to calculate the checksum of that specific line, and I brought the HD back to life. I rescued all the data of my client and I learned a little more about hard drives.

Can you be a little more specific?
:-?

_________________
A backup a day keeps DR away.

Sir can you be more specific? there are people with similar problems out here

our contribution will be very helpfull