Investigation: Recovering EFS after TWRP restore

[tennear]

WARNING: Do NOT use TWRP to restore EFS!

Several people have used TWRP to do a backup and restore of EFS, and rendered their phone's mobile settings invalid. This is typically indicated by cellular data not working and/or invalid IMEI.

This thread will attempt to find out how to restore these devices to a functional state. We will need help from the community to make this successful! Please read through the thread and try to help with any requests.

WARNING: Do NOT use TWRP to restore EFS!

To backup your EFS data for safe keeping or sending to someone, do the following:

1. Boot into TWRP (any version).
2. Backup:

adb shell dd if=/dev/block/bootdevice/by-name/modemst1 of=/tmp/modemst1.img
adb shell dd if=/dev/block/bootdevice/by-name/modemst2 of=/tmp/modemst2.img

3. Pull the files:

adb pull /tmp/modemst1.img
adb pull /tmp/modemst2.img

Now you should have the backup files on your PC. They should each be exactly 2097152 bytes long. DO NOT share these files with anyone that you don't trust.

 

[tennear]

Okay so the first thing to note is that the signed TWRP provided by tenfar has an error in the EFS backup procedure. From the backup log:

Backing up EFS...
I:Reading '/dev/block/sdf1', writing '/data/media/0/TWRP/BACKUPS/.../efs1.emmc.win'
Backing up efs2...
I:Reading '/dev/block/sdf2', writing '/data/media/0/TWRP/BACKUPS/.../efs1.emmc.win'

Note that it read sdf1 (aka modemst1), placing the backup into efs1.emmc.win. Then it read sdf2 (aka modemst2), also placing the backup into efs1.emmc.win. In other words, sdf1 data was overwritten and lost.

I am looking into what is in each of these partitions and how to best recover.

 

[gpz1100]

The twrp in question is different from the 'unofficial' twrp, correct?

I have this one installed on my phone

12/03/2016 15:12 17,932,169 twrp-recovery-3.0.2-2.zip

​

I believe this is the unofficial one?

 

[tennear]

The twrp in question is different from the 'unofficial' twrp, correct?

I have this one installed on my phone

12/03/2016 15:12 17,932,169 twrp-recovery-3.0.2-2.zip

​

I believe this is the unofficial one?

I can't say which is which. But regardless of the version you are using, the safest option is to never backup and restore EFS using TWRP.

 

[gpz1100]

Agreed. There's really no reason one should be messing/touching the EFS partition in the first place. I'm not sure why it was included. The only partitions needed for a successful backup include those below.

• Boot
• System
• Data

 

[tennear]

Alright, so the first thing I think we'll need is two known working backups of the EFS data for each model. I have a U model so if I can get a backup from someone else's U model, I can compare. This will provide some insight on where the IMEI is stored.

 

[Velrix]

Just a thought here, back when I had my original Galaxy S we had an issue with the EFS partition getting destroyed all the time. We almost always get a clean backup as a "just in case". However if you ever did a factory restore, meaning using Odin on that phone your EFS would always be restored. Is there any factory restore images for this phone that work in the same fashion?

 

[tennear]

Just a thought here, back when I had my original Galaxy S we had an issue with the EFS partition getting destroyed all the time. We almost always get a clean backup as a "just in case". However if you ever did a factory restore, meaning using Odin on that phone your EFS would always be restored. Is there any factory restore images for this phone that work in the same fashion?

Nope, not that I am aware of anyway. But I could possibly make one. It's a good idea. But first I want to see about helping people that have corrupted EFS.

 

[Velrix]

Nope, not that I am aware of anyway. But I could possibly make one. It's a good idea. But first I want to see about helping people that have corrupted EFS.

Ya, the issue you will face here is TWRP overwriting the original backup image with the second blob. The only fix is going to be finding the location of the IMEI inside that initial file and doing a manual change possibly without it being something the backup files would replace naturally. The problem here is the legality, while you are replacing the IMEI with the one original to the phone something like this being published would/could be used maliciously as well.

Has any of the users affected by this tried to roll back to a completely stock phone, removing TWRP?

 

[Controllerboy]

Ya, the issue you will face here is TWRP overwriting the original backup image with the second blob. The only fix is going to be finding the location of the IMEI inside that initial file and doing a manual change possibly without it being something the backup files would replace naturally. The problem here is the legality, while you are replacing the IMEI with the one original to the phone something like this being published would/could be used maliciously as well.

Has any of the users affected by this tried to roll back to a completely stock phone, removing TWRP?

