Pull firmware from drive

[Chubblez]

I've done some digging, and I understand the risks involved.

I have two Hitachi A7K2000 drives, with different firmware. I need to pull the firmware from one (older version) and push it to another. PN and revision for both drives is the same.

I can adjust the grown defect list later on the target drive, or reset it via low level format/scan, so I'm not worried about that.

The reason for this: I have a piece of gear that requires a specific firmware on the drive. It takes two drives. One is dead (magic smoke dead) and the other concerns me. I'm trying to retire it, but I'm not at that point yet. I'd go back to the vendor, but they don't exist anymore.

And todays lesson - If a vendor codes their software to a specific drive firmware, proceed to percussively educate them with said drive....

[labtech]

1)Do you have firmware tool specifically for hard drives and more specifically for Hitachi drives?

Also, there are a couple of aspects of firmware to be concerned when talking about drives in general, and more so, in Hitachi the flexibility of "pushing" non-native firmware onto some drive is not quite easy.

2) So, what firmware element do you exactly refer to?
3) How did you obtain the source firmware?

[Chubblez]

And as a follow up - If the firmware truly does live on the platters itself, instead of the flash IC on the PCB, is it possible that this will transfer in a sector by sector clone? I'd expect this area of the drive to be hidden from any tool or OS.

[labtech]

And as a follow up - If the firmware truly does live on the platters itself, instead of the flash IC on the PCB, is it possible that this will transfer in a sector by sector clone? I'd expect this area of the drive to be hidden from any tool or OS.

Separate elements of firmware, which have different purposes, but dependent on each other, are on both PCB and platters. Hence the question in the first post.

Firmware area residing on the platter is not clonable like user data is. As you mentioned, "it is hidden".

Last edited by labtech on July 28th, 2014, 8:40, edited 1 time in total.

[Chubblez]

1)Do you have firmware tool specifically for hard drives and more specifically for Hitachi drives?

Also, there are a couple of aspects of firmware to be concerned when talking about drives in general, and more so, in Hitachi the flexibility of "pushing" non-native firmware onto some drive is not quite easy.

2) So, what firmware element do you exactly refer to?
3) How did you obtain the source firmware?

1. Not at this time. Hoping for suggestions.

2. From what I can tell, the device these are going into is looking for a specific firmware revision. An A7K2000 with newer firmware is set as off-line with a "Value out of range" error.

3. I haven't. Hoping to pull it from my one remaining working drive.

This is an interesting position to be in, and in ~20 years of IT, it's a new one for me.

[Chubblez]

And as a follow up - If the firmware truly does live on the platters itself, instead of the flash IC on the PCB, is it possible that this will transfer in a sector by sector clone? I'd expect this area of the drive to be hidden from any tool or OS.

Separate elements of firmware, which have different purposes, but dependent on each other, are on both PCB and platters. Hence the question in the first post.

Firmware area residing on the platter is not clonable like user data is. As you mentioned, "it is hidden".

Answered. You posted as I was writing the follow up.

[labtech]

A drive is very much like a system board [on the computer] as "it is a computer" in itself, except with many more restrictions and complexities.

Best suggestion I can provide is that, if feasible, buy two new drives of the same firmware the machine accepts. Much less headache.
Other than that, if still want to make it happen with these drives, seek a very experienced specialist, more specifically a drive refurbishing specialist, in particular who knows Hitachi very well.

They will likely need the unit the drives will go in as well, to confirm everything works as expected.

[Chubblez]

A drive is very much like a system board [on the computer] as "it is a computer" in itself, except with many more restrictions and complexities.

Best suggestion I can provide is that, if feasible, buy two new drives of the same firmware the machine accepts. Much less headache.
Other than that, if still want to make it happen with these drives, seek a very experienced specialist, more specifically a drive refurbishing specialist, in particular who knows Hitachi very well.

They will likely need the unit the drives will go in as well, to confirm everything works as expected.

Unfortunately, picking up a pair of new drives isn't really an option. I have nearly 20 drives here, still sealed. Would it be worth investing in a copy of PC3000? I'm not sure what the license costs are, but at first glance, if they're under $2500USD, it might be worth it for us to go that route.

The unit that takes these is can not leave the facility. Period. That is inflexible, and beyond my pay grade and management level.

The existing dead drive is not recoverable. It's a long story, but it's been evaluated by a few different data recovery houses. So that just leaves me with the one, and the nagging requirement to pull firmware from it.

Though, I had a thought. Is there a way to dump the firmware info? Grab exact revision, date, generic feature list, etc, and diff them against my new drives? Can hdparm do this? How about pulling from SMART data?

[labtech]

