LDR needed for st3320820A

[magnetepazzo]

LDR needed for st3320820A firmware 3.AAD
Thanks

[fzabkar]

Your tool should be able to generate a loader from these resources:
http://files.hddguru.com/download/PC-3000%20Support/Firmware/Seagate/Galaxy/ST3320820A_S-6D_3.AAD_.089_.0GB.rar

[michael chiklis]

MRT hasn't any function for generating LDR file from U5 drives fw resources.
Building it directly from hdd doesn't work (fake ldr).

Last edited by michael chiklis on November 14th, 2018, 15:53, edited 1 time in total.

[fzabkar]

I can try to make a loader by hand, if the OP would like to give it a go.

Can you show us a "fake loader"?

[michael chiklis]

I can try to make a loader by hand, if the OP would like to give it a go.

Can you show us a "fake loader"?

https://mega.nz/#F!O01DkBRI!MxP2J6ZNqXD ... Q!mk1gjI7I

Download ST3160215A-3.AAD-9RABW60Y.rar from that folder, you will find two LDRs, one from mrt and another from pc3000, u can compare them.
I've saved also tracks inside ST3160215A-3.AAD-9RABW60Y.rar

[michael chiklis]

Can't you simply load by SDLD the required "tracks" from a PC-3000 dump using MRT ?

Like for example using SeDiv you do SDLD to the drives the relevant portion of firmware code on tracks ...

Not possible, it's possible only to load LDR (only from pc3000 database because those one created with mrt won't work) and buffer.

[michael chiklis]

Sorry, i thought mega folder could be shared publicly, but now i see it's not like that.
Ok, i attached here the fw resource

ST3160215A-3.AAD-9RABW60Y.rar

(2.17 MiB) Downloaded 470 times

[fzabkar]

PC3K loaders are compressed whereas MRT's are not. It seems very odd that MRT can recognise and decompress a PC3K loader, yet cannot make use of its own.

[reco]

PC3K loaders are compressed whereas MRT's are not. It seems very odd that MRT can recognise and decompress a PC3K loader, yet cannot make use of its own.

As i know, loaders backup by PC3K/MRT in data base are compressed, but when back up as file, both are uncompressed. MRT can recognise and decompress PC3K loader, however not the other way around.

I do not know why it can't be used here regarding a u5 drive, I do not have any in hand at moment otherwise i can try and give you more information by testing both PC3K&MRT. Personally experience this can be used so far if it is a f3 drive.

[fzabkar]

IIUC, a "classic" loader (LDR) consists of an "Mrt" header followed by several firmware components, each of which is preceded by a header of the form ...

ID (byte) eg 10 (ROM), 11 (App code), 12 (Cert), etc
size
PCHS (cyl / head / sector)

This would suggest that the data recovery software interprets the LDR file, extracts the individual firmware components, and then uploads them to the drive, one by one.

OTOH, an F3 loader (LOD) appears to be uploaded to the drive as a complete LOD file, and it is the drive's firmware which then extracts each component rather than the tool.

Could it be that PC3K's classic LDR is decompressed and executed by the drive?? Or could it be that MRT expects all LDR files to be compressed, in which case its own uncompressed version would be detected as a fake?

[fzabkar]

F3 loaders are like "overlay" that you send to the drive, for example like Module 11 on WD. Overlay on F3 arch can be send by ATA download microcode standard command.

I was in fact wondering whether there exists a Seagate format for a classic loader which can be sent by the ATA Download Microcode command (92h). I did attempt to parse the payload in an official Seagate Galaxy firmware update. It appears to have a special format that is totally different to Mrt's loader. However, it is not clear whether Seagate's update utility strips the firmware components from the LDR file and uploads them separately via a VSC, or whether the drive itself handles everything.

[colanco]

MRT has virtually no support for seagate with ST 10 architecture.

It has the module, but few possibilities (similar to the samsung module).

[reco]

Could it be that PC3K's classic LDR is decompressed and executed by the drive??

I'm sure this is not the case.

F3 loaders are like "overlay" that you send to the drive, for example like Module 11 on WD. Overlay on F3 arch can be send by ATA download microcode standard command. Some tools do have loaders "encrypted" for them. SeDiv do use this method. This is to prevent files for SeDiv to be used with other tools. SeDiv decrypts the files and send them to the drive.

On ST-10 / classic the drive have no way to decompress the loader in PC3K format (or MRT). Also you are not sending by ATA, you are SDLD (Seagate Protocol) by terminal the "components" so the tool itself have to decode the loader file and send individual components to the drive. You can also chose what components to send. You might want for example send only ATA + APP and don't send CERT, etc ... The drive doesn't understand "loader" and you are not sending it by ATA. Those loaders do have to be "decoded" by the firmware tool and when you use the SDLD protocol by terminal you need to send the code directly.

This is of course a MRT bug. It can decode the PC3K loader but can't decode it's own loader.

That make sense.