Restoration HELP - WDC VeniceR WD40EDAZ-11SLVB0

[Amarbir[CDR-Labs]]

Hello,
Drive came in external casing ,Customer Said the drive slowed down slowly and died .Head 00 was virtually not reading SA .I took a composite backup of modules ,ROM i have in unlocked state using MRT Ver 9.3 .In ID and ABA Structure Tests We can see modules that are bad like 0c, 32 ,33 and 36 etc . I do have a similiar hdd so i can share the backup of that hdds modules also .Can someone share the list of Imp modules for this SMR hard drive .According to me we should do the following

1 : Module 000C : We Can Borrow this from a donor

2 : Module 0032 :Relo List i can borrow a module from donor and might be empty it and restore checksome , But My Observation is That The Content is same till 0x0200 and then repeats itself i think , might be we can borrow a module clean it and restore entries from defective module

3 : Module 0033 : Is P list ,Entries Till 0x0200 are all MCK MCK i have seen this in many such hdds in few modules ,Might be there is valid data from 0x200 till end and might be there is some data lost if some entries are missing pre 0x0200

4 : Module 0036 : T List Module Enteries Are All ZERO Till 0c0200 , Might be same as i said in P List 0033 module .

PS : Module 0183 is added and also is Module 190 ,Modues 190 says 37XX GB Data ,ROM is Also Added

Google Drive Links :

Modules Backup : https://drive.google.com/file/d/1rTKUxN ... sp=sharing
Module 190 Backup : https://drive.google.com/file/d/1ZzN9NL ... sp=sharing
ROM Backup : https://drive.google.com/file/d/1PsqWmE ... sp=sharing

[Amarbir[CDR-Labs]]

Hello All,
Adding a Working DONOR Resources To the Thread

Google Drive Link - > https://drive.google.com/file/d/1vagOih ... sp=sharing

[fzabkar]

Module 0x32 can be repaired by stripping the first 0x200 bytes and adding a zero-filled sector to the end of the module. Then the checksum is correct.

To me, this is very weird corruption. The first sector of modules 0x33 and 0x0C have been overwritten, so this suggests that the drive may have been to another shop.

I would dump all the tracks from all the regions and try to reconstruct the SA from that. Then examine the reconstructed SA and compare it against the directory in module 01.

[Amarbir[CDR-Labs]]

Module 0x32 can be repaired by stripping the first 0x200 bytes and adding a zero-filled sector to the end of the module. Then the checksum is correct.

To me, this is very weird corruption. The first sector of modules 0x33 and 0x0C have been overwritten, so this suggests that the drive may have been to another shop.

I would dump all the tracks from all the regions and try to reconstruct the SA from that. Then examine the reconstructed SA and compare it against the directory in module 01.

Hello ,
Shall i upload Tracks From SA Regions Head 00 and Head 01 ,What would you find in Tracks ?

[fzabkar]

I can see two SA regions in the ROM, with copies of both regions on heads 0 and 1. Would the second region have the same data as the first region, or am I misunderstanding the concept of regions?

[Amarbir[CDR-Labs]]

I can see two SA regions in the ROM, with copies of both regions on heads 0 and 1. Would the second region have the same data as the first region, or am I misunderstanding the concept of regions?

Well,
For me a region is a section on one head which has firmware etc , only in a single head hdd there are two sections of regions per head ,In multihead hdd there is one region per head and that means sa copy in head 00 or region 1 and sa copy in head 01 region 2 are same imho

[fzabkar]

I think you and I are talking at cross-purposes. I believe that there are two regions on each of two heads, and each region is probably a copy of the other. In other words, there are 4 identical (?) regions, ie 2 copies of the SA on each head.

This was produced by my ROM parsing tool:

Code:

Active directory flag = 0x04

Identifying SA regions ...

Reg#    Reg size     Reg loc
----  ----------  ----------
0x00  0x000E8828  0x00000000 <-- first region in SA
0x01  0x000E8828  0x000EBFC8

Verifying ROYL modules ...

ID          Size (bytes)         Address    Checksum
dir   hdr        dir       hdr
----  ----   --------  --------   --------   --------
0001  N/A    00004000  N/A        00000000             N/A  <-- mod 0x01 at address 0 in SA
000A  OK     0000004E  00000200   0007C000   00000000  OK
000B  OK     0000013D  00000200   0007F826   00000000  OK
020B  OK     0000013D  00000200   0007D826   00000000  OK
0181  OK     00000C00  OK         000FE400   00000000  OK
0030  OK     00000400  OK         000FE000   00000000  OK
0047  OK     00000A8C  00000C00   0007C556   00000000  OK
000D  OK     00000108  00000200   0007C04E   00000000  OK
004F  OK     00000400  OK         0007C156   00000000  OK
01A2  OK     0000007E  00000200   0007CFE2   00000000  OK
01B6  OK     0000069E  00000800   0007D060   00000000  OK
01B0  OK     00000128  00000200   0007D6FE   00000000  OK

