Hard disk drive imaging… Beyond ddrescue and the like!

Few months ago I was approached by a colleague of mine to attempt rescuing his laptop. The thing was, he dropped his laptop on the ground (ouch!) while it was (still) powered on. My initial reaction was: ‘forget the laptop but do take out the hard drive and send it to a specialist – if you value your data’!? I also gave him a few estimates on the cost of that kind of a service – which he (regretfully) declined because it was a bit expensive!? I guess he didn’t value the data as much!? Anyhow, he entrusted me with the hard drive and said ‘do what you can do, and if it doesn’t work out no big deal’.

Now, to be honest – I kind of went through the same exercise before with a varying degree of success (mostly successful though), but even then, I was sure time will come when all my attempts at rescuing a failed/failing hard drive simply by resorting to software only would not be enough!

When a HDD drops on the ground – especially when it’s turned on – all sorts of bad problems could happen – but absolutely the worst (I think!) that could happen is that the head is damaged (e.g. bent inwards towards the platters) to the point that when you plug in your hard drive and it does its ‘reference run’, the platters get scratched and you end up with additional bad sectors further diminishing your chance of a successful data recovery! This is why specialists advise that the HDD is opened up by a professional first before it is plugged in. On top, this would be done in a controlled and very clean (dust free!) environment – making the chance of a successful data recovery greater.

I’m not a specialist nor I have a controlled environment, but I would like to kid myself every now and then that I know what I’m doing 🙂

So… I took (a risk essentially!) out the 2.5″ WD hard drive from its laptop bay, insert it in my USB docking station and plugged it in the computer. And immediately from the sound it made, I could tell the head wasn’t stuck and that the motor was spinning without any obstructions. But… it took a while before the drive was detected by my Linux kernel and mounted.

I used software tools from my trusty Linux toolbox and I concluded (by the way ddrescue was ‘progressing’ – which BTW was excruciatingly slow – that it’s the head most likely! Slow, very slow – but no bad sectors.

My next logical assumption was that it can’t be the firmware. The firmware cannot simply stop working on it’s own, being that we are talking about software. It either works – or it doesn’t – and if it has bugs, they’re hopefully sorted out before going into production. This is especially a valid conclusion when you see no physical damage on the controller board e.g. a burnt IC!? But I went along and ordered an identical donor drive off from eBay. After all, when I will have my next chance to swap two HDD controller boards and learn something new in the process? 🙂

the hard drives

Apparently, two identical drives!? But when you open them up and expose the PCBs:

the controller boards

You will immediately notice that:

  1. The shade of green (the lacquer finishing) on the boards is different!
  2. The two bigger ICs in the bottom – definitely different!
  3. The EEPROM ICs containing the firmware – also different!

Now, at close inspection, the layout seems identical – which tells me the supplier has (actually some of the suppliers have) changed. In the automotive industry where most of my experience comes from, even this type of a change would cause a change in revision!

Nevertheless, I went on by swapping the controller boards directly. If the revision is the same this should work ‘out of the box’, right? But because of all of the above, it didn’t – which was completely expected!

Then, with the help of some essential tools when working with SMD components (e.g. a hot air soldering/de-soldering station, a soldering iron, a microscope and then a few…):

dav

I first tried de-soldering the firmware IC off the donor board. This went rather smoothly. Then I tried de-soldering the firmware IC off the patient board. This didn’t go as smooth – even though I used/applied the same technique!? In the process, I managed also to de-solder the small ceramic capacitor next to the EEPROM IC. I tried soldering it back, but it was near impossible as it was of the smallest SMD footprint possible! Smaller than the IC pins (!!) :

the damaged capacitor

At the end, I soldered the patient’s firmware onto the donor controller board:

donor controlled board, patient firmware

… and vice versa:

patient controller board, donor firmware

Applied a bit of flux cleaning, mounted the controller boards on the hard drives and went along by plugging the donor hard drive with the patient’s controller board first and all was working properly. Hooray!

A short sigh of excitement! Short, because I realized that plugging in the patient hard drive with the donor’s controller board would yield the same results as prior to this ‘experiment’ – proving that it’s the drive’s head that is the problem.

All I am left to do now is to source a HDD head comb (cheaper) or head replacement tooling (more expensive) and swap out the heads between the donor and the patient hard drive!

BTW, have a look at this very informative videos: Don’t Waste $1000 on Data Recovery (don’t let the name fool you), Data Recovery: Hard Drive Platter Swap in Our Lab! and Repairing A Damaged Hard Drive And Data Recovery – Drive Thrown From 2nd Story Balcony. I learned a lot just by watching them. Reading on it’s own, is sometimes not enough!

I think I will try this one out. 🙂