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)