Decoding the tags is non-trivial because the layout is dependent on the myd.
What you have here is a raw dumping of the oob area which includes the yaffs
tags, bad block markers, ECC and some unused bytes. This layout is not fixed
and will depend on the mtd implementation. This varies from device to device.
For example, it could be:
2 bytes of bad block marker
28 bytes of packed tags
unused bytes
12 bytes of ecc
or maybe
2 bytes of bad block
10 bytes of ecc
14 bytes of packed tags
2 bytes of ecc
14 bytes of packed tags
unused.
yaffs accesses the oob via a "non-raw" interface that hides the ecc, bad block
markers etc. and just passes a buffer for the tags, not worrying how they are
actually stored. The mtd fiddles around and places the bytes. How it does
that is of no concern to yaffs.
You could possibly determine the actual layout by inspection but the easiest
is probably to look at the code.
-- Charles
On Tuesday 01 December 2009 11:22:33 Andrew Hoog wrote:
> Guys,
>
> John and I have tagged teamed on this so I'm going to jump in the middle
> here. With the dd (or cat) "image", I'm pretty sure we do not have the OOB
> data. At 0x800, there is no break in the user data. However, using the
> dump_image-arm program, at 0x800, the current file stops and I get the
> following:
>
> 0000800: d924 0100 2b09 0000 e600 0000 0008 0000 .$..+...........
> 0000810: 317f 0fd6 c51f 72c3 16dd 1a03 0b17 04a7 1.....r.........
> 0000820: 454b 5ae9 e89d 08c0 df4a f6be 77ab df87 EKZ......J..w...
> 0000830: cc52 0559 6114 bcfe 0000 0000 0000 0000 .R.Ya...........
>
> and then I see more user data. Charles, while I've studied the various OOB
> tag definitions (from packed to extended, ecc and others), I have yet to
> full discern what the OOB looks like (this is YAFFS2 on an Android device).
> Can you confirm this is the 64 bytes of OOB data? If so, can you share
> the best reference to decode the tags (I have the source from both cvs and
> the Android SDK which is what I will use unless you know of a better write
> up). Thanks Charles.
>
> Andrew Hoog
> Chief Investigative Officer
> tel: 312-283-0551
> ahoog@viaforensics.com
> ________________________________________
> From: yaffs-bounces@lists.aleph1.co.uk [yaffs-bounces@lists.aleph1.co.uk]
> On Behalf Of Charles Manning [manningc2@actrix.gen.nz] Sent: Monday,
> November 30, 2009 16:09
> To: McCash John-GKJN37
> Cc: yaffs@lists.aleph1.co.uk
> Subject: Re: [Yaffs] Access to files on a YAFFS2 image
>
> 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
>
> _______________________________________________
> yaffs mailing list
> yaffs@lists.aleph1.co.uk
> http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs
>
> The information contained in this communication may be confidential and may
> be privileged. This email is for the use of the intended recipient(s) only.
> If you believe you have received this email in error, please notify the
> sender immediately and then delete this email, all attachments and any
> copies. If you are not the intended recipient, you must not keep, use,
> disclose, copy or distribute this email without the author's prior
> permission; any review, retransmission, dissemination or other use of, or
> taking of any action in reliance upon, this information by persons or
> entities other than the intended recipient is strictly prohibited.
(text/plain)