Charles,
	I discovered that the nandroid backup utility includes something called 'dump_image-arm', which I'm guessing is the same as the nandddump utility you described. I've run this utility from the phone, and extracted a dump, but still get the same results when I attempt to write it back to an emulated nand device on my analysis VM.

	I'm using 'dump_image-arm  userdata -' piped through netcat to get the image off the phone, and then '/mnt/hgfs/G/andr# modprobe nandsim first_id_byte=0x20 second_id_byte=0xaa third_id_byte=0x00 fourth_id_byte=0x15 parts=24,1110,1788,2,40,768,4 overridesize=12' to set up the emulator and 'nandwrite -a -p' to read it back in. Unfortunately, I'm seeing the same results as when I tried this with the dd image. I tried 'nandwrite -a -o', but it says the image is not page aligned... I also went back and tried unyaffs on the new dump file, but got the same results as before.

		Any thoughts or suggestions?
			Thanks
				John McCash

-----Original Message-----
From: Charles Manning [mailto:manningc2@actrix.gen.nz] 
Sent: Monday, November 02, 2009 3:34 PM
To: yaffs@lists.aleph1.co.uk
Cc: McCash John-GKJN37
Subject: Re: [Yaffs] Access to files on a YAFFS2 image

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!