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
(text/plain)