how change seagate head map with hex editor?

[mmzhr]

hi
i dont have sediv or mrt or pc3000

i have many seagates with bad head

i want to edit head map and cut bad head
but i cannot locate head map in rom binary
if someone have skills help me

[fzabkar]

I am currently doing some work on F3 ROMs here:

Analysis of Seagate F3 ROM:
http://www.hddoracle.com/viewtopic.php?f=59&t=2173

I have analysed the RAP module and am now doing the same for the SAP.

If you upload your ROM samples, I can try to analyse them.

[mmzhr]

If it's ST-10 you can disable heads by terminal.

For F3 arch tools like SeDiv will "patch" ROM to "disable" head(s) for some drives. For others you can only cut the last head one at a time, meaning that if you have h0 h1 h2 h3 you can only cut h3, and the drive will have h0 h1 and h2, then you can cut h2 and so on. If on the same drive h1 is bad you can't cut it to have h0 h2 h3, you can only cut it and end up with h0 only.

thanks very much

i dont know how to thank you

this is my telegram id

https://t.me/mmzhr

[mmzhr]

I am currently doing some work on F3 ROMs here:

Analysis of Seagate F3 ROM:
http://www.hddoracle.com/viewtopic.php?f=59&t=2173

I have analysed the RAP module and am now doing the same for the SAP.

If you upload your ROM samples, I can try to analyse them.

thanks

model is st3500418as

head 1 is bad and iwant to cut head 1

Attachments

FILE_A_32A_0.7z

(433.03 KiB) Downloaded 591 times

[mmzhr]

Try this :

FILE_A_32A_0.rar

Procedure :

http://www.hddoracle.com/viewtopic.php? ... =20#p13389

thanks spildit

[mmzhr]

Try this :

FILE_A_32A_0.rar

Procedure :

http://www.hddoracle.com/viewtopic.php? ... =20#p13389

thanks spildit

finally i cut bad head and format sa and upload loader with lodedit
now i have working drive

[fzabkar]

ICBW, but this is how it looks to me:

CAP

Code:

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

00061656  36 45 FF FF FF FF FF FF FF FF FF FF 02 01 50 00 C5 00
                                              ^^
00061656  36 45 FF FF FF FF FF FF FF FF FF FF 01 01 50 00 C5 00
                                              ^^ number of heads

RAP

Code:

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

00061AFA  FF FF FF FF FF FF 01 0E 10 03 FF FF FF FF FF FF FF FF
                                     ^^
00061AFA  FF FF FF FF FF FF 01 0E 10 01 FF FF FF FF FF FF FF FF
                                     ^^ head map

SAP

Code:

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

0007E010  48 35 75 58 3B 37 01 00 01 00 01 00 A4 30 20 20
                                        ^^
0007E010  48 35 75 58 3B 37 01 00 01 00 00 00 A4 30 20 20
                                        ^^ max head

[mmzhr]

ICBW, but this is how it looks to me:

CAP

Code:

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

00061656  36 45 FF FF FF FF FF FF FF FF FF FF 02 01 50 00 C5 00
                                              ^^
00061656  36 45 FF FF FF FF FF FF FF FF FF FF 01 01 50 00 C5 00
                                              ^^ number of heads

RAP

Code:

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

00061AFA  FF FF FF FF FF FF 01 0E 10 03 FF FF FF FF FF FF FF FF
                                     ^^
00061AFA  FF FF FF FF FF FF 01 0E 10 01 FF FF FF FF FF FF FF FF
                                     ^^ head map

SAP

Code:

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

0007E010  48 35 75 58 3B 37 01 00 01 00 01 00 A4 30 20 20
                                        ^^
0007E010  48 35 75 58 3B 37 01 00 01 00 00 00 A4 30 20 20
                                        ^^ max head

what is wrong ?

[mmzhr]

ICBW, but this is how it looks to me:

CAP

Code:

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

00061656  36 45 FF FF FF FF FF FF FF FF FF FF 02 01 50 00 C5 00
                                              ^^
00061656  36 45 FF FF FF FF FF FF FF FF FF FF 01 01 50 00 C5 00
                                              ^^ number of heads

RAP

Code:

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

00061AFA  FF FF FF FF FF FF 01 0E 10 03 FF FF FF FF FF FF FF FF
                                     ^^
00061AFA  FF FF FF FF FF FF 01 0E 10 01 FF FF FF FF FF FF FF FF
                                     ^^ head map

SAP

Code:

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

0007E010  48 35 75 58 3B 37 01 00 01 00 01 00 A4 30 20 20
                                        ^^
0007E010  48 35 75 58 3B 37 01 00 01 00 00 00 A4 30 20 20
                                        ^^ max head