dir  -  Module ID/Size as reported in directory module (0x20B or 0x0B)
hdr  -  Module ID/Size as reported in module's header
N/A  -  Not Applicable
BAD  -  Module has invalid checksum. This may be due to non-existent module.

These are your SA modules sorted in RLBA order:

Code:

Number of SA modules = 0x246

        ID    size      attribs   RLBA1     RLBA2     Gap
--------------------------------------------------------------
14  02  0001  00000020  42901803  00000000  00000000 
14  02  0050  00000003  40903803  00000020  00000020 
14  02  0051  00000004  40903803  00000023  00000023
...
14  02  000C  0000000C  43883803  00000144  00000144 
14  02  0034  00000030  40C83803  00000150  00000150 
14  02  0032  0000003C  43C83803  00000180  00000180 
14  02  0036  000000D6  41883803  000001BC  000001BC 
...
14  02  032E  0000011A  40801803  0000262C  0000262C 
14  02  0033  00000960  40881803  00002746  00002746 
14  02  0031  00000960  41881803  000030A6  000030A6 
14  02  0183  00000DAC  41881803  00003A06  00003A06 
...
14  02  2529  00000396  00001803  000E6491  000E6491 
14  02  0121  00002001  40041803  000E6827  000E6827 

Note that the last SA module (0x121) spans RLBA E6827 - E8827. This corresponds to the size of each region, namely 0xE8828.

I'm suggesting that you dump the second SA region, 0xEBFC8 - 0x1D47EF and extract copies of your damaged modules from that.

I enclose the latest version of my parsing tool for module 0x01, plus the results of my ROM parsing tool.

Attachments

wdmod01a.7z

(21.16 KiB) Downloaded 145 times

ROManalysis.7z

(1.91 KiB) Downloaded 157 times

Mod_01_parse_results.7z

(6.09 KiB) Downloaded 161 times

[fzabkar]

I think someone has shifted the SA region by 1 sector in order to block access to the SA. Then the drive has somehow updated modules 0x21 and 0x32, with the result that both these modules are now shifted by one sector. That is why the first sector of these modules is duplicated.

For example, you can see that module 0x36 immediately follows module 0x32 in the SA. Because 0x32 has been shifted by one sector, the last sector of module 0x32, which was filled with zeros, has now overwritten the first sector of module 0x36.

[Amarbir[CDR-Labs]]

I think someone has shifted the SA region by 1 sector in order to block access to the SA. Then the drive has somehow updated modules 0x21 and 0x32, with the result that both these modules are now shifted by one sector. That is why the first sector of these modules is duplicated.

For example, you can see that module 0x36 immediately follows module 0x32 in the SA. Because 0x32 has been shifted by one sector, the last sector of module 0x32, which was filled with zeros, has now overwritten the first sector of module 0x36.

Yes ,
Seems The right and logical thing that might have happened ,So if we block access and shift SA by one as acelab tools do its imp we prevent sa write attempts ,Also might be we can forgo this technique to block sa access and rely on disable 411 disable 02 etc in smr hard drives ,Once i am in shop today i will try and dump what you told me and if i cannot understand i will dump virtually everything including tracks and post here

[fzabkar]

If you would like to experiment with an expendable donor drive, I could edit its ROM so that your drive will attempt to start from the second SA region. If this works, then you could dump the modules in this second region and compare them against those in the first region.

[Amarbir[CDR-Labs]]

If you would like to experiment with an expendable donor drive, I could edit its ROM so that your drive will attempt to start from the second SA region. If this works, then you could dump the modules in this second region and compare them against those in the first region.

Hi Frank ,
In MRT i could not find a method to dump the second section of both the regions on head 00 and head 01 .I have not tried this on Acelab PC 3000 UDMA that i have .Please edit the ROM and post here so that i can try and boot from Region 2 from head 00 and head 01 if it indeed exists in the HDD .I will disable 411 so that i can access drive F/W properly

PS : Anyone Has idea how to dump this so called 2nd section of the region frank is talking about

[fzabkar]

I am disinclined to experiment with live data. Module 0x190 in region 1 may not be the same as in region 0, so who knows what damage this could cause.

Instead I propose to edit module 0x01 and load it into RAM.

This is the RLBA address of module 0x33 in region 0 (excerpt from module 0x01):

Code:

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

000004B0                                14 02 33 00 60 09 00 00 03 18
000004C4  88 40 46 27 00 00 46 27 00 00
                ^^^^^^^^^^^ ===========

I propose to edit this address to point to the same module in region 1. I am assuming that the layout is the same in both regions, but this may not be the case.

Region 1 begins at RLBA 0x000EBFC8. Therefore I expect that mod 0x33 in region 1 will be at 0xEE70E (= 0xEBFC8 + 0x2746).

Code:

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

000004B0                                14 02 33 00 60 09 00 00 03 18
000004C4  88 40 0E E7 0E 00 0E E7 0E 00

I would upload the modified directory module (0x01) into the drive's RAM and then dump module 0x33. If the result is a good module, then we can try more adventurous methods.

Attachments

01_modified_33.7z

(3.46 KiB) Downloaded 134 times