I am sadly affected by this mishap on an otherwise brilliant phone.
I have not tried this. I have re-flashed completely to stock, but didn't relock my BL and/or remove TWRP. I do not know a lot about these matters, but tbh I don't see why that would help us, flashing the stock recovery back would only change the recovery partition, amirite?

Here's a thankful plea from an affected user. Please share a valid EFS partition backup with @tennear, @Tebor, @jcadduono or myself. We are NOT going to mess around with your IMEI or other data, we just want to try to help out ourselves and provide a future reference for people who happen to be in the same situation. THANK YOU. ETERNAL RESPECT.

 

[celoxocis]

This is weird. I never run across this issue?
Are maybe only A2017G affected?

I'm still on Tenfar's TWRP and due to habits I always creat a full backup. Meaning I included the EFS partitions.
While working on my own Axon-7 CM bring-up I have probably flashed my CM (while working on my bring-up) and restored those affected partitions like 20x times and never experienced above problems.

I'm on B29 stock. I just went into about phone to see if my IMEI's are listed. Everything is fine.

 

[gpz1100]

I extracted my efs partitions to the sd card. Appears there are 5 blocks that make up the sdf block devices.

[email protected]_ii:/sdcard # dd if=/dev/block/sdf1 of=/sdcard/efs1.img bs=4096
dd if=/dev/block/sdf1 of=/sdcard/efs1.img bs=4096
512+0 records in
512+0 records out
2097152 bytes transferred in 0.015 secs (139810133 bytes/sec)
[email protected]_ii:/sdcard # dd if=/dev/block/sdf2 of=/sdcard/efs2.img bs=4096
dd if=/dev/block/sdf2 of=/sdcard/efs2.img bs=4096
512+0 records in
512+0 records out
2097152 bytes transferred in 0.007 secs (299593142 bytes/sec)
[email protected]_ii:/sdcard # dd if=/dev/block/sdf3 of=/sdcard/efs3.img bs=4096
dd if=/dev/block/sdf3 of=/sdcard/efs3.img bs=4096
1+0 records in
1+0 records out
4096 bytes transferred in 0.008 secs (512000 bytes/sec)
[email protected]_ii:/sdcard # dd if=/dev/block/sdf4 of=/sdcard/efs4.img bs=4096
dd if=/dev/block/sdf4 of=/sdcard/efs4.img bs=4096
128+0 records in
128+0 records out
524288 bytes transferred in 0.008 secs (65536000 bytes/sec)
[email protected]_ii:/sdcard # dd if=/dev/block/sdf of=/sdcard/efs.img bs=4096
dd if=/dev/block/sdf of=/sdcard/efs.img bs=4096
10240+0 records in
10240+0 records out
41943040 bytes transferred in 0.212 secs (197844528 bytes/sec)

