HITACHI-ARM FIRMWARE RECOVERY.

[digisupport]

Loader creation is called "Off-line start resources" when you do HDD resources backup.

Attachments

2019-01-30.png (14.79 KiB) Viewed 14287 times

[drHDD]

Here :

The attachment HGSTHCC545050A7E380-GG2OAC90-TM85134THNWGUL.rar is no longer available

Do you think that you can try to make loader for me ?

I need file names in pc3k format.

I renamed your modules.

Attachments

loader.rar

(349.46 KiB) Downloaded 551 times

[michael chiklis]

I'm studying the LDR file, you might try to build LDR manually for other hitachi arm drives too...

I attached instructions on how to build ldr manually, but i'm not sure if is correct, in particular i'm not sure about first 200 (hex) bytes

MANUALLY CREATION OF LDR FILE FROM HITACHI ARM modules.rar

(633 Bytes) Downloaded 584 times

[michael chiklis]

I haven't test yet, i'm still doing some other checks, it seem that i was wrong about creating ldr portion regarding USAG.
After i will sure about it i will check with sediv.

[fzabkar]

I can't open the posted RAR instructions. However, I have had a look at the loader here:

http://www.hddoracle.com/viewtopic.php?t=2696&p=19960#p19960

[michael chiklis]

Yes, my USAGE ldr portion studing is wrong due to some bytes that in the ldr are different from USAGE module file!
It's tough for me to build USAGE portion correctly, i don't understand why pc3000 changes some bytes when creating the ldr, the only thing i understood is that inside ldr file created in pc3000 you can read since offset 200h which modules are included and in which order.

Inside USAGE module you can see all modules of service area

[fzabkar]

The differences between the USAG module in the loader and the corresponding USAG module in the SA are the result of adjusting the individual "offsets" of each component module when the preceding, unnecessary module (eg PSHT) is removed from the directory.

[michael chiklis]

It's not only that, some byte are also different.

[michael chiklis]

I show you which bytes are different, maybe you will find out how those bytes have to be modified.

[michael chiklis]

I noticed that all '04' bytes in USAGE file are swapped into '05' bytes in LDR and all '05' swapped into '04'.

[fzabkar]

Those bytes constitute a little-endian word, eg 0x052E -> 0x04C1.

[michael chiklis]

Thanks, i still don't understand what they mean this little-endian words and how to modify them correctly to build a proper ldr file.
I compared spildit USAGE file with my USAGE file (i posted in this thread from one of my hitachi fw resource), the are some little difference but all bytes are identical where ldr applys changes
Probably we don't need how to figure how pc3000 builds the loader, because probably difference between USAGE and LDR are always the same.
I would be able to confirm that, if drHDD can build a ldr from my fw resource and then i compare it with my USAGE.

[fzabkar]

The differences between the USAG module in the loader and the corresponding USAG module in the SA are the result of adjusting the individual "offsets" of each component module when the preceding, unnecessary module (eg PSHT) is removed from the directory.

AFAICT, the parameters which I have called "offsets" for each module in the USAG directory should be the PBA or sector number in the SA. This means that the locations of some of the modules in the loader's USAG directory do not match their actual locations in the SA. :?

[fzabkar]

ISTM that when PC3K creates a loader, it grabs all the necessary modules and compacts them all into a contiguous "virtual" SA which resides in RAM. The layout of this RAM based SA bears no relationship to the physical SA on the platters. AISI, this creates a potentially dangerous situation whereby one could overwrite a physical SA module with the wrong virtual SA module.

[fzabkar]

Try this :

MANUALLY CREATION OF LDR FILE FROM HITACHI ARM modules.rar

Code:

   IDNT (partially, from 0h to 400h)
   BA000h to BA400h

ISTM that the tool which was used for the SA dump incorrectly determined the size of the IDNT module as 3 sectors rather than 2 (as specified in the USAG directory). In fact the third sector of the IDNT dump is actually the first sector of the SRVP module. :?

Code:

Offset(h) 00   02   04   06   08   0A   0C   0E   10   12   14   16   18

000000EA                                          5352 5650 CC00 9404 00F0   SRVP
                                                                 ^^^^ sector 0x494
00000104  0300 0000 0400 0058 9200 BA02 0000 0000
...
00000138                                          4944 4E54 CC00 9204 00F0   IDNT
                                                                 ^^^^ sector 0x492
00000152  0300 0000 0200 00BC 9200 4802 0000 0000
                    ^^^^ size = 2 sectors, not 3

[fzabkar]

You are correct, on this model SeDiv does use a size of 3 sectors for IDNT. I can fix that very easy ... Just change the config file to 2 sectors for this model ...

I don't understand why SeDiv doesn't just consult the USAG directory rather than an INI file. :?

[BGman]

I don't understand why SeDiv doesn't just consult the USAG directory rather than an INI file.

Because USAG might be unreadable....

[guru]

Spot on answer BGman

I don't understand why SeDiv doesn't just consult the USAG directory rather than an INI file.

Because USAG might be unreadable....

[jubtc]

Spildit,
Please contact me
Whatsapp +79176782880
email Jubtcrussia@gmail.com

[iphdd]

HUS724040ALA640-MFAOA8G0

~~~~
I don't understand, who helped me create a LOD?

Attachments

HUS724040ALA640-MFAOA8G0-PN2331PAHN180T.rar

(569.7 KiB) Downloaded 402 times