Hi John
There are a few problems with this strategy...
On Tuesday 03 November 2009 08:03:16 McCash John-GKJN37 wrote:
> Hi Folks,
>
> Please CC me on any responses. I'm a forensic analyst,
> and I'm working on a process for analyzing YAFFS2 filesystem dumps from
> Android phones. We've been able to get onto the phones as root via adb,
> and extracted raw dumps of all the ro mtd devices via dd ("dd
>
> if=/dev/mtd/mtd2ro of=/sdcard/mtd2ro.dd bs=4096" for example).
Does that give you the OOB area? you will need that too. The best is probably
to use nanddump with the relevant options.
>
>
>
> We were initially expecting to mount these images on a
> YAFFS2-enabled Ubuntu Linux system (with YAFFS kernel compile options
> configured the same as those in the phone kernel) via the loop device,
> as we would with ext2, but this doesn't work.
Nope that won't work. Looping gives you a block device interface which works
with block-oriented fs. yaffs is not a block oriented fs.
> Then we tried using
> block2mtd, but that emulates a NOR device, and we can't mount an
> emulated NOR device as YAFFS2.
> Then we tried unyaffs, but it just says
> "broken image file" and exits.
unyaffs might work with a nanddump output.
>
>
>
> Finally, we tried using nandsim (modprobe nandsim
> first_id_byte=0x20 second_id_byte=0xac third_id_byte=0x00
> fourth_id_byte=0x15 parts=0x18,0x456,0x6FC,0x2,0x28,0x300,0x4), and
> writing our extracted images into one of the emulated nand flash
> devices. When we write the image files in with dd, the operation
> appears to succeed, but when we mount the associated block device, we
> see an empty lost+found directory, and nothing else. We tried writing
> the image back with "nandwrite -a -o", but it complains that our dd
> image is not page-aligned. We understand that the -o option is essential
> to correctly writing a YAFFS2 image, and the -p option is incompatible
> with it. In any case, when we tried using -p, we got the same result as
> with dd.
>
>
> We've also heard that dd may not capture all data from
> an mtd device (Can anybody explain why?), and that we should be using
> nanddump. After this we also tried writing one of the test images
> (userdata.img) from the Android SDK using "nandwrite -a -o". This
> appears to succeed, but when we mount the result, we again get just an
> empty lost+found directory, and nothing else, suggesting there's
> something wrong with our write methodology.
Nand flash has two areas to it: "inband" data (typically 2048 bytes per page)
and "oob" spare bytes (typically 64 bytes per page). yaffs typically uses
both. dd just copies the data area of a nand flash so that loses all the oob
area.
What you should probably be doing is using nanddump to extract an image and
nandwrite to push that image into nandsim.
>
>
> Can someone who really understands how mtd devices and
> YAFFS2 work look at this, and tell us if we're doing something
> fundamentally wrong? Can anyone suggest an alternative methodology for
> performing a YAFFS2 filesystem dump and examining its constituent files
> offline?
>
>
>
> Thanks much
>
> John McCash
>
>
>
> ----------------------------------------------------------
>
> Quis custodiet ipsos custodes?... I do!
(text/plain)