MTK: CCCI FS NVD_IMEI read fails, causing restore, leading to NVRAM_LOC_BIN_REGION_RESTORE_FAIL assert

[theradicalcentrist40]

I have been experimenting with a known good Mediatek firmware image and nvdata pulled from the compatible phone. At a certain stage in the execution there are a number of NVRAM ASSERT ERROR NVRAM_LOC_BIN_REGION_RESTORE_FAIL warnings, followed by Panda being called to dump the CPU state to screen. hw_write() is then called which asserts false as the value passed to it is equal to the number of offsets in the ring buffer.

Example log lines for NVRAM ASSERT ERROR:

[106.66529][NO_TASK] 0x90be9145 NVRAM ASSERT ERROR NVRAM_LOC_BIN_REGION_RESTORE_FAIL:6
[106.66621][NO_TASK] 0x90be9155 LID:1473, total_records:1, record_size:12290
[106.66681][NO_TASK] 0x90be9161 category:1000, attr:0
[106.66739][NO_TASK] 0x90be9171 fileprefix:FT02, fileverno:000

After the CPU state dump, the following log lines are printed before the exception in hw_write() is thrown:

[DEBUG] firmwire.hw.peripheral.PCCIF_Periph.PCCIF0_MD: PCCIF write TCHNUM 10
[�[1;31mERROR�[0m] firmwire.hw.peripheral.PCCIF_Periph.PCCIF0_MD: PCCIF ring no too large (value: 16, is only: 16)

I am testing this with the Samsung A41, and I have tested it with a number of the example firmware images you have provided.

I have attached the output log with debug information for PCCIF0_MD. Any hints at what is causing this exception to be thrown?
Crash_Log_FirmWire_PCCIF0_MD.txt.txt

[grant-h]

Thanks for opening this issue.

It looks like in your NV data the IMEI file may be missing or corrupt!

[5.95325][NO_TASK] 0x90159503 [CCCI_FS CMPT_Read] filename: Z:\NVRAM\NVD_IMEI\NV01A000
[5.95331] last message matched ban pattern 'CCCI_FS'
[DEBUG] firmwire.hw.peripheral.PCCIF_Periph.PCCIF0_MD: PCCIF write TCHNUM 4
[DEBUG] firmwire.hw.peripheral.PCCIF_Periph.PCCIF0_MD: incoming packet channel e
[DEBUG] firmwire.hw.peripheral.PCCIF_Periph.PCCIF0_MD: RCHNUM 0
[DEBUG] firmwire.hw.peripheral.PCCIF_Periph.PCCIF0_MD: PCCIF write TCHNUM 4
[DEBUG] firmwire.hw.peripheral.PCCIF_Periph.PCCIF0_MD: incoming packet channel e
[DEBUG] firmwire.hw.peripheral.PCCIF_Periph.PCCIF0_MD: RCHNUM 0
[6.14708] 24 total log lines omitted [NO_TASK=24]
[6.14721][NO_TASK] 0x90288825 Read Multiple Result: LID=622254e4, drv_status=ffff0000, fat_status=0, line=915660e8 [IO_READ_DATA_ITEM_MULTIPLE]
[DEBUG] firmwire.hw.peripheral.PCCIF_Periph.PCCIF0_MD: PCCIF write TCHNUM 4
[DEBUG] firmwire.hw.peripheral.PCCIF_Periph.PCCIF0_MD: incoming packet channel e
[DEBUG] firmwire.hw.peripheral.PCCIF_Periph.PCCIF0_MD: RCHNUM 0
[DEBUG] firmwire.hw.peripheral.PCCIF_Periph.PCCIF0_MD: PCCIF write TCHNUM 4
[DEBUG] firmwire.hw.peripheral.PCCIF_Periph.PCCIF0_MD: incoming packet channel e
[DEBUG] firmwire.hw.peripheral.PCCIF_Periph.PCCIF0_MD: RCHNUM 0
[6.26487] 23 total log lines omitted [NO_TASK=23]
[6.26501][NO_TASK] 0x90288825 Read Multiple Result: LID=62225544, drv_status=b, fat_status=0, line=915660e8 [IO_READ_DATA_ITEM_MULTIPLE]
[6.26728] 1 total log lines omitted [NO_TASK=1]

As a result the modem tried to restore it from backup, but the restore command for the CCCI FS interface is not currently implemented:

[WARN] firmwire.hw.peripheral.SHM_CCIF_Periph.SharedMemoryCCIF.FSD: Restore: /firmware/md1img.img_workspace/ccci_nvdatabngcbfvf/mnt/vendor/nvdata/md/NVRAM/NVD_IMEI/FILELIST stub!
[DEBUG] firmwire.hw.peripheral.PCCIF_Periph.PCCIF0_MD: RCHNUM 0
[DEBUG] firmwire.hw.peripheral.PCCIF_Periph.PCCIF0_MD: PCCIF write TCHNUM 4
[DEBUG] firmwire.hw.peripheral.PCCIF_Periph.PCCIF0_MD: incoming packet channel e
[DEBUG] firmwire.hw.peripheral.PCCIF_Periph.PCCIF0_MD: RCHNUM 0
[121.09565] 72 total log lines omitted [NO_TASK=72]
[121.09579][NO_TASK] 0x90288825 Read Multiple Result: LID=62225564, drv_status=3, fat_status=0, line=915660e8 [IO_READ_DATA_ITEM_MULTIPLE]
[121.09664][NO_TASK] 0x90be9145 NVRAM ASSERT ERROR NVRAM_LOC_BIN_REGION_RESTORE_FAIL:6

Finally it throws a fatal assert for NVRAM_LOC_BIN_REGION_RESTORE_FAIL.

What I think might be happening is that the IMEI may be encrypted or authenticated against the chip-unique key (to protect it against tampering). This could be causing the IMEI read to fail security checks, leading to the restoration. FirmWire does not currently emulate the chip-unique key. This makes me wonder why previous NV data we used did not experience this problem. Maybe the IMEI was not protected?

[Matheus-Garbelini]

@grant-h can you provide some nv data for any mediatek phone? We would like to try a few samples, but it's difficult to find an image online which has nvdata partition included.

[grant-h]

@grant-h can you provide some nv data for any mediatek phone? We would like to try a few samples, but it's difficult to find an image online which has nvdata partition included.

Unfortunately any NV data I provide would have personal information since it's unique per device. My best recommendation is to purchase a mediatek device, root it (or use MTKClient), and extract the NV partition