sorry i forget to send fixed rom

Attachments

Fixed ROM.7z

(433.03 KiB) Downloaded 553 times

[fzabkar]

I didn't mean to suggest that anything was wrong with the head cut. I was merely pointing out a few differences which I believed to be significant, especially since your initial question asked for the location of the head map. In fact there are several other important differences, such as model number, capacity, checksums.

[fzabkar]

ISTM that SeDiv makes extensive, unnecessary changes to the RAP module. That said, these changes appear to be benign and are probably ignored.

Here is one example (RAP Zone Format Budget Parms):

RAP_uncut.bin

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F       
                                                            head
                                                           log/phys
000002C0                          16 17 04 1D 05 0F 10 02    0/0
000002D0  09 0C 14 06 2E 18 FF FF 16 17 04 1D 05 0F 10 02    1/1
000002E0  09 0C 14 06 2E 18 FF FF 1B 1D 05 24 04 13 15 02    2/2
000002F0  0B 11 15 08 31 20 FF FF 1C 1E 05 28 04 14 16 02    3/3
00000300  0B 12 18 0A 33 23 FF FF 1C 1E 05 28 04 14 16 02    4/4
00000310  0B 12 18 0A 33 23 FF FF 1C 1E 05 29 04 14 16 02    5/5
00000320  0B 12 18 09 32 22 FF FF 1C 1E 05 2A 04 14 16 02    6/6
00000330  0B 12 19 09 32 22 FF FF 1B 1E 05 2A 04 13 16 02    7/7
00000340  0B 12 19 08 30 22 FF FF

RAP_cut_1.bin

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F       
                                                            head
                                                           log/phys
000002C0                          16 17 04 1D 05 0F 10 02    0/0
000002D0  09 0C 14 06 2E 18 FF FF 1B 1D 05 24 04 13 15 02    1/2 <-- head #1 cut
000002E0  0B 11 15 08 31 20 FF FF 1C 1E 05 28 04 14 16 02    2/3
000002F0  0B 12 18 0A 33 23 FF FF 1C 1E 05 28 04 14 16 02    3/4
00000300  0B 12 18 0A 33 23 FF FF 1C 1E 05 29 04 14 16 02    4/5
00000310  0B 12 18 09 32 22 FF FF 1C 1E 05 2A 04 14 16 02    5/6
00000320  0B 12 19 09 32 22 FF FF 1B 1E 05 2A 04 13 16 02    6/7
00000330  0B 12 19 08 30 22 FF FF 1B 1D 05 2A 04 13 15 02    7/?
00000340  0B 11 1A 09 32 21 FF FF

In the uncut ROM, there is a 1:1 correspondence between logical and pphysical heads (heads 2 - 7 are place holders). However, when head #1 is cut, the data for the remaining physical heads is shifted up by one position. ISTM that this is unnecessary since the cut has not changed the correspondence between logical head #0 and physical head #0, and head #0 is the only remaining physical head. If, OTOH, head #0 were cut, then the data for physical head #1 would need to be shifted up into the logical head #0 position.

[mmzhr]

ISTM that SeDiv makes extensive, unnecessary changes to the RAP module. That said, these changes appear to be benign and are probably ignored.

Here is one example (RAP Zone Format Budget Parms):

RAP_uncut.bin

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F       
                                                            head
                                                           log/phys
000002C0                          16 17 04 1D 05 0F 10 02    0/0
000002D0  09 0C 14 06 2E 18 FF FF 16 17 04 1D 05 0F 10 02    1/1
000002E0  09 0C 14 06 2E 18 FF FF 1B 1D 05 24 04 13 15 02    2/2
000002F0  0B 11 15 08 31 20 FF FF 1C 1E 05 28 04 14 16 02    3/3
00000300  0B 12 18 0A 33 23 FF FF 1C 1E 05 28 04 14 16 02    4/4
00000310  0B 12 18 0A 33 23 FF FF 1C 1E 05 29 04 14 16 02    5/5
00000320  0B 12 18 09 32 22 FF FF 1C 1E 05 2A 04 14 16 02    6/6
00000330  0B 12 19 09 32 22 FF FF 1B 1E 05 2A 04 13 16 02    7/7
00000340  0B 12 19 08 30 22 FF FF

RAP_cut_1.bin

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F       
                                                            head
                                                           log/phys
