All times are UTC - 5 hours [ DST ]




Post new topic Reply to topic  [ 62 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
 Post subject: Re: HITACHI-ARM FIRMWARE RECOVERY.
PostPosted: February 4th, 2019, 18:39 
Offline
User avatar

Joined: December 19th, 2006, 8:49
Posts: 10468
Location: Portugal
For HRT if you don't have edited ini files you can for example use Quantum utility and select this option :

Attachment:
3.jpg
3.jpg [ 23.88 KiB | Viewed 918 times ]


I did just test and it works GREAT as well and it's very fast (unlike SeDiv).

It uses standard ATA and it's the same standard ATA used to load Quantum loaders. If you do have "patched" ini files like me you will have those options on ALL HRT utilities including universal one.

If you do load either Temporary, Without Recall, etc it will NOT WORK and you will get this error in HRT :

Attachment:
4.jpg
4.jpg [ 14.29 KiB | Viewed 918 times ]


If you send with Permanent it works GREAT !!!

If you try to access SA - for example USAG with Super On + VSC to read USAG using correct PBA and if you did power on drive with for example damaged USAG and no loader you will get error and abort. If you load loader with HRT PERMANENT option you will get DRDY+DSC, then issue super ON + same command to read USAG and this time it does work GREATTTTT !!!

This is VERY COOOOLLLL !!!!

Now we need to find how to make loader for all other drives.

_________________
1Q9xrDTzTddUXeJAFRn37aqh1Yr6buDCdw - (Bitcoin Donations)
paypal.me/Spildit - (PayPal Donations)
The HDD Oracle - Platform for OPEN research on Data Recovery.


Top
 Profile  
 
 Post subject: Re: HITACHI-ARM FIRMWARE RECOVERY.
PostPosted: February 4th, 2019, 18:41 
Offline
User avatar

Joined: December 19th, 2006, 8:49
Posts: 10468
Location: Portugal
michael chiklis wrote:
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
Attachment:
MANUALLY CREATION OF LDR FILE FROM HITACHI ARM modules.rar


Did you test with your damaged drive ? You can use SeDiv Hitachi !!! It's way more slower than HRT to load the loader but i tested it and it does work as well.

_________________
1Q9xrDTzTddUXeJAFRn37aqh1Yr6buDCdw - (Bitcoin Donations)
paypal.me/Spildit - (PayPal Donations)
The HDD Oracle - Platform for OPEN research on Data Recovery.


Top
 Profile  
 
 Post subject: Re: HITACHI-ARM FIRMWARE RECOVERY.
PostPosted: February 4th, 2019, 19:07 
Offline

Joined: December 5th, 2011, 5:38
Posts: 1196
Location: Italy
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. :)


Top
 Profile  
 
 Post subject: Re: HITACHI-ARM FIRMWARE RECOVERY.
PostPosted: February 4th, 2019, 19:24 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 11106
Location: Australia
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

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: HITACHI-ARM FIRMWARE RECOVERY.
PostPosted: February 4th, 2019, 19:45 
Offline

Joined: December 5th, 2011, 5:38
Posts: 1196
Location: Italy
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.
Attachment:
ldr usage portion.jpg
ldr usage portion.jpg [ 690.93 KiB | Viewed 907 times ]


Inside USAGE module you can see all modules of service area
Attachment:
usage module.jpg
usage module.jpg [ 661.18 KiB | Viewed 907 times ]


Top
 Profile  
 
 Post subject: Re: HITACHI-ARM FIRMWARE RECOVERY.
PostPosted: February 4th, 2019, 19:51 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 11106
Location: Australia
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.

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: HITACHI-ARM FIRMWARE RECOVERY.
PostPosted: February 4th, 2019, 19:53 
Offline

Joined: December 5th, 2011, 5:38
Posts: 1196
Location: Italy
It's not only that, some byte are also different.


Top
 Profile  
 
 Post subject: Re: HITACHI-ARM FIRMWARE RECOVERY.
PostPosted: February 4th, 2019, 20:03 
Offline

Joined: December 5th, 2011, 5:38
Posts: 1196
Location: Italy
I show you which bytes are different, maybe you will find out how those bytes have to be modified.
Attachment:
difference ldr vs usage.jpg
difference ldr vs usage.jpg [ 687.03 KiB | Viewed 902 times ]


Top
 Profile  
 
 Post subject: Re: HITACHI-ARM FIRMWARE RECOVERY.
PostPosted: February 4th, 2019, 20:08 
Offline

Joined: December 5th, 2011, 5:38
Posts: 1196
Location: Italy
I noticed that all '04' bytes in USAGE file are swapped into '05' bytes in LDR and all '05' swapped into '04'.


Top
 Profile  
 
 Post subject: Re: HITACHI-ARM FIRMWARE RECOVERY.
