Firmware extract

[Monjur]

Using this tool I am trying to extract firmware of HDD. I execute :

sudo hddsupertool -t /dev/sdb -f wd_royl_dump_mod_all

It dump 325 files and then terminates with the following errors:
Module ID = 0x0  Size in sectors = 0x30
Command failed!
sense_key=0xb asc=0x0 ascq=0x0
error=0x4 count=0x43 lba=0x37 device=0xa0 status=0x51 altstatus=0x0
command_status= 0x0
data_transferred= 0x200
No previous script to load.
Script reached PREVIOUSSCRIPT command at line 248, exiting normally...
Total program run time = 41 seconds
.......................................................

1. The dump file are binary data; how to assure these are the firmware? Should we use other third party tool to extract these binary?
2. Does the error prevent the extraction?
3. Is it possible to get a single firmware image for HDD instead of hundreds of modules?

[Monjur]

I have fixed the error.

But, how to transfer the hex data to meaningful assemble code.

Is there any tool that will convert the .bin to assemble?

[Scott Dwyer]

I am curious how you fixed the error? It looked like it was trying to read the module ID of 0 which is likely not a valid ID, so the drive reported an aborted command.

I do not know of a program to convert the data to assembly. I don't even know what processor the code runs on, plus some of the modules are tables and not assembly. I based my dump script on analysis that someone else did and made public in a forum (and also basically asked me if I could write this script). I do not myself reverse engineer drive firmware. While it is very likely to be an accurate dump of the modules, I can make no guarantee, especially with the error. Also, this script only dumps the available SA modules, it does not dump the ROM chip.

Scripts to dump ROM can be found here:
http://www.hddoracle.com/viewforum.php?f=171

[Monjur]

Hi Scott,

There was a minor bug; the program gets terminated with showing error as we were passing some 0 module which does not exists at all. There was a loop that count the total module; there we change the loop count to assure that module 0 should not be called falsely.

We found that among the extracted modules; a set of modules belong to firmware and a set is not. We can differentiate these set by running the same frimware version with the same device model. Effectively, a set will be uniform across all set of unique device. These should be malware. The changes set is responsible for page table and other addressing.

Scott, do you know any tool that can combile all the module into a single binary image of firmware? We need this for further analyse. We found some tool that can analyse firmware image. Lets try to make this image out of the modules extracted. 

Any idea? 

[Scott Dwyer]

Are there more modules after the one marked as 0? Can you send me a copy of mod01 so that I can see what I can do different in my script to improve it?

I do not know of a tool to put the modules together. It could possibly be done with HDDSUperTool. but I need to know exactly how the modules need to be assembled into the whole. I can think of three possibilities.

1. Simply put the modules together in the order they are numbered. This would be too easy and you could actually do it with simple linux commands.

2. Put the modules together in the order they are listed in mod01. This could easily be done when reading the modules.

3. Put the modules into the exact location as they exist in the SA according to mod01.  I think I might be able to do that, but would be a bit of work.

So which way do they need to be assembled?

[Monjur]

Hi Scott,

No, I think there are no module after the zero mark. I have attached mod01.bin. 

For point 2; how to know module listing on mod01? After getting hexdump; how to identify the modules into there?

A few more thing:

1. Is the "hddsupertool" is an open source? Can we get the code for this tool?

2. We can read data from service area. Can we write data into service area? I mean, can we change any module and write back into device? There should be a way to write payload into modules.

Thanks

Monjur

[Scott Dwyer]

Here is a link to information about mod01 in older WD drives:
Analysis of MOD 01 - Western Digital WD2500BB-55RDA0:
http://www.hddoracle.com/viewtopic.php?f=59&t=184

The same author provided me the following analysis of a newer drive which I used to create the script:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  52 4F 59 4C 01 00 30 00 01 00 18 00 46 5A 2C 36 ROYL..0.....FZ,6
00000010  30 30 30 32 30 30 30 30 01 02 03 04 05 00 06 00 00020000........
00000020  07 00 00 00 08 00 00 00 09 00 00 00 0A 00 00 00 ................
00000030  4B 01 12 02 01 00 18 00 03 18 20 00 00 00 00 00 K......... .....
00000040  00 00 00 00 12 02 35 00 0A 00 03 18 00 00 18 00 ......5.........

Offset 0x30 is the number of directory entries, namely 0x14B.

Offset 0x32 is the beginning of the directory table. Each record is 0x12 bytes long.

