I am looking for someone to collaborate with to disassemble both the Seagate Yeti boot ROM and the firmware for a hard drive.

I own a PC3000 and am very familiar with the conventional methods of data recovery. The PC3000 enables recovery by repairing whatever is wrong with the drive.

My ultimate goal is to modify parts of the code to read from damaged drives, even if the drive will not boot, by bypassing parts of the initialization that are preventing the drive to boot. Envision reading the servo marks and the raw data, saving it for later decoding.

I am looking for someone who understands ARM processors and/or IDA

Anyone interested ?

Does anyone have an IDA project for the Seagate YETI bootloader ?

Just looking to save some time before I start from scratch.....

I think will not help you .
Or you mean the bootloader, which is somewhat different thing?
And... There are ways to do this without using IDA.

I am actually talking about both the bootloader and the ROM, but I want to start with the Yeti bootloader.

If anyone has attempted this, I am interested in what you have.
It will save me a lot of time and effort to not "re-invent the wheel"

Also if there are recommendations instead of IDA, I am all ears.....

I would think that you would need to disassemble the BOOTFW, CFW, and SFW segments of the external ROM. ISTM that the Yeti code would only deal with basic functions and would not know how to access peripheral devices (eg motor controller, read/write channel).

FWIW, @Severance (at HDD Oracle) has developed a nice GUI based tool to read and write memory via the Tiny Console in a WD drive. I suspect that PC3K can do this, though.

_________________
A backup a day keeps DR away.

you probably know about Binwalk, https://github.com/ReFirmLabs/binwalk
with some example here http://gearsofresistance.com/2018/09/demystifying-firmware-debugging/

IDA probably has the most support but you would need probably more than a standard install.

my only interest in the Yeti code is to determine what get loaded where and what is the entry point in the loaded code

I don't think it would initialize much beyond memory, serial i/o, and flash

I'm not an expert, but I can give a few advices:
1. Seagate firmwares disassemble OK enough in IDA. Selected small parts of code can even be debugged under IDA+QEMU - I attached a screenshot - with well-known limitations of such debugging, e.g. memory is not filled during execution...
2. dont' try to disassemble any files without knowing their loading addresses - it makes no sense, because there are direct addresses in code and you will lost any references to them
3. you can get loading addresses for parts of ROM e.g. from E123s' soft - F3 ROM explorer
4. the best method is not to take loading addresses from firmware itself, but dump RAM and then check, when given file/part of code loads. Then you are sure, that your code in disassembler is like in live drive.
5. you cant' really understand such low-level code without original symbols. Try to find such symbols in firmware updates... it's really difficult, symbols are intentionally removed from any distributed soft. I know only a few exceptions to this - old disks of Quantum or Samsung. Symbols dont' need to be for the given version - any are priceless.
6. chips: ROM initializes chips, which have no public available datasheets.... Try to find older/similar ones. For Lucent/Agere/LSI - forget it. For proprietary Seagates' ASIC - forget it. You can decrypt pins with logic analyzer of proper speed and cost , with probes of proper raster (0,025'' or smaller) and cost.... and proper very specialistic KNOWLEDGE.
The simple UART base address visible on attached disassembly was manually found by me, of course. Real meanings and names of [800D3000] address or function "ROM_puts_to_UART" dont' exist in firmware retail code
7. So.... I dont' think so

The L7250 SMOOTH motor controller has a public datasheet.

_________________
A backup a day keeps DR away.

I think a info is available for something very similar.....this is from October 2010

https://www.digchip.com/datasheets/3264 ... ndard.html



The second paragraph says.....

The TrueStore SC9500 IC is delivered with reference firmware


How do I locate this firmware ?
Anyone have a copy ?

@skeeter, sorry, but I'm sure you cant' get firmware or pinout of LSI chips.
Internals of such chips are too valuable to let them release to public.
The only method to uncover internals of them is reversing, but this is REAL hard - and often IMPOSSIBLE - work.
An example: uncovering Lucent (->Agere->LSI-> Avago->Broadcom) read-channel pins:
http://www.hddoracle.com/viewtopic.php? ... int#p19042
This was Quantum firmware research, made by Spildit, fzabkar and me.
For uncover this > 20-years-old chip, I had:
1. datasheets for all other chips on the board,
2. full disassembly with original Quantum symbols of firmware on the board.
3. easy access to 0,05'' pitch pins with standard probes
4. transfer on the board easy covered with 200MHz logic analyzer
And you can see the results: most important pins, as NRZ0-1 = bare output from disk, CLK, ReadGate, ServoGate.... - were revealed, but the rest remained secret.

@skeeter, you need something like this:

http://samples.technology-writer.com/ASIC.pdf

_________________
A backup a day keeps DR away.

where do I get a copy of the whole document ?

Seagate owns the IP, so you would need to ask them. In reality it would be highly unlikely that you would find the complete document anywhere.

_________________
A backup a day keeps DR away.

not the Seagate one, but the entire Quantum document.
The one toy referenced was only the table of contents.....

Quantum was acquired by Maxtor, and Maxtor was then acquired by Seagate ...

Presumably the document exists in abridged form because its author is using it to showcase his technical writing ability without infringing on Quantum's/Seagate's copyright.

http://samples.technology-writer.com/

_________________
A backup a day keeps DR away.

Try to contact the author (R.C. Ayeras):

http://technology-writer.com/cover.html

_________________
A backup a day keeps DR away.

I have made progress on the YETI rom.
I have an ongoing IDA project.
Wow, what a way to code.....using a static base, add offsets to print different strings.
If you think you can add to the project, let me know

I have most of the JTAG pins figured out also. I can see all 3 TAPs.
Problem is that the CPU wont halt, and I can't find SRST.
The mictor pads pin 9 is not connected to anything.



any ideas on how to locate SRST ????

Looking the thread, I can say that althounght the ASIC document does not say too much, is possible to use it to help reverse eng. the firmware of Quantum disks.

The document have several memory position for configuration registers in the summary

I'll try to use them to map the registers inside the firmware!

By the way, do someone has an annotaded reverse firmware for Quantum?

A very novice question from my side to HaQue et all;

if Binwalk returns a very high entropy so either the FW/blob is compressed or encrypted.

How would one approach such scenarios where there are no magic numbers localized?

--