Appears efs3 and efs4 are blank inside (just 00's). Efs, efs1, efs2 do contain data. Search all of them using a hex editor for either of the two imei's resulted in nothing. From past flashing, I know these are sometimes stored in a backward manner. Tried searching for that too with no luck. My guess is if the imei is stored in one of these files, it's in an encrypted manner.

Hash checksums for my files are below:

  File: efs4.img
CRC-32: 95d0e631
   MD4: 06be904db85f2f54e2cfe3ed65c11311
   MD5: 06f49b34524d523cbd925c2fa6fa27bf
 SHA-1: 7da5cedafe502f32a68ee9fb7a98433e71c2cf13

  File: efs3.img
CRC-32: 9adc2b3a
   MD4: 4075c3bfd61127e287dbb5c92a7e04fb
   MD5: 778800e21d5e0d70ae337c730b2d5e18
 SHA-1: 1ac72bb3eadcfa8af694ace9ebe096f97524424b

  File: efs2.img
CRC-32: eecb36a2
   MD4: 7d2f020ce6e3f1fcc8f2510fc60b5956
   MD5: a009e1cf60afdb6e03b3cb65a5695e95
 SHA-1: 76f9d21c1ef95983ff68c1ea8c771909b743fd7e

  File: efs1.img
CRC-32: 518ab8df
   MD4: e26a4c53061102537a868826e56e22e2
   MD5: 913ac8e53227eb6eadbaf0054c2e9092
 SHA-1: e9be6f2cd08e7a0fe2a7326920a920aefd064cb8

  File: efs.img
CRC-32: 7603f894
   MD4: 105bbc7d6d3d082c38d7bc25a7a3c02e
   MD5: 3b89d12ee514bbaa4dae27fd180237c3
 SHA-1: d8d260b860781c5da48f70c98c42c2c49d8f94f6

 

[Velrix]

I am sadly affected by this mishap on an otherwise brilliant phone.
I have not tried this. I have re-flashed completely to stock, but didn't relock my BL and/or remove TWRP. I do not know a lot about these matters, but tbh I don't see why that would help us, flashing the stock recovery back would only change the recovery partition, amirite?

Here's a thankful plea from an affected user. Please share a valid EFS partition backup with @tennear, @Tebor, @jcadduono or myself. We are NOT going to mess around with your IMEI or other data, we just want to try to help out ourselves and provide a future reference for people who happen to be in the same situation. THANK YOU. ETERNAL RESPECT.

I really hope I you didn't think I was implying anyone here needing this fix would be acting maliciously. I am just saying people could use it as so.

To answer your question, flashing recovery wouldn't fix that exactly, I mean getting a completely stock full image of the nand and re-flashing it.

 

[Loader009]

I extracted my efs partitions to the sd card. Appears there are 5 blocks that make up the sdf block devices.

Well, /dev/block/sdf is a device and sdf1, sdf2 etc. are partitions of that device.
If you backup the device itself, you backup all partitions within that device.
I don't know what sdf3 & sdf4 are but it appears that they are not important (as you have already stated).

There should be no need to backup the whole device but it doesn't hurt.

 

[tennear]

This is weird. I never run across this issue?
Are maybe only A2017G affected?

I'm still on Tenfar's TWRP and due to habits I always creat a full backup. Meaning I included the EFS partitions.
While working on my own Axon-7 CM bring-up I have probably flashed my CM (while working on my bring-up) and restored those affected partitions like 20x times and never experienced above problems.

I'm on B29 stock. I just went into about phone to see if my IMEI's are listed. Everything is fine.

No, the issue is definitely present. You can examine your recovery.log in your backup directory to see for yourself. You should have a file named efs1.emmc.win that is 2mb and the text that I showed in the recovery.log file.

If you have restored your EFS data and you still have functional data and IMEI, consider yourself lucky. I honestly don't know how that would be possible.

 

[Loader009]

Someone in this forum said that turning off the phone, switch the SIM to the other SIM-slot, turn on and then do it otherwise again might help...

But I am not affected, so I cannot test this.

 

[celoxocis]

No, the issue is definitely present. You can examine your recovery.log in your backup directory to see for yourself. You should have a file named efs1.emmc.win that is 2mb and the text that I showed in the recovery.log file.

If you have restored your EFS data and you still have functional data and IMEI, consider yourself lucky. I honestly don't know how that would be possible.

I've just double checked in the log.
I must have at some point in time been lucky to have switched to UDev's TWRP after having unlocked the bootloader.

As it reads:

ro.build.host=overrated
ro.build.tags=test-keys
ro.build.type=eng
ro.build.user=unjust

I doubt Tenfar's would have those flags.

I remember the subpartion restore being a bug that was fixed by TWRP. So Tenfar's build probably never included that fix. That warning should be posted in the thread he created too.

 

[tennear]

@gpz1100 the /dev/sdf "disk" contains 5 partitions:

sdf1 = modemst1 -> EFS data
sdf2 = modemst2 -> EFS data
sdf3 = fsc -> Unused?
sdf4 = ztecfg -> ZTE specific config stuff for stock ROM, unused in CM.
sdf5 = persist -> ext4 filesystem mounted as /persist, some device specific configs etc.

 

[tennear]

Update: I have one good backup of the EFS partitions from a G user. I'd like to get another to compare.

 

[Tebor]

Has any of the users affected by this tried to roll back to a completely stock phone, removing TWRP?

I have tried:

restoring stock recovery
flashing stock B02, B03, B05, B06 and B08
Flashing the small incremental updates
Flashing DrakenFX's twrp updates and bootstacks

I have swapped recoveries so many times, I can use tennear's tool with my eyes closed

Hell I've even tried flashing the U version firmware. (Nice boot animation by the way. Heaps better than the G version with the pictures :good

None of the factory firmware made any difference. Im guessing that none of the factory firmware makes changes to EFS related items
@tennear, have you had a chance to look into how this little program works --> http://en.miui.com/thread-271552-1-1.html

I can restore my imei numbers with it but it still wont connect to cellular. Funny thing is, when I restore my own numbers, enter my sim pin after rebooting, my carrier logo appears with full signal minus the 4G icon but I cannot make calls. It then proceeds cycle between my carrier and emergency calls only.

All this flashing and wiping has kind of shown me how good the Axon 7 is. I haven't had a single error nor bootlooped. It just takes everything and always boots up.