Josh Stone, Blog

Josh’s projects and security nerdery

EXT Forensics Fun

At work the other day, a situation arose that demanded more knowledge of the Ext filesystem than I have. It’s odd that I actually know more about NTFS internals than I do about Ext (especially given my general bias against Windows). Anyway, I pulled out File System Forensic Analysis by Brian Carrier for more info. Here’s the situation:

Homeboy runs Linux, and decides it’s time to re-install the OS. After starting the install, he encounters errors on the drive relating to creating the filesystems. I suppose this is kind of a good thing, because after thinking about it a bit, he realizes there’s data that he needs off the drive. Oops. So I get the call – can we get data off?

As always, the answer is – sure! But it depends. There’s only so much that can be done in Ext2/3 when you don’t have the metadata. For some playing around, I did something that I consider fun.

I created a 20MB filesystem and copied /etc to it (about 8MB of data). I then made a duplicate of this image. On the duplicate, I created a new filesystem with the same parameters (defaults for mkfs.ext2). This gave me two images – one where the Ext2 metadata refers to the data and one where the “fresh” metadata refers to an empty filesystem. I used one of my favorite techniques for quick-and-dirty visualization and built a little picture of the “diff”:

Each box is a block (1024 bytes) in the FS. The color is determined as follows:

ColorMeaning
BlackUnchanged zero-block (all zeros)
GrayData unchanged after mkfs
CyanData modified after mkfs (possibly set to zero)
YellowBeginning/End of inode table for block group 1

Unfortunately, the “modified” data in the inode table for group 1 is where formerly there were inodes, and now (after re-making the FS) they’ve been written to zeros. Alas – it would be so cool if this wasn’t the case. Apparently, the inode tables in each block group get blanked when you create a new FS.

All of the gray blocks represent the files that were in the original FS. It’s all there – but I can’t tell what is in what file, and if there were fragmentation (which there shouldn’t be, since I never deleted a file), it would be an absolute mess.

Too much fun… I enjoyed playing with visualizing the filesystem so much, I may try to do some more playing around with this idea. From a forensics point of view, seeing it really seems to add something. So often, I find myself trusting Brian Carrier’s tools. Not that I don’t trust them – it’s just cool to see it.