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 almost 4 years ago. Updated 9 months ago.

Telephony and mobile data
Target version:
Start date:
Due date:
% Done:


Estimated time:
Type of work:
C programming


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 Denis 'GNUtoo' Carikli over 1 year ago

  • Parent task set to #2025

Updated by Denis 'GNUtoo' Carikli over 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.


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

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


Updated by Denis 'GNUtoo' Carikli over 1 year 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
$ 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 over 1 year ago

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:


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.


Updated by _I3^ RELATIVISM 9 months ago

  • Type of work C programming added

Also available in: Atom PDF