dead hts541010a9e680

[andrius]

Hi, maybe someone could have any grate thought about my problem. I now have 2 of these hdd non responsive.
I have had one HDD that stoped spining, after some tests i understand that PCB went bad. i got other identical HDD (exept serial number of course), and switched 25FU40 flash chip form old drive to new pcb, and put new pcb on old HDD, no spinning.
then i made same with new hdd, puting old PCB with new BIOS and new HDD worked just fine so not a PCB issue, i have put that same old PCB with NEW bios to old drive, and bingo, it begins to spin, but ofcourse no recognision and so on (of course different bios and hdd data).
Now i read both new and old hdd bios to compair, see some interesting differences, but have too little experiance in HDD to see what is bad. but to make situation worse, i try to rewrite NEW BIOS (read new hdd bios, write that same bios back ) Guess what? i have now two non spining non working hdd, but unable to understand why, as i have read and write same type flash memory many times before in other computer parts like routers and so on.
any help on my topic would be grate.
i add both BIOS readed, many thanks

Attachments

hdd.rar

Both hdd bios

(241.22 KiB) Downloaded 612 times

[Nick_CT]

Does the PCB have a ROM and NVRAM IC?

[andrius]

nop, only one flash MCU. 25V40 i presented dumps i have read. other MCU only, main procesor, as i understand without internal eeprom, motor driver and of course RAM chip.
as i see in stucture that flash holds NVRAM area and full FW. one thing i can not understand is exesive difference from two same FW read flash chips. NVRAM diference okey, but why FW area differs too? and what i have done wrong to stop new hdd working? bad read?

[andrius]

no one to help ?

[andrius]

Could anyone help recalculate cheksum for this hitachi file? many thanks.

Attachments

NVRAM_naujausias_mod_old.rar

(2.28 KiB) Downloaded 511 times

[fzabkar]

@andrius, are you using a chip programmer to read/write your flash memory in-circuit? If so, did you not save the original copies of each of your ROMs?

AIUI, there are some circumstances under which a donor ROM/NVRAM is partially reprogrammed when the donor PCB is installed on a patient drive, rendering the donor drive inoperable. I'm not a data recovery professional, but I suspect that is what may have happened.

I have written a tool for calculating Hitachi's XOR16 checksums.

XOR16 checksum calculator for Hitachi NVRAM:
http://www.hddoracle.com/viewtopic.php?f=22&t=80&p=4588

I have extracted the primary and secondary copies of the NVRAM from each of your ROMs at offsets 0x2000 - 0x2FFF and 0x3000 - 0x3FFF. FWIW, there is also an E2CH block at 0x7000 - 0x7FFF. All have zero checksums.

Code:

C:\>xorchksm.exe -16 NVR_OLD1.BIN
NVR_OLD1.BIN: XOR16 checksum = 0x0000

C:\>xorchksm.exe -16 NVR_OLD2.BIN
NVR_OLD2.BIN: XOR16 checksum = 0x0000

C:\>xorchksm.exe -16 E2CH_OLD.BIN
E2CH_OLD.BIN: XOR16 checksum = 0x0000

C:\>xorchksm.exe -16 NVR_NEW1.BIN
NVR_NEW1.BIN: XOR16 checksum = 0x0000

C:\>xorchksm.exe -16 NVR_NEW2.BIN
NVR_NEW2.BIN: XOR16 checksum = 0x0000

C:\>xorchksm.exe -16 E2CH_NEW.BIN
E2CH_NEW.BIN: XOR16 checksum = 0x0000

Your edited NVRAM has a checksum of 0x9032.

Code:

C:\>xorchksm.exe -16 NVRAM_naujausias_mod_old.bin
NVRAM_naujausias_mod_old.bin: XOR16 checksum = 0x9032

I'm not certain, but I believe that the checksum bytes may be located at 0xFFA - 0xFFB, in which case the new checksum bytes would be 0xFFFF XOR 0x9032 (little endian).

To identify the location of the checksum bytes, I would obtain a working donor and read the ROM before and after enabling Power Up In Standby (PUIS). The PUIS flag plus the checksum bytes should be the only differences in the before-and-after comparison.

[andrius]

many thanks for reply. for my knowledge there is definetely XOR type cheksum at the end, but it is not XOR16 of hole dump for sure. it seams to be XOR16, because all bytes XOR to 0, but same result would be if it is XOR8, or 3 cheksums of different area XOR16 algo. would you guid me, how to enable options on hdd like Power Up In Standby? i would do reasearch on cheksums many thanks

my skype: greenfox1

[fzabkar]

PUIS can be enabled and disabled using tools such as HDAT2 or hdparm.

XOR8 is a special case of XOR16. For example, is the XOR16 checksum is 0x1234, then the XOR8 checksum is 0x12 XOR 0x34. Essentially the algorithm computes a parity for each bit.

XOR16 checksum bit #0 = [(bit #0 of word #0) + (bit #0 of word #1) + ... + (bit #0 of word #n)] modulo 2

...

XOR16 checksum bit #15 = [(bit #15 of word #0) + (bit #15 of word #1) + ... + (bit #15 of word #n)] modulo 2

[andrius]

yes, i understand perfectly what the numeber near XOR mean (bytes count), in fact in most cases CRC cheksum may give same result as XOR function, nethermind that CRC ha ROL ROR functions, and anditional XOR parameters. i know cheksum calculation very well. i have been working or reverse engineering CAR ECU, dash, cheksums and so on. when i get my equipment to read write that flash memory, on 20-22 of March, i will try to investigate is that realy XOR16 and could the area be located for the cheksum, and if other cheksum are present i have scanned hole NVRAM area for XOR8, XOR16, XOR24, XOR32, XOR40 cheksums and posible cheksum residue. but none were found.
So maybe someone already know what area are those 3 cheksums in the end of file belong to?

[fzabkar]

Well, it appears that you have much more experience with checksums than I do. I'll be very interested in your findings. BTW, you might like to examine the resource dumps for those other Hitachi models where the "ROM" (SPI flash) and "NVRAM" (microwire EEPROM) are implemented as separate ICs.

http://files.hddguru.com/index.php

You may find the following tool useful:

http://fsumfe.sourceforge.net/

Fsum Frontend is a free and easy-to-use tool that allows to compute message digests, checksums and HMACs for files and text strings.

It supports 96 algorithms: alder8, adler16, adler32, ap hash, bdkr, cksum, cksum mpeg2, crc8, crc16, crc16 ccitt, crc16 ibm, crc16 x25, crc16 xmodem, crc16 zmodem, crc24, crc32, crc32 bzip2, crc32 jamcrc, crc32 mpeg2, crc64, crc64 ecma, djb hash, dha256, edonley/emule, elf32, fletcher8, fletcher16, fletcher32, fnv0-32, fnv0-64, fnv1-32, fnv1-64, fnv1a-32, fnv1a-64, fork256, ghash3, ghash5, gost, has160, haval (128, 160, 192, 224, 256 bits) (3, 4, 5 passes), jhash, js hash, md2, md4, md5, panama, pjw32, ripemd128, ripemd160, ripemd256, ripemd320, rs hash, sdbm, sha0, sha1, sha224, sha256, sha384, sha512, size64, snefru2 (128, 256 bits) (4, 8 passes), sum8, sum16, sum24, sum32, sum64, sumbsd, sumsyv, tiger128, tiger160, tiger192, tiger2, tiger tree, tiger tree 2, whirlpool0, whirlpool1, whirlpool2, xor8, xum32.

Best of luck.