firmware translator

All posts tagged firmware translator


    Please note that I did not name the project. It is a play on our respective surnames.

For several months, my research partner Mr.De4d and I have been spelunking in the depths of the Seagate firmware, whose internals are legendarily undocumented.

We have been studying a form of hard drive failure which regularly occurs in the wild in the Seagate Moose and Pharoah drive families. A seemingly undamaged drive powers on, spins up, gets stuck in busy, and is never recognized by the connected operating system. Mr.De4d has fixed several of these manually in the wild by forcing a translator rebuild. So we strongly suspect a corrupted translator in the firmware to be at fault.

Our objective is to build a tool or at least a procedure to programmatically fix the translator and make that available. The first step is to make ourselves a controlled corrupted translator to build and test code against. That is proving to be harder than anticipated. Work is ongoing at the time of writing.

Along the way, we have found a number of interesting things about the lists used by the Seagate translator. I had thought to wait until after we had finished our entire project to publish anything. However, we have received feedback that the data recovery community would really like to see what we have found so far even if it is unfinished.

A Bit of Background on Lists used in Firmware Translators

Conventionally, HDDs handle sectors going bad by building a translator that converts Logical Block Address(LBA) to a physical location, usually represented by the combination of cylinder, head, sector (CHS). Some sectors, part of the physical address, are defective during manufacture, others fail over time. The translator is responsible for taking LBAs and mapping them onto good sectors, skipping the bad ones. Conventionally it uses two-three lists to manage the types of bad sectors. Translators are expected to be rebuilt periodically to factor in changes to those lists. For a more thorough explanation of the translator and remapping, please see MJM’s bad sector remapping article.

They are:

  • G-List – Grown Defect List, list of defects accumulated over time, expected to dynamically grow over time
  • P-List – Primary Defect List, list of defects found at factory at start of device’s lifetime, expected to be static through the life of the device
  • T-List – Thought to stand for Tracks Defects List, although there are other theories. Generally believed to be dynamic.

What We Found in the Firmware

We were expecting to find three, maybe four lists when we popped open the terminal and starting poking around. We were to looking to identify and overfill one of the Grown Defects Lists to simulate the broken translator found in the wild. So we have found eight lists, and we are not certain that we have discovered them all yet.

Seagate NameTypeNotes
Alt ListG– Alt List: entries  by Logical Block Address(LBA) or sector.
– Synced with G-List.
– Changes over time as defects accumulate. Expected to be dynamic.
G-ListG– G-List: entries by sector only, unlike Alt List
– Synced with Alt List
– Changes over time as defects accumulate. Expected to be dynamic.
LBA List?– Might be an alias for the Alt List
Non Resident G-list (NRG)P– The 2nd primary list generated at the factory after the P-List is generated.
– Generated after a 2nd Self-Scan Test
– Unclear why. Expected to be static.
P-listP– “Classic” P-List; Factory defect list used to generate the translator. Expected to be static
– Generated after initial Self-Scan Test performed at factory level.
T-List?– Cylinders are referenced when contents displayed and it looks similar to the Alt List
– May be a copy of the Alt List or may be a true T-list (track defect list).
User Slip Defect List (USDL)?– May be related to G-list, entries the same, but each entry has additional information
System Slip Defect List (SSDL)?– Able to view after ‘checks T-list” cmd(s) are run, suggesting a relationship to the T-List
– Much, much smaller than the USDL