Strange Artifacts – Wubi

I don’t speak French. I learned it at school and don’t use it much but, if it was a pinch, I could probably remember enough to get by. The same goes for using linux. I know a lot of the basic commands and how to set things up so that it is usable, but I’m not about to go recompiling kernel source code (sorry Hal). I’m pretty sure that owning a Mac, and using Macs at work have helped me learn the basics.

Having said that, I recently rekindled my love affair with linux, well, Ubuntu. I was looking for a Windows solution to a specific problem only to find that I would have to spend a good sum of money in attempting to solve the issue. As I was researching a solution I found that linux was equipped to deal with the situation at no cost and a small learning curve. My only issue was that I didn’t want to repartition my hard drive. I kinda have things set up the way I like them.

Enter Wubi (http://www.ubuntu.com/download/ubuntu/windows-installer).

Wubi is short for “Windows Ubuntu Installer”. You download the software inside Windows and run the installer. There is no partitioning, and the installation is quick and painless. Now, when you reboot, you are presented with an option to boot Windows or Ubuntu. This is all handled by the Windows loader, not a single mention of grub anywhere.

Once loaded you are presented with a complete installation of Ubuntu. But where is it installed?

I booted back into Windows and did some digging. In the directory “C:\ubuntu\disks” I found two files. One of which was named “root.disk”. I decided to throw caution to the wind and throw the file into FTK Imager as an image file…

It worked!

Before me I saw the complete Ext3 file system for my Ubuntu installation. Outstanding, but also a little scary. Still a little something to watch for when conducting your next investigation.

There is also something similar for linux called “lubi”. But I’m not sure I could bring myself to use a product with that particular name.

Flashpost: Google Plus Artefacts – URL Forwarding

While using Google Plus I noticed this and thought that it may be of use to some of you:

Whenever you click on a link in G+ you are redirected to a URL that looks like this:

http://www.google.com/url?sa=z&n=1309767169313&url=http%3A%2F%2Fdilbert.com%2Fstrips%2Fcomic%2F2009-10-04%2F&usg=EazZfazk8jxAKAEECZZ_4OneRqs.

You are then quickly redirected to the linked site.

Obviously you can see the original link URL (the Dilbert one) but you’ll also see a Unix time stamp in the URL “1309767169313″. This is the date and time (in GMT) that you clicked on the link, not the date and time that the link was posted. This is also saved in the history of your browser.

This could add value to forensic investigations. That is, until Google changes it.

UPDATE

The time stamp is generate server side. This means it is another way to detect BIOS clock changes. Suh-weet!

Detecting CMOS Clock Changes

During my short career in digital forensics I have seen and heard a number of defences. One that I have seen emerge a number of times is the claim that one of the parties has been ‘framed’ or ‘set-up’ by someone by changing the system clock and doing some nefarious deed before setting the clock back to the correct time.

If, for example, someone did this on my computer and browsed to some inappropriate website, all the internet history records and cached files would reflect the changed time. To the casual observer, a judge, or a jury it may look like I was responsible. Even a seasoned forensic investigator may be fooled into believing that it was I that did the deed. Without digging deeper each of us could be fooled by such trickery.

Dependent on your position how would you support/dismiss such a claim? I’ve given this a bit of thought recently and come up with a few ideas.

Event Logs

These are the superb resources for many reasons but we’re going to focus specifically on the time stamps for the entries.

Event logs in Windows XP has a default size of 512KB. In both Vista and Windows 7 the default size on event logs is 20MB. In either circumstance the logs act the same way – they fill up in order of events. Once the log is full it goes back to the beginning implementing a first-in-first-out overwriting process of old records.

So, what would you expect to see if the system clock had been changed?

Depending on the software and services running on the computer the event logs could generate hundreds of entries every day. This means that we should be able to easily identify any discrepancies in the logs. As the logs are written in order of occurrence we should be able to tell if the system clock has been changed by parsing the event logs themselves and ordering them by file offset. If the dates suddenly jump backwards and then forwards again it is a good indication that the system clock has been changed. Conversely if you see no such activity it is a good indication that the system clock has not been changed.

If someone changed the system clock from inside Windows (in Vista and Windows 7) then the clock change is also recorded in the event log as event ID 1. Such entries will appear as follows:

The system time has changed to 01/01/2011 08:51:43 from 15/01/2011 08:51:43.

Link Files

If files were accessed or created during a suspected changing of the system clock then evidence may also be found in the link files on the computer.

Harry Parsonage has done a lot of work on link files. As part of his research he has found that link files contain a sequence value. This value is incremented when the operating system is started/restarted. This means that all link files from a single session will retain the same sequence value, when the computer is rebooted the sequence value increases.

If the computer clock has not been changed then parsing the link files and ordering them by their sequence value should also mean that the links are in date order. If, in ordering the link files by sequence value, we see that the dates do not align it is fair to say that the system clock has been changed.

More information on Harry’s research can be found here: http://computerforensics.parsonage.co.uk/downloads/TheMeaningofLIFE.pdf

EDIT: After speaking to Harry I need to make a small correction. It appears as if the sequence value is only consecutive in XP. Apparently they were changed in Vista and Windows 7.

Restore Points

Since Windows XP restore points have been used by Microsoft. They have changed somewhat since being introduced but they essentially serve the same purpose. In each version of Windows the restore points are stored in the folder “System Volume Information”.

In XP the restore points are named incrementally. Each restore point will be contained in a folder with a naming convention of “RP##” where “##” is the incremental restore point number. If a restore point was created during a clock change there will be anomalies. What an analyst would see is ordered restore points but, when looking at the “RP” folders in order of creation datesthe incremental numbers would not match up. If this is the case then it is likely that the system clock has been changed.

The same thing goes for Vista and Windows 7. Although the restore points (shadow volumes or difference files) are different the same principles would apply. If a restore point was created during a clock change the order of the shadow volumes would be changed. The file named {3808876b-c176-4e48-b7ae-04046e6cc752} is an index of shadow volumes and is kept in order of creation, meaning that the most recent shadow volume will be last in the file. Each of these is recorded with the creation time of the difference file so an analyst could simply look at the creation times of the difference files and, if any are out of order it is evidence that the system clock has been changed.

HTML

A number of web pages include date and time stamps. The most obvious of these are forums, but time stamps are also found in web-based email, blog entries, Facebook, Twitter, and so on. Each of these would provide a clear indication of clock adjustment when looking at the creation and download dates of the data.

Others

Each of these provide a very systematic method for detecting clock manipulation but there are other ways for detecting such things. For example, a prefetch file may contain information about accessing specific files that may not have existed on the computer at the changed time, or an email message header will contain information about the date and time sent, HTTP response headers also have time information taken from the web server, etc.

Summing Up

If someone claims that the system clock has been changed we can provide substantial evidence supporting or refuting such claims. It may well be the case that a computer clock has been changed but it is then up to us to provide evidence to support our claims and not just suggest that it may have happened.

Do you have any other methods for detecting clock changes? Please feel free to add them in the comments.

Testing Acquisition Hardware Part 2

A few people liked what I wrote the other day so I’m coming back with a couple more tests that I’ve run today. I have acquired the same drive as with the software tools but this time I have done it with the Tableau TD1 and the ImageMaster Solo III. The hard drive is a 320GB SATA Laptop Drive.

The Tableau TD1 acquired the drive in one hour and eleven minutes. This device uses medium/fast compression but still was pretty fast.

The ImageMaster Solo III acquired the drive in four hours and seven minutes. Obviously this is a bit-for-bit DD image so it writes everything unlike the TD1.

More testing will be done with my external Tableau write-blockers soon, and I will give an update then.

The Risk of Rooting

If I were to say the name ‘Linus’ and your first reaction is ‘Torvalds’ then you are a monumental geek. You make me proud. If you thought ‘Peanuts’ then you’re still a geek, just not quite as serious a case.

Linus, from the Peanuts comic strip, used to keep a tight grip of his security blanket. If anything ever happened to said blanket he would go, somewhat, off the deep end. He felt like his world was ending and that nothing could ever make the world feel safer.

Passwords and keys are the grown-up versions of security blankets.

We carry our phones everywhere, regardless of their content. Our phones may contain confidential emails, embarrassing pictures and videos (such as this one… http://www.youtube.com/watch?v=vT1CVFaNEbA), and they may even hold our deepest, darkest secrets; things that we would never want others to uncover. Thankfully we password protect our phones so that no-one else can find out. Sadly these security blankets can often have large holes.

Typically, to gain access to an Android phone someone would need direct access to the phone, hope there was no passcode/pattern lock, and turn on USB Debugging in the settings. This allows the user to gain access to the the Android Development Bridge (adb). Once a user has access this part of your phone all bets are off as your device can then be exploited and all data be pulled down onto a computer. The easy way to stop this? Lock your phone so no one else can access the contents. It is very difficult to bypass a lock on an Android device, especially on devices using 2.0 and up. However, if you like to tinker with your phone, root it, and install custom firmware you are playing with fire.

I rooted my phone a few weeks back so that I could get the Froyo upgrade (2.2) before T-Mobile got to it and took out all of the good stuff. I downloaded an exploit package that allowed me to easily replace the phone’s recovery image, making it possible to install a ‘cooked’ rom. After some experimentation I discovered that the new ‘recovery’ allowed me to gain adb access without ever booting into the operating system. In turn I was able to mount the ‘data’ portion of the phone and download all the contents to my computer. I then turned the phone back on and, viola, the lock screen appeared as if nothing had happened.

Back at my computer I started to look at the extracted data. I found my text messages, phone logs, calendar items, email messages, facebook and twitter updates, internet history, and the list goes on. I was also able to find both the SSID and the key to any wireless network to which my phone had been associated. This not only meant that my own home network was potentially compromised, but my work network too! My whole life was laid bare for anyone to see, assuming they could get the phone away from me. Bad? Yes but not the end of the world because my private life really isn’t that interesting. However, if my phone bill suddenly tripled or quadrupled I could be in trouble!

I found that turning off the screen lock is a straight forward process that takes only a couple of minutes once access to the phone has been established. Full access to my phone is there for anyone that can lay their hands on my phone, all because I rooted it. Yes, I was the weak link in the phone’s security, not Google. If I hadn’t rooted my phone then the process of retrieving the data becomes infinitely more difficult.

The other difficulty is that locking your phone isn’t going to stop anyone from simply popping out the memory card and walking away with your photographs and videos. Android still doesn’t have a way of encrypting the memory card so that it can’t be used elsewhere. Another potential hole in the security blanket.

What have a I done now? I’ve gone to the stock HTC Rom for my HTC Desire. This allows me to get the latest OS upgrades first and overwrites the modified recovery with the standard, non-adb, version. Would I recommend everyone else do the same? Its entirely up to you.

Also, for those iPhone users laughing at the ‘poor security’ of Android phones take a look at the link below. I guarantee you’ll hold on to your iPhone a little tighter in the future. http://www.engadget.com/2010/10/25/ios-4-1-glitch-lets-you-bypass-lock-screen-to-access-phone-app/

Lessons from Data Recovery – Part 1 (Repost)

I originally posted this entry over on the Disklabs computer forensic forum (http://www.computer-forensics.co.uk/computer-forensics-forums/forum.php) but also thought a lot of people would benefit from it being repeated here too.

I’ve been working at Disklabs for a few weeks now. I’ve mostly been confined to the digital forensics lab but I’ve been able to poke my head out from time to time and see what the data recovery department are up to. I’m happy for this opportunity as it has taught me some interesting things that are useful for computer forensics, and some things that are potentially dangerous.

Over the next few weeks I’ll be posting articles about how data recovery has the potential to impact computer forensics in ways that few have thought possible.

A scenario occurred recently in which an employee left a company on less than gracious terms. The next day the employee’s former colleagues showed up for work and realised that the file server was inoperable. Upon closer inspection they found that all of the server’s drives were blank. Forensic analysis was conducted and nothing was found. If the drive had been wiped it had been done so with undetectable software. The forensic investigator, and the tools at his disposal, had failed to provide an adequate answer.

What would you do in a situation like this? I imagine that my report would be very sparse and contain very little information at all. You could look at wiping software artefacts, such as the sequence of bytes used, in order to determine if this individual had maliciously wiped the data from the drive but, failing this, what other avenues of investigation could be followed?

One of the first things I learned after starting at Disklabs was that each hard drive contains certain information that is not stored on the platters, but on the system area of the drive. The two items that I found to be of most interest are the number of times the drive has been powered on and the number of hours that the drive has been active. This may not seem like a huge finding but the implications are awesome.

Going back to our scenario the hard disk drives were turned over to a data recovery expert who was able to unequivocally state that the drive had only been powered on a handful of times and only had only been in operation for a few hours. What does this means in terms of this investigation? We can draw one of two conclusions either the drives had been replaced as a result of drive failure or they were replaced as a deliberate act intended to deceive. As it turns out the IT department of this company stated that the original drives should still be in operation inside the file server and that the information provided by the data recovery expert contradicted their own opinions.

The original drives were recovered from the former employee’s home a few days later.

My short time at Disklabs has proven to me that we need to educate ourselves on these matters. How can we offer opinion or facts in our reports if we haven’t covered every possibility?

Into The Shadows

This is going to be the first of a couple of articles about Volume Shadow Copies. I was going to put everything in one

Since their arrival in recent versions of the Windows operating system, volume shadow copies have troubled computer forensic investigators. Many investigations place less value on, or even ignore items found in these files due to their complexity. The only known way of fully accessing the contents of volume shadow copies consumes a great deal of both time and storage. This can prove costly for investigator and client alike.

First of all, what are Volume Shadow Copies?

The volume shadow service (vss) runs on the following operating systems:

• Windows Server 2003
• Windows Vista (all versions)
• Windows Server 2008
• Windows 7 (all versions)

The VSS monitors all changes made to a VSS enabled volume.  These changes are monitored in 16kb ‘blocks’. If a change is made to any data inside a 16kb block the entire block is copied to a volume shadow copy file.  This happens regardless of the file system settings.  All volume shadow copy files are stored in the ‘System Volume Information’ folder on the root of the volume and are recognisable by their names.  The file names for volume shadow copies look something like this:

{802c6ba4-300b-11df-a523-005056c00008}{3808876b-c176-4e48-b7ae-04046e6cc752}

You can tell that this is a volume shadow copy because the second set of braces contains the number 3808876b-c176-4e48-b7ae-04046e6cc752 which is a unique identifier specific to the volume shadow service.

There are several ways to create a new volume shadow copy:

• System Snapshot
• Software Installation
• Manual Snapshot

On Windows Vista the system snapshot is scheduled to take place every 24 hours. On Windows 7 it is scheduled to take place every 7 days.  You may notice that this is not exact. Windows Vista will not take volume snapshots exactly every 24 hours, there may be some time changes day to day. This is because the VSS will only create new shadow copies once the computer has been idle for a certain amount of time, or the computer is being turned off or rebooted, and so on.

A VSS enabled volume will always have a ‘live’ volume shadow copy. This file saves all of the 16kb block changes and then, once a new volume shadow copy is created, these changes are committed to the current VSC and the shadow copy is archived. From this point the contents of that volume shadow copy remains unchanged until it is deleted.

Now we know what volume shadow copies are, how do we examine them?

There are currently three main methods for dealing with Volume Shadow Copies:

1. Ignore them
2. Link them
3. Image them

Each of these have their own benefits and downfalls.

The first method is probably named somewhat unfairly. I don’t mean that the evidence contained in the volume shadow copies is completely ignored, what I mean is that a file carver is run over the shadow copies and anything found is reported as ‘system files’.  This is good because it is quick and simple, it is bad because you don’t get anything like the full picture.

Linking requires booting the computer, whether it be virtually or via a disk clone, and creating a hard link to the volume shadow copy so that all files and folders can be accessed. This is good but any analysis performed using this method must be conducted from with the virtual machine/cloned drive. There is limited flexibility using this method but allows quick access to the contents of the volume shadow copies.

Imaging will produce the best evidence but there are a couple of drawbacks. Imaging each volume shadow copy can take a great deal of time and storage space. On a 500GB hard drive, an investigator could end up with 20 disk images from a single volume. That could mean 10TB worth of data. It would take a long time to image this much data and you’d need to think about your storage needs.  The other problem here is that you won’t even know if imaging has been worthwhile until you have analysed the images. All of the promised data may still be in unallocated clusters. This method also requires the investigator to boot the computer either virtually or via a cloned drive.

Rob Lee recently wrote an article on the SANS Forensic Blog giving guidelines on retrieving timeline data from volume shadow copies. This seems to have the best of all three methods, speed, results, and something to take away for analysis. At the time I joked with him that this was bordering on making my research obsolete and, while he has made VSCs more accessible to investigators this method still requires booting the computer.

So, three distinct methods for analysing volume shadow copies and a hybrid method. I have used each of these methods on several occasions and seen, first hand, the good and the bad that each method can bring. Because of this I have remained unsatisfied. I waited patiently for someone else to find a better way of conducting analysis but my patience ran out. About a year ago I decided that I was going to do something about it myself.

Allow me to introduce a fourth method.

I have (mostly) determined the structure of a volume shadow copy. This means that it is now possible to traverse volume shadow copies, extracting meaningful data, and all without having to boot the computer or create extra data to analyse.

Volume shadow copies themselves are divided into 16kb blocks. These blocks are divided into one of two categories:

• Index Blocks
• Data Blocks

As the name suggests the index blocks are pointers to the 16kb data blocks that have been saved by the volume shadow service. The index blocks all start with the same string: 6B 87 08 38 76 C1 48 4E B7 AE 04 04 6E 6C C7 52 01 00.

Then there is a block of 6 bytes (which unfortunately I haven’t yet figured out its purpose). Next there are three 8-byte values. These are the index block’s own file offset, then the index block’s own logical volume offset, then the logical volume offset for the next index block.  This essentially forms a linked list for all index blocks in the volume shadow copy. You may be wondering why use a logical volume offset rather than a file offset, as you continue reading you will see that this is a consistent theme through shadow file technology but it is a question that, as of the time of writing, I’m unable to fully answer.

At offset 128 in each index block the data block index begins. Each record here is 32 bytes in length.  The first 8 bytes reference the original logical location of the referenced 16kb block. The second 8 bytes gives the file offset, in the current shadow file, for the original data. The third 8 bytes gives the logical volume address for the original data. I will discuss the fourth 8-byte value later.

All addresses in these index blocks are given in bytes, not sectors, not clusters, but bytes. This means that the theoretical maximum sized volume for the Volume Shadow Service would be 18,446,744,073,709,551,615 bytes (approximately 18 exabytes). This also means that the 4kb sector drives will not affect the workings of the volume shadow service.

The only thing I have to say is that I don’t know if this is universal across 32bit and 64bit machines. Anyone willing to help me with some testing feel free to volunteer.

I’m sure that you’re finding this all very interesting but would like to know about the practical application of this information. For this example I formatted a drive s NTFS.  The volume has 8 sectors per cluster making each cluster 4kb. I installed Windows Vista, making sure that system restore was active, I’ve then taken the Forensic 4cast logo (file size of 12KB) and copied it to that volume. The logo was found at cluster 109779 (0x1ACD3). As volume shadow copies do not work in clusters we convert it to bytes making it a logical offset of 449654784. Divide this by 16KB (16384) and we’re left with 27444.75. If we ignore the decimals we’re left with 27444 (6B34) which is the VSC block number that contains the start of this file. It should be noted, however, that this file does not start at the start of that block.  The block contains 4 clusters and the picture starts in the last of them. Also, as this file is over a cluster in size the logo is spread over two 16kb blocks. In this case the blocks are contiguous.

I created a volume shadow copy using the ‘System Protection’ dialogue on Windows Vista, deleted this file and performed some menial tasks. I then created another volume shadow copy.

Upon inspecting the volume I found that the beginning of the file had now been overwritten. When performing a file carve over the newer VSC I found a fragment of the Forensic 4cast logo:

If you’ve ever run a file carve over a volume shadow copy you’ve probably seen pictures like this before. This kind of thing can be VERY problematic in cases involving child abuse as you may see a fragment of the picture. You may even recognise the picture from the fragment but, without the rest of that picture, you have to exclude it from your investigation. So the question is how to we turn this fragment into the full picture?

If we ignore the numbers used above (as we wouldn’t have them in a real world situation) we need to recreate them from looking at the data stored inside the volume shadow copy.

Looking at the results of the file carving we see that this picture has a VSC file offset of 454656 (0x6F000).  When we divide this by 16384 we find that this file is not at the start of a VSC block, the file header for the picture starts 3/4 of the way into the block.  With this knowledge we can now take the 16384 byte block and multiply it by 3/4 which comes to 12288. We need to remember this for later.

Finding the beginning of that block we see that the file offset is 442368 (0x0006C000). If we now search for this hex value in little endian we find it appears in an index block with the recorded logical offset of 449642496. If we now add the 12288 bytes from before we have the logical offset for the original starting point of the file, 449654784.  So we know that the first 4096 bytes of this picture were located here, where is the rest of the picture? Ordinarily we’d need to find the original MFT entry for the file and follow the cluster runs from there, but we’re going to cheat and gamble that the picture was stored in contiguous clusters. So we copy the 4096 bytes of the picture from the VSC and then jump that same distance again from the original location. We look in the following sectors for the JPEG footer. We find it near the end of the next cluster. Copying this cluster and adding it to the data copied from the VSC we open the file as a JPEG and find that our picture now looks like this:

We have now successfully carved our first file from a volume shadow copy. If we wanted to find the metadata related to this picture we could traverse the live MFT and the MFT entries saved in the VSCs. This is not a simple task when done manually, but help is on the way. Mark McKinnon of Red Wolf Computer Forensics and I have been working on some software that will allow a forensic investigator to view the contents of volume shadow copies (including all metadata) quickly, without having to clone the volume or run it inside a virtual machine. We’re hoping that this will persuade examiners to spend more time investigating volume shadow copies as it will reduce a large number of the headaches that most investigators associate with these files.

Check back for the next instalment and for news on the release of the VSC software

Mac Forensics

Last Thursday I had the pleasure of attending the Mac Forensics F3 training day.  For those of you that do not know what F3 is, it is the ‘First Forensic Forum’.  Most digital forensic investigators in the UK are linked to this organisation in some way and they offer training days every few months.

I thought that I would quickly note some items that were shared with us before I either forget about it or lose my notes.

Imaging

This can be accomplished on either a Mac or a PC. If you’re looking to image with a Mac there are a few options to choose from but one of the best is offered by the guys over at http://macosxforensics.com.  Their Mac OS X Forensics Imager is based on libewf and offers a graphical interface to the console-driven acquisition tool.

Obviously there are the common everyday items such as DD and DCFLDD that are easily run on the Mac.

Although a write blocker is always recommended it is possible to image a drive without.  In order to do this you need to turn off ‘Disk Arbitration’. This is the process that automounts drives when they are connected to the computer.  After turning this off any newly connected drives will not be mounted. Just don’t forget to turn it back on once you’re finished otherwise you may run into some difficulty.  In order to turn this off just open Terminal and type:

sudo launchctl unload /System/Library/LaunchDaemons/com.apple.diskarbitration.plist

To turn it back on type:

sudo launchctl load /System/Library/LaunchDaemons/com.apple.diskarbitration.plist

Artefacts

Spotlight Files – These maintain an index of the volume from which the file is taken.

Swap File – /private/var/vm/swapfile0

Sleepimage – This file is like the hiberfile on Windows.

Log Files – /var/log – can be opened with the Mac ‘Console’

Property Lists – Two main types: XML and Binary – plists are like the Windows registry. A plist editor is available on the Mac Developer Tools provided with a new Mac. There is also ‘Pref Setter’ (which has a nice search feature) and iPod Robot offers a plist reader for Windows.

Printing – The Mac has an inbuilt PDF printer. This doubles up as a printer spool. This means that, regardless of the printer used, a PDF is created of anything that is printed from a Mac. Once the printing is finished the PDF is released into unallocated clusters. A file carve for PDFs in unallocated space will return items printed with the Mac. These PDFs will also contain metadata providing the application used to print.  I thought that this was the most interesting part of the day. This may be worth some more investigation and a full article written.

Useful Software

PeekIt, iBored, Hex Fiend, File Juicer, Mactracker, and Firefox Add-ons – CacheViewer and SQLiteManager.

MacBook Air Acquisition

The MacBook Air presents a unique problem that is not found with other Apple products.  With other Apple computers the ‘Macquisition’ tool can be used to create an image of the drive in question if the drive is not easily accessible.  Unfortunately Macquisition requires a free firewire (IEEE 1394) port in order to boot the computer into acquisition mode.  The MacBook Air has only one USB port, no firewire port, and no optical drive.  The Apple website suggests that only an Apple branded USB optical drive will allow booting from optical media (such as Helix).  These drives can be costly and largely pointless to purchase.
This guide provides a (relatively) simple method of removing the internal drive and imaging the drive using EnCase (or whatever brand of imaging tool you use).
Firstly, meet the MacBook Air:

The first thing you will notice is that this is a very thin computer; it has an aluminium (aluminum for you non-Brits) case.  This is quite slippery so take care not to drop it.
The first thing you will need to do is turn it over.
There are ten screws that need removing (circled below).  The front six screw are the same size; the rear-corner screws are a little longer; the middle-rear screws are longer still.  Keep track of these for putting it back together.

Once the bottom of the case is off you are going to focus your attention on the rear-right corner of the computer (highlighted below).

When you look closer at this corner you can see two ribbon cables.  The first of these is disconnected at ‘A’ by pulling on tab ‘B’ below:

Once this has been completed you will see four more screws (circle below).  The top two screws are easily enough removed, the bottom two screws are partially obscured by a thin wire.  The wire is tucked in the drive cage.  Gently pry the cable away until the screws are exposed and remove the screws.

We are now ready to remove the second ribbon cable.  Gently pull it away (marked in red below) until it is no longer connected.

Removing the drive is not difficult, carefully life the drive cage and slide the hard drive out from underneath.  Do not pull it out from the top or try to remove the drive cage as you may cause irreparable damage.

Once you have removed the drive the drive turn it over and carefully remove the black tape covering the ribbon connection (marked below).

Once the tape has been removed the ribbon connection is exposed.  Carefully pull the ribbon cable out of the connector (marked below).

When finished you should have something the looks like the picture below:

This is a ‘ZIF’ drive.  These drives are commonly found in iPods and ultraportable PCs.  In order to image this drive you will require the following:

• Either a ‘Tableau T14 IDE’ or a ‘Tableau T35e’ write blocking device
• A ‘TDA5-ZIF’ drive adapter kit

Why so specific? Well, Tableau state that the ‘ZIF’ adapter is only guaranteed to work with one of the two Tableaux mentioned above.  I do not want to risk something going wrong so I’ll follow their advice.  Thankfully I had a ‘T35e’ already available.  You can try using this adapter with a different model, or even a different brand of write-blocker, but its not recommended.
Carefully insert the new ribbon (provided with the adapter) into the ribbon connector on the hard drive and then connect the other end of the ribbon into the adapter (see below).  Then plug the adapter into the Tableau.

From this point forward it is exactly the same as acquiring any other hard drive.  The Tableau will pick up the drive allowing you to image as normal.

Hope this is useful to someone out there.