Image forensics: Difference between revisions

From OLPC
Jump to navigation Jump to search
No edit summary
m (loopback (misnomer) > loop, categorize)
 
(One intermediate revision by one other user not shown)
Line 1: Line 1:
<noinclude>[[Category:OS]]</noinclude>
== Mounting the Image ==
== Mounting the Image ==
One way to inspect a captured JFFS2 image is to configure a loopback device on top of it, to use the block2mtd module to produce an memory-technology device (mtd) backed by the loopback device, and finally to mount the resulting mtd.
One way to inspect a captured JFFS2 image is to configure a loop device on top of it, to use the block2mtd module to produce an memory-technology device (mtd) backed by the loop device, and finally to mount the resulting mtd.


As root, run:
As root, run:


losetup /dev/loop4 nand.img
losetup /dev/loop4 nand.img
modprobe block2mtd block2mtd=/dev/loop4
modprobe block2mtd block2mtd=/dev/loop4,128KiB
cat /proc/mtd # inspect status
cat /proc/mtd # inspect status
mkdir mtd
mkdir mtd

Latest revision as of 00:56, 12 November 2011

Mounting the Image

One way to inspect a captured JFFS2 image is to configure a loop device on top of it, to use the block2mtd module to produce an memory-technology device (mtd) backed by the loop device, and finally to mount the resulting mtd.

As root, run:

losetup /dev/loop4 nand.img
modprobe block2mtd block2mtd=/dev/loop4,128KiB 
cat /proc/mtd    # inspect status
mkdir mtd
modprobe jffs2
mount -t jffs2 mtd0 mtd

If you want to write to the image, you may need to pad it with several blocks of 0xFFFF bytes.

Also, on some kernels, the jffs2 module may fail to load due to incorrect licensing information in the mtdsuper module. In this case, rebuild the mtdsuper module with appropriate licensing information, overwrite the old version, and then load the jffs2 module. On Fedora, these operations consist of:

# install the appropriate kernel-devel rpm, perhaps downloaded from http://koji.laptop.org/packages/kernel/
mkdir mtdsuper && cd mtdsuper
wget -O mtdsuper.c http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.24.y.git;a=blob_plain;f=drivers/mtd/mtdsuper.c;hb=HEAD
echo 'MODULE_LICENSE("GPL");' >> mtdsuper.c
echo 'obj-m := mtdsuper.o' > Makefile
make -C /lib/modules/`uname -r`/build SUBDIRS=`pwd`
sudo mv mtdsuper.ko /lib/modules/`uname -r`/kernel/drivers/mtd/

Forensics

Let's assume that I've mounted my image at $ROOT. First, we will define some helpful environment variables:

mkdir ~/data # A data-collection directory.
export HASH=$(basename $(readlink $ROOT/versions/boot/current))
export RUN=$ROOT/versions/run/$HASH
export PRISTINE=$ROOT/versions/pristine/$HASH
alias rpm="rpm --define '__dbi_cdb create private nommap' --root=$RUN"

Then, we can begin inspecting the contents of the image. For example, we might run:

rpm -qa > ~/data/pkglist

in order to record what packages are installed in the image.

We could then run a command like

rpm -qV bootanim 

to determine compare the image's RPM databases's idea of the contents of the bootanim package to the installed versions.