One easy way to do this is to write a file with a constant pattern. The oobs should then stand out between them. The layout should show 2k of the pattern with oobbytes of oob between them. -- Charles On Tuesday 01 December 2009 10:33:41 McCash John-GKJN37 wrote: > 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