[Q] /efs recovery - Galaxy S II Q&A, Help & Troubleshooting

Very bad news.
I appear to have had an accident with /efs. Not 100% sure what I did but suspect it related to a product code change.
My SGS2 now will not show an IMEI or connect to the cell network.
I connected with /adb and saw a number of files were updated earlier today
drwxrwxr-x 5 root root 4096 Jan 1 2000 .files
drwxrwxr-x 2 radio radio 4096 Jan 1 2000 imei
-rw-rw-rw- 1 radio radio 832 Jan 1 2011 nv.log
-rw-rw-rw- 1 radio radio 1 Jan 1 2011 .nv_state
-rwx------ 1 radio radio 32 Jan 1 2011 .nv_data.bak.md5
-rwx------ 1 radio radio 2097152 Jan 1 2011 .nv_data.bak
-rwx------ 1 radio radio 32 Jan 1 2011 .nv_core.bak.md5
-rwx------ 1 radio radio 1048576 Jan 1 2011 .nv_core.bak
-rw-r--r-- 1 root root 1 Jan 1 2011 cryptprop_rebootMode
drwx------ 3 system system 4096 Jan 1 2011 dmp
-rw-r--r-- 1 system system 14 Jan 1 2011 cryptprop_persist.sys.timezone
-rw-r--r-- 1 system system 9 Jan 1 2011 cryptprop_applied_result
-rwxrwxr-- 1 radio radio 880 Jan 1 2011 redata.bin
-rw-rw-rw- 1 system system 6 Aug 12 22:43 calibration_data
-rw-rw-rw- 1 system system 256 Oct 4 15:55 edk_p
-rw-r--r-- 1 system system 3 Nov 2 01:27 cryptprop_persist.sys.language
-rw-r--r-- 1 system system 5 Nov 2 15:21 cryptprop_lockscreen.patterneverchosen
-rw-r--r-- 1 system system 6 Nov 2 15:21 cryptprop_lockscreen.password_type
-rw-r--r-- 1 system system 5 Nov 2 15:21 cryptprop_lock_pattern_visible_pattern
-rw-r--r-- 1 system system 6 Nov 2 15:21 cryptprop_lock_pattern_tactile_feedback_ena
bled
-rw-r--r-- 1 system system 5 Nov 2 15:21 cryptprop_lock_pattern_autolock
-rw-r--r-- 1 root root 3 Nov 2 21:08 cryptprop_securewipedata
-rwx------ 1 radio radio 32 Nov 3 17:44 nv_data.bin.md5
-rwx------ 1 radio radio 2097152 Nov 3 17:44 nv_data.bin
-rw-r--r-- 1 system system 0 Nov 3 18:02 cryptprop_onetimeboot
drwxrwx--x 5 radio system 4096 Nov 3 21:23 .
drwxr-xr-x 21 root root 0 Nov 3 21:58 ..
You can see the changes to nv_data.bin.md5 and nv_data.bin -- I have no idea what crptprop_onetimeboot is but it looks a little suspicious.
Firstly I have a copy of the above as
- a directory on my sdcard
- a dd'd image on my sdcard
- a file copy on my PC (!)
I also see I still have backup files, so with a lot of difficulty (fs kept going read only when trying to copy files, so I ended up renaming the old name to the new name)
ie
.nv_data.bak -> nv_data.bin
.nv_data.bak.md5 -> nv_data.bin.md5
This didn't work (still no service/no imei), so I removed(renamed) the .md5 file -- but it still doesn't work
so it now looks like
# ls -latr
ls -latr
drwxrwxr-x 5 root root 4096 Jan 1 2000 .files
drwxrwxr-x 2 radio radio 4096 Jan 1 2000 imei
-rwx------ 1 radio radio 32 Jan 1 2011 nv_data.bin.md5.orig
-rwx------ 1 radio radio 2097152 Jan 1 2011 nv_data.bin
-rw-rw-rw- 1 radio radio 832 Jan 1 2011 nv.log
-rw-rw-rw- 1 radio radio 1 Jan 1 2011 .nv_state
-rwx------ 1 radio radio 32 Jan 1 2011 .nv_core.bak.md5
-rwx------ 1 radio radio 1048576 Jan 1 2011 .nv_core.bak
-rw-r--r-- 1 root root 1 Jan 1 2011 cryptprop_rebootMode
drwx------ 3 system system 4096 Jan 1 2011 dmp
-rw-r--r-- 1 system system 14 Jan 1 2011 cryptprop_persist.sys.timezone
-rw-r--r-- 1 system system 9 Jan 1 2011 cryptprop_applied_result
-rwxrwxr-- 1 radio radio 880 Jan 1 2011 redata.bin
-rw-rw-rw- 1 system system 6 Aug 12 22:43 calibration_data
-rw-rw-rw- 1 system system 256 Oct 4 15:55 edk_p
-rw-r--r-- 1 system system 3 Nov 2 01:27 cryptprop_persist.sys.language
-rw-r--r-- 1 system system 5 Nov 2 15:21 cryptprop_lockscreen.patterneverchosen
-rw-r--r-- 1 system system 6 Nov 2 15:21 cryptprop_lockscreen.password_type
-rw-r--r-- 1 system system 5 Nov 2 15:21 cryptprop_lock_pattern_visible_pattern
-rw-r--r-- 1 system system 6 Nov 2 15:21 cryptprop_lock_pattern_tactile_feedback_ena
bled
-rw-r--r-- 1 system system 5 Nov 2 15:21 cryptprop_lock_pattern_autolock
-rw-r--r-- 1 root root 3 Nov 2 21:08 cryptprop_securewipedata
-rwx------ 1 radio radio 32 Nov 3 17:44 nv_data.bin.md5.bk
-rwx------ 1 radio radio 2097152 Nov 3 17:44 nv_data.bin.bk
-rw-rw-rw- 1 root root 0 Nov 3 20:55 p
drwxrwx--x 5 radio system 4096 Nov 3 21:48 .
-rw-r--r-- 1 system system 0 Nov 3 21:52 cryptprop_onetimeboot
drwxr-xr-x 21 root root 0 Nov 3 21:58 ..
#
[/FONT]
I DID NOT BACKUP EFS beforehand (only just learnt I need to) and know this may now be screwed, but I'm still hopeful I have the original file and just made a silly error.
I could also
- try recreating the whole fs and copying files back
- checking the prod code within the rom (but why?)
- flashing original firmware
- modifying the dd'd image *offline*, swapping the files, and dd'ing the image back
Any advice. PLEASE....

