Even Macbooks do crash

A friend of mine brought her 2-year-old Macbook with the hard disk in a sorry state and asked us to salvage some files she hadn't backed up yet.
Lots of things to learn:

• Should have got and used dd_rhelp right away, even if it's not installed by default and dd_rescue is. 5 minutes googling, d'oh. It tackles the really damaged sectors only at the very end: considering that those are usually not usable anyway, you can abort after a few hours and still have a mountable image.
• Where is that hard drive anyway? (see the ifixit Guide)
• running a ssh daemon on Knoppix: go to the Knoppix menu->Services->SSH daemon. Knoppix prompts you for a password for the user "knoppix", ssh runs on the standard port. I am a bit uncomfortable about that for security reasons: with a standard user name on a standard port, the only thing that keeps others from breaking in is your password - make it strong! You should definitely set a root password (also in the Knoppix menu).
  Trying to log in from home, I got a refusal accompanied by a "IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!" warning about a man-in-the-middle attack with a changed RSA key. This was due to the fact that the ssh daemon on the non-live system used a different RSA key and the daemon employs strict checking. I removed the host and key in ~/.ssh/known_hosts and accepted the new key at the next try.
  
• getting dd_rhelp to run on Knoppix: it's not installed by default. Get it from here, any version >0.1.0 will do. I extracted it right in the directory I wanted to write the image in, it's a shell script, so it runs out-of-the-box with
  ./dd_rhelp /dev/sdxy image.iso
  (Any compiling instructions out there refer to older versions)
  
• screen is awesome: As I had started dd_rhelp from a ssh session, I wanted to keep the process running after closing down the ssh session. Here, screen is the solution, where you can manage lots of virtual shells at once. It's installed by default at least on Knoppix and OpenSuSE. Running screen (root shell) on Knoppix got me "Directory '/var/run/screen' must have mode 755." at first, but chmod 0755 /var/run/screen solved that issue.
  I started the session with screen, acknowledged the greeter message with <Space> and started dd_rescue in the shell appearing after that. I detached the shell with <Ctrl+A> <D> (message [detached]).logged out and shut down the remote machine. I reconnected later via ssh and got the screened session back with screen -r.
• I ran photorec next: lots of unsorted, renamed and mostly fragmented files. Definitely a start, though.
  
• mounting and checking hfs+: The native tools for openSuSE seem to be the hfstools including hpfsck (no, there is no standard fsck.hfsplus). I don't know whether this has changed by now, but a number of web discussions report hfstools as badly maintained and indeed hpfsck had no clue about the disk image. Darwin's diskdev_cmds seem to be better, so I got them as described here. The opendarwin links didn't work for me, so I got the packages after some googling from a Gentoo repo. However, any mount attempts failed spectacularly (figures…); I set up the image as a loop device and ran fsck.hfsplus:
  losetup /dev/loop0
  fsck.hfsplus -rfd /dev/loop0
  Still no luck, errors: "Catalog file entry not found for extent" … "volume check failed with error 7". Googling got me the Mac OS disk volume structure overview. Damaged catalog file. Bummer. Last resort seems to be Disk Warrior, which is Mac OS only and costs 100$.
• Reassembling sucks: This machine doesn't want you to screw around with it. After accidentally detaching one of the small rubber guides in the narrow drive bay (it coiled up right in front of the SATA connectors), I attempted to remove the back cover, which is actually worse than assembling an IKEA wardrobe. In the end, I got the drive in with a combination of perseverance, pliers and praying.