Hello world

jmbach

New member
I am Jim from Tennessee. I am here to learn. More interested in firmware recovery than data recovery and it is more for my own interests than anything else. I have a small number of hard drives I have collected over the years that power on and is recognized by the computer but fail in various ways. So I thought I would learn on these. I am not concerned about the data on them and have no interest in replacing parts to get them to work. If I brick them that is okay but then the challenge would be to unbrick them. Most are WD but some are Seagate.

I have worked on firmware of various electronic devices when they become non functional because of firmware updates or component failure. Now I would like to see what I can do with these hard drives.
 

Jared

Administrator
Staff member
jmbach":umd4h4uo said:
[post]12848[/post] Now I would like to see what I can do with these hard drives.

Well, unless you have a good sum of cash you're willing to drop on some pro data recovery systems like PC-3000 you're not going to get far. Even just the vendor specific commands to read/write firmware are tightly guarded secrets for most drives.
 

jmbach

New member
Jared":2gmdeyw2 said:
jmbach":2gmdeyw2 said:
[post]12848[/post] Now I would like to see what I can do with these hard drives.

Well, unless you have a good sum of cash you're willing to drop on some pro data recovery systems like PC-3000 you're not going to get far. Even just the vendor specific commands to read/write firmware are tightly guarded secrets for most drives.
Thanks for the realistic response.

Well unless I am going into professional disk recovery, that is not going to happen. And I am not going into professional disk recovery. I understand my limitations and am okay with that. There are a few programs out there of reasonable cost that allow you to do some manipulation of the SA. I have eeprom programmers that I can write physically to chips if needed.

The equipment is expensive, hopefully the knowledge is not.
 

Jared

Administrator
Staff member
jmbach":174lqm1x said:
[post]12860[/post] I have eeprom programmers that I can write physically to chips if needed.

Very little of the code is stored in the PCB ROM. 99% of the firmware code is stored on the platters on most drives. And the ROM code is the culprit in only about 0.01% of cases.

I suspect you have the wrong idea about "firmware repairs" when it comes to data recovery. It's not that mass numbers of drives are going bad just because of firmware updates or random glitches in the code. When we talk about "firmware repair" in relation to data recovery it's usually always relating to patching up firmware to disable specific functions and stabilize a drive that's in a certain type of failed state. For example a WD or Seagate drive that has developed more bad sectors than it can re-map may get stuck in a busy state and require patching of the firmware code to disable certain things like background scanning, reallocation, media cache, etc. to stabilize it enough to extract the data.

If you think that just managing to read the firmware or ROM code from a drive is going to get you anywhere, think again. You can take a look at plenty of backed up firmware resources posted freely online. E.G.: files.hddguru.com

Knock yourself out looking at the code, I doubt you'll figure out much on your own unless you've got some powerful decompiling tools and experience in reverse engineering.
 

jmbach

New member
Jared":2we0cae0 said:
jmbach":2we0cae0 said:
[post]12860[/post] I have eeprom programmers that I can write physically to chips if needed.

Very little of the code is stored in the PCB ROM. 99% of the firmware code is stored on the platters on most drives. And the ROM code is the culprit in only about 0.01% of cases.

I suspect you have the wrong idea about "firmware repairs" when it comes to data recovery. It's not that mass numbers of drives are going bad just because of firmware updates or random glitches in the code. When we talk about "firmware repair" in relation to data recovery it's usually always relating to patching up firmware to disable specific functions and stabilize a drive that's in a certain type of failed state. For example a WD or Seagate drive that has developed more bad sectors than it can re-map may get stuck in a busy state and require patching of the firmware code to disable certain things like background scanning, reallocation, media cache, etc. to stabilize it enough to extract the data.

If you think that just managing to read the firmware or ROM code from a drive is going to get you anywhere, think again. You can take a look at plenty of backed up firmware resources posted freely online. E.G.: files.hddguru.com

