Develop Bugs

[REF] How to restore original product code!

Hi,
So i coulden't wait and had to try out JPC firmware. Personally i didn't like it at all, so i went back to JM7. 1 thing i did not like is my product code changed from XEN to KOR.
And here is how to fix that easly:
I tested this on 2.1 cause i was on JM7 when i found this out, but this works with JPC/JPH also.
this fix is for those who do not have (correct) .bak files in the /efs/ directory!
- First make sure you are ROOT and install a Terminal Emulator (can be found in the market)
- Now open the Terminal, enter ''su'' to gain root access
- Enter: cp /efs/nv_data.bin /sdcard/
- Connect you're SGS to the usb and download ''nv_data.bin'' to your computer
- Open ''nv_data.bin'' with notepad or wordpad and search for ''KOR'' change this to the product code matching your country (red marked text should be changed). Im dutch, so mine is XEN. The line looks like this:
Code:
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿMP 0.800 ÿ[COLOR="Red"]KOR[/COLOR] GT-I9000HKD[COLOR="Red"]KOR[/COLOR]
- Now simply save your changes.
- Connect your SGS with usb, upload ''nv_data.bin'' to internal sdcard.
- Disconnect USB !
- Open Terminal Emulator and enter ''su''
- Now enter: cp /sdcard/nv_data.bin /efs/nv_data.bin
Also enter: rm -rf /efs/nv_data.bin.md5
- Close terminal, Reboot Phone. And Voila!!! Product Code restored!!
**IF YOUR SIMCARD DOESN'T WORK AFTER THIS, EXECUTE THE FOLLOWING**
- adb shell
- su
- busybox chown 1001:1001 /efs/nv_data.bin
- reboot
You can also do this from the Terminal Emulator if you don't have ADB on your PC! Like this:
-su
-chown 1001:1001 /efs/nv_data.bin
-reboot
I hope it's easy to follow my steps, it works guaranteed.
UPDATE - 13/09
Some people say you don't have to create a new md5, just remove the old one on the phone. kaffre and i tested this, the phone recreates the md5 file for you. So i've updated the steps in my tutorial, to make it even more easy!
UPDATE - 15/09
Simcard fix added. Thanks to tokinux