000002C0                          16 17 04 1D 05 0F 10 02    0/0
000002D0  09 0C 14 06 2E 18 FF FF 1B 1D 05 24 04 13 15 02    1/2 <-- head #1 cut
000002E0  0B 11 15 08 31 20 FF FF 1C 1E 05 28 04 14 16 02    2/3
000002F0  0B 12 18 0A 33 23 FF FF 1C 1E 05 28 04 14 16 02    3/4
00000300  0B 12 18 0A 33 23 FF FF 1C 1E 05 29 04 14 16 02    4/5
00000310  0B 12 18 09 32 22 FF FF 1C 1E 05 2A 04 14 16 02    5/6
00000320  0B 12 19 09 32 22 FF FF 1B 1E 05 2A 04 13 16 02    6/7
00000330  0B 12 19 08 30 22 FF FF 1B 1D 05 2A 04 13 15 02    7/?
00000340  0B 11 1A 09 32 21 FF FF

In the uncut ROM, there is a 1:1 correspondence between logical and pphysical heads (heads 2 - 7 are place holders). However, when head #1 is cut, the data for the remaining physical heads is shifted up by one position. ISTM that this is unnecessary since the cut has not changed the correspondence between logical head #0 and physical head #0, and head #0 is the only remaining physical head. If, OTOH, head #0 were cut, then the data for physical head #1 would need to be shifted up into the logical head #0 position.

of course i found capacity offset and changed

original capacity 500gb = 976773168

976773168 = 3A386030

new capacity 250gb = 488397168

488397168 = 1D1C5970

but i dont know how updatae checksum

[mmzhr]

ISTM that SeDiv makes extensive, unnecessary changes to the RAP module. That said, these changes appear to be benign and are probably ignored.

Here is one example (RAP Zone Format Budget Parms):

RAP_uncut.bin

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F       
                                                            head
                                                           log/phys
000002C0                          16 17 04 1D 05 0F 10 02    0/0
000002D0  09 0C 14 06 2E 18 FF FF 16 17 04 1D 05 0F 10 02    1/1
000002E0  09 0C 14 06 2E 18 FF FF 1B 1D 05 24 04 13 15 02    2/2
000002F0  0B 11 15 08 31 20 FF FF 1C 1E 05 28 04 14 16 02    3/3
00000300  0B 12 18 0A 33 23 FF FF 1C 1E 05 28 04 14 16 02    4/4
00000310  0B 12 18 0A 33 23 FF FF 1C 1E 05 29 04 14 16 02    5/5
00000320  0B 12 18 09 32 22 FF FF 1C 1E 05 2A 04 14 16 02    6/6
00000330  0B 12 19 09 32 22 FF FF 1B 1E 05 2A 04 13 16 02    7/7
00000340  0B 12 19 08 30 22 FF FF

RAP_cut_1.bin

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F       
                                                            head
                                                           log/phys
000002C0                          16 17 04 1D 05 0F 10 02    0/0
000002D0  09 0C 14 06 2E 18 FF FF 1B 1D 05 24 04 13 15 02    1/2 <-- head #1 cut
000002E0  0B 11 15 08 31 20 FF FF 1C 1E 05 28 04 14 16 02    2/3
000002F0  0B 12 18 0A 33 23 FF FF 1C 1E 05 28 04 14 16 02    3/4
00000300  0B 12 18 0A 33 23 FF FF 1C 1E 05 29 04 14 16 02    4/5
00000310  0B 12 18 09 32 22 FF FF 1C 1E 05 2A 04 14 16 02    5/6
00000320  0B 12 19 09 32 22 FF FF 1B 1E 05 2A 04 13 16 02    6/7
00000330  0B 12 19 08 30 22 FF FF 1B 1D 05 2A 04 13 15 02    7/?
00000340  0B 11 1A 09 32 21 FF FF

In the uncut ROM, there is a 1:1 correspondence between logical and pphysical heads (heads 2 - 7 are place holders). However, when head #1 is cut, the data for the remaining physical heads is shifted up by one position. ISTM that this is unnecessary since the cut has not changed the correspondence between logical head #0 and physical head #0, and head #0 is the only remaining physical head. If, OTOH, head #0 were cut, then the data for physical head #1 would need to be shifted up into the logical head #0 position.

of course i found capacity offset and changed

original capacity 500gb = 976773168

976773168 = 3A386030

new capacity 250gb = 488397168

488397168 = 1D1C5970

but i dont know how updatae checksum

this is capacity in rom file

[mr_spokk]

And people wonder why, and get upset by Seagate locking their terminal. and SA...

[mmzhr]

And people wonder why, and get upset by Seagate locking their terminal. and SA...

This is silly.

For years now people have been researching and posting VSC in open forums.

Fujitsu VSCs for example are very well known for many, many years now and Fujitsu didn't "lock" or encrypt access to SA, neither did Toshiba, Seagate, etc ....