The format of each record appears to be ...

column  description
------------------------------------------
00      record length = 0x12 bytes
01      number of module copies in SA (= 2)
02-03   module ID
04-05   module size in sectors
0A-0D   location of first copy (LBA in SA)
0E-11   location of second copy (LBA in SA)

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11

00000000  12 02 01 00 18 00 03 18 20 00 00 00 00 00 00 00 00 00 ........ .........
00000012  12 02 35 00 0A 00 03 18 00 00 18 00 00 00 18 00 00 00 ..5...............
00000024  12 02 6D 00 01 00 03 18 00 00 97 0F 00 00 97 0F 00 00 ..m.......—...—...
00000036  12 02 10 01 18 00 03 18 10 00 EC FA 00 00 EC FA 00 00 ..........ìú..ìú..
00000048  12 02 02 01 01 00 03 18 10 00 EB FA 00 00 EB FA 00 00 ..........ëú..ëú..
0000005A  12 02 03 01 02 00 03 18 10 00 E9 FA 00 00 E9 FA 00 00 ..........éú..éú..
0000006C  12 02 04 01 01 00 03 18 10 00 E8 FA 00 00 E8 FA 00 00 ..........èú..èú..
0000007E  12 02 05 01 02 00 03 18 10 00 E6 FA 00 00 E6 FA 00 00 ..........æú..æú..
00000090  12 02 07 01 01 00 03 18 10 00 E5 FA 00 00 E5 FA 00 00 ..........åú..åú..
000000A2  12 02 06 01 01 00 03 18 10 00 E4 FA 00 00 E4 FA 00 00 ..........äú..äú..

[Scott Dwyer]

That same author has also replied to me with an analysis of your mod01 with sorted lists. I have attached that analysis which has the mods sorted by different orders. The last module has an id of 0 and does not seem normal. You also said the script produced 325 files, but there are 471 modules so there should be 471 files (minus the one with id of 0). With this information you should be able to figure out how to assemble the modules together in the order you need.

As for HDDSuiperTool is it not open source. I am writing a new cloning tool that I intend to sell and it shares too much code with it for me be willing to release it. But if you want to know how the commands are sent to a drive, look at the source for my ddru_diskutility (part of the ddrutiltiy suit that can be found at https://sourceforge.net/projects/ddrutility. And hdparm and sg3_utils are other good sources of that info.

As for writing data to the service area, look at the mod02 and mod32 patch scripts. They read those modules, modify them to apply a fix for a slow responding issue, and write them back. I am limited to what commands that I am aware of (I only know of commands made public), so if that is not enough then you will need to look into other tools.

Thanks,

Scott

[Monjur]

Yes I agree. In fact, we extracted 471 modules. But, how to identify the firmware modules ? Conceptually, does firmware be same for a same device model with same firmware version?

[Scott Dwyer]

I am not really familiar with the actual firmware itself. A good place to ask a question like that may be here:
http://www.hddoracle.com/

There is some good information in the R&D - Experiments section. And there are a couple members there that like to experiment and post results to help others understand. There are also other hard drive recovery forums you can try, but on some of them you must ask the right questions or you will not get good answers.

[Monjur]

Hi Scott,

Is it possible for you to write a script to combine a single image by following option (3): Put the modules into the exact location as they exist in the SA according to mod01?

a. What is the exact sequence of the data that we are extracting? Is it as same as module reading at read_module for file "wd_royl_dump_mod_all" ? If so, I will use python/shell script to combine all modules.

To be 100% sure that our script is extracting all data/code from service area, we purchased firmware with the same HD model and firmware version that we extract by using your tool. We found that the purchased one has exactly same modules that we extract by using hddsupertool. 

I am now analyzing how the firmware code differ, if any.

[Scott Dwyer]

Hi Monjur,

I will put writing that script on my list of things to do. But I have been busy with the new cloning tool which is my top priority, and also had a setback of my own when a 2TB drive failed on me (did get to beta test the new cloning tool on myself for the recovery). I hope you understand.

The wd_royl_dump_mod_all script reads the modules in the order of module number, which is not how they exist in the SA. And many of the modules can be smaller than the space allocated for each in SA, meaning there can be empty space between modules. Refer to a previous post here that has the info about the modules LBA location in the SA for your dump.

I am glad to hear that you were able to verify that my tool is extracting the firmware modules correctly. FYI the attachments for comparison did not have any data in them.

Scott