I`d suggest using a hex editor instead of any wordpad/notepad editor ...

Methyldioxide said:
Hi,
So i coulden't wait and had to try out JPC firmware. Personally i didn't like it at all, so i went back to JM7. 1 thing i did not like is my product code changed from XEN to KOR.
So f*ck that and here is how to fix that easly:
I tested this on 2.1 cause i was on JM7 when i found this out, but im 99% sure this works with JPC also.
- First make sure you are ROOT and install a Terminal Emulator (can be found in the market)
- Now open the Terminal, enter ''su'' to gain root access
- Enter: cp /efs/nv_data.bin /sdcard/
- Connect you're SGS to the usb and download ''nv_data.bin'' to your computer
- Open ''nv_data.bin'' with notepad or wordpad and search for ''KOR'' change this to the product code matching your country. Im dutch, so mine is XEN. The line looks like this:
Code:
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿMP 0.800 ÿKOR GT-I9000HKDKOR
- Now simply save your changes.
- Download a md5 creator tool, i use MD5SUMMER
- Create a MD5 file using ''nv_data.bin" and save this as ''nv_data.bin.md5''
- Open ''nv_data.bin.md5'' with notepad and delete all the lines beside the line wich is similar to this one: 4ba37998243f14158884c5f464933398 (ofcourse your line of numbers is different ! ) Save the md5 file.
- Now your md5 file should be exactly 32bytes (this is the same size of the md5 file used by samsung, so please follow this step carefully)
- Connect your SGS with usb, upload ''nv_data.bin.md5'' and ''nv_data.bin'' to internal sdcard.
- Disconnect USB !
- Open Terminal Emulator and enter ''su''
- Now enter: cp /sdcard/nv_data.bin.md5 /efs/nv_data.bin.md5
cp /sdcard/nv_data.bin /efs/nv_data.bin
- Close terminal, Reboot Phone. And Voila!!! Product Code restored!!
I hope it's easy to follow my steps, it works guaranteed.
Click to expand...
Click to collapse
editing those files is there a risk of changing the IMEI in 004999010640000 ??
i think something similar happened to me and now i'm with XXXXXXX as product code and that fake IMEI.......

Narcissus85 said:
editing those files is there a risk of changing the IMEI in 004999010640000 ??
i think something similar happened to me and now i'm with XXXXXXX as product code and that fake IMEI.......
Click to expand...
Click to collapse
My imei did never change, also not after product code restore

For me it seems to be easier to do it with the *#272*hhmm#* solution.
Read about this here: http://forum.xda-developers.com/showthread.php?t=779580
Its doing also a hardreset.. so backup you data!
In case you dont want a hard-reset, this manual solution is much better! So Thx, Methyldioxide for your work and sharing with us!

Donald Nice said:
For me it seems to be easier to do it with the *#272*hhmm#* solution.
Read about this here: http://forum.xda-developers.com/showthread.php?t=779580
Its doing also a hardreset.. so backup you data!
In case you dont want a hard-reset, this manual solution is much better! So Thx, Methyldioxide for your work and sharing with us!
Click to expand...
Click to collapse
but his doesnt change the product code! i did it and still is KOR.
what is true is that putting the right csc is making my phone act like a normal one so at the end having a KOR phone gives me no problems at the moment...

Donald Nice said:
For me it seems to be easier to do it with the *#272*hhmm#* solution.
Read about this here: http://forum.xda-developers.com/showthread.php?t=779580
Its doing also a hardreset.. so backup you data!
In case you dont want a hard-reset, this manual solution is much better! So Thx, Methyldioxide for your work and sharing with us!
Click to expand...
Click to collapse
*#272*hhmm#* only changes the CSC settings indeed, not the actual product code. With warrenty this can be an issue. So i preffer my original product code

Did this actually change the product code or did your Galaxy S replace the changed nv_data.bin file from the backup .nv_data.bak file?
The default action is to use the bak file to write a new nv_data.bin if the original is missing or corrupt. If your original .nv_data.bak still had the original code in it this could be what happened.

I´ve copied my original nv_data.bin and nv_data.bin.md5 to my pc und used md5summer to check if the md5 hash stored in nv_data.bin.md5 is a normal md5 hash of the filesize.
The Hash generated with md5summer didn´t match!!!
Seems to be not an normal md5 hash of the filesize. There must be more.
If i do steps from OP the product code of my phone changes to XXXXXXXX.
Have used an Hex Editor and md5summer. Also tried WinMD5, same ****.

Aery said:
I´ve copied my original nv_data.bin and nv_data.bin.md5 to my pc und used md5summer to check if the md5 hash stored in nv_data.bin.md5 is a normal md5 hash of the filesize.
The Hash generated with md5summer didn´t match!!!
Seems to be not an normal md5 hash of the filesize. There must be more.
If i do steps from OP the product code of my phone changes to XXXXXXXX.
Have used an Hex Editor and md5summer. Also tried WinMD5, same ****.
Click to expand...
Click to collapse
You dont read proper, plz read the steps carefully and you will create the correct md5 hash. I think your problem is that you did not open nv_data.bin.md5 after you generated it and deleted all lines beside the HASH line. This all is stated clearly in my steps, and you shouldent have any issue.
EDIT: The nv_data.bin.md5 you generated should be exactly 32bytes! else you did not follow my steps properly

ghostgull said:
Did this actually change the product code or did your Galaxy S replace the changed nv_data.bin file from the backup .nv_data.bak file?
The default action is to use the bak file to write a new nv_data.bin if the original is missing or corrupt. If your original .nv_data.bak still had the original code in it this could be what happened.
Click to expand...
Click to collapse
Nope, i wish it was that easy for me This works only if you backup up your rom with Clockworks for example.

Methyldioxide said:
You dont read proper, plz read the steps carefully and you will create the correct md5 hash. I think your problem is that you did not open nv_data.bin.md5 after you generated it and deleted all lines beside the HASH line. This all is stated clearly in my steps, and you shouldent have any issue.
EDIT: The nv_data.bin.md5 you generated should be exactly 32bytes! else you did not follow my steps properly
Click to expand...
Click to collapse
I´ve much knowledge about computers, linux (running a lenny root server) and so on. I´m not stupid. ;-)
In nv_data.bin.md5 there is only the hash code and its 32 bytes.
Will try hashing the file under ubuntu or debian and report back. Maybe windows is doing **** here.

This is very crazy.
My original files:
nv_data.bin -> DBT
hash in nv_data.bin.md5 -> 3012f56623f1a296c1ecd33ee8f0819b
Hash of nv_data.bin (windows, md5summer) -> 1e44ea7702c0e6b603c01ef0bf5508b0
Hash of nv_data.bin (ubuntu, md5sum) -> 1e44ea7702c0e6b603c01ef0bf5508b0
With my original Files Product Code of Phone is DBT.
If i use the md5 Hash generated by md5summer, put it in nv_data.bin.md5 Phone says XXXXXXXX.
Pretty strange.

Aery said:
This is very crazy.
My original files:
nv_data.bin -> DBT
hash in nv_data.bin.md5 -> 3012f56623f1a296c1ecd33ee8f0819b
Hash of nv_data.bin (windows, md5summer) -> 1e44ea7702c0e6b603c01ef0bf5508b0
Hash of nv_data.bin (ubuntu, md5sum) -> 1e44ea7702c0e6b603c01ef0bf5508b0
With my original Files Product Code of Phone is DBT.
If i use the md5 Hash generated by md5summer, put it in nv_data.bin.md5 Phone says XXXXXXXX.
Pretty strange.
Click to expand...
Click to collapse
I've been looking to correctly generate the .md5 file as well. As you can see Samsung uses more than just the file contents for generating the MD5 hash. An interesting thing is that when the phone recreates the nv_data.bin file based on the .nv_data.bak file it also regenerated the md5 file. The hash in this file was different from the one in the backup (original and backup were exactly the same nv_data with the same product code). So I suspect at least the timestamp of the file is also taken into account. I already tried diffenent scenario's but did not manage to generate a correct hash yet.

Aery said:
This is very crazy.
My original files:
nv_data.bin -> DBT
hash in nv_data.bin.md5 -> 3012f56623f1a296c1ecd33ee8f0819b
Hash of nv_data.bin (windows, md5summer) -> 1e44ea7702c0e6b603c01ef0bf5508b0
Hash of nv_data.bin (ubuntu, md5sum) -> 1e44ea7702c0e6b603c01ef0bf5508b0
With my original Files Product Code of Phone is DBT.
If i use the md5 Hash generated by md5summer, put it in nv_data.bin.md5 Phone says XXXXXXXX.
Pretty strange.
Click to expand...
Click to collapse
i was talking about this in my post....check ur imei too...

THANKS
Using the steps in 1st post, I could change my Product code from KOR to INU after updating to JPC thro kies.
Thanks.

Its not working. cant generate a correct md5 file.
Is the Imei stored in the nv_data.bin too????

Imei is not on that file, but /efs/imei/bt.txt if i recall that correctly.
And my fix does work great, if you cannot create a correct md5 then it's prolly cause you do it wrong. I bet if you send me your modified file and i make the md5 for you it will work.
Sent from my GT-I9000 using XDA App

At that location there's the bluetooth mac aaddress.
I think your product code reverted to the original because you damaged your nv_data.bin and nv_data.bin.md5 files and the phone recreated them from the backup.
If you don't have backups don't try this.
Sent from my GT-I9000 using XDA App

Methyldioxide said:
Hi,
So i coulden't wait and had to try out JPC firmware. Personally i didn't like it at all, so i went back to JM7. 1 thing i did not like is my product code changed from XEN to KOR.
And here is how to fix that easly:
I tested this on 2.1 cause i was on JM7 when i found this out, but im 99% sure this works with JPC also.
- First make sure you are ROOT and install a Terminal Emulator (can be found in the market)
- Now open the Terminal, enter ''su'' to gain root access
- Enter: cp /efs/nv_data.bin /sdcard/
- Connect you're SGS to the usb and download ''nv_data.bin'' to your computer
- Open ''nv_data.bin'' with notepad or wordpad and search for ''KOR'' change this to the product code matching your country. Im dutch, so mine is XEN. The line looks like this:
Code:
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿMP 0.800 ÿKOR GT-I9000HKDKOR
- Now simply save your changes.
- Download a md5 creator tool, i use MD5SUMMER
- Create a MD5 file using ''nv_data.bin" and save this as ''nv_data.bin.md5''
- Open ''nv_data.bin.md5'' with notepad and delete all the lines beside the line wich is similar to this one: 4ba37998243f14158884c5f464933398 (ofcourse your line of numbers is different ! ) Save the md5 file.
- Now your md5 file should be exactly 32bytes (this is the same size of the md5 file used by samsung, so please follow this step carefully)
- Connect your SGS with usb, upload ''nv_data.bin.md5'' and ''nv_data.bin'' to internal sdcard.
- Disconnect USB !
- Open Terminal Emulator and enter ''su''
- Now enter: cp /sdcard/nv_data.bin.md5 /efs/nv_data.bin.md5
cp /sdcard/nv_data.bin /efs/nv_data.bin
- Close terminal, Reboot Phone. And Voila!!! Product Code restored!!
I hope it's easy to follow my steps, it works guaranteed.
Click to expand...
Click to collapse
I did it!!!!
but, if I can , there's a small error,you 've to correct the red line ''nv_data.bin.md5'' in "nv_data.md5" .... this worked for me....
very helpfull guide, greetings mate

Taking EFS folder from SGS and putting it in another SGS

So I have an SGS and I screwed up when JPC came out and so I have the default IMEI number and product code of XXX. So out of curiosity, I'm wondering if I took the efs folder of another sgs and putting it in this 'paper weight' phone.
I'm obviously going to have to buy another SGS, but this is a thought that I had. I"m going to take a stab and think that this should work right since it's just like backing up/restoring the efs folder, just putting it on another phone.
I'm just looking for feedback on this idea, it's just going to be a costly solution for me. I'm primarily doing this until there's a solution to restoring the IMEI number for the SGS and then selling the other SGS.

I'm not a developer... but I would assume you would need to edit the new nv_data.bin files using a hex editor before you put them on the bricked device.
If you do a search on downloads.com you ought to find a freeware one.
Use that to search and replace the xxx imei number with that on the barcode on the side of the box.
Please be advised that this is pure speculation as my imei didn't default... but I found I could change my product code in a similar way.

Won't work. the /efs folder stores your IMEI number stuff, and the file's digitally signed. You can't just dump another file from another phone into it to fix the problem.

Well, my device not bricked as i can still use it, its just that i have a default imei and product code. Im aware that its digitally signed, but if im taking a file thats digitally signed by the same product then i would assume thats okay.
A digitally signed file from an one i9000m should be signed the same way as another i9000m would digitally sign a file no?
Sent from my GT-I9000M using XDA App

BakaSenpai said:
Well, my device not bricked as i can still use it, its just that i have a default imei and product code. Im aware that its digitally signed, but if im taking a file thats digitally signed by the same product then i would assume thats okay.
A digitally signed file from an one i9000m should be signed the same way as another i9000m would digitally sign a file no?
Sent from my GT-I9000M using XDA App
Click to expand...
Click to collapse
Yes most likely but then it will have the IMEI of THE OTHER device and that's not what you want. If you change the file then the md5 checksum becomes invalid. However, I thought I read somewhere that the phone would re-create teh checksum file if it's missing. Whether this allows you to change the file I do not know......

ewok666 said:
Yes most likely but then it will have the IMEI of THE OTHER device and that's not what you want. If you change the file then the md5 checksum becomes invalid. However, I thought I read somewhere that the phone would re-create teh checksum file if it's missing. Whether this allows you to change the file I do not know......
Click to expand...
Click to collapse
It won't work, the files are device specific.
EDIT: Aha, found the posts i was looking for.
http://forum.xda-developers.com/showpost.php?p=7509851&postcount=24
http://forum.xda-developers.com/showthread.php?t=743183&highlight=IMEI

It works only for product code...
i restore my DBT product code in this way:
-first copy the nv_data.bin and md5 files with their bak files (4 files)
-reboot
then my sims didnt work right ... (wrong pin error)
-with root explorer i deleted the nv_data.bin and nv_data.bin.md5 files. DONT DELETE the .bak files....
reboot.
my product code is now ok and my sim works.
imei...wrong.

Rawat said:
It won't work, the files are device specific.
EDIT: Aha, found the posts i was looking for.
http://forum.xda-developers.com/showpost.php?p=7509851&postcount=24
http://forum.xda-developers.com/showthread.php?t=743183&highlight=IMEI
Click to expand...
Click to collapse
Bah! Had I only found this earlier, then I guess I wouldn't have posted this questions then. *sigh* I guess i just have to wait for some kind of solution. Thanks Rawat

check if this guy can restore your IMEI
http://forum.samdroid.net/f28/complete-imei-restore-how-1817/
(should be similar methodology)

I tried this and it dosen't work. The device somehow validates the imei..
Sent from my GT-I9000 using XDA App

Docomo SIM unlock: Jup's Grand Theory of Permanent SIM Unlock

This theory now seems to be confirmed by number of successful applications & my additional research. It should be generally safe to try both experiments. However, it still requires you know basics of shell. Above all, backup. And as allways, I am not responsible for anything, I don't even exist, etc...
And if you test this, please provide feedback.
This post will be updated as needed. For update list see the end.
What you need
Rooted GNEX with perm unlock & generic IMEI by ****Docomo app from this thread: http://forum.xda-developers.com/showthread.php?t=1548210. If you bought Docomo device from Negri, you already have this "patch" applied & just need root.
4.0.4 based ROM, yakju and takju builds are tested. Feel free to try different versions but we know that 4.0.3 is different.
Some form of shell access to your device
Busybox helps, but is not really needed.
The basic theory of permanently unlocking gnex w/ IMEI intact
Theorems
lock status and your IMEI are contained in nv_data.bin files on gnex.
there are usually three nv_data.bin file: /factory/.nv_data.bak, /factory/nv_data.bin, /data/radio/nv_data.bin. The one in /data/radio is the one really used under normal operation, but the least important one. In some way, it gets updated during every boot (boot counter?) and if you destroy it, it will get replaced from /factory ones (I am not sure which one is preferred).
all of these files are signed and signature is in accompanying files with .md5 sum.
unfortunately, it's not clean md5, there is some seed added to it, so nobody knows how to generate them correctly.
From these follows
It would appear that on Galaxy S 2 and other phones you could get around SIM lock simply by editing nv_data.bin files. There are well known locations where one can find unlock status and some additional data and basically unlocking consists of resetting byte at 0x181469 with 0 (contains 1) and replacing about 30 bytes before that with 0xff. If you did this for /data/radio/, you'd get temp unlock, if you replaced files in /factory, you'd get permanently unlocked phone. Easy.
This also (partially) worked on 4.0.3 ICS for files in /data/radio, however /factory files are now protected by md5 checksum with unknown seed. Since 4.0.4 this md5 protection was extended to /data files. THIS IS UNCONFIRMED AS OF NOW.
md5 protection makes it impossible to tamper with those files unless one has a way to generate correct checksum. When system encounters files that have incorrect checksum, it will simply ignore them.
****DocomoV2 perm unlock correctly replaces nv_data.bin files with their unlocked versions (hex manipulation above) but where it fails is generating correct md5 files. Hence all the nv_data.bin files get ignored outright and gnex falls back to some nv_data.bin with generic IMEI that is obviously last resort and probably meant for developers. So unlock only works as side effect. On further reboots, /data/radio/nv_data.bin is correctly checksumed, so it's used, but it contains generic IMEI. On wipe, it's regenerated from fallback again.
If you have phone from negri that has permanent lock applied, you don't even have backup of your original DOCOMO locked nv_data.bin files. This may not be
true for all versions, but it's true for recent shipments from negri with ICS
4.0.4 and can be confirmed by checking byte 0x181469 at all three nv_data.bin
files. It will be 0x00 == unlocked. However, except for unlocking them, ****Docomo didn't do any damage to them, it just rendered them invalid from samsung point of view - checksums don't match.
So if we have way how to generate correct md5 files matching these, we will get unlocked phone with real IMEI. And thanks to little oversight on Samsung part, we do. This oversight is called log files.
Following tests assume that you have phone with permanent unlock of ****Docomo applied. Ie you have phone from Negri with generic IMEI.
1. Theory test (reasonably SAFE)
It's probably better to have phone in airplane mode for these tests. I did for some, didn't for others. But it may overwrite /data/radio if you don't. Switch it off only after reboot.
Log into your phone. su to root. I use adb shell, but any shell will work as
long as you can get root privileges.
Code:
$ su
# cd /data/radio/log
# cat nv.log
Check that it contains lines like this example (2 different at least):
Code:
Tue Apr 17 11:33:47 2012: MD5 fail. orignal md5 '24989da14a3ad550546d2d23254c8f03' computed md5 'adaa0bf9506d939d18d57f96c0c330a3' (rild)
hashes will obviously differ for each gnex. If you can't see these, you could try wiping /data/radio/nv_* (2 files) and rebooting. This will attempt to regenerate files from factory files. If then you still don't see lines, then either your phone hasn't been tampered with or my theory is incorrect. Let me know.
Code:
# cat /factory/nv_data.bin.md5
this will output another md5 hash. Try to find it in above log in column original md5. It should be there. If it is, congratulations, you have correctly f*&^%ed device. The line tells us that md5sum in the aforementioned md5 file is invalid. It also tells us what valid md5 should be! How kind of Samsung. Let's correct this "glitch". Copy somewhere the part in apostrophes after computed md5 on the SAME line that contains hash from above md5 under original md5 (32 characters, for example, if cat outputs 24989da14a3ad550546d2d23254c8f03, it will be adaa0bf9506d939d18d57f96c0c330a3 for above line). I will call it COMPUTED.
Code:
# cd /data/radio
# rm nv_data.bin nv_data.bin.md5
# busybox cp /factory/nv_data.bin .
# echo COMPUTED > nv_data.bin.md5
# chown radio.radio nv_data.bin*
# chmod 700 nv_data.bin*
So we're copying original file from /factory to /data/radio and creating brand new md5 file that contains hash matching this nv_data.bin.
Code:
# reboot
If you did everything correctly, you end up with your original IMEI after reboot. If you destroyed something in /data/radio, don't worry. The files in /data/radio will be regenerated if md5 sum doesn't match or if you delete them, you'll just end up with generic IMEI. Check the log file and try to figure out what happend. If it says default NV restored at the end with current timestamp, well, default NV is the generic one. If you end up with completely wiped IMEI, that usually means permissions of the files in /data/radio are incorect. If above procedure worked, no lines should be added to it, because /data/radio/nv_data.bin was correct.
Mention that we're only touching /data/radio/. This is mostly to prove theory. This file WILL get wiped on factory reset and you'll end up with generic IMEI again. So we just recreated, painfully, temp unlock of ****Docomo app, except that this version works for 4.0.4. But this is side effect just to prove the theory. The real goodie comes now:
2. Theory application (do at your OWN RISK)
You know what's coming anyway. You're smart guys. But first:
BACKUP your /factory off the device
BACKUP your /factory to the cloud
the best thing is to use tar from busybox (preserves file permissions), you can probably use recovery ROMs etc. Just make the good backup. If you damage your /factory/, you may screw your device and never get GSM access again unless paying somebody with SPTBox. There's NO SAFEGUARD unlike when you modify /data/radio. NONE. I hope you got it.
Remount /factory rw. I used root explorer, you can use command line, but you need write access. Do not touch nv_data.bin or .nv_data.bak files. They've been already fixed by ****Docomo and you really NEED them, so please, don't delete them. Also, remember that files starting with dot are treated as hidden by linux, meaning if you want to see them in output of ls, you need to use -a argument.
Now we just need to fix md5 sums. So do as above for data. Find matching lines in nv.log by original md5 and correct md5 sum in computed md5 part and
Code:
$ su
# cd /factory
# echo COMPUTED > nv_data.bin.md5
# chown radio.radio nv_data.bin.md5
# chmod 700 nv_data.bin.md5
# echo COMPUTED2 > .nv_data.bak.md5
# chown radio.radio .nv_data.bak.md5
# chmod 700 .nv_data.bak.md5
So yes, COMPUTED is the same as for /data/radio (it matches nv_data.bin), COMPUTED2 is different (and matches .nv_data.bak).
Remount /factory R/O (probably not needed, but it should sync it so recommended).
Wipe /data/radio/nv_* (2 files):
Code:
# cd /data/radio
# rm nv_data.bin nv_data.bin.md5
This is strictly speaking redundant, if you did the theory test before, since you already have correct files there. However, it will verify that everything is fine and it simulates what happens during factory reset. So wipe them.
Code:
# reboot
... and hope for the best. If you have original IMEI after that, you're probably unlocked forever and may forget about terminals. Try factory reset if you want, flash roms, your gnex is liberated. Go get a beer, it's worth it. If something broke, chances are you're back on generic imei, in which case, nv.log is your friend. And let me know.
Notes
it would be probably better to use "echo -n" instead of "echo", somone could give it try, but I used "echo" myself and it works. However, md5 sums have redundant newline at the end.
I am quite sure this will stop working on future firmwares. This is a loophole that will be closed once people at Samsung mention it (and I am pretty sure they monitor these forums, uhm, hello there). However, I believe that once you have complete set (nv_data.bin & matching md5 files), you're basically not distinguishable from stock sim unlocked phone, so you should be safe there. There's no 100% guarantee though - they are the guys that know their hardware inside out.
Backup /factory if everything works. SEPARATELY from previous backup. This may come handy in future as it contains /factory files matching unlocked version of you phone, so if you loose it, you can use it again.
If you run ****Docomo yourself, you might also want to backup /sdcard/.unlock_backup (or where ****Docomo creates its backup) or better yet, backup /factory off device before running ****Docomo. We, with Negri phones, don't have this luxury.
DISCLAIMER: I don't think this method can be used to spoof IMEI and that's a good thing. Some people claim they know how to change IMEI in nv_data.bin, but I am quite sure there are other security measures to protect it. So this can only return you your old IMEI. Which is good thing in my books (and probably evil in Samsung's, although they're just playing by carrier's tune here)
If this theory is confirmed, someone should write an app. It can be automated with grep or sed.
Updates:
Changed slightly commands in theory test to make sure that nv_data.bin has correct permissons. If it doesn't, you'll end up with wiped up IMEI (which is not really problem, this can be fixed, but you won't be able to get GSM connection until then) -- thanks cpxchewy for this
4/20 - Added Docomo to title, changed intro to reflect successful tests
4/26 - Added info about takju test.
4/27 - mention that files with dot are hidden

The theory test that I tried erased my IMEI and baseband completely. I wonder if it's because I used echo instead of echo -n? I'll try again after I restore from Nandroid (I tried it twice, and both time same results)
EDIT: oh I know why, on your tutorial you left out a line to chown radio.radio nv_data.bin Just did that and now it works!

very exciting news!!!!!!!

Tested and verified. Good job figuring this out man.
If you had a donate button I'd buy you a beverage ;D

hi can anyone build a app

jup007 said:
BACKUP your /factory off the device
BACKUP your /factory to the cloud
Click to expand...
Click to collapse
Hi, sory I'm really new on this..
How can I make a TAR backup of this folder? (I'm not sure how to do this with busybox)
I was only able to copy the entire folder to my pc. I "need" to do this backup before starting flashing anything.
thanks

Till an app is built, I wish some good soul could make at least a bash script to run it from computer or from a mobile shell...I am not good at using "grep" or "sed" command.
That would complete the excellent JUP insight on this issue.

cpxchewy said:
The theory test that I tried erased my IMEI and baseband completely. I wonder if it's because I used echo instead of echo -n? I'll try again after I restore from Nandroid (I tried it twice, and both time same results)
EDIT: oh I know why, on your tutorial you left out a line to chown radio.radio nv_data.bin Just did that and now it works!
Click to expand...
Click to collapse
Good info, thanks. I'll update the initial post. I used busybox cp which preserves permissions but if you use other methods, yes, you need to make sure the file has correct permission. It seems logical that when radio process can't read or write to it, it doesn't know how to read/update the file and just ends up with all zeros/question marks IMEI. So that's another phone state explained.

albsat said:
Till an app is built, I wish some good should could make at least a bash script to run it from computer or from a mobile shell...I am not good at using "grep" or "sed" command.
That would complete the excellent JUP insight on this issue.
Click to expand...
Click to collapse
I know. If nobody picks this up, I may write some script in future, but don't expect it to happen this week. I already lost enough time on this plus I believe it's good to test on people who know their way around bash first before writing an app/script. If you break something by hand, you probably have general idea how to fix it. If script breaks something, I will have to go into hiding.
It's not like there wouldn't be too much hurry anyway. Generic IMEI mostly works just fine. And this thread so far seems to confirm that permanent unlock & unique IMEI is possible. And rest assured, if it's possible, there will be automated way in near future. So those who don't dare to play with it by hand, you can still sleep more lightly now and survive on generic IMEI few more days.
etche said:
Hi, sory I'm really new on this..
How can I make a TAR backup of this folder? (I'm not sure how to do this with busybox)
I was only able to copy the entire folder to my pc. I "need" to do this backup before starting flashing anything.
thanks
Click to expand...
Click to collapse
Code:
# busybox tar -cvf /sdcard/factory.tgz /factory
This assumes you have busybox installed. It's good idea to do it while /factory is still read only mounted.
Then just on computer do:
Code:
adb pull /sdcard/factory.tgz .
and save it somewhere.

jup007 said:
I know. If nobody picks this up, I may write some script in future, but don't expect it to happen this week. I already lost enough time on this plus I believe it's good to test on people who know their way around bash first before writing an app/script. If you break something by hand, you probably have general idea how to fix it. If script breaks something, I will have to go into hiding.
Click to expand...
Click to collapse
It would be great to have a script just for the what you called 1. Theory test (reasonably SAFE) at least.
---------- Post added at 10:06 AM ---------- Previous post was at 09:27 AM ----------
Question please.
When I issue the command
# cd /data/radio/log
# cat nv.log
Click to expand...
Click to collapse
I get two lines with two different correct MD5. So in total it mentions 4 md5 sums.
Which is the correct one?

albsat said:
I get two lines with two different correct MD5. So in total it mentions 4 md5 sums.
Which is the correct one?
Click to expand...
Click to collapse
There should be two, that's correct. You need to run the next command I wrote in that post, # cat /factory/nv_data.bin.md5 . This will only match one of the lines (it must match exactly the code in "orignal md5" section on one line). That's your line and computed md5 there is the one that needs to be in md5.
The other line belongs to /factory/.nv_data.bak .

if i used temp unlock in ****docomo (keep original imei)
is this method also work ? and get a perm unlock?
or i have get a forever unlock 1st(wrong imei)

Hi,
Just to confirm that the first method worked perfectly. I managed to do it just by phone using terminal application and a file manager like ES File.
I will try the second and permanent method when I get back home.
Great job JUP!!!!
---------- Post added at 02:58 PM ---------- Previous post was at 02:13 PM ----------
@Jup
Another idea. Following the first temporary unlock method, I have this idea.
If we unlock temporary the files, can a backup of correct files from /data/radio be used again in case of a factory reset or new rom install? In such case, we can make a CWM package of these files and install it through CM recovery or through a file manager.
What do you think?
@Admin
Please make this thread a sticky. There are so many Docomo users that will be happy with Jup's work.

Wow, this is pretty incredible. I didn't think your theory would actually work but since it's confirmed by others this is fantastic.
I hope this method transcends what it is now.
Update: I'll be trying this method and I'll be willing to test out things should you need me. I'm not too confident in my ability but know how to follow explicit details.

albsat said:
@Jup
Another idea. Following the first temporary unlock method, I have this idea.
If we unlock temporary the files, can a backup of correct files from /data/radio be used again in case of a factory reset or new rom install? In such case, we can make a CWM package of these files and install it through CM recovery or through a file manager.
What do you think?
Click to expand...
Click to collapse
I am pretty sure this will work. Once you have correct set of files from /data/radio, you can make backup of them and restore them after wipe. Heck, I am quite sure this is what "condom" functionality of current fdocomo.apk does - it keeps backup of these files somewhere and can just restore them after wipe. No need to touch /factory at all. The only thing here is, you still have to do this restore manually after wipe. If you modify /factory, you should not have to worry and it may increase resale value of your phone quite a bit - if you have, for the same price, device that keeps IMEI after wipe and device that needs to run some wierd app, which will you buy?

ygvuhb said:
if i used temp unlock in ****docomo (keep original imei)
is this method also work ? and get a perm unlock?
or i have get a forever unlock 1st(wrong imei)
Click to expand...
Click to collapse
I don't think it will work with temp unlock.
But honestly, I don't really know how temp unlock of fdocomo apk works because negri phone I got was already perm unlocked. I believe it uses some vulnerability in 4.0.3 and earlier versions to get correct md5 sum for files in data, so more or less it does similar thing to theory test by different means. However, I don't know how it modifies the files in /factory - according to author, it does modify one, not the other. And this method relies on the fact that you have both of files in /factory (nv_data.bin & .nv_data.bak) are in unlocked state. Which is done by perm unlock.
Strictly speaking, you don't need fdocomo for this method to work. You could achieve same results by using hexedit and unlocking factory nv_data files by hand. It's just much more convinient this way.

thanks i will try this later

Just to confirm that even the second method worked perfectly. You can do all the procedure by your phone alone using a terminal and Root Explorer.
Thanks again jup007. Please add Docomo or Negri at subject. I think there will be more people interested.
Sent from my Galaxy Nexus using Tapatalk

I 2nd the proposal to please add Negri or Docomo to the subject line.
also, i 2nd the proposal to make this thead a sticky. there are so many people concerned about this.

Could also maybe clean up the instructions a bit and slim it down?
So I'm gonna try this out, but basically. Do we have to do theory 1 in order to do theory 2? or can we just go straight to theory 2 if we already have perm unlock with generic IMEI?
The backing up thru busybox code you put would also be helpful if you just put it in at Theory 2

[REF][GUIDE]CWM md5 mismatch problem solved

So, many of you probably faced the issue, when you tried to restore your CWM backup, that the recovery says MD5 mistmach, and will do nothing. The problem is now solved, and was solved, so I'm not the one, who made thing possible, I'm just porting this to the V.
So, the problem (in my iterations at least) are based on the /cache/ cannot be mounted error, which is common in the V. For why is that, I simply don't have a clue, but it is present. Because of this, the backup won't be full, and thus, the md5 image won't be made for the recovery, so cannot be recovered as is.
But happily you can make an md5 image from the backup yourself, and thus recover your backup.
WARNING!​
I'm no dev, just someone, that knows linux.
If you follow this path, you do it on your own. I'm not responsible for bricked devices, lost data or whatsoever, including the future the past and the present.​
Click to expand...
Click to collapse
There are three ways for you, to make an md5 sum of the img files, the good and the bad one and also the quoted one:
One (the good)
For this, you will need adb, root, and a working android. Yo don't have it? Here you go.
Go to the directory, were you have adb (or have extracted adb.exe, suggested c:\htc\), then plug in your phone (just for charge, no data connection), open terminal (syntax: cmd) then type in:
adb shell
this will get you to the phone's terminal
if you have # at the end of the line, you are good to go, if not, then type su
The syntaxes needed:
cd /sdcard/clockworkmod/backup/{recovery_timestamped_directory} <- this is from your backup, so you need to fill in appropirate data
md5sum *img > nandroid.md5
Click to expand...
Click to collapse
This will make an md5 image with the name that cwm acknowledges.
Two (the bad one)
So, you'we fired your ROM, cannot even boot, but cwm comes in. Than this is for you. There are programs (e.g. total commander) which can make md5 images. So if you have your backup folder, just go into it (sd card reader is preferred). You will see something like this in it:
.android_secure.vfat.tar
boot.img
data.ext4.tar
{nandroid.md5}
recovery.img
system.ext4.tar
Click to expand...
Click to collapse
sidenote:
If you have the nandroid.md5 and you cannot recover, don't try to recover from it!!!
The image itself is corrup, you have no luck, try RUU. (you can recover if you delete the md5 and create a new, but it is not really recommended)
1.
So, there are 2 .img files, highlight them in totalcommander. go to file->create checksum files
2.
tick in md5, then ok
3.
No, you're not done
open the md5 file in text editor, and remove the * 's from before the file names.
4.
Rename the file to nandroid.md5
5.
Now you're done, go to cwm, then recover.
Three (the quoted one)
Also on the 2nd page you will find an alternative solution for the problem which can help you if you have got busybox installed on your device.
The solution resembles the One type of fix, so with quotes here's the one (thanx for Meeshka for it).
Meeshka said:
For those who keep getting "md5sum not found" both in adb and in android terminql on device:
try instead
# busybox md5sum *img > nandroid.md5
worked for me
Click to expand...
Click to collapse
If I helped, don't hesitate to push the Thanks button.

Thanks... a very useful guide. Bookmarked

WORKED!!! Tho I'm from a different device the first (adb) method saved my AOKP backup!!! Daysaver I'd say!!

I keep getting "md5sum: not found"

Put this in the general android section as it works across most devices. ..
Sent from my One V

Nevell said:
I keep getting "md5sum: not found"
Click to expand...
Click to collapse
if you send me the 2 img files i can create an appropirate md5 image of them, but send the one you did, so I can guess what the problem is.
send them to the email of my usr here, or in pm. and mainly, the md5 image has the name "nandroid.md5" like small caption all the way, even the md5? If it is there where it must, it must work, ad absurd it will be "wrong checksum error", but that is another version.
General android section has this, I have learned this from there, but it had only 1st option, and was "discovered" when cwm had generated wrong md5s, the V, in the V the problem is a tad bit different, but the solution is the same.

I fixed it in adb
Sent from my SPH-L710 using xda premium

Nevell said:
I fixed it in adb
Sent from my SPH-L710 using xda premium
Click to expand...
Click to collapse
Can you explain what did you do to fix md5sum: not found error??
please i need it!

thatsgamer said:
Can you explain what did you do to fix md5sum: not found error??
please i need it!
Click to expand...
Click to collapse
Just created an md5sum manualy from the img files with the name of nandroid.md5, because on the V the recovery doesn't creates them because of cache mount problem.
The recovery process will end in an error message, because cache cannot be recovered, but the main thing will be recovered this way.

i have one x and i can't put sdcard in to card reader because one x dose not have sd card... and i cant fix it whit first solution because i cant acces my phone

haky1988 said:
i have one x and i can't put sdcard in to card reader because one x dose not have sd card... and i cant fix it whit first solution because i cant acces my phone
Click to expand...
Click to collapse
See : http://forum.xda-developers.com/showpost.php?p=32248108&postcount=7

unfortunately none of the methods described in the first post have worked for me, at the first one i got an "unable to write, source is read-only" error, and the second one failed from the first try
after almost giving up and beginning to deal with the idea of loosing my backups, i found this topic and in 10 secs it got the job done, now i'm back on my latest cwm backup

CWM showing different versions
-Delete-

maranello69 said:
unfortunately none of the methods described in the first post have worked for me, at the first one i got an "unable to write, source is read-only" error, and the second one failed from the first try
after almost giving up and beginning to deal with the idea of loosing my backups, i found this topic and in 10 secs it got the job done, now i'm back on my latest cwm backup
Click to expand...
Click to collapse
You do know that the first method is exactly like the one you linked right?
Aside that, I'm happy that the community could help you out

Loir can u help me. I can't locate the boot.img inside the downloads for cyanogen mod u provided. Forgive me but can you post a directory to this kernel file? Tks
Sent from my HTC Desire X using xda app-developers app

Thank you so much. You saved my phone.

For those who keep getting "md5sum not found" both in adb and in android terminql on device:
try instead
# busybox md5sum *img > nandroid.md5
worked for me

no * 's
Ken-Shi_Kun said:
So, many of you probably faced the issue, when you tried to restore your CWM backup, that the recovery says MD5 mistmach, and will do nothing. The problem is now solved, and was solved, so I'm not the one, who made thing possible, I'm just porting this to the V.
So, the problem (in my iterations at least) are based on the /cache/ cannot be mounted error, which is common in the V. For why is that, I simply don't have a clue, but it is present. Because of this, the backup won't be full, and thus, the md5 image won't be made for the recovery, so cannot be recovered as is.
But happily you can make an md5 image from the backup yourself, and thus recover your backup.
​
There are two ways for you, to make an md5 sum of the img files, the good and the bad one:
One (the good)
For this, you will need adb, root, and a working android. Yo don't have it? Here you go.
Go to the directory, were you have adb (or have extracted adb.exe, suggested c:\htc\), then plug in your phone (just for charge, no data connection), open terminal (syntax: cmd) then type in:
adb shell
this will get you to the phone's terminal
if you have # at the end of the line, you are good to go, if not, then type su
The syntaxes needed:
This will make an md5 image with the name that cwm acknowledges.
Two (the bad one)
So, you'we fired your ROM, cannot even boot, but cwm comes in. Than this is for you. There are programs (e.g. total commander) which can make md5 images. So if you have your backup folder, just go into it (sd card reader is preferred). You will see something like this in it:
sidenote:
If you have the nandroid.md5 and you cannot recover, don't try to recover from it!!!
The image itself is corrup, you have no luck, try RUU. (you can recover if you delete the md5 and create a new, but it is not really recommended)
1.
So, there are 2 .img files, highlight them in totalcommander. go to file->create checksum files
2.
tick in md5, then ok
3.
No, you're not done
open the md5 file in text editor, and remove the * 's from before the file names.
4.
Rename the file to nandroid.md5
5.
Now you're done, go to cwm, then recover.
If I helped, don't hesitate to push the Thanks button.
Click to expand...
Click to collapse
in 3. it says to remove the * *'s, but i don't see any, so i was wondering should i leave that be or if im doing something wrong.

Beastben13 said:
in 3. it says to remove the * *'s, but i don't see any, so i was wondering should i leave that be or if im doing something wrong.
Click to expand...
Click to collapse
I have done the thing with a legacy tcmd, so there is a probability, that they have modified the md5sum algorithm, so if you don't se the stars don't panic. (also it should do the trick even with stars in the file, but wanted to be sure at the time I wrote the post)

plz provide touch recovery for karbon a9+ plz and ther is bugs in cwm recovery 5.0.2.8 plz

modem DME4, DMF1

Hello everyone I have a problem with note 2
he flashed the modem DMF1, DME4 and recognizes them with the restore efs folder but when I reboot is imei null and baseband unknown
Solutions?

héllo
in first sorry for my english :silly:
backup your efs file
I made a RAR file with the 2 modem inside
unzip it on the pc or the phone
put the zip files in the sd card
flash via recovery
DMF1_MODEM modem_XXDME4 rar

jioan62 said:
héllo
in first sorry for my english :silly:
backup your efs file
I made a RAR file with the 2 modem inside
unzip it on the pc or the phone
put the zip files in the sd card
flash via recovery
DMF1_MODEM modem_XXDME4 rar
Click to expand...
Click to collapse
thanks for the reply
I will try to flash them, she takes it but when I restart then returns null imei
I do not understand why

mysterionTM said:
thanks for the reply
I will try to flash them, she takes it but when I restart then returns null imei
I do not understand why
Click to expand...
Click to collapse
I already discuseed this, you need to restore your EFS backup after you flash the ROM that you made the backup with.
so flash XXDMF1 with ROM XXDME6 (or DXDMF1) and then restore EFS.
if that didn't work. then flash XXDME4 then OTA update will give you XXDMF1.
If you can't recieve OTA updates and you have Root, then tell me so I send you my XXDMF1 and DME6. (dr.ketan has DXDMF1 which you must try first).
After every flash restore efs then restart to see if it is fixed.

thethiny said:
I already discuseed this, you need to restore your EFS backup after you flash the ROM that you made the backup with.
so flash XXDMF1 with ROM XXDME6 (or DXDMF1) and then restore EFS.
if that didn't work. then flash XXDME4 then OTA update will give you XXDMF1.
If you can't recieve OTA updates and you have Root, then tell me so I send you my XXDMF1 and DME6. (dr.ketan has DXDMF1 which you must try first).
After every flash restore efs then restart to see if it is fixed.
Click to expand...
Click to collapse
if you can put him I would be grateful
but then there is no way to have permanent XXDME4?
With the other note 2 had managed to get it going with this I can not

@mysterionTM
hello
take this and flash via odin pc and updates via OTA or KIES but after do backup efs file
/N7100XXDMB6_N7100OXADMB1_XEF.zip

mysterionTM said:
if you can put him I would be grateful
but then there is no way to have permanent XXDME4?
With the other note 2 had managed to get it going with this I can not
Click to expand...
Click to collapse
first of all make sure your phone is rooted. then download mobile odin Pro (you need Pro version to maintain root or simply root again). then download this file:
http://www.mediafire.com/download/ena68zhyjhwpc78/update.zip
Edit: this will make your mobile a french mobile, so don't flash it just get someone to convert it to a modem.bin or modify it for your country.
now open mobile odin pro and flash the Stock ROM XXDME6.
after it finishes open mobile odin pro again and go to update file, and choose the file you downloaded above. then flash it.
you you have build number XXDME6 and buildbase XXDMF1
now restore EFS by using this app: https://play.google.com/store/apps/details?id=jackpal.androidterm&hl=en
Code:
Put your EFS file on your mobile (External SD Card is preferred on the Root of the Card, so its location should be /storage/extSdCard/efs.img).
name it efs.img for easier use (if it was an img file).
now in the terminal type this:
SU
then grant it superuser permissions.
then type this:
dd if=/storage/extSdCard/efs.img of=/dev/block/mmcblk0p3 bs=4096
it will show you numbers if it was done correctly.
then reboot your phone and everything should work correctly. Reboot again to make sure.
In case it didn't work, then Flash the DME6 ROM, it should come with DXDMF1 , then try restoring EFS again.
tell me what happens with you.

@mysterionTM
what is your configuration of your phone? (your rom)

I put thanks to you both
thethiny said:
first of all make sure your phone is rooted. then download mobile odin Pro (you need Pro version to maintain root or simply root again). then download this file:
http://www.mediafire.com/download/ena68zhyjhwpc78/update.zip
Edit: this will make your mobile a french mobile, so don't flash it just get someone to convert it to a modem.bin or modify it for your country.
now open mobile odin pro and flash the Stock ROM XXDME6.
after it finishes open mobile odin pro again and go to update file, and choose the file you downloaded above. then flash it.
you you have build number XXDME6 and buildbase XXDMF1
now restore EFS by using this app: https://play.google.com/store/apps/details?id=jackpal.androidterm&hl=en
Code:
Put your EFS file on your mobile (External SD Card is preferred on the Root of the Card, so its location should be /storage/extSdCard/efs.img).
name it efs.img for easier use (if it was an img file).
now in the terminal type this:
SU
then grant it superuser permissions.
then type this:
dd if=/storage/extSdCard/efs.img of=/dev/block/mmcblk0p3 bs=4096
it will show you numbers if it was done correctly.
then reboot your phone and everything should work correctly. Reboot again to make sure.
In case it didn't work, then Flash the DME6 ROM, it should come with DXDMF1 , then try restoring EFS again.
tell me what happens with you.
Click to expand...
Click to collapse
excellent guide compliments
but to have the modem DME4 there is no permanent way?
jioan62 said:
@mysterionTM
what is your configuration of your phone? (your rom)
Click to expand...
Click to collapse
DME6

your CSC ?

jioan62 said:
your CSC ?
Click to expand...
Click to collapse
ITVDMF1

go here
http://forum.xda-developers.com/showthread.php?t=1896696

jioan62 said:
go here
http://forum.xda-developers.com/showthread.php?t=1896696
Click to expand...
Click to collapse
I saw it but I was looking for a way to install the modem DME4
I do not understand why it goes and then restart imei returns null
should be something inherent in the nv_data.bin or nv_data.bin.md5
I was looking for a way to fix the folder efs

ITV N7100XXDME6 is this your rom ?
flash via odin pc
download this your stock rom http://hotfile.com/dl/229491057/c20905b/ITV-N7100XXDME6-20130605085627.zip.html

mysterionTM said:
I put thanks to you both
excellent guide compliments
but to have the modem DME4 there is no permanent way?
Click to expand...
Click to collapse
what do you mean permanent way? why would you need DME4 if you have a higher better one?
you can flash DME4 (it comes with ROM DMB4) modem alone and keep it permanently, but if your EFS backup was when you had anything other than DME4 then you can't use it anymore, you have to recover EFS everytime.
just use XXDMF1 (since your CSC is DMF1) and restore EFS. don't see any reason to use an old modem.

jioan62 said:
ITV N7100XXDME6 is this your rom ?
flash via odin pc
download this your stock rom http://hotfile.com/dl/229491057/c20905b/ITV-N7100XXDME6-20130605085627.zip.html
Click to expand...
Click to collapse
yes, it is my rom
but by flashing the stock rom does not solve anything......
thethiny said:
what do you mean permanent way? why would you need DME4 if you have a higher better one?
you can flash DME4 (it comes with ROM DMB4) modem alone and keep it permanently, but if your EFS backup was when you had anything other than DME4 then you can't use it anymore, you have to recover EFS everytime.
just use XXDMF1 (since your CSC is DMF1) and restore EFS. don't see any reason to use an old modem.
Click to expand...
Click to collapse
you're right but with the other note 2 that I had was in the same condition and and I managed to do it !
with this I can not ....
I was leaving the modem DMF1 and I was able to go to the modem DME4 without any problems

mysterionTM said:
yes, it is my rom
but by flashing the stock rom does not solve anything......
you're right but with the other note 2 that I had was in the same condition and and I managed to do it !
with this I can not ....
I was leaving the modem DMF1 and I was able to go to the modem DME4 without any problems
Click to expand...
Click to collapse
on your other phone , you had EFS backup on DME4. on this phone, your backup is on DMF1. DMF can read DME backups, but DME can't read DMF backups because samsung changed the EFS read type on DMF1. so once you go DMF1, your EFS partition is changed permanently!

thethiny said:
on your other phone , you had EFS backup on DME4. on this phone, your backup is on DMF1. DMF can read DME backups, but DME can't read DMF backups because samsung changed the EFS read type on DMF1. so once you go DMF1, your EFS partition is changed permanently!
Click to expand...
Click to collapse
you're wrong
I was only backup on DMF1 on the other note 2
I followed this procedure and are able to put DME4 :
1. make a copy of your EFS folder using root explorer and store it somewhere safe (on your SD card and external SD card should do it).
2. delete the EFS folder from the root of your phone using root explorer.
3. reboot the phone
4. open root explorer and go to the EFS folder (yes, it is still there! The Android OS has generated a new one for us) and delete the following files:
nv_data.bin
nv_data.bin.md5
nv.log
.nv_data.bak
.nv_data.bak.md5
nv_data.bin.bak
and the entire IMEI folder.
5.Now go to your backed up EFS folder on your sd card and copy the IMEI folder and the " .nv_data" file (note the dot) to your new EFS folder.
6.Make another copy of the ".nv_data" file in your new EFS folder. Rename one of them to "nv_data.bin" and the other one to "nv_data.bin.bak".
7. Connect your phone to your PC and start up EFS PRO. After your phone has been detected, press the "Repair nv data" button to correct the ownership and permissions.
8. Reboot your phone into recovery mode using the three botton combo and flash the original modem firmware (the modem.bin file that you extracted earlier) to your phone using Odin (use the "phone" button for the upload) or Heimdall (use the "radio" partition for the modem.bin file upload).
9. Reboot the phone normally and your IMEI number will be restored and you will be able to connect to your mobile network again
but on this note I can not!

mysterionTM said:
you're wrong
I was only backup on DMF1 on the other note 2
I followed this procedure and are able to put DME4 :
1. make a copy of your EFS folder using root explorer and store it somewhere safe (on your SD card and external SD card should do it).
2. delete the EFS folder from the root of your phone using root explorer.
3. reboot the phone
4. open root explorer and go to the EFS folder (yes, it is still there! The Android OS has generated a new one for us) and delete the following files:
nv_data.bin
nv_data.bin.md5
nv.log
.nv_data.bak
.nv_data.bak.md5
nv_data.bin.bak
and the entire IMEI folder.
5.Now go to your backed up EFS folder on your sd card and copy the IMEI folder and the " .nv_data" file (note the dot) to your new EFS folder.
6.Make another copy of the ".nv_data" file in your new EFS folder. Rename one of them to "nv_data.bin" and the other one to "nv_data.bin.bak".
7. Connect your phone to your PC and start up EFS PRO. After your phone has been detected, press the "Repair nv data" button to correct the ownership and permissions.
8. Reboot your phone into recovery mode using the three botton combo and flash the original modem firmware (the modem.bin file that you extracted earlier) to your phone using Odin (use the "phone" button for the upload) or Heimdall (use the "radio" partition for the modem.bin file upload).
9. Reboot the phone normally and your IMEI number will be restored and you will be able to connect to your mobile network again
but on this note I can not!
Click to expand...
Click to collapse
oh, you followed the folder method! then yeah it works, but not recommended as it messed up permissions.
I was speaking about the mmcblk0p3 method.

how to know which modem i need? Im on stock firmware 4.4.2, Malaysia. Have the imei issue/corrupted efs and no backup