WD scripts to read module 02 were posted many years ago, even scripts to read configuration of WDC based MCU were posted way before and espite WD did make some progress encrypting and protecting the drives (newer ones) there were no significant "change" to the way SA access works even on modern USB based drives.

What you state is just a silly argument to encourage people to stop sharing. The majority of drive makers will just not bother even if the commands to access SA are known. They might change from time to time one aspect or two related to security but with exception of Seagate they will not lock much.

Seagate have their own data recovery business and they do make very crappy drives that are getting worse by each new model they make.

I would be more concearned by the crappy platter quality of newer Seagate drives than with terminal locks. You will not need terminal access at all if the quality of Seagate drives keeps the same ... as you will end up with platters without magnetic substract anyway !!!

yes i dont know why seagate making crappy drives

wdc making quality drives with long mtbf

[mmzhr]

The ROM that I posted have already correct capacity for the CUT. Doesn't need to be changed.

thanks spildit

[mmzhr]

i share correct offset for cut bad head

CAP

Offset 61662 --> Head Number
Offset 61682 --> Head Number

RAP

Offset 61B03 --> Head Map

SAP

Offset 7E01A --> Max Heads

tkanks spildit and fzabkar

[mmzhr]

i share correct offset for cut bad head

CAP

Offset 61662 --> Head Number
Offset 61682 --> Head Number

RAP

Offset 61B03 --> Head Map

SAP

Offset 7E01A --> Max Heads

tkanks spildit and fzabkar

You still need correct checksums !

yes i compare original rom with modified rom that you send and find checksum offset but how calcualte checksum plese help me

[mmzhr]

yes i dont know why seagate making crappy drives

wdc making quality drives with long mtbf

Instead of wasting time in locking FW access and signing ROM, etc ... Seagate could use their resources for something more usefull like making reliable drives at the platter/head level ?!

Nowadays Seagate platters/substract are crap and firmware itself is junk as well.

Instead of locking FW and prevent end users from manipulating FW they could simplify FW in order to be functional ....

Drives like Toshiba, Hitachi, etc have very known VSC and they don't bother to lock SA access.

For example the command to CLEAR S.M.A.R.T. (that can be abused by people wanting to sell used drives as new) have been the same since IBM is S.M.A.R.T. capable and it's the same for ALL drives from IBM/Hitachi/HGST from arch M24 to ARM based.

The changes that Seagate do to firmware from drive to drive in order for commands that work with one drive cause damage to the others are ABSURD.

Seagate was fine on the ST-10 age. As soon as Seagate moved to F3 arch it was a nightmare.

Just DON'T BUY, DON'T USE AND STAY AWAY from Seagat F3 ARCH. ALL drives from 7200.11 and newer are just junk-

7200.11 have the popular BSY bug + LBA 0 problem - Seagate enters the data recovery market.

- Popular Fix is released.

- Drives from 7200.12 series now have entries on NRG-List and translator problems. You use commands that would "fix" 7200.11 drives on 7200-12 drives and you end up with partial access due to NRG-List.

- Then you have DM series with media cache problems, you have to disable re-location by editing sysfiles as well. Quality of platter is junk. Each time a new feauture is introduced on firmware it causes more harm than good.



I don't see any point on this.

For example Hitachi/HGST ARM and Toshiba have the same set of VSCs for AGES.

If you want to "unlock" ATA password on Toshiba you issue 2 commands. One is the super on the other regenerate the password sector / clear it / replace it with clear copy.

That LBA 48 command (for SATA) is almost the same as the "older" LBA 28 for IDE. Translator system is very simple and you don't have a huge amount of un-necessary defect lists like the non-resident, etc ... Yet those drives work and last ....

There are no measures to "prevent" users from access the FW on those if one knows the VSC.

Seagate on the other hand does make life harder to people wanting to access the FW and at the same time makes FW more buggy in order that it's really necessary to access it to fix the problems that they create ....

I'm telling all people to just forget about Seagate and buy other brands of HDDs.

segate making me angry
seagate and wdc main companies are in usa but why seagate making junk drives?

[labtech]

seagate and wdc main companies are in usa but why seagate making junk drives?

They may be headquartered in the USA, but most of the production is in Asia. Trust, they don't like to pay taxes in USA according to how it is expected, hence all the free trade agreements loopholes.

Like just about everything else in the world, not all Seagate product lines are junk. The low end cheap models are. Seagate makes them with cheap components, so people can afford them. Same with food, cars, clothes, shoes, appliances, etc. Typically there are three broad categories of products: ok (cheap usually), better, best.

Whoever does not want junk, then should buy something expensive, as, statistically, quality will be better.
Voting with the wallet is best.