ubireader_display_info displays information about the ubi file but I can't extract them

[onekey-sec]

ubireader_display_info displays information about the ubi file but I can't extract them

[jrspruitt]

Did you remove the OOB data from the NAND dump? The size and placement will depend on your NAND chip. If so you might try extracting the UBIFS images, and making sure UBIFS was used as iirc different file systems are possible on top of UBI. You might also try the -w flag which might get you through if there is corrupted data, which is another possibility, there is no error correction (EEC) when dumping the NAND, it is possible there are some bad bits.

…

-Jason

On Mon, Feb 17, 2020 at 2:22 AM DMirror ***@***.***> wrote: Hello Jason, I have a problem here and wanted to ask you if you might know what I can do to fix this. I dumped the content of a NAND flash. Binwalk extracted an ubi file from the dump and when I used ubireader_display_info I got the following output: `UBI File Min I/O: 2048 LEB Size: 126976 PEB Size: 131072 Total Block Count: 847 Data Block Count: 377 Layout Block Count: 2 Internal Volume Block Count: 468 Unknown Block Count: 0 First UBI PEB Number: 10 Image: 1681423409 --------------------- Image Sequence Num: 1681423409 Volume Name:spare Volume Name:data1 Volume Name:root1 Volume Name:root0 Volume Name:data0 PEB Range: 0 - 855 Volume: spare --------------------- Vol ID: 4 Name: spare Block Count: 142 Volume Record --------------------- alignment: 1 crc: '0x743003a9' data_pad: 0 errors: '' flags: 0 name: u'spare' name_len: 5 padding: u'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' rec_index: 4 reserved_pebs: 386 upd_marker: 0 vol_type: 'dynamic' Volume: data1 --------------------- Vol ID: 3 Name: data1 Block Count: 8 Volume Record --------------------- alignment: 1 crc: '0xefc3e0d' data_pad: 0 errors: '' flags: 0 name: u'data1' name_len: 5 padding: u'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' rec_index: 3 reserved_pebs: 34 upd_marker: 0 vol_type: 'dynamic' Volume: root1 --------------------- Vol ID: 1 Name: root1 Block Count: 110 Volume Record --------------------- alignment: 1 crc: '0x4a7089bd' data_pad: 0 errors: '' flags: 0 name: u'root1' name_len: 5 padding: u'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' rec_index: 1 reserved_pebs: 232 upd_marker: 0 vol_type: 'dynamic' Volume: root0 --------------------- Vol ID: 0 Name: root0 Block Count: 108 Volume Record --------------------- alignment: 1 crc: '0x38a2ed27' data_pad: 0 errors: '' flags: 0 name: u'root0' name_len: 5 padding: u'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' rec_index: 0 reserved_pebs: 232 upd_marker: 0 vol_type: 'dynamic' Volume: data0 --------------------- Vol ID: 2 Name: data0 Block Count: 9 Volume Record --------------------- alignment: 1 crc: '0x7c2e5a97' data_pad: 0 errors: '' flags: 0 name: u'data0' name_len: 5 padding: u'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' rec_index: 2 reserved_pebs: 34 upd_marker: 0 vol_type: 'dynamic'` This looked promising to me. The problem is when I try to extract the files with ubireader_extract_files I receive an error message: Extracting files to: ubifs-root/1681423409/spare extract_files Error: No inodes found Extracting files to: ubifs-root/1681423409/data1 read Error: LEB: 10 is corrupted or has no data. extract_files Error: 1 UBIFS Fatal: Super block error: Wrong node type. Is it possible that the dump itself is incomplete and if that is the case can I do something to extract files anyways without having to dump it again? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#35>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGV2GPHQT6434PNK3Z7FNLRDJQPDANCNFSM4KWOU2YQ> .

[DMirror]

Hello Jason,

I removed the OOB Bytes before using the tool and I also used the -w flag. The error message that you can see in my first post was the output with -w flag.
As far as my knowledge goes the filesystem that is used on top of UBI is SquashFS.
To be more specific the idea is to get the content of the SquashFS filesystem but I can't extract the files because it is on top of ubi which seems to be a problem for unsquash and sasquatch.

Also the NAND flash that I work with has internal ECC enabled. In the datasheet it sais "During a READ operation, the page data is read from the array to the cache register, where the ECC code is calculated and compared with the ECC code value read from the array. If error bits are detected, the error is corrected in the cache register. Only corrected data is output on the I/O bus."
Since the NAND flash is powered up and I perform several read operations to dump the conent this should be not an issue I guess.

Do you think that the tools from the test branch could deal with this problem?

[jrspruitt]

Hi, Okay you should be able to just use the extract images script, and get a SquashFS image, ubi_reader can't handle it, so you'll have to use some other way of extracting the files from those images. As for ECC I believe it is possible but I'm not familiar enough with it, to say how to do it.

…

-Jason

On Tue, Feb 25, 2020 at 12:37 AM DMirror ***@***.***> wrote: Hello Jason, I removed the OOB Bytes before using the tool and I also used the -w flag. As far as my knowledge go the filesystem that is used on top of UBI is SquashFS. In case there are some bad bits, is there a way to correct these afterwards? ECC Bits should be in the OOB area right? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#35>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGV2GL3BXN3SFXD5VOCVMDRETKF5ANCNFSM4KWOU2YQ> .

[DMirror]

Hey,

thank you fo your help. I could use the extract images script and I found indeed a SquashFS filesystem within.
Still having trouble in reading it but that is an other problem.
Thank you for your time.