As some of you may remember, I’ve previously written about a technique for mounting EXT3 file system images with the read-only option, even when power was abruptly removed from the system– as is typical during forensic seizure– and the file system is still “dirty”. In these cases, my technique involves using an alternate superblock, which will not have the “needs journal recovery” flag set, and using the “-t ext2” option to ignore any entries in the EXT3 file system’s journal.
In the last year, however, I’ve been starting to see cases where I’ve had to analyze the newer EXT4 file system (hence my recent series of articles on EXT4 internals). It turns out that the technique I developed for mounting EXT3 file systems does not work with EXT4:
# mount -t ext2 -o loop,ro,noexec,sb=131072 ext4-test.img /mnt/test/ 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 # dmesg | tail -1 [124897.443002] EXT2-fs: loop0: couldn't mount because of unsupported optional features (240).
So, unfortunately, our trick of using “-t ext2” to get the file system drivers to ignore the journal is not going to work for us here, because the EXT2 drivers don’t recognize many of the new file system options in EXT4.
So what can we do to mount our EXT4 file systems? When in doubt, refer to the man page:
# man mount [...] -r, --read-only Mount the filesystem read-only. A synonym is -o ro. Note that, depending on the filesystem type, state and kernel behavior, the system may still write to the device. For example, Ext3 or ext4 will replay its journal if the filesystem is dirty. To prevent this kind of write access, you may want to mount ext3 or ext4 filesystem with "ro,noload" mount options or set the block device to read-only mode, see command blockdev(8). [...] noload Do not load the ext3 filesystem's journal on mounting. [...]
The “noload” option looks promising. Let’s give it a try:
# file ext4-test.img ext4-test.img: Linux rev 1.0 ext4 filesystem data, UUID=... (needs journal recovery) ... # mount -o loop,ro,noexec,noload ext4-test.img /mnt/test/ # ls /mnt/test backups crash lib lock lost+found opt spool cache games local log mail run tmp
You can see the “needs journal recovery” flag in the output of the file command, so our file system is definitely dirty. But happily the “noload” option does indeed allow us to mount the EXT4 file system.
But what about EXT3? The manual page suggests that “noload” will work there as well. Unfortunately, this doesn’t appear to be correct:
# file ext3-test.img ext3-test.img: Linux rev 1.0 ext3 filesystem data, UUID=... (needs journal recovery) # mount -o loop,ro,noexec,noload ext3-test.img /mnt/test/ 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 # dmesg | tail -1 [126955.823010] ext3: No journal on filesystem on loop0
It appears that the “noload” option does in fact cause the journal not to be loaded. But the EXT3 drivers apparently regard this as an error condition and refuse to do the mount. And before you ask, adding “-t ext2” to the command line above doesn’t work either.
So at this point I was stuck with having one method for mounting EXT4 and a different, painful method for mounting EXT3. But then I got an email from Gebhard Zocher, which pointed out a clever solution:
# mount -t ext4 -o loop,ro,noexec,noload ext3-test.img /mnt/test/ # ls /mnt/test bin dev home lib mnt proc sbin usr boot etc initrd lost+found opt root tmp var
Since the EXT4 drivers are backwards compatible with EXT3 file systems, you can just specify “-t ext4” and then use “noload” to mount your EXT3 file systems without mucking around with alternate superblocks. And that means we now have a consistent solution for mounting both EXT3 and EXT4 file systems. Thanks Gebhard!
Hal Pomeranz is an Independent IT/Security Consultant, a SANS Institute Faculty Fellow, and a GCFA. File systems fear him. Hal will be teaching For508: Advanced Computer Forensic Analysis and Incident Response in Baltimore, Oct 9-14.