---

if you have a backup the easiest way I have found is to use root explorer.
go in to the /efs folder, set to read/write, mark everything and delete (not scrictly necessary simply copying over will work) but if you have been tinkering probably better.
then paste all the back up files and folders in
finally reboot (in my experience when something has gone wrong even this is not necessary)
Root explorer is worth every penny
and keep multiple backup's of your /efs on different drives
If this does not work you are screwed. The file contains your IMEI encrypted and the only way to get that restored is by returning it.
oh I just realised you are saying the back up you have is only of it in the current state?
If that's the case you are probably screwed, have you ever used any apps like nitrality or any unlocking tools? they will create copies of your efs folder on the scard in various locations. have you run a file seach on you sdcard to see if there is any copies at all?
if you have no backups of this folder then I think you will find its a return to manufacturer / sevice centre / provider issue.

---

I *think* I have restored the files -- and the dates look reasonable, as if they were the originals.
I've now flashed an old ROM (KE5) for good measure, but still no signal
One discrepancy I did notice is that after installing a rom there was some bootup message about csc and XEU when copying files.
My original sales code was VOD (UK vodafone). I had then run XEU firmware and just recently tried to set the sales code to XEU using a *# code. I subsequently flashed back to vodafone firmware today.
So somewhere there's a lingering reference to XEU -- this prod code incompatability could be causing the error?
I definately feel I should have the data to fix this -- after all I have the encrypted file, but am not quite sure of all the factors involved (one being "you're stuffed I know")

---