PostPosted: February 4th, 2019, 20:24 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 11106
Location: Australia
Those bytes constitute a little-endian word, eg 0x052E -> 0x04C1.

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: HITACHI-ARM FIRMWARE RECOVERY.
PostPosted: February 4th, 2019, 20:39 
Offline

Joined: December 5th, 2011, 5:38
Posts: 1196
Location: Italy
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.


Top
 Profile  
 
 Post subject: Re: HITACHI-ARM FIRMWARE RECOVERY.
PostPosted: February 5th, 2019, 4:56 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 11106
Location: Australia
fzabkar wrote:
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. :?

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: HITACHI-ARM FIRMWARE RECOVERY.
PostPosted: February 5th, 2019, 5:28 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 11106
Location: Australia
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.

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: HITACHI-ARM FIRMWARE RECOVERY.
PostPosted: February 5th, 2019, 16:10 
Offline
User avatar

Joined: December 19th, 2006, 8:49
Posts: 10468
Location: Portugal
fzabkar wrote:
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.


When you use a firmware tool or Vendor Specific Commands to READ/WRITE the SA of a IBM based drive (ARM and older M24 ARCH) you do issue a LBA 48 command with the PBAs that you do need to read.

This is NOT like WD drives that you fetch the module by ID. This is more like the old VSCs for WDC MCU based drives that you need to specify on the VSC exactly what place on platter you are going to read/write.

If you have incorrect USAG on RAM it still doesn't matter for the VSC !!! It might be a problem if for example the drive itself do use wrong location for it's modules like tries to write S.M.A.R.T. and the place for the module is no longer correct as on RAM you do have incorrect directory but for the VSC and firmware tools to read and write modules it doesn't matter as you are reading PBAs directly instead of reading/writing by an ID that the drive itself will translate to a module location ....

_________________
1Q9xrDTzTddUXeJAFRn37aqh1Yr6buDCdw - (Bitcoin Donations)
paypal.me/Spildit - (PayPal Donations)
The HDD Oracle - Platform for OPEN research on Data Recovery.


Top
 Profile  
 
 Post subject: Re: HITACHI-ARM FIRMWARE RECOVERY.
PostPosted: February 5th, 2019, 16:12 
Offline
User avatar

Joined: December 19th, 2006, 8:49
Posts: 10468
Location: Portugal
fzabkar wrote:
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


Try this :

Attachment:

_________________
1Q9xrDTzTddUXeJAFRn37aqh1Yr6buDCdw - (Bitcoin Donations)
paypal.me/Spildit - (PayPal Donations)
The HDD Oracle - Platform for OPEN research on Data Recovery.


Top
 Profile  
 
 Post subject: Re: HITACHI-ARM FIRMWARE RECOVERY.
PostPosted: February 5th, 2019, 21:00 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 11106
Location: Australia
Spildit wrote:
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

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: HITACHI-ARM FIRMWARE RECOVERY.
PostPosted: February 6th, 2019, 16:01 
Offline
User avatar

Joined: December 19th, 2006, 8:49
Posts: 10468
Location: Portugal
Maybe SeDiv did mess it but but the loader still works ...

This is most likely because drive doesn't care for USAG to read/write firmware as long as you use the correct PBAs on the VSC ...

_________________
1Q9xrDTzTddUXeJAFRn37aqh1Yr6buDCdw - (Bitcoin Donations)
paypal.me/Spildit - (PayPal Donations)
The HDD Oracle - Platform for OPEN research on Data Recovery.


Top
 Profile  
 
 Post subject: Re: HITACHI-ARM FIRMWARE RECOVERY.
PostPosted: February 6th, 2019, 16:19 
Offline
User avatar

Joined: December 19th, 2006, 8:49
Posts: 10468
Location: Portugal
fzabkar wrote:
Spildit wrote:
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


SeDiv "bug" ... or more like little problem ...

It's not a big deal. If i write back that IDNT it will use correct PBA on platter and will replace first sector of SRVP.

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 ...

Attachment:
a.jpg
a.jpg [ 106.61 KiB | Viewed 694 times ]

_________________
1Q9xrDTzTddUXeJAFRn37aqh1Yr6buDCdw - (Bitcoin Donations)
paypal.me/Spildit - (PayPal Donations)
The HDD Oracle - Platform for OPEN research on Data Recovery.


Top
 Profile  
 
 Post subject: Re: HITACHI-ARM FIRMWARE RECOVERY.
PostPosted: February 6th, 2019, 18:41 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 11106
Location: Australia
Spildit wrote:
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. :?

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: HITACHI-ARM FIRMWARE RECOVERY.
PostPosted: February 7th, 2019, 2:35 
Offline

Joined: September 30th, 2005, 7:33
Posts: 619
fzabkar wrote:
I don't understand why SeDiv doesn't just consult the USAG directory rather than an INI file. :?

Because USAG might be unreadable....


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 62 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC - 5 hours [ DST ]


Who is online

Users browsing this forum: imtra84 and 29 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group