jmbach wrote:Source of the post Now I would like to see what I can do with these hard drives.
Thanks for the realistic response.Jared wrote:jmbach wrote:Source of the 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 wrote:Source of the post I have eeprom programmers that I can write physically to chips if needed.
I appreciate the time and information you have given me so far.Jared wrote:jmbach wrote:Source of the 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 wrote:Source of the post My one drive I am working on fixing has one module with a bad CRC checksum.
jmbach wrote:Source of the post Also has issues reading track -1 on both headd 0 and 1
jmbach wrote:Source of the post Another drive I have, DCO and HPA has been disabled as well as the ability to toggle PUIS
Jared wrote: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.
Jared wrote: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.
Jared wrote: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 wrote:Source of the post It is a WD40NPZZ.
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 wrote:jmbach wrote:Source of the 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 wrote:Source of the 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?
Users browsing this forum: No registered users and 0 guests