5,600,725 Members 38,914 Now Online
XDA Developers Android and Mobile Development Forum

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

Tip us?
 
jup007
Old
(Last edited by jup007; 27th April 2012 at 04:26 PM.)
#1  
Member - OP
Thanks Meter 77
Posts: 78
Join Date: Sep 2010
Default 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/show....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 Following 36 Users Say Thank You to jup007 For This Useful Post: [ Click to Expand ]
 
cpxchewy
Old
(Last edited by cpxchewy; 19th April 2012 at 03:07 AM.)
#2  
Junior Member
Thanks Meter 2
Posts: 12
Join Date: Aug 2011
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!
The Following User Says Thank You to cpxchewy For This Useful Post: [ Click to Expand ]
 
ygvuhb
Old
#3  
Senior Member
Thanks Meter 36
Posts: 441
Join Date: Jul 2010
very exciting news!!!!!!!
 
netarchy
Old
(Last edited by netarchy; 19th April 2012 at 04:13 AM.)
#4  
netarchy's Avatar
Senior Recognized Developer
Thanks Meter 1330
Posts: 1,439
Join Date: Jun 2010
Location: San Antonio, TX

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

Been helped by my efforts? Feel free to

(Funds go towards world domination... or possibly beer)

[My Github] [My Twitter]
[Got win? TeamWin]

 
ygvuhb
Old
#5  
Senior Member
Thanks Meter 36
Posts: 441
Join Date: Jul 2010
hi can anyone build a app
 
etche
Old
(Last edited by etche; 19th April 2012 at 07:44 AM.)
#6  
Member
Thanks Meter 16
Posts: 38
Join Date: Aug 2010
Location: Buenos Aires
Quote:
Originally Posted by jup007 View Post
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
 
albsat
Old
(Last edited by albsat; 19th April 2012 at 05:31 PM.)
#7  
Senior Member
Thanks Meter 314
Posts: 2,049
Join Date: Jan 2012
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.
 
jup007
Old
#8  
Member - OP
Thanks Meter 77
Posts: 78
Join Date: Sep 2010
Quote:
Originally Posted by cpxchewy View Post
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.
The Following User Says Thank You to jup007 For This Useful Post: [ Click to Expand ]
 
jup007
Old
#9  
Member - OP
Thanks Meter 77
Posts: 78
Join Date: Sep 2010
Quote:
Originally Posted by albsat View Post
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.

Quote:
Originally Posted by etche View Post
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.
The Following 3 Users Say Thank You to jup007 For This Useful Post: [ Click to Expand ]
 
albsat
Old
#10  
Senior Member
Thanks Meter 314
Posts: 2,049
Join Date: Jan 2012
Quote:
Originally Posted by jup007 View Post
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
Quote:
# 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?

The Following User Says Thank You to albsat For This Useful Post: [ Click to Expand ]
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes