Having trouble with a UBI filesystem

Having trouble with a UBI filesystem

[Ron Bowes]

Hey Linux-mtd folks,

I'm a security consultant that does a variety of different consulting
work for our customers. In my current project, I'm trying to read a
UBI filesystem from a flash-chip dump, but I'm having a lot of
trouble. I've tried to use both the MTD userland tools (from you
folks) and ubi-reader (from https://github.com/jrspruitt/ubi_reader).

I'm struggling to understand the filesystem, and it seems to be - at
least initially - because the VID header is offset by 0x40 bytes from
where I think it should be. I was wondering if anybody recognizes
what's going on here, and can help point me in the right direction?

I've been working directly on the file dump in a hex editor right now,
and I see why the tools are struggling, but I don't understand why.

In the image, the block sizes are 0x21000 bytes, the VID header is at
offset 0x800, and the data offset is 0x1000. The first block is empty,
but here's the second EB block header:

```
          ---magic---     ver -  -  -     --------- EC --------------
00021000: 55 42 49 23     01 00 00 00     00 00 00 00     00 00 10 0d
UBI#............
          vid_hdr_off     data_offset     -image_seq-     --padding--
00021010: 00 00 08 00     00 00 10 00     8b 19 3b a0     00 00 00 00
..........;.....
          --------------------------padding--------------------------
00021020: 00 00 00 00     00 00 00 00     00 00 00 00     00 00 00 00
................
          -----------------padding-------------------     ----crc----
00021030: 00 00 00 00     00 00 00 00     00 00 00 00     c4 b3 6f 75
..............ou

00021040: 00 00 00 00     00 00 00 00     00 00 00 00     00 00 00 00
................
...empty...
000217f0: 00 00 00 00     00 00 00 00     00 00 00 00     00 00 00 00
................
```

That all looks legit. It lists the vid_hdr_offset as 0x800, and the
data_offset at 0x1000. Looks good so far!

If I fast forward to 0x800 bytes into the block, where I'd expect to
see the VID header, I see:

```
00021800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00021810: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00021820: 12 2e e1 ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00021830: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
```

It appears that the checksum is set, but nothing else at all,
including the 'magic'. However, if I go an additional 0x40 bytes to
0x840 from the start of the block, I see what appears to be a UBI VID
header (starts with 'UBI!'):

```
                             type  compat
          ---magic---     ver   copy      --vol_id---     ---lnum----
00021840: 55 42 49 21     01 01 00 00     00 00 00 00     00 00 01 18
UBI!............

          ----pad----     -data_size-     -used_ebs--     data_padding
00021850: 00 00 00 00     00 00 00 00     00 00 00 00     00 00 00 00
................

          data_crc        padding         ----------seq_num----------
00021860: 00 00 00 00     00 00 00 00     00 00 00 00     00 7e 0c ad
.............~..

          ------------------padding------------------     ----crc----
00021870: 00 00 00 00     00 00 00 00     00 00 00 00     bc b0 9f 45
...............E

00021880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
...empty...
00021ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
```

It doesn't look 100% perfect, but it does start with the "UBI!" magic
and apparently has a CRC32 at the end.

If I go to 0x1000 offset from the start, it looks like it could be a
data block, but I haven't gotten far enough to know what that's
supposed to look like yet. I'm still working through the headers.

I haven't dug super deep into the RFC or docs just yet, just the list
of headers. But I thought maybe somebody here with a deeper knowledge
might tell me if I'm on the right track.

Can anybody help me understand what I'm looking at? And how I can
either mount or extract this?

Thanks!

Re: Having trouble with a UBI filesystem

[Emil Lenngren]

Hi Ron,

Den tors 3 jan. 2019 kl 20:52 skrev Ron Bowes <ron@skullsecurity.net>:
>
> Hey Linux-mtd folks,
>
> I'm a security consultant that does a variety of different consulting
> work for our customers. In my current project, I'm trying to read a
> UBI filesystem from a flash-chip dump, but I'm having a lot of
> trouble. I've tried to use both the MTD userland tools (from you
> folks) and ubi-reader (from https://github.com/jrspruitt/ubi_reader).
>
> I'm struggling to understand the filesystem, and it seems to be - at
> least initially - because the VID header is offset by 0x40 bytes from
> where I think it should be. I was wondering if anybody recognizes
> what's going on here, and can help point me in the right direction?
>
> I've been working directly on the file dump in a hex editor right now,
> and I see why the tools are struggling, but I don't understand why.
>
> In the image, the block sizes are 0x21000 bytes, the VID header is at
> offset 0x800, and the data offset is 0x1000. The first block is empty,
> but here's the second EB block header:
>
> ```
>           ---magic---     ver -  -  -     --------- EC --------------
> 00021000: 55 42 49 23     01 00 00 00     00 00 00 00     00 00 10 0d
> UBI#............
>           vid_hdr_off     data_offset     -image_seq-     --padding--
> 00021010: 00 00 08 00     00 00 10 00     8b 19 3b a0     00 00 00 00
> ..........;.....
>           --------------------------padding--------------------------
> 00021020: 00 00 00 00     00 00 00 00     00 00 00 00     00 00 00 00
> ................
>           -----------------padding-------------------     ----crc----
> 00021030: 00 00 00 00     00 00 00 00     00 00 00 00     c4 b3 6f 75
> ..............ou
>
> 00021040: 00 00 00 00     00 00 00 00     00 00 00 00     00 00 00 00
> ................
> ...empty...
> 000217f0: 00 00 00 00     00 00 00 00     00 00 00 00     00 00 00 00
> ................
> ```
>
> That all looks legit. It lists the vid_hdr_offset as 0x800, and the
> data_offset at 0x1000. Looks good so far!
>
> If I fast forward to 0x800 bytes into the block, where I'd expect to
> see the VID header, I see:
>
> ```
> 00021800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
> 00021810: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
> 00021820: 12 2e e1 ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
> 00021830: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
> ```
>
> It appears that the checksum is set, but nothing else at all,
> including the 'magic'. However, if I go an additional 0x40 bytes to
> 0x840 from the start of the block, I see what appears to be a UBI VID
> header (starts with 'UBI!'):
>
> ```
>                              type  compat
>           ---magic---     ver   copy      --vol_id---     ---lnum----
> 00021840: 55 42 49 21     01 01 00 00     00 00 00 00     00 00 01 18
> UBI!............
>
>           ----pad----     -data_size-     -used_ebs--     data_padding
> 00021850: 00 00 00 00     00 00 00 00     00 00 00 00     00 00 00 00
> ................
>
>           data_crc        padding         ----------seq_num----------
> 00021860: 00 00 00 00     00 00 00 00     00 00 00 00     00 7e 0c ad
> .............~..
>
>           ------------------padding------------------     ----crc----
> 00021870: 00 00 00 00     00 00 00 00     00 00 00 00     bc b0 9f 45
> ...............E
>
> 00021880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> ...empty...
> 00021ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> ```
>
> It doesn't look 100% perfect, but it does start with the "UBI!" magic
> and apparently has a CRC32 at the end.
>
> If I go to 0x1000 offset from the start, it looks like it could be a
> data block, but I haven't gotten far enough to know what that's
> supposed to look like yet. I'm still working through the headers.
>
> I haven't dug super deep into the RFC or docs just yet, just the list
> of headers. But I thought maybe somebody here with a deeper knowledge
> might tell me if I'm on the right track.
>
> Can anybody help me understand what I'm looking at? And how I can
> either mount or extract this?
>
> Thanks!

What's the flash parameters? Is it NAND or NOR? What's your page size,
oob size etc.?
Assuming you have a NAND flash, a first guess would be that your flash
chip dump contains also the pages' OOB data after every page. If your
page size is 2048 (0x800) bytes and OOB size is 64 bytes (0x40), that
would explain why the VID header is 0x40 bytes offset, since those
extra 0x40 bytes are filled with OOB data.

/Emil

Re: Having trouble with a UBI filesystem

[Richard Weinberger]

On Thu, Jan 3, 2019 at 8:52 PM Ron Bowes <ron@skullsecurity.net> wrote:
> folks) and ubi-reader (from https://github.com/jrspruitt/ubi_reader).

Last time I looked at ubi_reader I was not satisfied at all.
So I'd not recommend it. But this was over a year ago.

> Can anybody help me understand what I'm looking at? And how I can
> either mount or extract this?

Find the correct flash parameters and load the image into mtdram
or nandsim to mount it.

-- 
Thanks,
//richard

Re: Having trouble with a UBI filesystem

[Ron Bowes]

Hi Emil and Richard,

Thanks for the quick responses!

Email - It is indeed a NAND flash chip. I did some googling about OOB
data, and that looks very promising. I'll have to read up some more,
but I'm guessing this is why I'm seeing a UBI header every 0x21000
bytes instead of the more normal 0x20000 bytes - there's 0x1000 bytes
of OOB data in each block. I'll do some more reading and see if I can
eliminate that.

Richard - yeah, the tool hasn't worked well so far, but I was hoping
it'd work well enough to avoid reading kernel code. I'm definitely out
of my element!

I tried using mtdram and ubiattach, but I couldn't get it to work
right. It always complained that the data started at 0x1000 instead of
0x840, and I couldn't figure out why:

[ 5828.047122] ubi0 error: validate_ec_hdr: bad data offset 4096, expected 2112
[ 5828.047499] ubi0 error: validate_ec_hdr: bad EC header
[ 5828.047817] Erase counter header dump:
[ 5828.048099]  magic          0x55424923
[ 5828.048377]  version        1
[ 5828.048643]  ec             0
[ 5828.048911]  vid_hdr_offset 2048
[ 5828.049197]  data_offset    4096
[ 5828.049469]  image_seq      606494591
[ 5828.049747]  hdr_crc        0x9116275f

I traced my way through ubiattach, but it looks like this is a
kernel-level thing. That's when I started looking at the Python tool.

Emil's comment about OOB data might be the issue, though. Other parts
of the memory dump were unexpected sizes, as well, so I think OOB data
is probably the culprit.

Thanks!

On Thu, Jan 3, 2019 at 12:25 PM Richard Weinberger
<richard.weinberger@gmail.com> wrote:
>
> On Thu, Jan 3, 2019 at 8:52 PM Ron Bowes <ron@skullsecurity.net> wrote:
> > folks) and ubi-reader (from https://github.com/jrspruitt/ubi_reader).
>
> Last time I looked at ubi_reader I was not satisfied at all.
> So I'd not recommend it. But this was over a year ago.
>
> > Can anybody help me understand what I'm looking at? And how I can
> > either mount or extract this?
>
> Find the correct flash parameters and load the image into mtdram
> or nandsim to mount it.
>
> --
> Thanks,
> //richard

Re: Having trouble with a UBI filesystem

[Richard Weinberger]

Ron,

Am Donnerstag, 3. Januar 2019, 21:30:59 CET schrieb Ron Bowes:
> I tried using mtdram and ubiattach, but I couldn't get it to work
> right. It always complained that the data started at 0x1000 instead of
> 0x840, and I couldn't figure out why:

I suggest using nandsim, since this is a NAND image.

Find the id bytes if the NAND chip and pass them to nandsim, then use ubiattach.
It has a "-O" parameter to set the offset of the VID header yourself.
This is often needed when the sub-page configuration is different.
 
Thanks,
//richard

Re: Having trouble with a UBI filesystem

[Ron Bowes]

I hadn't heard of nandsim, I'll take a look!

I was using -O for the VID header, but ubiattach was complaining about
data_offset being unusual.

It's probably the OOB data, though, so nandsim may fix all my problems.

Thanks so much!

On Thu, Jan 3, 2019 at 12:34 PM Richard Weinberger <richard@nod.at> wrote:
>
> Ron,
>
> Am Donnerstag, 3. Januar 2019, 21:30:59 CET schrieb Ron Bowes:
> > I tried using mtdram and ubiattach, but I couldn't get it to work
> > right. It always complained that the data started at 0x1000 instead of
> > 0x840, and I couldn't figure out why:
>
> I suggest using nandsim, since this is a NAND image.
>
> Find the id bytes if the NAND chip and pass them to nandsim, then use ubiattach.
> It has a "-O" parameter to set the offset of the VID header yourself.
> This is often needed when the sub-page configuration is different.
>
> Thanks,
> //richard
>
>
>

Re: Having trouble with a UBI filesystem

[Richard Weinberger]

Ron,

Am Donnerstag, 3. Januar 2019, 21:35:46 CET schrieb Ron Bowes:
> I hadn't heard of nandsim, I'll take a look!
> 
> I was using -O for the VID header, but ubiattach was complaining about
> data_offset being unusual.

Yeah, I bet this was due to the simulated NOR chip. NOR does not have OOB.
 
> It's probably the OOB data, though, so nandsim may fix all my problems.

:-)

Thanks,
//richard

Re: Having trouble with a UBI filesystem

[Ron Bowes]

Hey folks,

Thanks for the pointers! I removed all the OOB data, which gave me a
pristine dump. I was able to extract other stuff (like the kernel and
boot image) once that was all removed. I also grabbed a clean dump of
the UBI filesystem, without all the OOB stuff.

Once that was done, I used ubi_reader to convert it to a ubifs (I'm
sure I could have done that with mtdtools as well).

Then I used this guide, pretty much as-is, to mount it:

http://www.linux-mtd.infradead.org/faq/ubifs.html#L_ubifs_extract

Thanks so much for your help!


Ron

On Thu, Jan 3, 2019 at 12:41 PM Richard Weinberger <richard@nod.at> wrote:
>
> Ron,
>
> Am Donnerstag, 3. Januar 2019, 21:35:46 CET schrieb Ron Bowes:
> > I hadn't heard of nandsim, I'll take a look!
> >
> > I was using -O for the VID header, but ubiattach was complaining about
> > data_offset being unusual.
>
> Yeah, I bet this was due to the simulated NOR chip. NOR does not have OOB.
>
> > It's probably the OOB data, though, so nandsim may fix all my problems.
>
> :-)
>
> Thanks,
> //richard
>
>