Related
I can't read french, but the translation site seems to indicate that this hexedit will permanently unlock any phone. My Captivate nv_data.bin matches perfectly.
I just can't translate all the comments and i really want to read what everyone is saying.
Any french speakers out there?
http://forum.frandroid.com/forum/viewtopic.php?id=26052
Thanks to zzyxy for posting this in another thread.
EDIT - changed title and found English Post on XDA.
http://forum.xda-developers.com/showpost.php?p=8182729&postcount=107
Translated by google chrome
Here is how to unlock a phone that has missed its flash Froyo JPC (request for unlock code and displays the correct imei)
New semi automated method available here: http://forum.frandroid.com/forum/viewtopic.php?id=27019
Beware if the imei is not good before you start, it will not be at the end.
This method can also be used to modify the Product Code for those interested
All that was done on'm Android 2.1 since Froyo modifies the files to his liking (I advise to do New JM1, it works very well).
Thank you for everything you read, do not fly the tutorial is very important !!!!! I could not be responsible for those who are mishandling
Before anything else, save the file efs /, we will play with:
http://forum.frandroid.com/forum/viewtopic.php?id=25668
Need to be root, busybox, android sdk available here:
http://developer.android.com/sdk/index.html
(In windows) we decompress the ZIP, it renames the file "android-sdk-windows" to "android" short and placed in c: \ (the name and location to the sdk is placed are important to commands typed by hand later)
Extracting a nv_data.bin:
Plug the phone in usb mode enabled USB debugging
Start => Run => cmd (a DOS window will open)
Tapper to space by:
cd ..
cd ..
cd android
cd tools
adb pull / efs / nv_data.bin
Close the DOS window
The file will appear in the nv_data.bin réperoire c: \ android \ tools.
Edit the file with a hex editor nv_data.bin (EditHexa available in my example here: ... http://www.logitheque.com/logiciels/win a_9903.htm):
188 021 offset (page 3137) to "XEF" (ca will recognize the phone as "naked") (thus change the product code)
Offset 18146E (page 3,083) to "00000000" (ac will put the network unlock code 00000000)
We backup ^ ^
Then we go back in adb ^ ^
Start => Run => cmd (a DOS window will open)
Tapper and point in space by:
cd ..
cd ..
cd android
cd tools
adb shell mkdir / sdcard / efs "
adb push nv_data.bin / sdcard / efs
adb shell
su
mv / efs / .nv_data.bak / efs / .nv_data.bakk
mv / efs/.nv_data.bak.md5 / efs/.nv_data.bakk.md5
rm / efs / nv_data.bin
rm / efs/nv_data.bin.md5
rm / efs/.nv2.bak
rm / efs/.nv2.bak.md5
cp busybox / sdcard / efs / nv_data.bin / efs / nv_data.bin
chmod 755 / efs / nv_data.bin
chown radio.radio / efs / nv_data.bin
If he ever put the radio user does not exist, try "chown 1001:1001 / efs / nv_data.bin" instead and yes for some it is still not the same ....( thank you Froyo JPC / JPH )
There may be errors on. Nv2.bak and md5 (they do not exist at all)
I renamed the. Bak. BAKK to set aside the time everything is finished, they will be erased later.
do: ctrl + c
unplug the phone, remove the battery without turning the phone 30 seconds.
restart (on or before this point we must put the sim)
The network will unlock code: 00000000, it will the code is good but not unlock it anyway. If its not working properly and restart the phone again.
once functional, * # 06 # displays the correct imei
After there are bugs that require reflashing, reflash in New JM1 via Odin with re-partition active (I did not test other firmwares)
Must rooter again (the busybox normally installs with the root) ... and yes again ^ ^
reboot (so the normally nv_data.bin.md5 must have recreated)
Creating the. Bak
plug the phone into USB debugging mode enabled
We return under adb ^ ^
Start => Run => cmd (a DOS window will open)
Tapper and point in space by:
cd ..
cd ..
cd android
cd tools
adb shell
su
rm / efs / .nv_data.bakk
rm / efs/.nv_data.bakk.md5
busybox cp / efs / nv_data.bin / efs / .nv_data.bak
busybox cp / efs/nv_data.bin.md5 / efs/.nv_data.bak.md5
chown radio.radio / efs / .nv_data.bak
chown radio.radio / efs/.nv_data.bak.md5
Ctrl + c
Unplug your phone
and it finally finished your phone is unlocked and working again all operators ... remember to save them now ^ ^
A big thank you to Rickou who brought me on a platter chown radio.radio Chaineau who was missing.
And has Reve40 with whom I studied nv_data.
And Hideki Jis26 who tested the method before it is online.
A remark Hideki:
hideki wrote:
Otherwise I just add details about my case.
So personally I stopped before the stage flashing in JM1 because I had no problem and my bak files were recreated itself at startup.
I tried the following reredémarrer my imei and no problems still, no application code. And like bin files are recreated at each boot from bak, I concluded that my bak was so good .
What greatly simplify the procedure .
This was not the case for me and therefore Jis26 peus be that after the Roma moved to the base, we could have some small variations, I can not say more.
Last edited by helroz (25-09-2010 1:50:37 p.m.)
Thanks for the translation but I found something even better then machine gobbly gook ,
I just found the original post by Helroz - in english on XDA if anyone wants:
http://forum.xda-developers.com/showpost.php?p=8182729&postcount=107
"This method work for galaxy s with damaged nv_data caused by froyo JPC (good imei but unlock code required)
this method is to recreate a new unlock code and allow the phone to unlock with new unlock code
I post this on frandroid with pictures and link for software:
h***://forum.frandroid.com/forum/viewtopic.php?id=26052"
So has anyone tried this method? Is changing the country code "XEF" necessary for unlock? Is that just for changing the product code?
michael.seltzer said:
So has anyone tried this method? Is changing the country code "XEF" necessary for unlock? Is that just for changing the product code?
Click to expand...
Click to collapse
I have yet to try it, but changing the country code is only necessary if you flashed a different international firmware and it changed that.
Ya i flashed to cognition 2.2 so it shouldn't be an issue right?
michael.seltzer said:
Ya i flashed to cognition 2.2 so it shouldn't be an issue right?
Click to expand...
Click to collapse
Not the country code, since you flashed an AT&T build.
when performing the busybox line, I get
cp: write error: No space left on device
Why? I have plently of room on my phone, what is the problem here?
No one has any idea?
Vae Hostilis said:
when performing the busybox line, I get
cp: write error: No space left on device
Why? I have plently of room on my phone, what is the problem here?
Click to expand...
Click to collapse
I ran into this, and i have an answer... took me bit to discover it...
The /efs partition is only about 6MB in size - the nv_data.bin is 2mb. There is a hidden backup file and another file as well that are also about 2mb.
ls -l -a (you can't do ls -la as in linux or unix) will show you hidden files and sizes.
So you probably tried to backup your nv_data.bin in the /efs folder, and then copying a new one over and you ran out of space. Delete the nv_data.bin after you back it up to your SD card, then copy the changed one over.
alphadog00 said:
I ran into this, and i have an answer... took me bit to discover it...
The /efs partition is only about 6MB in size - the nv_data.bin is 2mb. There is a hidden backup file and another file as well that are also about 2mb.
ls -l -a (you can't do ls -la as in linux or unix) will show you hidden files and sizes.
So you probably tried to backup your nv_data.bin in the /efs folder, and then copying a new one over and you ran out of space. Delete the nv_data.bin after you back it up to your SD card, then copy the changed one over.
Click to expand...
Click to collapse
Tried deleting the file in the efs folder, then just copying the file over using root file manager and it still says I don't have enough room. after deleting the file, I have 1.91mb free in that folder. is there anything in there I can toss?
And what does busybox have to do with transfering the file? as in why do i have to include busybox when typing in the command on adb?
Edit: here is the list of files in there in case I have some unnecessary ones.
.android (folder)
---empty
.imei (size: 15)
.nv_data.bakk (2097152)
.nv_data.bakk.md5 (32)
.nv_state (1)
imei (folder)
---bt.text (23)
---mps_code.dat (3)
nv.log (96)
after listing these off, I notice there is a serious math problem here..... how do i have 4.01 mb (according to root file manager) filled?
Vae Hostilis said:
Tried deleting the file in the efs folder, then just copying the file over using root file manager and it still says I don't have enough room. after deleting the file, I have 1.91mb free in that folder. is there anything in there I can toss?
And what does busybox have to do with transfering the file? as in why do i have to include busybox when typing in the command on adb?
Edit: here is the list of files in there in case I have some unnecessary ones.
.android (folder)
---empty
.imei (size: 15)
.nv_data.bakk (2097152)
.nv_data.bakk.md5 (32)
.nv_state (1)
imei (folder)
---bt.text (23)
---mps_code.dat (3)
nv.log (96)
after listing these off, I notice there is a serious math problem here..... how do i have 4.01 mb (according to root file manager) filled?
Click to expand...
Click to collapse
I did all this via ADB shell and i didnt use the busybox command; but i don't see your original nv_dat.bin - that is 2MB. You can delete the bakk file - that was made by some script - i have never seen the OS add 2 K's.
If you want to keep something move it to SD card and then delete from /efs. I know it is the nv_data.bin and .nv_data.bin that are 2MB files - they take up the room in the partition.
Unless you use a terminal and type in the commands - it is hard to tell what the file manager may still be hiding. I haven't used root file manager.
alphadog00 said:
I did all this via ADB shell and i didnt use the busybox command; but i don't see your original nv_dat.bin - that is 2MB. You can delete the bakk file - that was made by some script - i have never seen the OS add 2 K's.
If you want to keep something move it to SD card and then delete from /efs. I know it is the nv_data.bin and .nv_data.bin that are 2MB files - they take up the room in the partition.
Unless you use a terminal and type in the commands - it is hard to tell what the file manager may still be hiding. I haven't used root file manager.
Click to expand...
Click to collapse
I have the .nv_data.bak, the .nv2.bak, and the nv_data.bin in the sdcard folder. I believe the instructions told us to move those out of the efs folder and rename the copies (left in the efs folder) to .bakk instead of .bak, as they were the ones that would be deleted later.
All the files you see, are all the files in there, looking through ADB and the Root File manager app w/ hidden files shown. and the file sizes are not adding up to the total 4 it says I have in there, but I will try deleting the .bakk file and see what happens.
The nv_data.bin is the important one.
With what you listed, you should have about 4mb free, not 4 mb used. If you are in ADB shell you also have the df and du commands to show you how much of the /efs partition is used.
lol. it tells me 4.01mb is used.... sigh.....
Edit: just wiped my phone for the hell of it to see if it fixed anything. All the files are back, safe and sound, and the MATH ADDS UP (Yeay!). I'll try one more time before I give up.
Edit 2: just ordered a replacement device from at&t. I'll just run the Generate Code program on that, hopefully. Thank you for your help!!
So has anyone actually tried this? Does it actually work?
Sent from my SAMSUNG-SGH-I897 using XDA App
How did you get att to replace it?
michael.seltzer said:
So has anyone actually tried this? Does it actually work?
Sent from my SAMSUNG-SGH-I897 using XDA App
Click to expand...
Click to collapse
It does work. As long as your IMEI is good. (*#06#). Take a good unlocked nv_data.bin - put your IMEI and unlock/unfreeze codes in it; in the right places. Move it your phone and reboot.
so if i just follow the guide exactly i'll be good? Is there a chance that my phone might not boot up? For some reason my phone can't get into download or recovery mode so i don't want to be stuck.
michael.seltzer said:
so if i just follow the guide exactly i'll be good? Is there a chance that my phone might not boot up? For some reason my phone can't get into download or recovery mode so i don't want to be stuck.
Click to expand...
Click to collapse
with a bad nv_data.bin - it should still boot -but I can't guarantee it. Never tried.
Hacking system files, there is always the chance the phone won't boot. AT&T did it with OTA upgrade.... How bad do you need to unlock your phone -that is the question you need to ask yourself.
Hi,
i hope anybody can help me to make a Galaxy 3 Rom Backup Tool.
I made a little script for the German Forum, and it works fine but i can not flash the backupped Rom files.
Can somebody help me how i can push the backupped /data partition in datafs.rfs to the Phone without getting a Bootloop?
Here is a link to the Script http://www.multiupload.com/TAIJ9Z53J7
Sry for my english ^^
Nice work!
Will try ASAP...
And btw your english is good enough!
Ok, translated for you :
Code:
Install Total Commander and connect your Galaxy 3 to your PC in USB debugging mode
Next run Backup.bat
Your backup is finished when the window closes by itself. You can find the data in the folder backup on your SD
Copy the whole folder to your PC
Open the ROM Image.tar in total commander
Now you can flash your backup as One Package in Odin.
WARNING: please mention my name when you upload or translate the tool
Thanks for the code, I was just thinking along the same lines. You can skip the Total commander thing if you'd include something like 7zip commandline which is free. You can then call it from your batch file. Or tar it in the phone itself or is this too slow/bad for SD ?
You pull the files over with adb pull, but instruct to copy them from the SD as well.
As for why it bootloops : need to test it, but will probably wait for a fresh rom.
You can also put it back with dd ?
hmm
with which adb command i can put all 5 files in a flashable .tar file?
and how i can put the whole /data partition from the datafs.rfs in the /data folder and overwrite the files in the data folder?
Hmm, I see it's Busybox responding on my Galaxy, maybe it's not installed by default, but it was included in a custom ROM ?
Code:
BusyBox v1.18.4 (2011-03-20 15:16:04 CDT) multi-call binary.
Usage: tar -[cxtzjamvO] [-X FILE] [-f TARFILE] [-C DIR] [FILE]...
Create, extract, or list files from a tar file
Operation:
c Create
x Extract
t List
Options:
f Name of TARFILE ('-' for stdin/out)
C Change to DIR before operation
v Verbose
z (De)compress using gzip
j (De)compress using bzip2
a (De)compress using lzma
O Extract to stdout
h Follow symlinks
m Don't restore mtime
exclude File to exclude
X File with names to exclude
T File with names to include
You'd have to remount /data r/w to make any changes to it. But if you're dd-ing, it'll talk to the block device directly. Not sure how to clear it though, maybe dd does it by itself. Have a google for linux commands.
hmm ok,
and why i get a bootloop when i want to flash the files with odin?
one more question ^^
how i can pull the complete /data partition to SD card?
And Creating a .tar file with 7zip commandline works, but the File is not flashable.
you can find the info in i9000 forum
http://forum.xda-developers.com/showthread.php?t=943588
http://forum.xda-developers.com/showthread.php?t=960946
http://forum.xda-developers.com/showthread.php?t=965190
Okay i have a 1 click Rom backup now ^^
But its still the problem that i get a bootloop after flashing...
Ok, I tested it and /data was wiped, phone can't mount sd card etc. etc.
tgm28 said:
Ok, I tested it and /data was wiped, phone can't mount sd card etc. etc.
Click to expand...
Click to collapse
Use THIS from HERE.
Quoting deskjeti.
deskjeti said:
Hi,
I made a Backup & Recovery Script in the German Android Hilfe Forum for the Galaxy 3.
The Tool make a flashable Rom with 3 Clicks and Restore the Backup with one Flash and one Click.
The Script restores all Apps, app Data Google Account and Wifi key´s.
How To:
Unzip the zip file wherever you want and plug in your Phone with USB Debugging Mode.
Run the Step1 and wait, after Step1 is finished run Step2 and if Step2 finished Run Step3
In the "Alexgalaxys G3 Recovery v2 Final" Folder now is a CustomRom.tar.
Flash it as One Package.
If the Phone is started plug the Phone in Usb debugging mode and Run the Recovery.bat after it is complete you have to reboot you Phone.
Link: http://www.multiupload.com/NV0CFVYV2I
Click to expand...
Click to collapse
Although I edited the files to just be one click.
I wrote a small app that requires Superuser and allows you to expose custom disk images instead of the real SD card.
Source code: https://github.com/thejh/ImageExposer
Download: https://github.com/thejh/ImageExposer/downloads
To use this, you will have to:
- prepare an empty disk image
- create a partition table in the image
- create a partition and format it as FAT in the image
- copy the image to the android device (if you didn't create it there)
Then, open the app, "select new image file", choose the image.
Alternatively (that's how I did it), you can expose the empty image right after creating it and then do the partitioning stuff from the PC. Creating an empty image is as easy as running this command on Android (using ConnectBot or so):
Code:
dd if=/dev/zero of=<path to the image file> bs=1024 count=<size in KB>
So, for a 100MB image, use something like
Code:
dd if=/dev/zero of=/sdcard/my_image bs=1024 count=102400
.
I wrote this app in order to be able to boot linux variants over USB from my sdcard - but sadly, it looks like booting from this thing doesn't work for some reason. Still, it should be usable e.g. for transferring files using the phone over USB while playing music or for preventing people from seeing all the stuff on your sdcard just because you want to take some files home or so.
What do you think? Is this stuff usable for something?
Edit: It's in the market now: https://play.google.com/store/apps/details?id=thejh.imageexposer
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:
Code:
cd C:\Android\sdk\platform-tools
Then start the shell using adb:
Code:
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:
[email protected]:/ $
Now switch to root-user:
Code:
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:
Code:
[email protected]:/ # 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:
Code:
mount | grep efs
It should show something like:
Code:
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):
Code:
tar -cvf /data/media/0/efs.tar /efs
Your output will look like this:
Code:
[email protected]:/ # 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:
Code:
chown media_rw:media_rw /data/media/0/efs.tar
And the file permissions:
Code:
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'.
Code:
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:
Code:
ls -al /dev/block/platform/msm_sdcc.1/by-name/efs
This will show you the mmcblk which is the EFS-partition:
Code:
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:
Code:
/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':
Code:
dd if=/dev/block/mmcblk0p10 of=/data/media/0/efs.img
When it finishes, it will show you something like:
Code:
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:
Code:
chown media_rw:media_rw /data/media/0/efs.img
And the file permissions:
Code:
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'.
Code:
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:
Code:
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:
Code:
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:
Code:
[email protected]:/ # 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.
Code:
dd if=/data/media/0/efs.img of=/dev/block/mmcblk0p10
Output will be similar to:
Code:
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.
Reservation for second post, just in case.
Isn't rooting and using rootexplorer to zip de efs folder to external SD card and just copying that with a microSD cabel way easier?
johan81 said:
Isn't rooting and using rootexplorer to zip de efs folder to external SD card and just copying that with a microSD cabel way easier?
Click to expand...
Click to collapse
Yes, zipping is easier but you will lose your permissions (owner and file permissions (changed via chown/chmod)) so it is actually not a good backup. The permissions/ownerships are backupped with the tar- and dd-backup.
The dd-file includes more than just the file; it also contains the partition meta-data, in case your filesystem got corrupted and it is not possible to recovery it.
Good job man.
EFS Professional v2.0.35 is now support S4. You can also use this:
http://forum.xda-developers.com/showthread.php?t=1308546
shaq1907 said:
EFS Professional v2.0.35 is now support S4. You can also use this:
http://forum.xda-developers.com/showthread.php?t=1308546
Click to expand...
Click to collapse
dont seem to work crashes out while backing up
working now with new update
anybody knows how to adb read the the entire partition table of the galaxy s4?
From now on, Android rom can be easy to pack. You don't need to worry about the permissions of the files or the symlinks anymore.
What does this package do:
1. Automatically find and recognize the img with patterned name in the same folder of this package.
2. Automatically wipe and flash the system partition when system.img is found.
3. Automatically flash the addon pack without wiping the system partition when addon.*.img is found.
4. Automatically backup efs and efs_gsm partition, on Samsung Duo sim card phones.
5. Be able to flash the unmountable partitions like boot, recovery, modem, etc.
How to pack:
1. Make you rom on on the Phone or Linux. On the Phone? Yes, you can test your patches on your phone.
2. No matter on the Phone or on Linux, cd /system/ or cd <your system folder>, check the permissions and symlinks. Usually I don't check cause I modify directly on a system I dumped from my phone. Yes a dump of system partition is a good idea.
3. You have two optitions: 1. Use the modified dumped system partition dump as system.img. This usually generate a big img to flash, but will flash faster. 2. If you use extracted folder or want to use small files, cd to the system folder in shell and make the folder to a tarball with the command: 'tar --lzma -cf <your tar file> * .[!.]*'. Why use * .[!.]*? This will put the .* files and folders in the tarball.
4. Then rename the dumped image or the tarball to system.img and put it in the same folder of the FLASHER.
5. Want to make an addon? Just make the name like addon.<your name>.img. Don't for get the permissions and ownership of the files and folders.
Future plan:
1. Make a packer/dumper for the system partition.
Github:
https://github.com/maxfu/universal_android_flasher
I will edit this post and post some pictures later.