type *#06# this should display you IMEI number
if this does not match your IMEI from the box then you have not fixed this
if it shows all zeros or 004999010640000 then you are on a generic IMEI number
strangely when I screwed mine up and got the generic one above I was still able to use mine with a vodafone (UK) sim but not an orange on
if this is the case, and there is no efs backup prior to this you might well be screwed.
if this backup is all you have an you believe the .bak file is intact then I believe you will find solutions for deleting the primary version of the file and keeping only the backups and rebooting
the log file should give you more information on how successful this was, but if this was the result of flashing you probably overwrote both primary and backup

---

*#1234# is returning a reasonable CSC I9100VODKE2
Checking the nv data files, it appears
- the new ones modded today contain XEU
- the original ones contain VOD
This is consistent with what happened, so I am still confused why the renamed original files do not work, and why there's a reference to multi-csc XEU during bootup.
Some remnant of XEU?

---

*#06# is currently showing blank -- but those .bak files looked fine.
Annoyed and frustrated...

---

In that case I would try deleting nv_data.bin and nv_data.m5 and rebooting
(assuming you have copies of everything
with just nv_data.bak nv_data.bak.md5
At least with the SGS1 this would work provided those bak files are the originals but the nv.log file will tell you more after the boot.
HOWEVER the SGSII has a lot more in this folder and I do not claim to fully understand them all but if you have a back up it's worth a shot
planetf1 said:
*#1234# is returning a reasonable CSC I9100VODKE2
Checking the nv data files, it appears
- the new ones modded today contain XEU
- the original ones contain VOD
This is consistent with what happened, so I am still confused why the renamed original files do not work, and why there's a reference to multi-csc XEU during bootup.
Some remnant of XEU?
Click to expand...
Click to collapse

---

Took some inspiration from http://www.communityhosting.net/sgsunlock/i9000.html and decided to check permissions & recreation of md5.
md5 wasn't recreated, so no matter, I had a backup. that is restored, but I don't know if the .bak files are needed. Yet trying to create them I get:
# mv nv_data.bin.md5.orig nv_data.bin.md5
mv nv_data.bin.md5.orig nv_data.bin.md5
# cp nv_data.bin .nv_data.bak
cp nv_data.bin .nv_data.bak
cp: write error: Read-only file system
#
This isn't a space issue.
There could be another cause -- /efs/imei/mps_info.dat contains the 3 characters "XEU" even though the file is dated Jan 2011
So either
- the date has been manually fudged
OR
- the code always was XEU -- unlikely.
I'm currently working on the basis that fundamentally the IMEI is intact, that the original nv_data.bin is intact & that the phone is validating the CSC in mps_info.dat (XEU) against nv_data.bin (VOD) and failing.
Though this wouldn't explain why before the fix, with XEU in the nv_data.bin, it wasn't working
Unless the issue is the filesystem itself. could it be corrupt? Is this in fact why it switched to R/O mode each time? I've tried multiple kernels including insecure. surely they wouldn't all "protect" this fs.
But if this is the case where is fsck? maybe I need to copy the fs image to another linux box with ext4 & inspect/correct before shipping back and dd'ing

---

Continuing.
Found /system/bin/e2fsck -- ran this against /efs with
# /system/bin/e2fsck /dev/block/mmcblk0p1
/system/bin/e2fsck /dev/block/mmcblk0p1
e2fsck 1.41.11 (14-Mar-2010)
ext2fs_check_if_mount: Can't check if filesystem is mounted due to missing mtab file while determini
ng whether /dev/block/mmcblk0p1 is mounted.
/dev/block/mmcblk0p1 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
/lost+found not found. Create<y>? y
yes
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: -(3202--3203) +4104
Fix<y>? yes
/dev/block/mmcblk0p1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/block/mmcblk0p1: 60/1280 files (1.7% non-contiguous), 2188/5120 blocks
**** >>> I NOW HAVE AN IMEI <<< ****
AND SIGNAL
LOGGED ONTO VODAFONE
WOOOHAY.
THIS HAS BEEN FUN. LOOK AND LEARN..
and seriously thanks to all the other articles and some moral support here tonight.
Going to put back proper firmware , remove dodgy kernels and GET A BIG BEER OR THREE

---

planetf1 said:
Continuing.
Going to put back proper firmware , remove dodgy kernels and GET A BIG BEER OR THREE
Click to expand...
Click to collapse
and make several backups of the /efs folder in its current state one would assume

---

Phone seems working. restoring over a HSPA connection happily, recognized voda sim.
now reinstalling titanium backup and copying down from dropbox...

---

The final step was restoring from titanium backup.
I had erased my sdcard -- though my backup was on dropbox.
However titanium backup is awful at copying files to/from dropbox -- as is IMO the phone when in "phone/kies" mode.
Finally I simply copied the dropbox directory back in USB debug=mass storage mode which was quick and reliable -- and then restored most items en-masse (I have a pro license).
For the record so far phone is fine - and indeed I've since run a new efs backup
The key takeaways from this are
* Backup efs and save it somewhere offline
* get titanium backup pro. it's good (better if it backed up efs too!)
* usb mass storage mode is the most reliable way for file xfer
* backup efs (again)
* don't get complacent
And of course if you do get a similar problem to mine
a) take a backup of efs with dd if=/dev/mmcXXX of=/mnt/scard/myefs.img (check name - I forget)
b) copy files you can to sdcard
c) copy both of this to a seperate pc
d) Just try running fsck (as above) - If I'd done this sooner I'd have saved hours. I should have gone with the obvious -- I've seen this on enough linux systems in the past to know what was happening but was thrown by no kernel messages.

