Project

General

Profile

Issue #1869

Issue #2025: Enable to recreate the EFS partition completely from scratch

Investigate the creation of nv_data.bin by the nonfree RIL

Added by Denis 'GNUtoo' Carikli over 3 years ago. Updated 3 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Telephony and mobile data
Target version:
Replicant 6.0
Start date:
04/21/2020
Due date:
% Done:

0%

Estimated time:
Resolution:
Device:
Grant:
Type of work:
C programming

Description

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.

Files

radio_efs_5293814414abb3831e3fc1a1b35e69bc.log (298 KB) radio_efs_5293814414abb3831e3fc1a1b35e69bc.log Denis 'GNUtoo' Carikli, 07/08/2020 02:03 PM
#2

Updated by Denis 'GNUtoo' Carikli about 1 year ago

  • Parent task set to #2025
#3

Updated by Denis 'GNUtoo' Carikli about 1 year 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.

#4

Updated by Denis 'GNUtoo' Carikli about 1 year ago

  • Subject changed from Investigate, and avoid/recover from EFS corruptions. to Investigate the creation of nv_data.bin by the nonfree RIL
#5

Updated by Denis 'GNUtoo' Carikli about 1 year ago

It might be a good idea to try the following approach:
  • 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

#6

Updated by Denis 'GNUtoo' Carikli 12 months 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

Then:

$ 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.

#7

Updated by Denis 'GNUtoo' Carikli 12 months ago

Here's the log after that.

Notes

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.

#8

Updated by _I3^ RELATIVISM 3 months ago

  • Type of work C programming added

Also available in: Atom PDF