Charles, All of my image files, whether created by dd or dump_image-arm, come out to be the correct size. I'm guessing that the oob data is simply being read as nulls. Where would I look with a hex editor to see whether this is the case? Is there an offset within the image that is within the oob area, and should definitely not contain nulls? Thanks John -----Original Message----- From: yaffs-bounces@lists.aleph1.co.uk [mailto:yaffs-bounces@lists.aleph1.co.uk] On Behalf Of Charles Manning Sent: Monday, November 30, 2009 3:22 PM To: yaffs@lists.aleph1.co.uk Subject: Re: [Yaffs] Access to files on a YAFFS2 image On Tuesday 01 December 2009 08:49:13 McCash John-GKJN37 wrote: > 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. It might not be.... Do they both dump the same OOB bytes? > 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. nandwrite -a -p will definitely not give you the results you're hoping for because it does not write oob. nandwrite -a -o will work so long as the oob is handled correctly. This sounds like dump_image-arm does not dump the same oob bytes that nandwrite -a -o wants to write and that's why there are alignment issues. I would suggest checking the size of the image file to see if it is what you'd expect. -- CHarles > > 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! > > _______________________________________________ > yaffs mailing list > yaffs@lists.aleph1.co.uk > http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs _______________________________________________ yaffs mailing list yaffs@lists.aleph1.co.uk http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs