Hello boys ,
Got this case from some person its a ST500DM002-1BD142 With Firmware KC48 Written ,When i connect the board to the hda i get the following message

Rst 0x10M
Servo Processor Is Reset.
RW: Disc Ctlr Initialization Completed.
ExecuteSpinRequest
(P) SATA Reset

And Reports CC49 Firmware Never Seen CC49 in Firmware of ST500DM002 ?

Proper ST500DM002 Reports In Terminal

Boot 0x10M
Spin Up[0x00000000][0x0000B67C][0x0000BA10]
Trans.

Rst 0x10M
MC Internal LPC Process
Spin Up
(P) SATA Reset


PS : What Has The Older DR Firm Done Updated Modded ROM ? ,I Have Added The Patient ROM to Post ,I Want To Take a KC48 ROM And Import Adaptives To That From This ROM And Revert Back Till Then any Suggestions

_________________
Regards
Amarbir S Dhillon , Chandigarh Data Recovery Labs [India]
Logical,Semi Physical And Physical Data Recovery
Website-> http://www.chandigarhdatarecovery.com

Hi,
Also With Patient PCB/ROM If i Try And Check Translator In Terminal i Get This Message

Overlay PartNum: 01101642
CFW PartNum: 03071103
Overlay CompileDate: 20130110
CFW CompileDate: 20110307

OverlayCompatibilityCheck failed

Unable to load Diag Cmd Processor Overlay

_________________
Regards
Amarbir S Dhillon , Chandigarh Data Recovery Labs [India]
Logical,Semi Physical And Physical Data Recovery
Website-> http://www.chandigarhdatarecovery.com

_________________
A backup a day keeps DR away.

Hi Frank ,
How Are You Today Exactly My Point ,But Label on HDD is ST500DM002 And Serial No is Also Same In PC3k Utility Checking

_________________
Regards
Amarbir S Dhillon , Chandigarh Data Recovery Labs [India]
Logical,Semi Physical And Physical Data Recovery
Website-> http://www.chandigarhdatarecovery.com

AIUI, the ST500DM002 is a 7200.12 model. If the serial number is a match, then I'm suggesting that the client may have applied the official 7200.12 CC49 firmware update.

Here is the configuration matrix:
http://www.users.on.net/~fzabkar/HDD/PH-CC49.TXT

IIUC, after the update is applied, the controller and servo firmware versions become PH0G2D.CCD4.JQ019Y.CC49.D289.

You could extract the PHCC492H.LOD file from the update and compare its ROM segments against your ROM dump (Moltke has written a ZOC script to parse the LOD file and identify its segments). You might also want to check the other LODs in the package, just in case the client selected the wrong file.

_________________
A backup a day keeps DR away.

The header of your ROM defines 7 segments, 3 of which are code. The other 4 segments are adaptives.



The SFW and SHELL components are a match for the Pharaoh CC49 update, but the CFW segment appears to have been replaced after the update. ???


Here are the ends of each CFW segment:

CC49_update_2H_section_6.bin


Rom-Original.bin


Note that the whole-space checksum is identical in both cases. However, the used space checksum is different. The old used space checksum (00009475) is still present, but now there is a new used space checksum (00001BC4) in the previous dword. This suggests that the CC49 CFW has been replaced with a different version, and this new version is smaller by 4 bytes. This in turn suggests that someone may have pasted the new CFW segment into the ROM with a hex editor (or could it be a PC3K CFW patch???).

BTW, I believe that "CPRS" signifies compressed code/data. Each compressed section begins and ends with a CPRS signature. The first dword following the signature is the size of the section in bytes.

0x5C884 + 0x41B4 = 0x60A38

I suspect that the CC4H version of the ROM can be restored by patching the CC4H CFW segment (CC49_update_2H_section_6.bin) into your ROM dump (see attachment).

_________________
A backup a day keeps DR away.

I checked each of the 4 overlays in the CC4H update. They all have a compilation date of 03/07/2011.


This would suggest that the client drive's SA overlay was compiled 2 years after the CC4H update. Also, this would suggest that the CFW module in the ROM is OK, even though it doesn't match the CC4H update???

BTW, you can extract each of the 4 SA overlays (03/07/2011) from the CC4H LOD file.

_________________
A backup a day keeps DR away.

The CAP module has a date stamp of 06/04/2013.

Z3TM5KB
W000073482NU5
06042013
ST500DM002-1BD142

