I haven't uploaded it. I wrote it in QBasic (hey, I'm an engineer, not a programmer), so I'm a little embarrassed about it. :-)

_________________
A backup a day keeps DR away.

Ok, I've only got one real question, how would you go about recalculating the checksums. Its kinda sad I can dump modules, I even can write them back, but I can't recalculate checksums to make them valid. Not asking for much just a basic idea of how to do a recalculation. I understand that the module checksum is supposed to add to 0 by utilizing 4 bytes of data. I even know which 4 bytes are the checksum inside the module I just am having trouble figuring out how to recalculate for changed information.

Even better, if you'd like to let me get ahold of your little calculation program that would be wonderful. Here's to hoping.

The Disdale checksum prog posted by fzabkar worked great for me.

I've tried it but I'm not sure how to utilize it. I run it and the original I get an output of 0x00000000 as expected and obviously on the modified file I get a different value but I can't figure out how to use that to recalculate the 4 byte checksum to return it to 0x00000000

gdude192003, which software are you using to write the firmware modules?

_________________
A backup a day keeps DR away.

I'm doing it manually with MHDD scripts and Vendor Specific Commands that took a little bit of time to figure out to get it to write. Only problem is if I don't fix the checksum then the drive just ignores them and grabs the modules from the backup set on second platter.

I'd be more than happy to share my notes on what I've sorted out so far, but I can't tell for certain that it is actually writing as I suspect because if I change the module and write it back without recalculating the checksum bytes the drive just corrects it with the backup module off the second platter and I end up with the original module again. Obviously this is going to happen since without correcting the checksum bytes the drive sees the modified module as corrupted and relies on the backup modules. Got to love redundancy and error detection. Actually its probably a good thing considering if the module really was corrupted then that would be extremely bad lol.

Anyway I'm just not fully up to speed on how to recalculate the 4 bytes the module uses for its checksum after making changes to it. So about all I can do is add 00 bytes to the end of it without changing the module length in the header which really doesn't help much.

If the contents of the modified module sum to X, then simply subtract X from the original checksum bytes.

_________________
A backup a day keeps DR away.

wow, I can't believe I didn't consider that. then again you wouldn't believe how easy it was to get the module write script to work was. I still have a hard time believing the simple change to each module's vsc key is all it needed.

Here is what I found:

08 00 02 00 32 00 00 00 00 00 00 00 00 00 00 00 wrtmod32.bin
08 00 02 00 34 00 00 00 00 00 00 00 00 00 00 00 wrtmod34.bin

I think the format is self explanatory, when you compare it with the equivalent read keys.

_________________
A backup a day keeps DR away.

yep and its way simpler than I thought western digital would make it. Interesting, are those for a ROYL drive, cause I believe those are the RBBL and G List modules

Yes, that's it.

AIUI, there's a 300-page WD VSC Protocol document that has leaked into the data recovery community. Those that have it are empowered by it, while the rest of us have to do it the hard way.

_________________
A backup a day keeps DR away.

eh the hard way seems to be more fun for me. I get to learn. Right now I'm playing with a dying Western Digital Scorpio Blue 320gb drive. Mostly seeing what I can do to it.

One thing I've been trying to figure out is how I can reset its S.M.A.R.T. table. I can write the modules that contain it in but it changes back every time regardless of the checksum though never exactly the same as the original. Might be a lost cause and its not important. One of those things where I want to do it just because I can.

I'm also curious on clearing the G list and the RBBL. Granted it'll just repopulate when the bad sectors are accessed again but another one of those I want to do it because I can.

I have some other interesting thoughts that I doubt are even possible but I'll save those for another time.

Try and find that "simple" key within a compressed ROM image..... Simple when you know how.....

_________________
All went well until I plugged the drive in.

well, I've managed writing SA modules as well as reading atleast to one platter lol. still haven't figured out how the ROYL drive handles its SMART table so that I can change the module storing it all I want and it get rewritten.

Are you sure in this? When it had happend?

_________________
Angel Data Recovery

WD ROYL module Chksum recalculating

public UInt32 Chksum32(byte[] Data)
{
UInt32 sum = System.BitConverter.ToUInt32(Data, 0xc);
UInt32 ChkSum = 0;
int lenght = Data.Length / 4;
try
{

for (int i = 0; i < lenght; i++)
{
ChkSum = ChkSum + System.BitConverter.ToUInt32(Data, i * 4);
}
}
catch
{
return 0;
}
finally
{
ChkSum = ChkSum - sum;
ChkSum = (~ChkSum) + 1;
}

return ChkSum;

}

Hi, fzabkar. This sum must be zero. The checksum bytes of WD modules are at offsets 0x0C - 0x0F.

I found the value of checksum bytes are not zero in the module. So I don't know why this sum must be zero. Can you share it with me? Thanks