Data recovery on a MAC HFS journalled external drive

A friend of mine recently asked me whether I had any experience of data recovery. Her WD Elements external hard drive was no longer mountable and she had years of data stored on it. A data recovery company was asking for 800 EUR to fix it.

After a bit of Googling, I came up with two tools. The first was PhotoRec and the second was TeskDisk. I downloaded the Ultimate Boot CD, which is essentially a bunch of LINUX tools that run off a bootable CD. Both PhotoRec and TeskDisk are available on that disk.

Ultimate Boo CD v5.3 boot up screen

I first ran PhotoRec. and it successfully started to extract her files off the disk. Since PhotoRec was working so well I started to realise that the disk was probably not that corrupted, so I killed the PhotoRec process.

My gut feeling was that the partitions were still there, but the MBR was corrupted, probably because the disk had been pulled out of the machine without being unmounted first.

TestDisk isn’t that obvious but I battled through with it. First you choose to [Create] a new log file.

teskdisk – create new log file

Then you choose the physical disk that you want to work with. I choose based on the disk size since I knew it was 1000GB (i.e. 1TB). It was labelled /dev/sda.

The first thing you have to do is to select a partition type. I knew this disk had been setup on an older Mac, so I choose [EFI GPT].

TeskDisk – Choose a partition type. I chose EFI GPT

I then select to [Analyse]

It found two partitions. One EFI and the other was Mac HFS. You can move between the two partitions. The EFI one had the [P] option to ‘list files’.  The Mac HFS one didn’t. I chose the [Deeper Search] option and it started to scan the drive in more detail.

The process was so slow on this 1TB drive that i left it run overnight. This process ended up listing what seemed like hundreds on Mac HFS partitions. That seemed strange. I then Googled around and realised that the HFS system is “journalled”, meaning that the file system stores versions of your data. Each partition was a slightly different version of the same data. I came across a post that suggested I could use the ‘pdisk’ utility to rebuild all of those partitions, but it meant naming and sizing all of those (what seemed like) hundreds of partitions. The lazy hacker in me said no. There must be a better option.

I researched further and came across Revision of Case Study: Repair mac filesystem. I followed through the [Advanced] section [Superblock] and noted that I also had the error “Sectors are not identical”. I selected [Backup BS], which then seemed to fix the issue.

I then asked my friend to plugin the drive into her Mac. It still didn’t mount, but using the built-in Mac Disk Utility app, it could now see the drive! Result.

However, the volume/partition was greyed out. The right hand panel noted that the volume needed to be repaired. We clicked on repair and the Disk Utility went through a series of checks that were output in the Disk Utility output panel. Finally we had a green light and the disk popped up on the desktop.

It was fixed!

How I stay calm, by people with very stressful jobs

What I do is install underwater gas and oil wells. The whole job involves stress, from getting in a helicopter to fly out to a ship 300km north of Shetland, to getting on the dive ship itself. There’s the pre-saturation medical, and then I go into a 2.5m x 7m chamber for a month. I’ll be in there with 11 other divers, working in teams of three. You go up and down to the sea bed in a submersible decompression chamber, basically a diving bell, that’s lowered to 20m above the sea bed. Then two of you get out of a little hole in the bell and you’re “locked out”, as we call it, for six hours in the pitch black and off to do your work with all sorts of marine life. I’ve been doing this for 20 years. Usually I work one month and then have two months off.

There’s no room for arguments in this environment. You need to be very tolerant of other people because you’re living in such close proximity. You also need to accept the fact that if it goes wrong, you’re probably not going to get out alive. You need to go in with your eyes open. There are deaths. We lost a 32-year-old diver a couple of years ago who had a three-week-old daughter. It happens, so you need to be aware of the risks.

Interesting read. Not a job for me!


The golden rules of encryption for developers

It is easier to provide the list of things that are worth worrying about than it is to list the things that are safe. There are a lot of as-yet unbroken ciphers and constructions. So, here are the things to avoid:

* Block ciphers in the default mode (“ECB”).

* The Dual_EC random number generator, which virtually nobody uses anyways. You weren’t going to accidentally end up using it. Or, for that matter, any other PKRNG (random numbers produced by public key algorithms).

* RSA with 1024 bit moduli (or below); RSA-2048 is your starting point. Conventional DH at similar key sizes will be an issue too, but there’s a “means/motive/opportunity” issue for RSA-1024 given its prevalence.

* MD4, MD5, and SHA1 aren’t backdoored, but are broken or weak. But: all three are survivable in HMAC (don’t use them, though). SHA2 is your best all-around hashing bet right now.

* The NIST P- curves. There’s no evidence to suggest they’re backdoored, but (a) the rationale behind their generation is questionable and (b) they have other annoying properties.

So far as I can tell, you are now fully briefed on the “distrusted” crypto.

Don’t build your own crypto. Use PGP for data at rest, TLS for data in motion, and NaCl for the rare in-between cases.

Source @tptacek:

Photo credit: Jill Catley via Flickr.