We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Hardware Hacking Village - Reversing Corruption in Seagate HDD

00:00

Formal Metadata

Title
Hardware Hacking Village - Reversing Corruption in Seagate HDD
Title of Series
Number of Parts
335
Author
N. N.
License
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Translation tables are a dynamic component of HDD firmware that translate logical addresses to physical locations on the disk. Corrupted translators can be the cause of drive failures in drives that appear undamaged and are without physical trauma. That failure can be reversed in many cases. We will present ways to identify if a drive’s translator has been corrupted for the Moose & Pharaoh drive families specifically, how to force a translator rebuild, and open source tool(s) to help you repair the translator. Data recovery is a notoriously secretive field. Very little information about firmware and its internal data structures is public. Knowledge should be open source. By sharing what we’ve learned we hope to open this field up to more people, encourage repair, encourage re-use rather than disposal of hard drives, and encourage further publicly shared research. After the talk, attendees should be able to fix this type of error themselves in HDDs of the appropriate families using a TTL converter and the supplied code. Familiarity with the basic components of hard drive firmware is helpful, but not required.
BitFlow separationComputer hardwareExpert systemData recoveryLevel (video gaming)Group actionProcess (computing)Sinc functionMereologyRoboticsSoftware developerAddress spaceHacker (term)SoftwareCompilerProjective planeMaizeHard disk driveLecture/Conference
Order (biology)FamilyMultiplication signPoint (geometry)Hacker (term)Radical (chemistry)Reading (process)CausalityDirected graphAddress spacePersonal identification numberComputer programmingGame controllerReverse engineeringData recoveryDisk read-and-write headHard disk driveCompilerBinary codeType theoryNP-hardStress (mechanics)CASE <Informatik>Scripting languageData miningInformation securityBootingVorwärtsfehlerkorrekturLogic gateElectric generatorWave packetLecture/Conference
NumberRight angleStandard deviationLatent heatService (economics)Shared memorySoftware bugCompilerCausalityNP-hardHard disk driveRadical (chemistry)Interface (computing)ArmType theorySuite (music)Data recoveryOpen sourceFamilyLogic gateSynchronizationImplementationAbsolute valueNear-ringLecture/Conference
Social engineering (security)CompilerHard disk driveAsynchronous Transfer ModeOptical disc driveGeometryBitService (economics)NumberAreaExecution unitRing (mathematics)Error detection and correctionCylinder (geometry)HypermediaDisk read-and-write headMiniDiscReading (process)WritingVorwärtsfehlerkorrekturType theoryElement (mathematics)Stack (abstract data type)Multiplication signWindowPoint (geometry)Electronic visual displayScaling (geometry)Bit rateMathematicsCASE <Informatik>Computer architecturePhysicalismData centerUniform resource locatorCompilerMultiplicationCausalityLecture/ConferenceMeeting/Interview
Crossflow cylinder headElectronic mailing listUniform resource locatorAddress spaceCylinder (geometry)Disk read-and-write headHacker (term)PhysicalismComputational complexity theoryGeometryBlock (periodic table)CompilerComputer hardwareFactory (trading post)FirmwareMiniDiscTime zoneType theoryNumber2 (number)Form (programming)Goodness of fitFunctional (mathematics)Data structureSoftwareComputer architectureHard disk driveModel theorySpeicheradressePort scannerPerfect groupMappingPerspective (visual)Software testingLimit (category theory)Array data structure1 (number)Multiplication signLogicData managementPriority queueLevel (video gaming)AbstractionFreewareNP-hardLecture/Conference
Disk read-and-write headPlastikkarteMultiplication signRadical (chemistry)Partial derivativeCompilerCompilerAreaBootingElectronic mailing listMatching (graph theory)Lecture/Conference
Radical (chemistry)Electronic mailing listCompilerAsynchronous Transfer ModeReading (process)Order (biology)Point (geometry)Error messageSimulationLecture/Conference
Electronic mailing listError messageSimulationAsynchronous Transfer ModeMultiplication signRadical (chemistry)Lecture/Conference
CompilerFirmwareFuzzy logicQuicksortElectronic mailing listSign (mathematics)Software testingTouchscreenStapeldateiAsynchronous Transfer ModeCASE <Informatik>PiOptical disc driveEndliche ModelltheorieTotal S.A.2 (number)Address spaceSoftwareForm (programming)Analytic continuationBitSemiconductor memoryGoodness of fitRandomizationBlock (periodic table)Scripting languageComputer hardwareNumberFood energyPlastikkarteTrailComputer programmingHacker (term)Lecture/ConferenceMeeting/Interview
Flow separationMultiplication signGodSoftware testingDigital electronicsVideo gamePoint (geometry)Error messageServer (computing)Mortality rateDisk read-and-write headSoftwareService (economics)AreaSlide ruleScripting languageDifferent (Kate Ryan album)Function (mathematics)Game controllerVarianceOrder (biology)Data recovery2 (number)Revision controlWindowSerial portArithmetic progressionElectronic mailing listReverse engineeringFirmwareVorwärtsfehlerkorrekturLevel (video gaming)StapeldateiAsynchronous Transfer ModeComputer fileGoodness of fitParameter (computer programming)CompilerIntegrated development environmentSoftware engineeringSocial classCASE <Informatik>Computer hardwareGraph (mathematics)Computer engineeringResultantFile Transfer ProtocolSimulationLecture/Conference
Information privacyInformation securityAxiom of choiceVarianceAreaInformationVorwärtsfehlerkorrekturMultiplication signPoint (geometry)Disk read-and-write headService (economics)Type theorySoftware developerSoftware bugField (computer science)Data miningBitElectronic mailing listCausalityLatent heatHard disk drivePersonal identification numberFamilyProduct (business)FirmwareAddress spaceAdaptive behaviorProjective planeMereologyHacker (term)Power (physics)CircleWritingReading (process)Serial portData recoveryTouchscreenModule (mathematics)Reverse engineeringAsynchronous Transfer ModeRevision controlOrder (biology)Radical (chemistry)Perspective (visual)Connected spaceCAN busCodeEndliche ModelltheorieDifferent (Kate Ryan album)Lecture/Conference
AreaSoftwareRadical (chemistry)State of matterPower (physics)Asynchronous Transfer ModeComputer hardwareScripting languageService (economics)Order (biology)SpeicheradressePersonal identification numberHookingDeterminantLecture/Conference
Scripting languageElectronic mailing listVorwärtsfehlerkorrekturFunction (mathematics)CompilerOperator (mathematics)FamilyPrice indexCompilerOnline helpData recoveryInclusion mapDifferent (Kate Ryan album)Software testingInheritance (object-oriented programming)Term (mathematics)Open sourceArmSuite (music)Focus (optics)Open setLecture/Conference
Data conversionOracleVideo projectorSign (mathematics)Scheduling (computing)Hard disk driveSpeech synthesisComputer hardwareInternet forumMaizeUniform resource locatorLecture/Conference
Transcript: English(auto-generated)
Alright, hi, thank you all for coming to Reversing Corruption, Seagate Hard Drive Translators, also known as the Naked Trail Data Recovery Project. Because we've had some technical difficulties, I may speak really fast, I'm from New York, I'm sorry. Um, but thank you for all making it through the maze and through the confusion to be here, I really appreciate it. My name is Allison, I'm one of several Allison Octoborns, uh, I'm a
software developer by trade, I build high level blue, blue software, so this has nothing to do with what I do as a day job. I haven't really touched hardware since college where I did a bunch of robotics research and learned that cutting edge research is the easy part of getting published in IEEE publication. It left a little bit of a mark,
about a dozen years worth of a mark, so that's really it for my hardware experience. I'm not an expert in this, that's her, that's her job, so feel free to tell me I'm wrong. That's a slow transition. Look dude, I'm Mr. Dead, um, I named the project, it's a play on our last names, you know, uh, Born Naked is her last name in
Dutch. Um, I've given talks at Hushcon, Teardown, and then Arch Reactor Hackerspace. Uh, I founded Revenant Data, which is a data recovery company in Oregon with Wire Glitch, who's somewhere around here. Um, I've co-founded a couple of hackerspaces, uh, the most recent one, so like Pascal and PDX Hack Labs. I, I try
to do like, uh, workshops on reverse engineering and focusing on assembly and binary challenges. I don't have a formal education, I did not go to Carnegie Mellon University like Allison. Everything that I know is self-taught, like minus, I, I did do Scott Moulton's data recovery training, the remote one. Um, I've never actually met him,
which is kind of funny. Um, and I do roller derby and I like stress bake, I get stressed out and I bake stuff. That's my non-infosec hacking stuff. Alright, the original quest. We dubbed it the seemingly undavaged HDD in a really bad day. Uh, so,
what ends up happening is, this is out of order, oh that's fine. I get a lot of these cases in, translator corruption, which basically means I have zero access to user data, or sometimes we'll have partial access. What that, how that manifests is, it'll
boot, spin, it'll get stuck or never, and by, you know, stuck and busy, it just means not recognized by the host. Uh, and then it never initializes. Another thing that can happen is it will boot, spin, click, not all clicks are clicks of death, uh, and then it'll spin down. So, when that happens, um, especially if there's clicking
involved, and this is always, the type of corruption that we're talking about occurs in Faro Seagates and Moose Seagates, which I know many of you may not actually be familiar with family names in hard drives, but you can ask me about that later. Um, so when the clicking happens, it usually is indicating the short points problem, uh, which
means that I have to short the read pins, or short the read points in order to gain terminal access, and then force a regeneration of the translator, success. That's a little off, and that's messed up. Success, but it's actually never really that easy. Um, it can become, like an extremely awful time sink for me. Uh, like in order to, I have to
short these read pins at a very precise time, and then I have to send a control Z to gain terminal access at a very precise time, and it can suck up anywhere between an hour of my time to six hours, I'm not kidding. My, uh, partner and I would often have to like switch
off, cause we'd get tired of like sitting there and listening for the heads to leave the platter and then like start mashing control Z. So, um, what makes this extremely frustrating is once I get terminal access, forcing the translator regeneration is actually very simple, but it's this timing issue that drives me nuts. Long story
short, um, I went to the, the hacker space and started complaining about this a lot. I really don't like this. Yeah, but anyway, um, Allison overheard me and I, I said, oh, I want to automate this. I would love to be able to bypass this like four to six hour timing issue of shorting these points and sending a terminal command so that I can just
boom, get to the translator regeneration, and she chimed in, she's like, oh, I can transcript that. Um, I think you said, hey, I need some code, it'll be really easy. I'm pretty sure that's what you said. I may have tried to sucker her into it knowing damn well, cause I'm not a coder, I don't, like, I, I've very little programming skills. Um,
so along the way, while we were doing research to try to solve this particular issue, we started realizing there's a bunch of other little, like, much simpler tools that we could fit, or that we could build, and we started doing that, um, cause the ultimate goal, where we are currently focusing on translators and also just C gates, even more specifically, these two families, however, several of our tools do work
on pretty much any C gate, uh, 7200 dot 12 and beyond. Um, anywho, yeah, we started, uh, working on other types of tools that we can fix. We want to turn it into a full-on data recovery suite that's open source. Reasons to care. I know a lot of people think that
hard drives are obsolete or near-obsoletion, obsolescence, but, um, there are some pretty important reasons to care. Number one, right to know, uh, there are standards for hard drives, a lot of you are probably familiar with ATA standards, the INCITST13
committee, they issue those. Um, the problem is, is majority of these are vendor specific. The tool that we built, we used the, um, terminal debug interface that has zero standards, everything's vendor specific. So, if you don't know what you're doing, you either have to send it to a data recovery company, it's going to cost you an arm and a leg, most likely, or you have to sink, honestly, probably months, if not years of
research into figuring out, what commands can I use? What does this command mean? Um, these lack of standards make it really difficult to, like, implement quality assurance, and again, you're forced to rely on very costly data recovery tools or services. Um, right to repair, I wholeheartedly believe ownership is not a time share. Uh, it
really bugs me that manufacturers want you to use their data recovery services only. Um, again, I think that ultimately drives down QA. Um, they're not compostable, and there are a hell of a lot of them, especially when you factor in data centers and the fact
that they're still using predominantly spinning disks. Um, they're manufactured with cobalt on the platters, um, that can, it can cause neurodegenerative diseases, it's been linked to ALS recently, and I do have citations for all this, and then of course silica, also neurodegenerative diseases. That's you. Yup. This podium is
freaking me out. Alright, so, why you know Linux? Yeah, yeah, and apparently I can't
use Windows, so I suppose I don't have any stones to throw. Alright, so, of the disks that cross Mr. Dead's desk for repair, about 50% of them are Seagate's. Of that, just over 8% display translator corruption. This doesn't sound like a ton, but, um, scale's
a funny thing. So, Seagate started shipping drives in 80, 1980, and about 20 years later they announced that they shipped 250 million hard drives. And they've kept shipping at about that rate. So, let's do some bar math. Um, translators really first appeared with the F3 architecture, which was shipped in about 2008. And if we say
there are 100 million drives active, then we are looking at north of 8 million cases of translator corruption. So the odds are good if you have a couple drives or you run a data center, it's gonna happen to you. And when it does, you'll find out that this can be really expensive. We did some social engineering and we found that the cost of a
translator repair can run you somewhere between 700 and 3000 dollars. And in general, repair on a hard drive can run you north of 8000. So, getting your bits back can be extremely expensive. And I don't know about you, but I don't necessarily have a spare 8K laying around. So, that's the reason you should care beside the high-minded stuff.
I'm gonna try to get through this, cause I know it's kinda boring, hard drive anatomy. Um, haha, uh, number one, filter, not very important. Number two, however, those are the platters, aka the media, aka spinning disks. And that's where your data is technically actually stored. Um, what else to pay attention to? Six, the,
the heads, right, the read and write elements of the drive. They're gonna fly over the platters, reading and writing data. They're parked on the head ramp there, uh, but honestly the second or, you know, third most important element is seven, that's the head stack connector. So, that's connected via that number eight, the ribbon, to the
head stack connector. If you remember, I was talking about shorting read points. Well, I have to know where those are, because that's what I'm doing. I'm preventing, um, via this solution. The, the read, like, the, the heads seeking the service area, it'll stop. I'm tricking it into giving me a debug mode. So, anatomy. Hard disk
geometry. Uh, I wanted to bring, like, I wanted you all to kinda have a little bit of background on this, because, you know, CHS, this is introducing you to CHS and LBA. Um, service area is that grayish blue ring around the outside, if they're outer parked heads on a
ramp. The, it could also be on the inner ring, um, which that would be inner parked heads, so heads are parked on the platter. I can't issue this solution with those types of drives all the time. It's harder, because I'm literally listening and also kinda feeling for when the heads are leaving the, the ramp. Um, two, the sectors, which is the S
and CHS, um, that is physical location of data. It is the smallest unit of data on the hard drive. 512 bytes of user data, 520 if you factor in ECC error correction code. Um, and is then divided up into cylinders, which are concentrically expanding rings from the
center of the drive. Um, if you have multiple platters, that's going all through every platter. Uh, I highlighted it there, number four, that is a cylinder, those are all cylinders, some people will dispute and call them tracks, that's a whole big debate. Uh, and then, um, that cylinder, again, that would be the C and CHS, the H is the heads, uh, so
cylinder head sector, and a zone is, that includes, like, several cylinders, and it is just a way to, like, aid in translator, but we're not gonna get into that. There you go, that's you. Hardware is icky, let's talk about software instead. And guys in the back,
feel free to come in and sit down, we got plenty of seats. So, what's inside the firmware that we really care about? Well, one of the most important data structures is the translator, and the translator maps from logical block addresses to cylinder head sectors. Anytime you see the word logical in a name, it's a cue that we made this up. Uh, logical block addresses are an abstraction. CHS represent a location in
physical space on the disk. Your translator will map between one and the other and vice versa. Well, how does it do this? Well, like all the data structures or famous hackers, it has a posse. Uh, it's posse is made up of defect lists. Um, your translator is a great place to hide things if you don't want the host OS to know they're
there. Not that I would encourage you to do this, but in theory, it wouldn't be half bad. So, the list that you use as a helper to construct the, the translator as a translator structure are two types of lists. We have primary defect lists and grown
defects lists. Primary defects are defined as defects that are found at factory or creation. You're either broke or you're not. Sectors are just kinda bad sometimes, we make them, no one makes a perfect disk. Grown defects are the ones that accumulate over time. Flakes or rusts, cosmic rays, aliens staring at your hard drive, stuff just goes bad over time and we know it. So, we tend to stick them in two lists. The
grown defect list usually has a lot more space than the primary lists because it's, the size of that tends to determine how long your drive will really stay viable. In Seagate's, we find a second form of primary list called the non-resident grown defect list. This showed up in... It showed it up, uh, after 7200.12. It doesn't
exist in 7200.11. Ask her. After the architecture came out in 2008, so around then, but ask me about that later. Anyway, go go go. Alright, um, these two lists are
created by something in Seagate lingo called a self scan test. As far as I can tell, it's a QA test they run. Um, and when working with these lists, they appear to largely function as glorified arrays, but I haven't been able to fully prove that's what they really are. They just seem to act a lot like it. So, alright, let's talk
about some lists. No no no, not lists, this is physical to logical. I was getting there. Oh. Oh, it's your turn. Wait, I thought this was me. No, it's not my name on it. What? No, that's management. Alright, we'll let you do it. Okay. So, how does CHS map to LBA? This is, and how do skip lists and remap lists work? That's what
this is showing. Up above, uh, the darker blocks is cylinder head sector. Those are the physical blocks, geometric location. Keep in mind CHS is always oblivious to these defects. It has no idea that it, that they exist. That's where the translator will come in. The primary lists found at factory, so P list, NRG list, maybe a few others,
we're not entirely sure yet. Um, functions like this. So, 0, 1, and 2, those are good, those are good blocks, good sectors, and they map identical, address wise, to the CHS. Physical block 3 is bad, so we skip it and 4 becomes 3, and that's how a skip
list work. It's fast, it's significantly faster than remaps, which we will get to, now. And an important thing to note, from his perspective, is they have a limitation, they're static. So, we tend to pair them with primary lists, because they're expected to be static and unchanging. Physical, physical to logical via remapping, which is what the
grown defects list are, so anything in G list is functioning like a remap. Uh, again, 0 and 1 physically, you know, having the similar, having the same address. We get to 2 and 3, those are both bad. Um, the heads will, you know, hit that and, uh, check the
ECC, it doesn't match, it knows to, translator tells it, okay, go to the reserved area, which, the heads have to fly to a totally different area, this can really, really start to increase, um, the time that you have to spend, you know, waiting for your data to show up. So, a lot of times, when your drive's starting to slow down, it can often indicate, via smart data, kinda, sorta, don't ever really rely on that, but it can
indicate a grown defects list, potentially. If you're in CS, this will cause it to resemble a linked list, in a lot of ways. Yeah. And, uh, yeah, actually, that's all I got, but if you have more questions, you can talk to me about that later, I know it's kinda, it's esoteric. Ah, science translator may be corrupted. Um, again, as I mentioned,
earlier, uh, drive will boot, it'll spin, um, or it'll do the partial boot, ultimately, it's never recognized by the host. Ah, if you're able to get, you know, terminal debug mode, you will see these errors, pretty much anything that begins with LED is indicative of a
translator issue. Ah, that top one there, ending in A051, it's just kind of like a classic stuck and busy. Ah, could, could be, you know, lists need to be merged, or the G-list needs to be purged. Ah, the second one there, ending in A7E5, pretty much always
means, in a faro or moose drive, that I'm gonna have to do the shorting of the read points in order to gain terminal access. Um, the sim errors down here, any sim error that you see that's like 1000 through 1008, probably, uh, corrupted defects list, don't really know which one, you'd have to research that, or memorize it over time. Sim
errors are something that one of our tools can fix. Um, but those are things to look for in terminal debug mode if you ever decide to do this for fun, or, yeah. You. I came up with a plan worthy of a Bond villain. It is foolproof, it cannot possibly fail. So we're
gonna corrupt a translator in a controlled manner, because I like properly testing my software, run it through a manual fix, take some notes, take some numbers, model with a program, test it on some unsuspecting members of our hackerspace, and profit. Who's written software before? Show of hands. Or played with proprietary hardware. Yeah. Yeah,
you all know where this is going. Unsurprisingly, we ran into a few problems. So, initially, we were expecting to find three lists, the P list, the NRG list, which is that second form of P list, and, and a G list, right? When we start spelunking in the
hardware, we find two out of three. So far, so good, we are on track, I'm feeling good about it, it's warm and fuzzy. Warm and fuzzy never lasts. I'm the reason I can't have nice names. So, instead of finding one G list, we found three, which became our first problem. Which of these grown defects lists are we gonna try to overfill, and are they
all really actually G lists? Because we just sort of found a bunch of lists and had to figure out what they were, what they did, and whether they were actually useful. So. If you were confused by the remap, the physical to, to logical remap, ask me later what is copied and why that happens and how. Alrighty, anyway. So, we ended up trying to fill some
of these lists and seeing what the drive did and seeing if we got the sort of signs of corruption we were expecting. We ultimately settled on the eponymous G list, so the first one at the top, and that's the one we used for the rest of our experiments and testing. So, that's the, that's the list we settled on for future use. We also found these
two, um, they're called slip lists. That means we found a total of seven lists here when we were expecting three, it's a little crowded in there. They aren't relevant to this talk and we're not entirely sure what they do, but we found them and we wanted to share that in case they're useful to other people. So, we, we expected that we'd sort of fill
the list by hand once, it'd fall over at two thousand entries, we'd move on. Uh, that's not how that went. So, initially, Mr. Dead here added three thousand some odd entries by hand. Not that she was counting. Uh, I added about thirty four before wanting to
throw out the wall and deciding pie cereal was the lesser of two evils. Promptly scripted that. So, even then I'm like alright, we'll run it overnight, it'll be done. Well, we ended up north of six thousand entries and the translator wouldn't corrupt. And we're like, we don't think it has that much space, it shouldn't have that much space.
We've run some numbers, we think it should only have like two gigs. And it finally dawned on me that the translator was actually a little bit smarter than I'd given it credit for and it was adding entry sequentially and just skipping the entire block. We were basically telling it that it's continuous memory was bad and it was like okay, continuous memory is bad, we'll just skip that. So, I ended up having to add a
randomizer to the script so it'd add random jumps so that it couldn't block it. Uh, even then we found that the list had way more space. We were expecting it to fall over at two thousand entries and it usually takes between four thousand and five thousand for it to fall over. Um, the drive didn't like being up for a lot of that. If you look at the far screen over there, you'll see the drive powering down in the middle of me doing
things. So, we found we also had to batch it and give the drive pauses between stuff. And you'll see on the left, that's the screen attached in diagnostic mode and it's got way fewer entries in its G-list than I was expecting it to have, which was sort of my tip off that it was doing something smarter. I'm a little embarrassed to say it took me a
while to see that. I just sort of thought I was doing it wrong or wiring it backward, which happened a lot. Alright, so, firmware is really weird. It was the third problem I personally ran into. What does level six E2 do? Any takers? This
creates a user batch file zero. Uh, how about level T, I4, parameters one, you already know the answer. You can clean the erasers after class. This clears the G-list. I have no idea how this corresponds to clearing the G-list, but it does. And so, if anyone ever says
this to you. Every time you say code is self-documenting, God kills a kitten. Yeah. Why you ruin my punchline. I've been waiting ten years to use this picture from my worker's desk. Um, so, Seagate firmware is extremely non-self-documenting, and that can be
very difficult to work with when you have to rely on partially transcribed Chinese manuals found on sketching FTP servers. The other problem we ran into that isn't really on a slide, because I didn't think it needed a slide, was that we also ran into differences between firmware, like different behavior, different output. Some commands that we expected output from didn't output in the Apple firmware version, and it took us a lot of
head-banging to figure that out. So, when you're messing with this, you can't even count on output to be consistent across commands to tell you whether something succeeded or not. In some cases, the Apple version just doesn't do anything, if it succeeds or if it fails, you just have to try later and see if it actually did something. So, again, that
timing issue and why I wanted to automate this, because it takes forever. Um, this is just a little graph that Allison made, it's the results of several timing tests recorded, um, during our attempts at the manual fix to short the points problem. Um, this is from
powering on the drive to me hearing, listening for the heads to seek the service area. What's not shown is the timing between shorting the points and sending control Z, uh, we didn't include that because we never actually got that far. Um, as you can see, there's a huge variance, um, I think it was roughly between, like, 4.28 or something like that, uh, up to,
like, almost 6.4 or something. Um, this is only from a single drive and we spent about two hours with zero success. Uh, so, this was, you know, we had successfully corrupted the drive by overfilling the G-list and here we are trying to figure out, well, how are we
going to script this timing issue? And we're still not there, so. Alright, so, to recap, we had some surprises. There were more lists than we anticipated. We ended up stumbling around trying to figure out which one. The translator was smarter than I expected by actually a fair amount. Firmware is extremely weird, it has differences and
the G-list was a lot larger than we anticipated which did significantly slow us down in places because I expected to be able to fill that sucker in four hours and it takes closer to 48. Yeah, data recovery technicians and professionals are patient when we're
working and then in the rest of life we're kinda assholes, I think. But, uh, some other problems we ran into, um, you know, we're only human, we're mere mortals, uh, lots of human errors. Software engineer can't hardware, hardware engineer can't software. She crossed wires, I don't know how many times, probably wasted about four hours on just confusing TX, RX and maybe not even having ground in which I think she did
actually kill one of our drives by not having ground in. Uh, and then I failed, I, I was trying to, you know, uh, use the, her script that she wrote to intentionally corrupt. I didn't read the documentation so I'm just like, go, go, go. Nothing's happening, Allison, and I went back to manually inputting. That was, that was pretty
awful. Uh, I also poked through the PCB when trying to short the points. Um, but it's okay, I have so many of these to play with. Uh, the significant timing variance, um, the command output that we're waiting for in order to verify anything could take between one second. She put six minutes, realistically it's like ten minutes. It could be ten minutes even with really, really expensive, awesome data
recovery tools like the PC-3000. Had to wait upwards of ten minutes with the PC-3000. Um, Pi cereal was less reliable, don't use it on Windows. Um, I'm not the best Linux user at all, but this forced me to learn a lot more and sort of get away from Windows. So, don't judge me please. Alright, so, where we're at now, now that we've
arrived at you for some background and our experimental progress and emotional journey, we can consistently reverse corruption if diagnostic mode is available. So, if you see SIM error 111009, we know we can always reverse that. That one works very
well. We can consistently corrupt our target drive, so I do have good test environments. Now, we, so if you want to play with reversing corruption, we can get you a drive that is in shape for that. The unfortunate thing is though, is we haven't been able to reproduce the original target solution on our corrupted drives. Because of the
variance in timing and the fact that I don't have a way to programmatically detect where the heads are, I'm not actually convinced that we'll ever really get to a fully automated fix for the original problem, but that doesn't stop us from trying. Ta.
Alright, so before we show you code, the development philosophy for this project is a little bit different. I generally believe that not all hackers are coders. It's a little bit of a controversial opinion these days in some circles, but I do believe that. And I have met some very technical people in the data recovery community who can't read or
write code for, for anything. Like that one. For, not, not that I would be so crass as to name names at a podium while we're being recorded. Anyway, so, this makes my spirit, my hacker spirit sad. And the whole point of this project is that the data privacy community has to, there was not a can of caffeine in that latte, I'm saying. They
have to operate with this giant veil of secrecy. Manufacturers are withholding information, a lot of it's proprietary. People who make tools are extremely secretive. The large companies that do data recovery do not share. So our goal is to make this open. And if you can't read the code, then you don't really know what it's
doing, and you haven't learned. Code represents intelligence. So, this code has been written with those people in mind. If you are a developer, and you are a purist, avert thine eyes, because there are fragrant violations of dry, it is over commented from a developer perspective, and it is very procedural, and it will basically piss off anyone
who writes code professionally. I'm okay with that, because they're not my target audience. I want people who do data recovery to be able to read it. It's in Python for two reasons. One, because it's the lingua franca of security, and it's our poison of choice. But also because in my experience teaching people, it is the easiest type of code for non-coders to understand. It is also GPLv3, because we are interested in
making sure this information stays open. There's already a bunch of proprietary and closed stored stuff. I'm not interested in spending my precious free time adding to that. So, if you want to yell at me about the license choice, feel free, go for it. Uh, please file your bugs with this, this philosophy in mind. It is a little bit
different. So, to the meat of it, what you're going to need to implement this at home with one of your Ferro or Moose Seagate drives, um, side note, I wasn't entirely comfortable with this. I'm definitely very used to my expensive fun tools, uh, but I
very much want this to become open source. So, to do this entire thing, if you already have the drive, shouldn't cost you more than 15 bucks. You just need a USB to TTL adapter with the FTDI chip, FT232, access to the ground pin, so you're going to have to shell your drive. Um, if you have, if you're not using one of the adapters
that has, you know, shared power with the host, you're going to need a power adapter. You'll need the code, which you can find on her GitHub. Uh, you'll need pi serial module. We strongly encourage and incur, well, we encourage you to install screen to issue a sanity check to make sure that you are in fact connected to the reverse corruption. Uh, we also strongly encourage that you never use this on a hard
drive with data that you give a damn about. Uh, don't. Um, you do have to match it in a very particular way. Um, all hard drives are broken up into these really bizarre, like, uh, families and lots of other things. Um, generally with the, the
Seagate, Moose and Ferro, match the model number. You can ID it if it's a good drive via the debug mode and I can, like, you know, we'll document that somewhere. There's a special command you can send for that. Um, if not, you can kind of go off the model number. Ferro and Moose drives almost always end in something, something AS with the model number. Uh, match the firmware versions because, again, this, the
exact specific type of corruption we were trying to fix with the shorting of the readpoints, um, in order to gain terminal access doesn't incur in a couple of, like, Apple, it can occur there, but it's difficult to fix, um, because when it's seeking the service area and at what points it's reading the service area are different than in other firmware. The Dell specific firmware, JC4A, we were never able to get
corruption. I don't know why. I don't know if it's somehow impervious to G-list overfill. I'd have to do a lot more research to figure that out. This is our setup. Um, that's my little, uh, pin or, uh, readpoint shorting tool that I, it's just tweezers and I tried to space them, uh, as perfectly apart to quickly hit the
readpoints which are in the middle there and the, uh, it's just solder wrapped around the, wrapped around there trying to bridge it. It's a really shoddy setup and I'm embarrassed by it, I guess. Um, and, yeah, those are the readpoints we're aiming for when we're, you know, right after power on, listening for it to leave, uh, listening for the heads to leave and then, uh, once we actually did reach
corruption, because we have done that, uh, I just wanted to verify it in one of my fancy tools so it's hooked up to the PC-2000 over there. They have these fancy terminal connectors that are way better than, way better than that, uh, much less likely to cause connectivity issues. Um, so, yeah, when you're doing this, just make sure that,
you know, you're criss-crossing your RX and TX from host to device. Um, it's like, honestly, kind of a, a, kind of a trek to even figure out what pins are TX, RX on the drives. Um, so, TX is always closest to, uh, the SATA, then RX right next to it and then ground is the very last. So, we didn't show the power connector, it's there.
Please be very careful, um, there's a lot that you can do to destroy your drive and never get access to your data again. So, again, if you're going to be doing this, choose it, choose to start with a drive you don't care about at all. And before you start, very first thing, back up the service area, which, yes, you can do via terminal debug
mode commands, you can save that way, um, ask me about that later, but definitely, definitely, definitely back up the service area. Alright, so you've got your equipment, you're ready to go. Please get your software installed in order. Remember to give it executable permissions. Hook up the connectors, double check your connectors. If
you're in software, have someone in hardware check your connectors. Determine what port your OS has been assigned. Read on the scripts, read the, I'd say read the documentation before you start, but I'm a realist and know that nobody does that apparently. So, before you hit run, please read the documentation because the order of the
LBA address as you enter matters. So, yeah, running this once you've got all your stuff and set up and are good to go is actually pretty quick. However, there is one gotcha I do want to mention. So, as we mentioned earlier, some of those, especially when you get a
full G-list, your remap operations get really, really slow. And we did see some of the commands to add entries take north of 10 minutes to fully execute. So, the script will timeout, you'll see received byte 0. In the setup, you can see on the left that we are actually getting the sectors reassigned, i.e. added to the G-list, even though the script
says we got nothing back. This is because I went and made T and came back and there was the output. So, be aware that if you see receive 0, it's not an indication that the operation failed, it just means it was taking longer than the script was willing to wait. So, don't freak if you see those. Alright, so what's next? This is the shameless
plug for help. We would like to try solving the original problem without shorting. We'd like to write some code to configure the translator to rebuild based on the list you specify. You may remember that we have 7 of them to pick from. I'm guessing you'll
get some different behavior and some different performance if you rebuild the translator with different lists. We'd like to expand this to include other Seagate families or even better, other manufacturers. We could potentially do this with the ATEA commands because they are not specific to Seagate. So, again, long-term goal, we would like an open source data recovery suite, uh, so that people don't have to spend an arm
and a leg or, you know, hundreds to up to 10 grand sometimes on data recovery. Um, feature requests, again, our current focus is on translators and defects list issues. Uh, we do want to expand to include other solutions and, of course, other manufacturers. Um,
code contributions, just make sure you please keep Allison's philosophy in mind. Uh, you know, make this for people that don't know how to code. Um, we would love help testing that doesn't always include just writing scripts. There's other things that I would definitely like help with and you can ask me about that later if you're interested. Um,
open knowledge about the firmware, all this again, data recovery is super, super, super secretive. The manufacturers are secretive, other data recovery companies are very secretive. Um, you know, it's, it's hard, there's a lot of digging. Uh, there's some great forums out there, HDD oracle is one of my favorite. Um, I highly recommend you visit that if you haven't. So, acknowledgements, um, speaking of HDD oracle, uh, really, one of the
things spilled it, never met him, but he founded HDD oracle and he's just a fantastic researcher. Um, just wants to, he loves what he does and he's not in it to make money. Um, uh, I think that's it. And then if you want. I'd like to thank Leap Bunny and the two
goons who sprinted over Cross Hotels to get us a projector at T minus five minutes because I don't think I could have done that. No. Yeah, Leap Bunny's awesome. He's always wearing a green hat pretty much. Definitely buy him food or booze or something. And then bibliography you can find on my GitHub that I never use or that
little URL, which is totally safe, I promise. And if something happens, find Dean Pierce. Okay. So we were supposed to take five minutes of questions, but because we got such a late start, we're going to take all of our questions over under the hardware hacking village sign to try to keep this room as on schedule as it is
usable to be at Def Con. So thank you all for coming. Thanks for forwarding the maze. We look forward to seeing you over there to have a longer conversation.