Issue #2025: Enable to recreate the EFS partition completely from scratch
Investigate the creation of nv_data.bin by the nonfree RIL
Currently, stock Android operating systems are able to recreate nv_data.bin and similar files inside the EFS partition. They are also able to fix or use corrupted nv_data.bin files.
In such situation the user is required to temporarily reinstall an android distribution that is able to do that, and then reinstall Replicant. To avoid the temporary usage of non-free software and make Replicant more robust, it would be nice to fix this issue.
Updated by Kurtis Hanna 9 months ago
This xda post from last year might be helpful for this: https://forum.xda-developers.com/galaxy-s3/orig-development/official-lineageos-14-1-i9300-t3544531/post75981429#post75981429
Updated by Denis 'GNUtoo' Carikli 3 months ago
I didn't understand where the interesting part was in that link.
In any case I've advanced a bit on this.
I've a Galaxy S that I need t fix as I need it for libsamsung-ipc work as we intend to continue supporting it in libsamsung-ipc but not in Replicant.
I don't know if I messed up and completely lost the EFS data or if it was like that when it was shipped to me (more likely).
- I've done tests with it and so far the proprietary RIL is able to recreate some files in /efs/ however if you do that you end up with a default IMEI (004999010640000).
- I've done some research on the modem firmware by reading libsamsung-ipc and looking at firmware headers, and I found that there is a NV partition inside the modem firmware. I've documented it in the Modem-partitions section of the XMMBoot page
So the next step would be to check if this NV partition is similar to the data that is created in the efs partition.
Updated by Denis 'GNUtoo' Carikli about 1 month ago
- Remove the GSM antenna and the SIM card to reduce the amount of sources of information that can result in the EFS being updated, and/or block and/or log the EFS update from the RFS protocol by patching the kernel.
- remove the nv_data.bin (after a good backup of course) and prevent access to the /efs filesystem after boot
- mount a local or remote filesystem backed by a log based filesystem to be able to easily reconstruct all the operations
- restart the ril through strace to validate that the NV partition is being copied later on
- Give back the permissions to write nv_data.bin, make sure that no nv_data.bin is present
- wait a bit for the file to be created
- recover and diff the various version of the nv_data file through the log based filesystem utilities
update: we can also block or log RFS messages
Updated by Denis 'GNUtoo' Carikli 2 days ago
I've tried something faster on a Galaxy S (GT-I9000).
As libsamsung-ipc checks for the size of nv_data.bin, I did that:
$ adb shell "rm /efs/nv_data.bin /efs/nv_data.bin/md5 /efs/.nv_data.bak /efs/.nv_data.bak.md5" $ ddrescue -s 2097152 /dev/zero zero.bin $ ./nv_data-md5 zero.bin 5293814414abb3831e3fc1a1b35e69bc $ adb push zero.bin /efs/nv_data.bin $ adb shell "echo -n 5293814414abb3831e3fc1a1b35e69bc > /efs/nv_data.bin.md5" $ adb shell "killall rild"
Then I wait several seconds and observe the message flowing in logcat -b radio
$ adb pull /efs/nv_data.bin ./ $ strings nv_data.bin
And I can observe the similar strings than with the nv_data.bin having been recreated by LineageOS.
Updated by Denis 'GNUtoo' Carikli 2 days ago
- File radio_efs_5293814414abb3831e3fc1a1b35e69bc.log radio_efs_5293814414abb3831e3fc1a1b35e69bc.log added
Here's the log after that.
In libsamsung-ipc and libsamsung-ril, many RFS commands are unimplemented.
The SamsungGalaxyBackdoor wiki page lists the following commands:
IPC_RFS_READ_FILE IPC_RFS_WRITE_FILE IPC_RFS_LSEEK_FILE IPC_RFS_CLOSE_FILE IPC_RFS_PUT_FILE IPC_RFS_GET_FILE IPC_RFS_RENAME_FILE IPC_RFS_GET_FILE_INFO IPC_RFS_UNLINK_FILE IPC_RFS_MAKE_DIR IPC_RFS_REMOVE_DIR IPC_RFS_OPEN_DIR IPC_RFS_READ_DIR IPC_RFS_CLOSE_DIR IPC_RFS_OPEN_FILE IPC_RFS_FTRUNCATE_FILE IPC_RFS_GET_HANDLE_INFO IPC_RFS_CREATE_FILE
However we only have IPC_RFS_NV_READ_ITEM and IPC_RFS_NV_WRITE_ITEM implemented in libsamsung-ril and libsamsung-ipc (grepping IPC.*RFS only show these two commands).
In addition log would print command=0x for inimplemented commands as seen in ipc_utils.c .
Since we don't see command=0x in the log, the modem firmware probably doesn't try to open files and do things on its own when the IMEI is invalid. So we probably need to dig deeper as the nonfree ril most probably has code to detect a problematic IMEI and react to it by dialoging with the modem firwmare.
In some other devices there is a .imei or similar files in the /efs/ somewhere, and XDA forums explain that with that, after some level of corruption, it's sometimes possible to somehow repair/recreate the EFS with that .imei.