There is need of advanced tools like PC3000 or similar to even toy with the idea. I personally do not have vast experience modifying the firmware in the matter intended, which is very like refurbishing. I concentrate on "repairing" the firmware as oppose to modifying it. Either way, I anticipate a lot of hurdles in toying with this because of Hitachi firmware architecture.

Another possible cheaper and more convenient timely option is to have someone come to you onsite. It will be more than $2500 most likely.
Not in the sense of undermining you and your ability in any way, but the reason I am suggesting this is because the learning curve on the firmware by yourself is quite steep. You will definitely need somebody experienced to have a shot at this as the tools themselves will more than likely not do the trick, There is no "press button and firmware gets modified" as expected type of option.

Best wishes

[Madoka]

Greetings !
If the idea is to bypass a copy protection or a requirment of a device to use a drive with a specific model, serial and firmware version you can pick a simple/cheaper drive and tools to work with like wdr and wd drives and "spoof" the model/firmware version on the drive, that way your wd drive will look like an hitachi with a specific fw version when the device attempt to id the drive, bypassing the need of a specific model/brand/fw.

[HaQue]

Greetings !
If the idea is to bypass a copy protection or a requirment of a device to use a drive with a specific model, serial and firmware version you can pick a simple/cheaper drive and tools to work with like wdr and wd drives and "spoof" the model/firmware version on the drive, that way your wd drive will look like an hitachi with a specific fw version when the device attempt to id the drive, bypassing the need of a specific model/brand/fw.

Unless the device goes deeper and itself uses specific VSC's to store whatever it is storing.. I doubt it, but a thought. I bet I am not the only person interested in what this device is.

What about getting identical drives s/h and swapping/copying the ROM?

Hitachi A7K2000 shouldn't be too hard to find from either ebay or a donor drive shop.

Myself, I would be REing the software and patching it. but sounds like that might not be option.

How did you ascertain it was checking the firmware?

[fzabkar]

Is there a way to dump the firmware info? Grab exact revision, date, generic feature list, etc, and diff them against my new drives? Can hdparm do this? How about pulling from SMART data?

The drive's feature set is reported by the ATA Identify Device command.

You could capture these data using the Text Copy function in CrystalDiskInfo:
http://crystalmark.info/software/Crysta ... dex-e.html

First go to Edit -> Copy Option and select Identify Device. Then go to Edit -> Copy. This will copy the disk information to the clipboard. Then open up NotePad or whichever word processor ships with your version of Windows, and choose Edit -> Paste (or Ctrl-V) to input the clipboard data, or simply paste it into your next post.

CrystalDiskInfo also reports the SMART information.

The Identify Device data are explained in the following standards document:

Working Draft AT Attachment 8 - ATA/ATAPI Command Set (ATA8-ACS):
http://www.t13.org/documents/UploadedDo ... A8-ACS.pdf

If your prefer Linux, then smartctl (from smartmontools) can do all the above:

http://www.smartmontools.org/

BTW, HDDHackr is a free tool that can modify the firmware in certain WD models so that it reports the same model number, serial number, and firmware version as another drive.

See http://www.users.on.net/~fzabkar/HDD/Hd ... lysis.html

[labtech]

For me, I would use a different approach. I would first go about understanding what exactly the unit itself expects/requires, which is still unknown. Don't even know what the unit is... Then determine feasibility on the Hitachi drives.

[fzabkar]

I have two Hitachi A7K2000 drives, with different firmware. I need to pull the firmware from one (older version) and push it to another. PN and revision for both drives is the same.

Did you mean to write that the model numbers of both drives are identical?

I can adjust the grown defect list later on the target drive, or reset it via low level format/scan ...

No, you cannot, and why would you want to do it anyway?

[Chubblez]

Greetings !
If the idea is to bypass a copy protection or a requirment of a device to use a drive with a specific model, serial and firmware version you can pick a simple/cheaper drive and tools to work with like wdr and wd drives and "spoof" the model/firmware version on the drive, that way your wd drive will look like an hitachi with a specific fw version when the device attempt to id the drive, bypassing the need of a specific model/brand/fw.

Unless the device goes deeper and itself uses specific VSC's to store whatever it is storing.. I doubt it, but a thought. I bet I am not the only person interested in what this device is.

What about getting identical drives s/h and swapping/copying the ROM?

Hitachi A7K2000 shouldn't be too hard to find from either ebay or a donor drive shop.

Myself, I would be REing the software and patching it. but sounds like that might not be option.

How did you ascertain it was checking the firmware?

The device the drives are going into is a data recorder for some calibration equipment. I'm not allowed to touch it. It was written in-house, and I have some documentation, but not much. Original developer is not reachable.

One of the notes I have in my limited documentation:

"System is hard coded to check for specific drive firmware. We do this to ensure uniform operation across the platform. Need to change this to call a lookup table that can be altered 3rd party, so as not to disrupt code signing and binary checksuming. - Low priority"

