Parsing extracted i.MX NAND flash

[Zhihao Cheng]

在 2024/11/22 2:15, Rogan Dawes 写道:
> On Thu, Nov 21, 2024 at 12:42:16PM +0800, Zhihao Cheng wrote:
>> ? 2024/11/20 23:51, Rogan Dawes ??:
>>> On Mon, Nov 18, 2024 at 07:39:39PM +0200, Rogan Dawes wrote:
>>>> Hi folks,
>>>>
>>>> I have an i.MX6 target I am trying to get a shell on. It is using High
>>>> Assurance Boot and various other configurations to prevent this. My
>>>> current approach is to remove the flash, extract the filesystems, modify
>>>> one that is not subject to HAB, then put it all back, in order to enable
>>>> a shell.
>>>>
>>>> I have removed the flash, and extracted its contents using an Xgecu
>>>> flash reader. Now I need to parse the FCB and extract the actual data
>>>> from the dump. I have found imx-nand-tools, but this doesn't work due to
>>>> bitrot (the bchlib dependency has moved on while imx-nand-tools has not
>>>> been updated).
>>>
>>> I was able to get imx-nand-tools working by pinning the version of the
>>> bchlib dependency to v0.14.0, and have been able to obtain a "clean"
>>> flash image. Still trying to mount the various UBI filesystems, as I get
>>> the following errors:
>>>
>>> [360972.710050] ubi0: default fastmap pool size: 8
>>> [360972.710055] ubi0: default fastmap WL pool size: 4
>>> [360972.710056] ubi0: attaching mtd5
>>> [360972.710099] ubi0 error: validate_ec_hdr [ubi]: bad VID header offset 2048, expected 512
>>
>> Hi Rogan,
>> How did you use ubiattach? ubiattach -O 512?  Try 'ubiattach -O2048'.
> 
> Hi,
> 
> I simply ran it without any specific offset options:
> 
> sudo ubiattach -m 5
> 
> which produced the panic in my previous mail..
> 
> If I try with -O 2048, this is what I get:
> 
> $ sudo ubiattach -O 2048 -m 5
> [sudo] password for rogan:
> ubiattach: error!: cannot attach mtd5
>             error 22 (Invalid argument)
> 
> [614006.620517] ubi0: default fastmap pool size: 8
> [614006.620520] ubi0: default fastmap WL pool size: 4
> [614006.620521] ubi0: attaching mtd5
> [614006.620749] ubi0: scanning is finished
> [614006.620787] ubi0 error: vtbl_check [ubi]: bad CRC at record 11: 0xc8e5abb1, not 0xf116c36b
> [614006.620816] Volume table record 11 dump:
> [614006.620818] 	reserved_pebs   0
> [614006.620819] 	alignment       0
> [614006.620820] 	data_pad        0
> [614006.620821] 	vol_type        0
> [614006.620834] 	upd_marker      0
> [614006.620835] 	name_len        0
> [614006.620836] 	name            NULL
> [614006.620838] ubi0 error: vtbl_check [ubi]: bad CRC at record 11: 0xc8e5abb1, not 0xf116c36b
> [614006.620848] Volume table record 11 dump:
> [614006.620849] 	reserved_pebs   0
> [614006.620850] 	alignment       0
> [614006.620851] 	data_pad        0
> [614006.620852] 	vol_type        0
> [614006.620852] 	upd_marker      0
> [614006.620853] 	name_len        0
> [614006.620854] 	name            NULL
> [614006.620855] ubi0 error: process_lvol [ubi]: both volume tables are corrupted
> [614006.620872] ubi0 error: ubi_attach_mtd_dev [ubi]: failed to attach mtd5, error -22
> 

Above messages means that:
1. The UBI has scanned all PEBs, which is failed in previous mail.
2. The UBI cannot find a valid layout volume, the layout volume has two 
LEBs, both of them are corrupted(data in LEB is not correct, crc 
verifying fails).
> Regards,
> 
> Rogan
> 
> .
>