Knock yourself out looking at the code, I doubt you'll figure out much on your own unless you've got some powerful decompiling tools and experience in reverse engineering.
I appreciate the time and information you have given me so far.

Reverse engineering and decompiling tools I have. I have surmised sofar that the firmware on the chip starts the boot process for the drive and it is finished after certain modules are loaded into the ram and execution is started. Certain modules look to be code to be executed and others hold data for configuration or data for logs. Since I am new into this, I may using or misusing the nomenclature.

My one drive I am working on fixing has one module with a bad CRC checksum. Also has issues reading track -1 on both headd 0 and 1.

Another drive I have, DCO and HPA has been disabled as well as the ability to toggle PUIS. I would like to modify those to be accessible.

Not sure if I will need high powered hardware for this or just a program to access and edit those areas.
 

Jared

Administrator
Staff member
jmbach":1iii46k0 said:
[post]12869[/post] My one drive I am working on fixing has one module with a bad CRC checksum.

Which module is it? Some modules, such as WD module 6F, don't actually have a checksum, so it'll always show a checksum error in most tools.

jmbach":1iii46k0 said:
[post]12869[/post] Also has issues reading track -1 on both headd 0 and 1

This is totally normal on most WD drives. Rarely is track -1 any good and there's never anything stored there. It's the farthest outer ring of the platters, so totally normal that it's a useless track.

jmbach":1iii46k0 said:
[post]12869[/post] Another drive I have, DCO and HPA has been disabled as well as the ability to toggle PUIS

What model drive is it? If it's a Seagate you may be able to turn those on just through terminal commands and a TTL adapter. Or, this program may be able to perform a device configuration reset on it: https://hdat2.com/
 

jmbach

New member
Jared":1bunj7nx said:
Which module is it? Some modules, such as WD module 6F, don't actually have a checksum, so it'll always show a checksum error in most tools.

Module ID 1050

Jared":1bunj7nx said:
This is totally normal on most WD drives. Rarely is track -1 any good and there's never anything stored there. It's the farthest outer ring of the platters, so totally normal that it's a useless track.

That is very good to know Thanks. I would not have expected that.

Jared":1bunj7nx said:
What model drive is it? If it's a Seagate you may be able to turn those on just through terminal commands and a TTL adapter. Or, this program may be able to perform a device configuration reset on it: https://hdat2.com/

It is a WD40NPZZ. Tried HDAT2 but it displays limited options to set as compared to other drives.
 

Jared

Administrator
Staff member
jmbach":3pnd9tlv said:
[post]12892[/post] It is a WD40NPZZ.

Yeah, that's a really new drive, so it's no surprise if it's not fully supported by most tools. You can try using HDAT2 which will send the generic ATA command to reset the device configuration. But, if it was a drive configured from the factory to disable those functions, such as for a DVR or other special purpose device, it probably won't help.
 

jmbach

New member
Jared":3s591nic said:
jmbach":3s591nic said:
[post]12892[/post] It is a WD40NPZZ.

Yeah, that's a really new drive, so it's no surprise if it's not fully supported by most tools. You can try using HDAT2 which will send the generic ATA command to reset the device configuration. But, if it was a drive configured from the factory to disable those functions, such as for a DVR or other special purpose device, it probably won't help.
HDAT2 was a no go on reset. Which is why I am contemplating modifying the appropriate module. Is there standard within or between manufacturers of what the modules functions as/represent?
 

Jared

Administrator
Staff member
jmbach":11a19pjr said:
[post]12897[/post] HDAT2 was a no go on reset. Which is why I am contemplating modifying the appropriate module. Is there standard within or between manufacturers of what the modules functions as/represent?

No, not even almost. From one manufacturer to the next it's entirely different architecture from the ground up. Generic ATA commands are universal since they all work as a collective (research the T13 group) to keep these consistent with makers of SATA controllers and motherboards. But, once you start talking about actual firmware it can be totally different architecture just from one model to the next even from the same company.
 
Top