Both drives are HUA722020ALA330. Original is dated Dec 2009, replacement is Apr 2010.

What about getting identical drives s/h and swapping/copying the ROM?

This is exactly what I'm trying to do. Copy the Dec 2009 ROM to the Apr 2010 drive.

[fzabkar]

This is exactly what I'm trying to do. Copy the Dec 2009 ROM to the Apr 2010 drive.

Is this your PCB?
http://www.harddrivesforsale.com/media/ ... 26062a.jpg

If so, then the "ROM" is the 8-pin "25F" device at the bottom left corner of the MCU. It appears to incorporate both the "adaptives" and the firmware, IIUC. Therefore a straight ROM swap for the purpose of firmware transfer would not be feasible. You would need to maintain the destination drive's own adaptives. That would require some patching and a recalculation of the checksum. In any case, how could you be certain that the ROM code was compatible with the SA code?

Could we see a photo of the damaged patient PCB? If the damage is restricted to the PCB, then you could repair the patient drive by transferring the ROM to a compatible donor PCB.

[HaQue]

please don't take this as a flame, we all want to fix whatever lands on our desk. but It seems the device in question is arguably important or the location it resides has some level of importance/secrecy/whatever. It also sounds like you may not have a complete understanding of all factors to get to your goal, or are missing part of the expertise to do so. it may be a better idea, and better for your own grey hair and time devoted that this is stealing time from other jobs.. to tell your upper chain that they either need to solve the problem in a different way or get someone in that can. I don't know how much more we can help without knowing more. there may be a lot easier way to fix the issue such as fzabkars.

Unfortunately, picking up a pair of new drives isn't really an option. I have nearly 20 drives here, still sealed. Would it be worth investing in a copy of PC3000? I'm not sure what the license costs are, but at first glance, if they're under $2500USD, it might be worth it for us to go that route.

paying up to $500 for a pair of drives isn't an option but quite a few $1,000 is? I don't understand that.
I saw a post from July, 2013 "pricing out the pc-3000 with or without the data extractor. it is $4300 for the pc-3000 udma plus $2500 for the extractor."

The unit that takes these is can not leave the facility. Period. That is inflexible, and beyond my pay grade and management level.

The existing dead drive is not recoverable. It's a long story...

Well the story might be long, but might be a help to share it.

but it's been evaluated by a few different data recovery houses. So that just leaves me with the one, and the nagging requirement to pull firmware from it.

So why hasn't any of these data recovery houses suggested exactly what you have, or helped you to do it? maybe a few more DR Shops need to be contacted, or some other specialised service.
I don't believe the ONLY other option is what you suggest. IMHO patching the software, if it is abandoned, is an option too. if the drive is 1 or 2TB the device cant be THAT old, are you sure the vendor is totally gone? Not been sucked up by another company that could give support? Are there any hacking forums related to this device? many GPS, DVR, CarPC etc have dedicated forums that really get into the nitty's of a product.

[labtech]

"System is hard coded to check for specific drive firmware. We do this to ensure uniform operation across the platform. Need to change this to call a lookup table that can be altered 3rd party, so as not to disrupt code signing and binary checksuming. - Low priority"

The key is in the "specific drive firmware". Whatever the parameters are that defines that system's process, then that is what you need to be after.

The ROM itself on this model series Hitachi is pretty generic in terms of drives with the same version, therefore not unique. But they are more or less unique when it comes to the rest of the firmware and how they tie in with from one element to another.

Overall, I would think that the original developer should have highly considered the possibility of drive failure, therefore must have designed the device with some degree of flexibility in terms of drive replacement. But again, we sometimes do come across some major design issues despite how minuscule/unimportant they seem at first. It happens.

Another question of mine would be: why is there a two drive config? Is it a mirror (RAID 1) based system?

Another solution that could possibly work better and also increase fault flexibility while maintaining security is to alter the code to allow for easier modification. I believe a fairly good programmer, someone who specializes/works in the industry, should be able to re-write the code to meet your needs. And it is likely not to be thousands. Plus you get a better more suitable fault tolerant configuration, which hopefully will prevent being in this predicament in the future. The drives will fail, that's a guarantee.

[fzabkar]

What I don't understand is, if the software was written in-house, then surely there would be source code somewhere within the company. If so, then it should be a very easy job to modify and recompile the code, as appears to have been originally intended by the developer.

In fact I was once given a very similar task, also on a datalogging PC in a production environment. As in your case, the problem was that the software was written in-house, and the programmer had made use of code which was hardware dependent. Specifically, he had implemented a timing delay which consisted of a fixed number of iterations of a FOR-NEXT loop. When they moved from their own 286 PC to a much faster 486 PC, which I supplied, the program broke and I was lumped with the job of debugging it (to prove that I wasn't responsible for the problem).