[Galaxy S 4 General] Mr_Q:
This guide has been made with and for the i9505, but will most likely also work on other Galaxy S4-models.

Please be extra careful on models other than i9505 as the 'mmcblkXpXX' partition numbers might differ on your device. How to check this is written in the procedure.

As I could not find a procedure in this forum yet, I have made one myself.

Of course all of the below is 'USE AT YOUR OWN RISK'.

Requirements before you start

Install KIES software (and included driver) and connected your S4 atleast once (to see if it works)

Have ADB-executable available. It can be found in the ADT Bundle from Google. There are also

much

smaller packages with ADB-only which will work. I might create one myself later on and attach it to this thread..

Device is rooted and has busybox-installed (default with motochopper root method). Applications with a similar name in Play Store will allow you to install busybox manually.

Enable developer mode, go to Settings - More - Device-info - Tap 7 times on 'Build number' to unlock 'Developer options' in the previous screen. Then go to 'Developer options' and thick 'USB debugging'

Connect USB cable to your computer and smartphone with 'USB debugging' enabled

Preparations for both backup methods

Now open a ADB-shell, in Windows this would be: 'cmd' in Start-menu (or CTRL+R).

Change the directory to the ADT directory: sdk\platform-tools. In my case:

cd C:\Android\sdk\platform-tools

Then start the shell using adb:

adb shell

If you get the error:

'error: device offline'

Then, check your device and allow USB debugging for the presented device. Now try again the command 'adb shell'

If all goes well, you will see the following:

shell@android:/ $

Now switch to root-user:

su -

It is possible that the phone now asks you to permit or deny root access. Of course, please permit.

When the switch succeeds, the '$' changes to '#', but you can also verify it by the id-command:

root@android:/ # id
id
uid=0(root) gid=0(root) context=u:r:shell:s0

If it shows root, all is fine.

Then, check with the following command if /efs is available and mounted:

mount | grep efs

It should show something like:

mount | grep efs
/dev/block/platform/msm_sdcc.1/by-name/efs /efs ext4 rw,seclabel,nosuid,nodev,no
atime,discard,journal_checksum,journal_async_commit,noauto_da_alloc,errors=panic
,data=ordered 0 0

Backup method using TAR

NOTE: In case you left the ADB shell, please return to it using command 'adb shell' and switch to root again via 'su -' as described above.

Run the folowing command to backup the whole efs-partition (all the files available on the system):

tar -cvf /data/media/0/efs.tar /efs

Your output will look like this:

root@android:/ # tar -cvf /data/media/0/efs.tar /efs
tar -cvf /data/media/0/efs.tar /efs
tar: removing leading '/' from member names
efs/
efs/imei/
efs/imei/mps_code.dat
efs/wifi/
efs/wifi/.mac.info
efs/FactoryApp/
efs/FactoryApp/test_nv
efs/FactoryApp/hist_nv
efs/FactoryApp/fdata
efs/FactoryApp/serial_no
efs/FactoryApp/factorymode
efs/FactoryApp/keystr
efs/FactoryApp/hw_ver
efs/FactoryApp/baro_delta
efs/FactoryApp/prepay
efs/FactoryApp/earjack_count
efs/FactoryApp/batt_cable_count
efs/bluetooth/
efs/bluetooth/bt_addr
efs/gyro_cal_data
efs/00000000.authtokcont
efs/carrier/
efs/carrier/HiddenMenu
efs/drm/
efs/drm/widevine/
efs/drm/widevine/5dsokxEEDXgQhkN50bp-Z2K5InM_/
efs/drm/widevine/5dsokxEEDXgQhkN50bp-Z2K5InM_/D3qpp0bxmJhbiZwIsCbXJ1434rc_
efs/drm/widevine/5dsokxEEDXgQhkN50bp-Z2K5InM_/RXFABDUxyT6Q+Zwx9ZhPGOq2Bq8_
efs/drm/playready/
efs/drm/playready/00004.PRV
efs/drm/playready/playready0.dat
efs/drm/playready/playready1.dat
efs/drm/playready/playready.hds
efs/wv.keys
efs/log/
efs/log/boot_cause
efs/.files/
efs/.files/.dx1/
efs/.files/.dm33/
efs/.files/.mp301/
efs/ss_data
efs/h2k.dat
efs/hw_offset

This will add all files in /efs to the tar archive located on your internal memory as 'efs.tar'.

Now, the permissions of this tar are incorrect (for this location) so we have to correct them:

Change owner and group:

chown media_rw:media_rw /data/media/0/efs.tar

And the file permissions:

chmod 664 /data/media/0/efs.tar

Now, your tar-backup is ready and can be copied via MTP towards your computer or you can use adb to copy it over. First type 'exit' twice to exit the adb shell. CTRL+C is an alternative to leave the 'adb shell'.

adb pull /mnt/shell/emulated/0/efs.tar .

This will copy the efs.tar to your current directory, which is in my case C:\Android\sdk\platform-tools. You can also replace the last . with the directory where you would like to put the file in.

Backup method using 'dd'

NOTE: In case you left the ADB shell, please return to it using command 'adb shell' and switch to root again via 'su -' as described above.

From the output of the earlier executed command 'mount | grep efs', you can get the path of the EFS partition. It start with '/dev/block/..' is the part which you can use to find the original partition on your device.

As you can see, in my case this is, and I do not expect it to be any different on your device:

/dev/block/platform/msm_sdcc.1/by-name/efs

To check which 'mmcblk' partition it is, we should check out this link:

ls -al /dev/block/platform/msm_sdcc.1/by-name/efs

This will show you the mmcblk which is the EFS-partition:

ls -al /dev/block/platform/msm_sdcc.1/by-name/efs
lrwxrwxrwx root root 1970-01-05 23:39 efs -> /dev/block/mmcblk0p10