---

Thanks for letting us know, might be a nice reference for future problems, especially the filesystem check.

---

Writing about it also helped keep me sane.giving up and hitting the beer was becoming increasingly attractive.
I do think making the warning about efs clearer would help.backup really should be a must at the earliest opportunity
Sent from my GT-I9100 using Tapatalk

---

Another thought.do unmount /efs before fsck
Sent from my GT-I9100 using Tapatalk

---

Unable to restore
I know I had a valid IMEI during the last week or so.
I have flashed several ROM's during the last month.
Last night lost IMEI
Now , no matter what I try, I can't seem to restore my IMEI. I have the fake one that ends in a bunch of zero''s
My SDCARD has a folder called EFS_BACKUP with multiple efs_xxxxxxx.tar.gz files in it. If I extract any of these and try to restore them to the /EFS folder I still have the fake IMEI number.
Please help - I didn't understand all the adb code in this post

---

Hi there,
/efs is fairly new to me too, to be honest it took hours of careful rooting before I gained some useful knowledge in how that area works.
-- what I would suggest before *anything else* is to copy anything you do have left in /efs. You will need to be root to do this. I found the gui root explorer type tools a bit clunky so I used the android SDK (adb is one of the tools in this package) to help. IF YOU NEED HELP WITH THIS SAY. You need to copy the files to multiple places for safety. Someone OFF your phone, ie on a PC. This is just in case things get worse. Do the same with any of those .gz backups you have. Maybe you'll need them *if* you make things worse...
If you're familiar with linux/unix systems this is all fairly easy, but if you're not it can be quite scary. For example you have to be able to write to /efs as well as list files and move them around. One wrong step and you could make things worse.
If you're unsure perhaps you could find a friend who knows *nix well to help you out. The bottom line is that you need to
a) ensure the right files are in there
b) The filesystem itself was intact
I definately suffered from b -- less sure about a.
What you need to do will depend a fair bit on what files you find in there, and what dates they are.
You said you had some backup files. Are you sure you have some from before the problem started? Can you look inside those backup files (I think winzip or similar will expand them for you). WIthout divoluging the actual contents (since you don't want to share your IMEI with anyone), is there an nv_data.bin file in there? Out of all the files it seems to be the most critical. When's it dated (mine was Jan 2011). If you cant' find that file how about .nv_data.bak - is that a good size, and again an old one.
If you have either of these -- even without anything else I think you can probably recover.
If you can get up and running with adb, a good start would be
adb shell
ls -laR /efs

---

Thank you very much, fsck method fixed my efs. Phone just broke it while doing nothing :/

---

I love you
You just saved my Galaxy S2

---

Yay. Brilliant news