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

Search This thread

jup007

Senior Member
Sep 28, 2010
87
81
0
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
 
Last edited:

cpxchewy

Member
Aug 10, 2011
12
2
0
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!
 
Last edited:
  • Like
Reactions: livaye

etche

Member
Aug 31, 2010
40
16
0
Buenos Aires
BACKUP your /factory off the device
BACKUP your /factory to the cloud

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
 
Last edited:

albsat

Senior Member
Jan 1, 2012
3,319
555
243
Xiaomi Mi 10T / 10T Pro
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.
 
Last edited:

jup007

Senior Member
Sep 28, 2010
87
81
0
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!

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. :)
 
  • Like
Reactions: poging22

jup007

Senior Member
Sep 28, 2010
87
81
0
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.

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.

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
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.
 

albsat

Senior Member
Jan 1, 2012
3,319
555
243
Xiaomi Mi 10T / 10T Pro
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 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

I get two lines with two different correct MD5. So in total it mentions 4 md5 sums.

Which is the correct one?
 
  • Like
Reactions: Cabal_

jup007

Senior Member
Sep 28, 2010
87
81
0
I get two lines with two different correct MD5. So in total it mentions 4 md5 sums.

Which is the correct one?

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 .
 
  • Like
Reactions: poging22 and albsat

ygvuhb

Senior Member
Jul 13, 2010
454
38
0
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)
 
Last edited:

albsat

Senior Member
Jan 1, 2012
3,319
555
243
Xiaomi Mi 10T / 10T Pro
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.
 
Last edited:

chlehqls

Senior Member
Jun 18, 2011
1,700
349
0
Toledo, OH
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.
 
Last edited:

jup007

Senior Member
Sep 28, 2010
87
81
0
@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?
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?;)
 
  • Like
Reactions: poging22

jup007

Senior Member
Sep 28, 2010
87
81
0
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)

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.;)
 
  • Like
Reactions: poging22

albsat

Senior Member
Jan 1, 2012
3,319
555
243
Xiaomi Mi 10T / 10T Pro
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
 

slickromeo

Senior Member
Jun 10, 2010
260
61
0
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.
 

pewpewbangbang

Senior Member
Feb 13, 2010
2,046
257
0
Ann Arbor & NYC
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
 
Last edited:

Top Liked Posts

  • There are no posts matching your filters.
  • 36
    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
    3
    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.

    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.

    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
    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.
    2
    Simplified Instructions

    I see some people are still occasionally having trouble. I boiled jup007's "Theory Test" (restores IMEI until factory wipe) to an info graphic.

    Instead of cp I use dd to copy the file from factory. dd reads the contents of if= and writes it into of=. Since I'm not deleting the files, the file permissions should stay the same and you won't need to chmod.

    Hopefully this is a little more clear for those who are struggling to follow jup007's thorough explaination.
    2
    Can I unroot the phone and run stock ICS on this after I use this method and still keep everything (IMEI) intact?
    Yes, if you use theory application. To our current knowledge, once you fix /factory files, it's more or less same as factory unlocked phone.

    Although... Why would you want to unroot it?;)
    2
    I get two lines with two different correct MD5. So in total it mentions 4 md5 sums.

    Which is the correct one?

    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 .
Our Apps
Get our official app!
The best way to access XDA on your phone
Nav Gestures
Add swipe gestures to any Android
One Handed Mode
Eases uses one hand with your phone