As you can see, the actual partition in my case is:

/dev/block/mmcblk0p10

I expect that this is the same for all i9505-devices, but it's better safe to check it. On i9500-devices this might be a different number as they have a different partition-layout, that's why we're checking this.

It is very important to save this location, also for future restores.

Now, to backup the partition using dd, run the following command, please make sure that the part directly after 'if=' is the partition you found using the 'ls -l' command. In my case '/dev/block/mmcblk0p10':

dd if=/dev/block/mmcblk0p10 of=/data/media/0/efs.img

When it finishes, it will show you something like:

27904+0 records in
27904+0 records out
14286848 bytes transferred in 1.195 secs (11955521 bytes/sec)

This command reads the efs-partition, byte-by-byte to your internal memory, which you can transfer later on to your PC using ADB or MTP.

As the file created is owned by root:root and doesn't have the default permissions used for files at this location, it can be corrected with the following 2 commands:

Change owner and group:

chown media_rw:media_rw /data/media/0/efs.img

And the file permissions:

chmod 664 /data/media/0/efs.img

Now, your DD-backup is ready and can be copied via MTP towards your computer or you can use adb to copy it over. First type 'exit' twice to exit the adb shell. CTRL+C is an alternative to leave the 'adb shell'.

adb pull /mnt/shell/emulated/0/efs.img .

This will copy the efs.img to your current directory, which is in my case C:\Android\sdk\platform-tools. You can also replace the last . with the directory where you would like to put the file in.

To restore the files

Now to restore the files, in case there is really a need to, like imei-number ****up or something with the MAC-address of your wifi, or whatever.. the following commands can be used:

Of course, once again. USE AT YOUR OWN RISK!!!! Do not use this if not really necessary, as there are risks involved in doing this.

To restore the tar-backup, open 'adb shell' and switch to root using 'su -'. Now, first switch to the root directory, which is most likely not needed, but just to make sure the files will be extracted to the right location:

cd /

Before executing the next command, I assume that you have the efs.tar file in the root-directory of your internal SD-card.

Now, extract the tar file:

tar -xvf /data/media/0/efs.tar

This will extract the efs.tar file back to it's original location. It will show you something like:

root@android:/ # tar -xvf /data/media/0/efs.tar
tar -xvf /data/media/0/efs.tar
efs/
efs/imei/
efs/imei/mps_code.dat
efs/wifi/
efs/wifi/.mac.info
efs/FactoryApp/
efs/FactoryApp/test_nv
efs/FactoryApp/hist_nv
efs/FactoryApp/fdata
efs/FactoryApp/serial_no
efs/FactoryApp/factorymode
efs/FactoryApp/keystr
efs/FactoryApp/hw_ver
efs/FactoryApp/baro_delta
efs/FactoryApp/prepay
efs/FactoryApp/earjack_count
efs/FactoryApp/batt_cable_count
efs/bluetooth/
efs/bluetooth/bt_addr
efs/gyro_cal_data
efs/00000000.authtokcont
efs/carrier/
efs/carrier/HiddenMenu
efs/drm/
efs/drm/widevine/
efs/drm/widevine/5dsokxEEDXgQhkN50bp-Z2K5InM_/
efs/drm/widevine/5dsokxEEDXgQhkN50bp-Z2K5InM_/D3qpp0bxmJhbiZwIsCbXJ1434rc_
efs/drm/widevine/5dsokxEEDXgQhkN50bp-Z2K5InM_/RXFABDUxyT6Q+Zwx9ZhPGOq2Bq8_
efs/drm/playready/
efs/drm/playready/00004.PRV
efs/drm/playready/playready0.dat
efs/drm/playready/playready1.dat
efs/drm/playready/playready.hds
efs/wv.keys
efs/log/
efs/log/boot_cause
efs/.files/
efs/.files/.dx1/
efs/.files/.dm33/
efs/.files/.mp301/
efs/ss_data
efs/h2k.dat
efs/hw_offset

Then reboot your phone normally and see if it works again as you would expect.

If you restored the TAR-backup succesfully, you do not need to restore the dd-image. But in case your tar did not work or your /efs is not mounted due to corruption (in recovery) you can try the dd-recovery instead.

PLEASE BE AWARE THAT YOU SHOULD BE SURE ABOUT THE LOCATION OF THE EFS-PARTITION. THIS LOCATION WAS FOUND USING the 'ls -al /dev/block/platform/msm_sdcc.1/by-name/efs'-COMMAND EARLIER DESCRIBED. If you do not know this location, there's a risk you are overwriting other partitions (MODEM, SYSTEM, RECOVERY, ETC).

If you are sure about the original location, /dev/block/mmcblk......, then use this path just straight after 'of='. On my device the partition is /dev/block/mmcblk0p10.

dd if=/data/media/0/efs.img of=/dev/block/mmcblk0p10

Output will be similar to:

27904+0 records in
27904+0 records out
14286848 bytes transferred in 1.195 secs (11955521 bytes/sec)

This will read the efs.img and put it back in the original location.

NOTE 1: This thread gives you two options of backupping the EFS-partition. It is preferred to do both, better safe than sorry.

NOTE 2: Luckily, I have never had to restore any of the backups myself (not on this phone and not on earlier phones). This means that I was never able to test the restores, which counts for the most of us.

NOTE 3: DO NOT RESTORE

unless

you are really sure this will solve your issue. This will never resolve any lag or other problems with your rom.

NOTE 4: It is normal that the DD-file is much larger (10MB in size) as it also copies unused space and other meta-data of the partition.

NOTE 5: USE AT YOUR OWN RISK! Although the backup part is nearly riskless.

Note X: Feel free to thank me for this post.