Note that the information in this article has been superseded by a new technique that leverages the EXT4 file system drivers. If your analysis system supports EXT4 (and most Linux distros do at this point), then I recommend looking at this article for more details.
Several months ago, I blogged about using alternate superblocks to fake out the ext3 drivers so you could mount file system images read-only, even if they were needing journal recovery. However, due to recent changes in the ext file system driver the method I describe in my posting is no longer sufficient. Happily, there's a quick work-around.
Let's try the solution from the end of my previous posting under a more recent Linux kernel:
# mount -o loop,ro,sb=131072 dev_sda2.dd /mnt mount: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so
This looks like the original error output we got when using the primary superblock. Looking at the relevant dmesg output we see something different, however:
[163135.527484] JBD: Ignoring recovery information on journal [163135.795917] Buffer I/O error on device loop0, logical block 0 [163135.795931] lost page write due to I/O error on loop0 [163135.795944] Buffer I/O error on device loop0, logical block 1 [163135.795949] lost page write due to I/O error on loop0 [163135.795958] Buffer I/O error on device loop0, logical block 2 [163135.795963] lost page write due to I/O error on loop0 [163135.795973] Buffer I/O error on device loop0, logical block 3 [163135.795977] lost page write due to I/O error on loop0 [163135.795986] Buffer I/O error on device loop0, logical block 18 [163135.795991] lost page write due to I/O error on loop0 [163135.795999] Buffer I/O error on device loop0, logical block 32 [163135.796034] lost page write due to I/O error on loop0 [163135.796232] Buffer I/O error on device loop0, logical block 73 [163135.796238] lost page write due to I/O error on loop0 [163135.796248] Buffer I/O error on device loop0, logical block 74 [163135.796253] lost page write due to I/O error on loop0 [163135.796261] Buffer I/O error on device loop0, logical block 94 [163135.796267] lost page write due to I/O error on loop0 [163135.796275] Buffer I/O error on device loop0, logical block 96 [163135.796280] lost page write due to I/O error on loop0 [163135.796516] JBD: recovery failed [163135.796520] EXT3-fs: error loading journal.
It would appear that even though we're using an alternate superblock that's marked as not requiring journal recovery, the ext file system driver is still finding the uncompleted journal entries and trying to apply them. This is arguably "more correct" behavior than the old driver used, but it doesn't help us very much.
The simple work-around is to tell the ext file system driver to ignore the journal by forcing the file system to be mounted as ext2:
# mount -t ext2 -o loop,ro,sb=131072 dev_sda2.dd /mnt # ls /mnt bin dev home lib mnt proc sbin usr boot etc initrd lost+found opt root tmp var
Excellent! With this small modification our trick is working again. Hurrah!
You might well wonder what happens if you just try to mount our image as ext2 without using the alternate superblock. Unfortunately, simply mounting as ext2 is not sufficient because the primary superblock is still marked as needing journal recovery. Though I wonder why this flag should be relevant to an ext2 file system, it's enough to prevent the mount from happening. So the result is that you need to both mount using an alternate superblock and (at least on modern Linux kernels) mount the file system as ext2 to stop the file system driver from looking at the journal.
Hal Pomeranz is an independent IT/Computer Security consultant and a SANS Faculty Fellow. He actually discovered this problem when attempting to give a live demo in the middle of a class. Unfortunately, the solution only occurred to him after class was concluded. This is one of the reasons why being a SANS Instructor can be so... invigorating.