What is the manufacture date on the label? Does this match the YYWW date codes on the PCB and its ICs?

_________________
A backup a day keeps DR away.

Frank,
But i do not see the update being for the st500dm002 only i see for other drives .Can you point me to the link were i can read moltke's zoo script ,never used his tools before .Though i am also going to read what more you have written and applied ,

_________________
Regards
Amarbir S Dhillon , Chandigarh Data Recovery Labs [India]
Logical,Semi Physical And Physical Data Recovery
Website-> http://www.chandigarhdatarecovery.com

Here are Moltke's scripts.

ZOC scripts - Seagate LOD files parsing :
http://www.hddoracle.com/viewtopic.php? ... 815&p=3162

I can think of two ways in which a user may have applied the 7200.12 CC49 update to the ST500DM002, even though this model is not actually targeted by the update. In any case, can you not check the integrity of the ROM with PC3K or MRT? If so, then I suspect you should see a warning message such as the following:


If you check my patched ROM, I expect that all its checksums will be valid.

_________________
A backup a day keeps DR away.

Could the DR company have used the 7200.12 CC49 ROM (with modified CFW) to gain access to the SA? If so, then wouldn't you need a matching CC49 loader? You could build such a loader from the 4 overlay files in my last attachment, otherwise I could build one for you.

_________________
A backup a day keeps DR away.

The CFW segments in your ROM and the CC49 ROM each have 4 compressed sections (CPRS). The last 3 CPRS sections are identical. However, the first CPRS section in your ROM is 4 bytes shorter than that of the CC49 ROM, and there are many differences in the body. Could it be that the first CPRS section was unpacked, hacked, and then repacked??? Is this how Ace implements the "Kahuna CFW 1" patch?

The PH-CC49 configuration file in the CC49 update indicates that the new firmware package version becomes "PH0G2D.CCD4.JQ019Y.CC49.D289". AIUI, the first 4 components correspond to the CPRS sections in the CFW, while last component, D289, corresponds to the single CPRS section in the SFW segment.

_________________
A backup a day keeps DR away.

Press Control A in terminal and tell me the Package number, i give you its resources,
You can simply upload the resources, to fix the Overlay Failed error,
Its safe for Data Recovery


Is this your hdd details = The PH-CC49 configuration file in the CC49 update indicates that the new firmware package version becomes "PH0G2D.CCD4.JQ019Y.CC49.D289". AIUI, the first 4 components correspond to the CPRS sections in the CFW, while last component, D289, corresponds to the single CPRS section in the SFW segment.


Regards
Waqas Ali

IIUC, the SA resources are probably the original KC48 overlays. It is the ROM which is not original. You need to supply the OP with a KC48 ROM which matches his overlay version. That said, this will only restore the drive to its original condition (hopefully). It doesn't explain why the ROM has been modified in such an unusual way.

_________________
A backup a day keeps DR away.

If the Rom is modified there is no problem.

Some times the rom is dead, so a person can transfer its RAP CAP SAP, head adaptives to donor rom, and write to hdd

After that you must need to load a compatiable overlay into the hdd (Below then 7200.14 series), after that you are able to excute some commands which need overlay .

Like Clear smart etc.

So there is no problem . if some one do this as i write above , then the package will be change to the donor ROM automatically, because its in ROM, not in RAP CAP SAP and head adaptives.

you can just tell me the P/N number, i will give you the Drives original resources. the TGT Code, and the Overlay.

If some one change then Press Ctrl + A send me log, i will give you only the overlay file compatible with that ROM.

The overlays which are compatible with the OP's CC49 ROM are probably those in my attachment.

_________________
A backup a day keeps DR away.

Yes, I am aware of that. So how do you explain the fact that the CFW segment in the donor ROM has two used-space checksum dwords? The second dword appears to be a remnant of Seagate's official Pharaoh CC49 update.

Please perform an integrity check of the OP's ROM (and my patched version) and hopefully you will see the error in the CFW whole-space checksum that I alluded to earlier. The OP doesn't appear to understand how to do this.

_________________
A backup a day keeps DR away.

Hi fzabkar

I( can't work like this,, because i not have much knowledge like you,

you can an engineer, i am only technician.

Check sum i can't understand.

i have factory files , and i use them for this type of errors.

Regards
Waqas Ali

I'm talking about ROM parsing as in the following threads:

viewtopic.php?f=11&p=248974
http://forum.acelaboratory.com/viewtopic.php?t=7736

_________________
A backup a day keeps DR away.