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
Related
Hey out there,
after flashing my german SGS back from JPC to JM7 i had a look at the cusomer.xml file in /system/csc/.
There are two lines that now show KOREAN:
1. <SalesCode>KOR</SalesCode>
2. <Country>Korea</Country>
Before I did the following from the Guide JM7 by Richthofen:
Open Root Explorer and go to the "EFS" folder in the root.
Check the date on .nv_data.bak and .nv_data.bak.md5 files.
If it is earlier than 08/26/2010 you´re clear, if it is later then you may stop reading.
Once the date has been checked, select files nv_data.bin and nv_data.bin.md5 simultaneously and delete (yes, delete) them. Reboot the phone.
Now your phone is in the same condition (atleast permanent memory wise) as it was prior I9000XXJPC update.
Click to expand...
Click to collapse
So normaly my SalesCode should be DBT, so do i have to change it? But i dont know what should be in Country.. i havent written it down. So can someone with a german (o2) phone, with no JPC tell me what shlod be in line 5 <Country>Korea</Country>?
Thx in advance!
i *think* that simply flashing with a german CSC should remedy that.
dont edit the nv_data.bin! if you still have your old .bak files (from before the JPC flash) then just delete the normal.bin and .md5 and the phone will create new files out of the backups. in any case: save the backups to some place safe in case you need them!
just flashing the CSC will not help, because the efs data is not touched by any firmeware (besides JPC)
you can also try flashing back to an older firmware like JM 1 with Odin 1.3 and EFS clear, some people from Android-Hilfe.de reported this repaired the efs for them.
In any case, always back up the efs files!
My /system/csc is fine after using the *#272*hhmm* thing and selected my product code and clicked install.
Asdain said:
dont edit the nv_data.bin! if you still have your old .bak files (from before the JPC flash) then just delete the normal.bin and .md5 and the phone will create new files out of the backups. in any case: save the backups to some place safe in case you need them!
just flashing the CSC will not help, because the efs data is not touched by any firmeware (besides JPC)
you can also try flashing back to an older firmware like JM 1 with Odin 1.3 and EFS clear, some people from Android-Hilfe.de reported this repaired the efs for them.
In any case, always back up the efs files!
Click to expand...
Click to collapse
Will it nuke all records for the EFS and fix it back to the correct product code and IMEI ?
It really puzzles me why such things are not hard coded into the phone it self.
dutchcow said:
My /system/csc is fine after using the *#272*hhmm* thing and selected my product code and clicked install.
Click to expand...
Click to collapse
thanks, this made me restore my product code!
only a couple of clarifications..
- it's *#272*HHMM#
- this makes a factory reset to the phone, deleting all apps and setting, be sure to backup all that stuff before!
Donald Nice said:
So normaly my SalesCode should be DBT, so do i have to change it? But i dont know what should be in Country.. i havent written it down. So can someone with a german (o2) phone, with no JPC tell me what shlod be in line 5 <Country>Korea</Country>?
Click to expand...
Click to collapse
You must follow the point 7 of the first post from this thread:
http://forum.xda-developers.com/showthread.php?t=769400
7. My Phone asks me for a Unlock Code. Product Code has changed to KOR. What to do?
- Your Phone have to be rooted! Busybox is required!
- Start->Run-> cmd
- Change to your SDK\tools Directory e.g cd C:\Program Files (x86)\Android SDK\tools
- adb shell
- su
- cd /efs
- ls -al
If now nv_data.bak AND nv_data.bak.md5 are displayed, do the next few steps marked with (a)
If now .nv_data.bak AND .nv_data.bak.md5 are displayed (dot before filenames), do the next few steps marked with (b).
(a)- mv nv_data.bin nv_data.jpc
(a)- mv nv_data.bin.md5 nv_data.jpc.md5
(a)- mv nv_data.bak nv_data.bin
(a)- mv nv_data.bak.md5 nv_data.bin.md5
(a)- reboot
(b)- mv nv_data.bin nv_data.jpc
(b)- mv nv_data.bin.md5 nv_data.jpc.md5
(b)- mv .nv_data.bak nv_data.bin
(b)- mv .nv_data.bak.md5 nv_data.bin.md5
(b)- reboot
Click to expand...
Click to collapse
The right codes are saved in your device as .bak (backup)
First, you must find out if your needed files contains an . or not before the name. Now you must use way (a) or (b)
- On the first two lines, you make a backup from the (wrong Korean) JPC codes (if something goes wrong )
- Line 3 and 4 overwrites these code with your original backup codes.
- Reboot - reboots you device and the stock countrycode should be restored.
As I understand, these files are digitaly signed, so you shouldn't change something on it to keep the signature.
I've made these steps from JPC to JM2 with an non branded german device with success.
Ah, i forgot something. In this howto it was explained you should use
- ls -al
Click to expand...
Click to collapse
to show you all (even hidden) files in folder /efs.
It should be
ls -a
Click to expand...
Click to collapse
eltommi said:
thanks, this made me restore my product code!
only a couple of clarifications..
- it's *#272*HHMM#
- this makes a factory reset to the phone, deleting all apps and setting, be sure to backup all that stuff before!
Click to expand...
Click to collapse
When I try to do this I get something like an error message "Rejected". And I can't see anything in this EFS folder. There are no files inside it. What to do?
eltommi said:
thanks, this made me restore my product code!
only a couple of clarifications..
- it's *#272*HHMM#
- this makes a factory reset to the phone, deleting all apps and setting, be sure to backup all that stuff before!
Click to expand...
Click to collapse
Thats it! Tahnk you so much!!!!
Donald Nice said:
Thats it! Tahnk you so much!!!!
Click to expand...
Click to collapse
Sorry to disappoint you but as soon as you flash again your product code and sales code will revert to KOR. You really need to fix it in the EFS folder (carefully!!). First thing is to backup somewhere the files .nv_data.bak and .nv_data.md5.bak to be safe.
dnsp said:
Sorry to disappoint you but as soon as you flash again your product code will revert to KOR. You really need to fix it in the EFS folder (carefully!!). First thing is to backup somewhere the files .nv_data.bak and .nv_data.md5.bak to be safe.
Click to expand...
Click to collapse
Yes i know... and i have done this! But thank you for your advice!
Thanks! Thank you so much!!!
I have got my original product code back!
I used JM2, work.
Thanks again.
dnsp said:
Sorry to disappoint you but as soon as you flash again your product code and sales code will revert to KOR. You really need to fix it in the EFS folder (carefully!!). First thing is to backup somewhere the files .nv_data.bak and .nv_data.md5.bak to be safe.
Click to expand...
Click to collapse
I flashed JPC with Kies, then I returned to jm7 followin Richtofen istructions on the first post of jm7 thread..
I checked my .bak..they were dated June..so I deleted nv_data.bin and nv_data.bin.md5 and rebooted recreating new files based on .bak..so I think the stuff on /efs should be ok now..
KOR product code was here until today btw..
so you're telling me that if I flash again it will be back to KOR? despite of the work I made on /efs after flashing jm7?
I'm too lazy to try by myself flashing once more tonight =)
thanks!
eltommi said:
I flashed JPC with Kies, then I returned to jm7 followin Richtofen istructions on the first post of jm7 thread..
I checked my .bak..they were dated June..so I deleted nv_data.bin and nv_data.bin.md5 and rebooted recreating new files based on .bak..so I think the stuff on /efs should be ok now..
KOR product code was here until today btw..
so you're telling me that if I flash again it will be back to KOR? despite of the work I made on /efs after flashing jm7?
I'm too lazy to try by myself flashing once more tonight =)
thanks!
Click to expand...
Click to collapse
You did it right. I was referring to the method below:
eltommi said:
thanks, this made me restore my product code!
only a couple of clarifications..
- it's *#272*HHMM#
- this makes a factory reset to the phone, deleting all apps and setting, be sure to backup all that stuff before!
Click to expand...
Click to collapse
This will give you a non permanent product code. Will go back to KOR again after a re-flash.
dnsp said:
You did it right. I was referring to the other method:
Click to expand...
Click to collapse
I did both of them..some days ago the first one, but KOR was still there..today the second one..uhm..
Ok I'm going to flash again and see what happens =)
scorpio16v said:
You must follow the point 7 of the first post from this thread:
http://forum.xda-developers.com/showthread.php?t=769400
The right codes are saved in your device as .bak (backup)
First, you must find out if your needed files contains an . or not before the name. Now you must use way (a) or (b)
- On the first two lines, you make a backup from the (wrong Korean) JPC codes (if something goes wrong )
- Line 3 and 4 overwrites these code with your original backup codes.
- Reboot - reboots you device and the stock countrycode should be restored.
As I understand, these files are digitaly signed, so you shouldn't change something on it to keep the signature.
I've made these steps from JPC to JM2 with an non branded german device with success.
Ah, i forgot something. In this howto it was explained you should use
to show you all (even hidden) files in folder /efs.
It should be
Click to expand...
Click to collapse
Those are the steps that I did, i got my phone unlocked but the product code and IMEI got messed up.. and I didnt have a back-up of my nv_files... I guess this is be a permanent effect on the phone already .. any chance a service center can restore this ?
EDIT:
Also would anyone know if I flashed to the JM1 firmware like what was said a few posts back and if it messes up the efs folder would it prevent my phone from booting ? I already made a copy of my efs folder using root explorer..
ummm
I try te JPC and then i flash the phone about 3 times.........so at the moment in my efs folder there arent the .bak files.
No way to restore the orginal product code for me?
I would like create a backup (of my entire system including boot image, data and system partitions. Is there any way I can do this without the CWM. The main reason is that I could return the phone to the original state in case if I have to return for service.
For my knowledge (and i have no knoledge! ) samsung accept rooted device on service (otherwise if the phone has broken screen it is not accepted)...but, if i were you, i would install cwm and make a nandroid backup of the whole system. If you want to have all of google system images(to restore original stock) you could set your sdk environment http://developer.android.com/sdk/index.html and download google images (bootloader, rom, radio) and put in a safe place (the SDK supply adb/fasboot which are tools that you would use to restore the google's files). that's the thread with these contents: http://forum.xda-developers.com/showthread.php?t=1366806 That's the standard (so yours) original stock files from google actually on your phone!
and also i advise you to follow these steps to save your /EFS partition (you never know) before flashing custom things, BUT IT REQUIRES ROOT: http://forum.xda-developers.com/showthread.php?t=1352371
BUT, if you don't want to install cwm, you could also see here: http://forum.xda-developers.com/showthread.php?t=1392310
Thank you. If I am right, msskip's tools will install the CWM onto my phone as well. I have just come across a guide for back-up without CWM <http://forum.xda-developers.com/showthread.php?t=1420351>. I am just not quite sure if it is the same full back-up as I get for the Nandriod or CWM. Does anyone have any experience with this?
The post you linked doens' backup /boot partition and recovery. So you can backup only /system and /data; you can obtain these EXACTLY files just downloading the google system (4.0.1 - 4.0.2 - 4.0.3) files (*.img estension) and you have the same result, plus you can get bootloader.img and recovery (evrything stock, meaning samsung galaxy nexus stock files)...these are in the post i linked and are the stock google images and these are the files that our phones has inside (also including system.img).
that' the explanation why i think that is basically useless to make a backup of /system and /data for warranty purpose, because google (or first phone users in november when the phone came out on the market) provied all .img that you need to revert (using fastboot) anytime your phone to a stock 'new'phone (which is your now, so in warranty!). Make, instead, a backup for the files and apps (apk) (usually /data) that you need if you want to try custom roms and then if you are not satisfied get back to stock...
To answer to your question, no is not the same kind of backup, you will lack /boot and recovery.
adding that you can use adb to generate .img by
Code:
cat /proc/mtd
and you will have a fs table with adresses (i have no phone now so cannot provide), then using dd (assuming boot is on mtd2):
Code:
dd if=/dev/mtd/mtd2 of=/sdcard/boot-stock.img bs=2048
and also use this for recovery partition...never tried for system and data partition (but could work, i'm not sure so not do that in this way, wait more knowing-knoledge people and also never tried on ics but, just ginger remembering...dont' know if it's the same in this new system)
but this process make use of
Code:
adb shell
su
the second one requires root....
as of now, i dont' now any method not involving root to make these things but as i stated at first post, i don't know anything
Thank you. I am wondering if the image file you have provided is for yakjuux. I have come across many posts that if I get the wrong baseband, the phone will not work correctly.
post, please, your baseband version which you can find on settings->phone info->basedand version in your phone; mine is 19250xxkl1 that i have recently updated from xxkk1 (the stock one)
My Build # is ITL41F I9250 UGKL1 and the kernel is 3.0.1-ga052f63 [email protected] #1.
Do you think you have a image of this? Thanks.
As far is i know, you have a GSM version of Galaxy Nexus. So it's safe to grab google image of /system, /boot and for the radio grab UGKL1 radio/baseband version. To better answear it's better to know also you bootloader version (which probably is primekk15): you can view this by going on bootloader on you phone doing this:
1 setup android sdk environment (include fastboot) for your pc system (windows-linux-osx)
2 enter in the settings menu of the phone and tic the 'debug usb'
3 attach the phone to the pc and let it recognize your phone (windows-osx), for linux install udev that already are in your distrib/repo
4 (assuming you are on windows) on pc... start/run/ cmd: the the terminal open up and go in your android-sdk directory, enter and then go to platform-tools; there is adb command, run: adb reboot bootloader
this will restart your phone in the bootloader menu. There, you have all of information you need...just write here your bootloader version (to have a confirmation) to understand which versione you need to download and put in a safe place in case of warranty-need...
Then wait someone better than me that knows how to make backup of all partitions without root (without exploit i think it's difficult to grant su access on the standard ics system); if there is no such possibility, just root, install cwm and do a nandroid backup and then trasnferr on a safe place on your place and you are good to go to try modding.....
now i need sleep as here is 8 in the morning and finishing compilemy l701x kernel which weight 3,4 mb lzo compressed, fine tuning.....good nite,ehm,good mornig..mmm... good is enough
Thank you. It takes some time to download the packages.
The Bootloader shows the following
Product Name: Tuna
Variant: Maguro
HW Version: 9
Bootloader Verson: Primekk14
Baseband Version: I9250UGKL1
Carrier Info: None
Signing: Production
What would be the appropriate to donload. Do you have their respective link? Thank you for your ongoing support.
Would anyone with experience please provide me with inputs if:
1. there is any way to back-up without root
OR
2. the phone has to be rooted, is there any way to have a program residing in my computer iso the phone (CWM in this case).
OR
3. there is any way to remove CWM and other rooted apps before I use GNex Toolkit to relock the phone.
Thanks.
Here you go:
http://forum.xda-developers.com/showthread.php?t=1420351
Would anyone with experience please help?
I am struggling with the same issue. Restoring the nandroid, removing su and superuser.apk and then relocking the bootloader actually brings the phone to quite factory looking mode (except for timestamps in system)
I wonder if it is possible to pull dump of system the same way it is done for boot and recovery.
Guys - it is pretty trivial to restore all partitions you would be modifying to factory conditions because Google provides the factory images for which you can use fastboot to restore. You don't even need to be unlocked much less rooted or have CWM installed because the Google images are official and have the correct signatures.
As for making image copies of your phones partitions this cannot be done w/o root access because these partitions are only available to root. If you are rooted you can use a utility such as dd on the phone to copy the partitions.
Sent from my Galaxy Nexus using XDA App
silow said:
Guys - it is pretty trivial to restore all partitions you would be modifying to factory conditions because Google provides the factory images for which you can use fastboot to restore. You don't even need to be unlocked much less rooted or have CWM installed because the Google images are official and have the correct signatures.
As for making image copies of your phones partitions this cannot be done w/o root access because these partitions are only available to root. If you are rooted you can use a utility such as dd on the phone to copy the partitions.
Sent from my Galaxy Nexus using XDA App
Click to expand...
Click to collapse
Google provides yakju images only. Phones here in Canada come with yakjuux which is even 4.0.1. It will be pretty obvious you have thinkered with your phone if you return it with yakju image instead the original one.
As for root - I think it might not be necesary - I was able to do nandroid backup without flashing neither recovery or root to my system by simply unlocking the boot loader and booting CWM off fastboot. I am thinking can we dd while in CWM (flash of phone still intact - except of bootloader which is not an issue since it can be relocked)
Anyone have the dd syntax handy and the partition that needs to be dumped?
system partition seems to be /dev/block/platform/omap/omap_hsmmc.0/by-name/system (this is the df output after I mounted it in CWM)
Would the dd command be something like
Code:
dd if=/dev/block/platform/omap/omap_hsmmc.0/by-name/system of=/sdcard/yakjuux.img
CWM provides you "root" because it has the su binaries in the ramdisk.
You can run the following when booted into CWM since CWM will mount /data:
Code:
dd if=/dev/block/mmcblk0p10 of=/data/media/system.img
leobg said:
[snip]
Anyone have the dd syntax handy and the partition that needs to be dumped?
system partition seems to be /dev/block/platform/omap/omap_hsmmc.0/by-name/system (this is the df output after I mounted it in CWM)
Would the dd command be something like
Code:
dd if=/dev/block/platform/omap/omap_hsmmc.0/by-name/system of=/sdcard/yakjuux.img
Click to expand...
Click to collapse
I think that may work. The output file may be padded with extra zeros, so you may need to trim them before flashing (this is certainly the case when you dump the radio).
EDIT: I would probably use this instead (although I am not sure it will make a difference:
Code:
dd if=/dev/block/platform/omap/omap_hsmmc.0/by-name/system of=/data/media/yakjuux.img
efrant said:
I think that may work. The output file may be padded with extra zeros, so you may need to trim them before flashing (this is certainly the case when you dump the radio).
EDIT: I would probably use this instead (although I am not sure it will make a difference:
Code:
dd if=/dev/block/platform/omap/omap_hsmmc.0/by-name/system of=/data/media/yakjuux.img
Click to expand...
Click to collapse
Yes, that was what I actually ended up doing since /sdcard was a sym link to /data/media. Resulting file is 654MB uncompressed. I wonder how can I easily check if content is right on a win machine.
---------- Post added at 09:44 PM ---------- Previous post was at 09:37 PM ----------
silow said:
CWM provides you "root" because it has the su binaries in the ramdisk.
You can run the following when booted into CWM since CWM will mount /data:
Code:
dd if=/dev/block/mmcblk0p10 of=/data/media/system.img
Click to expand...
Click to collapse
Yes, I meant it's not necessary to make any changes on the filesystem to achieve it once bootloader lock is off. And by simply relocking the device after, there are zero traces of any 'hackery' being done on the phone.
leobg said:
Yes, that was what I actually ended up doing since /sdcard was a sym link to /data/media. Resulting file is 654MB uncompressed. I wonder how can I easily check if content is right on a win machine.
Click to expand...
Click to collapse
There is obviously some extra padding in there, as the file size should be closer to half that size uncompressed.
---------- Post added at 09:08 AM ---------- Previous post was at 08:51 AM ----------
leobg said:
[snip]
And by simply relocking the device after, there are zero traces of any 'hackery' being done on the phone.
Click to expand...
Click to collapse
Not sure why so many people are worried about "traces of hackery". I can't speak from personal experience, but many Nexus One owners (if not all of who have attempted), had NO issues returning devices to HTC that were unlocked... Remember, the N1 did not have a relockable bootloader, so they obviously knew you were messing around.
You don't have to FLASH CWM to USE CWM.
Just BOOT CWM. Simple.
I have a rooted Galaxy Nexus GSM (Maguro) running ClockworkMod and the stable version of CM9. I've been trying to find out how exactly the IMEI is stored --- whether it's baked into the radio component or whether it's controllable from firmware --- and how /factory/nv_data.bin relates to it.
I was able to "break" my IMEI, i.e., set it to the infamous 004999010640000, via the following procedure (derived from http://forum.xda-developers.com/showthread.php?t=1264021 ):
0. Get an adb root shell
1. Back up the contents of `/factory`, e.g., with `adb pull`
2. Remount the `/factory` filesystem read-only with `mount -oremount,rw /dev/block/mtdblock0 /factory`
3. Delete `/factory/nv_data.bin` and `/factory/nv_data.bin.md5`
4. Delete `/data/radio/nv_data.bin` and `/data/radio/nv_data.bin.md5`
5. Reboot
After this, the IMEI was reported as 004999010640000. Then I was able to restore my IMEI to its original value as follows:
0. Restore `/factory/nv_data.bin` (owned by root)
1. Restore `/data/radio/nv_data.bin` (owned by radio)
So it seems clear that the IMEI reported by the device depends on the contents of the firmware. But it's possible that the radio unit is hard-wired to only be in two possible states, 004999 and the true IMEI.
`/data/radio/nv.log` has log lines from code attempting to read `nv_data.bin`, in particular:
Fri Aug 24 01:10:53 2012: MD5 is turned on.
I searched all the repositories in the Google Android codebase for the string "MD5 is turned on" and couldn't find the code that generates this log line. Is it possible that it's generated by a proprietary binary blob?
So, the open questions:
1. Where is the code that knows how to interpret nv_data.bin?
2. Does nv_data.bin actually contain the IMEI?
Thanks for your time!
Have a look at this thread.
efrant said:
Have a look at this thread.
Click to expand...
Click to collapse
That's more or less what I did; I was able to break and unbreak my IMEI using the procedures outlined there. What I'm trying to find out is whether the IMEI is actually stored in that file (the first "theorem" in that post, although it is not proven), what code is able to read the IMEI, and whether the IMEI can be modified.
There's some more information here: http://forum.xda-developers.com/showthread.php?t=1626593&page=2
which points to the Samsung rild as the code which knows how to interpret nv_data.bin, and suggests that the md5 verification is performed with a secret seed. But I can't find the source code for the Samsung-specific rild to confirm this. Perhaps it is a binary blob somewhere on my phone's filesystem?
The two strings I have to recognize the code are the log message `MD5 is turned on.` and the function `__refresh_md5_file`.
Update: running `pmap` on `/system/bin/rild` showed that it links against `/system/vendor/lib/libsec-ril.so`. I think this is the relevant blob --- it looks like both of those strings are in there.
slingamn said:
Update: running `pmap` on `/system/bin/rild` showed that it links against `/system/vendor/lib/libsec-ril.so`. I think this is the relevant blob --- it looks like both of those strings are in there.
Click to expand...
Click to collapse
/system/vendor/lib/libsec-ril.so is just the "radio interface layer". It has nothing to do with the IMEI.
efrant said:
/system/vendor/lib/libsec-ril.so is just the "radio interface layer". It has nothing to do with the IMEI.
Click to expand...
Click to collapse
I think it does have to do with the IMEI, based on the strings that are in it. Here's the output of `nm -D` on it: gist.github.com/70f5222ce6d578a9655e
In particular, here are some suggestive strings: requestGetIMEI, requesetOemImei, requestOemEventStartIMEI, TxIMEI_EventStartImei, RxIMEI_UpdateItem.
I think it's likely that some of the functions here can be used to push a new IMEI value into the radio unit. But given that it also contains the log messages found in `nv_data.log`, it seems like it definitely has the role of reading and verifying `nv_data.bin`.
Does anyone have any guesses about the naming scheme of these functions, in particular the "Tx" and "Rx" strings?
slingamn said:
I think it does have to do with the IMEI, based on the strings that are in it. Here's the output of `nm -D` on it: gist.github.com/70f5222ce6d578a9655e
In particular, here are some suggestive strings: requestGetIMEI, requesetOemImei, requestOemEventStartIMEI, TxIMEI_EventStartImei, RxIMEI_UpdateItem.
I think it's likely that some of the functions here can be used to push a new IMEI value into the radio unit. But given that it also contains the log messages found in `nv_data.log`, it seems like it definitely has the role of reading and verifying `nv_data.bin`.
Does anyone have any guesses about the naming scheme of these functions, in particular the "Tx" and "Rx" strings?
Click to expand...
Click to collapse
so? no updates on this?
i'm stuck with the 0000049xxxxx generic IMEI and no back up... i'm trying everything i found on the internet with my poor knowledge and i'm stuck... no idea what to do
blasael said:
so? no updates on this?
i'm stuck with the 0000049xxxxx generic IMEI and no back up... i'm trying everything i found on the internet with my poor knowledge and i'm stuck... no idea what to do
Click to expand...
Click to collapse
I gave up on this project. If you're interested in working on it further, I would suggest contacting the Replicant developers (#replicant on freenode) for advice --- they're the people I would expect to know the most about hardware issues of this stripe.
slingamn said:
I gave up on this project. If you're interested in working on it further, I would suggest contacting the Replicant developers (#replicant on freenode) for advice --- they're the people I would expect to know the most about hardware issues of this stripe.
Click to expand...
Click to collapse
i am also haviong the same problem.I installed 4.3 factory image,build JWR66Y on my Galaxy Nexus .But after flashing my IMEI become generic (004999010640000).So I cant registered on network. Can give some suggestions to restore my genuine IMEI...
Update: To work with the AT&T ICS ROM, this method requires installing a modified libsec-ril file. You do not need to bother with the MD5 checksums since they aren't output by this ROM and are bypassed altogether thanks to Phoenix84188's work.
Update 2: I made an update zip to easily apply Phoenix84188's modified libsec-ril file. It may also be worth mentioning that spocky12's GalaxSim Unlock works on this phone too.
Hello,
I was trying to figure out a way to unlock the phone while keeping my IMEI.
I tried tinkering with the CSC files and factory resets on stock recovery to reapply same. No luck, although I might have been able to relock it to another network, didn't bother testing. (Fixing these files also eliminates any re-locking possibilities on factory reset.)
After some research on other methods and programs for the SGS I, II and III, I managed to pull it off. There are some slight variations across models, but I got the right mix for this one. I've since called, texted and used cellular data with my Virgin Mobile Canada SIM, and it also took my T-Mobile USA SIM without complaint and roamed on Rogers. My ex girlfriend's now using it on Telus. Multiple confirmed unlocks from various parts of the world in this thread as well.
Requirements
Working ADB installation
Hex editor
Root (could also be done with CWM on an unrooted ROM.)
Instructions
Backup the /efs partition (ideally with a tar archive as it preserves ownership and permissions information)
Open nv_data.bin in a hex editor. (Frhed is one open-source option.)
In the hex editor, go to offset 0x181469. An offset is a byte's position in a file, it can be given in either decimal or hexadecimal format. (The 0x notation is for hexadecimal values)
On the hex side, change that value from 01 to 00 (To be technical I could have written 0x01 to 0x00)
Using the hex editor's search capabilities, look for the string "302720" (Rogers) or an appropriate AT&T MNC/MCC combination (try "310410" or "310380") as applicable.
This should bring you to a series of MNC/MCC pairs. (Which should match those found in your original CSC customer.xml file.) For information, the strings in my file started from offset 0x180069 and read: 30272030237030272#30237#00101#99999#999990001010001012
Overwrite the strings by changing them to xFF (ASCII non-breaking space.)
From the command prompt, push the modified nv_data.bin into place. On the stock, secure kernel:
Code:
C:\(Whatever your path is)>adb push nv_data.bin /sdcard/
C:\(...)>adb shell
$ su [I](check for a possible superuser prompt on the phone itself)[/I]
# cp /sdcard/nv_data.bin /efs/nv_data.bin
# chown radio.radio /efs/nv_data.bin
# reboot
Once the phone has done rebooting, from the command prompt:
Code:
C:\>adb shell
$ su
# cat /efs/nv.log
The log should spit out a pair of error messages like this:
Code:
Wed Aug 29 10:45:04 2012: MD5 fail. orignal md5 '9e1e52346ec8bc3ea07988c967dab04c' computed md5 'd931816e4be7d60a3e41f6fddc27e2e4' (rild)
Wed Aug 29 10:45:05 2012: backup NV restored.
Copy the freshly computed, lightly salted (i.e. not reproducible otherwise), md5 hash from the command prompt window. (Remember that you can use the mouse to select and copy)
Open nv_data.bin.md5 in a hex (or text) editor and paste it over the old one.
ADB push both the previously modified nv_data.bin and nv_data.bin.md5 back to /efs/ and don't forget to chown them both again.
Code:
C:\(...)>adb push nv_data.bin /sdcard/
C:\(...)>adb push nv_data.bin.md5 /sdcard/
C:\(...)>adb shell
$ su
# cp /sdcard/nv_data.bin /efs/nv_data.bin
# cp /sdcard/nv_data.bin.md5 /efs/nv_data.bin.md5
# chown radio.radio /efs/nv_data.bin
# chown radio.radio /efs/nv_data.bin.md5
Reboot (although on second thought, shutting down, inserting a foreign SIM and turning the phone back on should work)
Done! Confirm the unlock works with a "foreign" SIM, and for bonus points edit the CSC customer.xml file, setting the <NbNetworkLock> property to 0 and deleting the networks listed immediately below. You could also remove the leftover modified files on the SD card, from ADB shell:
Code:
$ rm /sdcard/nv_data.bin
$ rm /sdcard/nv_data.bin.md5
If you're having a hard time with this guide, please stick to public threads where more people can help you instead of PM-ing me. Thanks.
Goodbye,
Darkshado
Will try !!!
If this works, I can finally get rid of that piece of paper on my wallet with the Unlock Code for my phone XD
I purchased an "unlocked" glide from amazon and been using it no problem here in Mexico, do I have to worry about it locking at some point?
I flashed ICS / CWM and the backlight fix on it and so far so good
rovar said:
I purchased an "unlocked" glide from amazon and been using it no problem here in Mexico, do I have to worry about it locking at some point?
I flashed ICS / CWM and the backlight fix on it and so far so good
Click to expand...
Click to collapse
Going by my Ace and Gio experience, the following conditions have to be met for the phone to relock itself:
Native or no SIM card
Stock ROM with CSC files that contains network lock settings.
Stock Samsung recovery
Factory reset triggered, which makes the stock recovery reapply the CSC parameters.
Alright, thanks!. Guess I'll stick to reflashing the ROM instead of factory reset whenever there's a problem
is this method good for GB as well as ICS/JB ?
I've done it with the stock Rogers GB ROM.
With that said, if it doesn't work with the ICS leak, or with a custom ROM of some sort, you can always restore your original nv_data.bin and nv_data.bin.md5 files. You'll be back with a locked phone but no harm should be done.
IIRC, the RIL files are part of the proprietaries when used with a custom ROM anyway, so you should be good.
thanks for the reply,its seems a bit tricky for me but will try to get it working when i get my phone (in about a week or so), by the way backupin the /efs partition is with cwmr?
Either that or with a rooted phone. I suggest you make the backup as a tar archive, it'll keep the permissions.
Works like a charm. Running it unlocked since 24h on a foreign SIM without issues. Thank you so much!
(Running OsiMood 2.06.07 + Rogers kernel as posted on the rooting thread + SwissCom SIM card).
i used this method:
http://forum.xda-developers.com/showthread.php?t=859914
to backup my efs to an tar.gz file, is it good enough?
if i need to restore it then i use cwmr?
it's seem that my offset 0x181469 was already at value 00,
and i couldn't find 302720 any where in the file so i tries to go to the offset 0x180069
that you found the string at and saw its all 00
so maybe my phone is already sim free and didn't know it - as i didn't even tried putting my sim to check
cos i thought that its useless to do so.
one question if i will update to ICS, official at&t rom or custom one build upon that rom, will it change my nv_data.bin?
and if so can i put my, presumably sim free, nv_data.bin?
Taiber2000, you should have checked either with a "foreign" SIM or by dialing code *#7465625# which outputs lock status. It would have told you where you stood lock-wise.
Your phone might relock if you flash a stock ROM through Odin or otherwise trigger a factory reset with either no SIM card in the phone or an AT&T/Rogers (as applicable) one.
You could probably return to your unlocked nv_data.bin in that scenario, but in case the ICS update also applies other changes it may be better to unlock the nv_data.bin that's been relocked.
i see i will check it out and see, thanks for the help.
edit: scrach that i found out the problem is with my sim card on the phone, it works on my n97 but no on the glide, will change my sim at my mobile center.
nice unlock, but have some doubts
Darkshado said:
Hello,
I was trying to figure out a way to unlock the phone while keeping my IMEI.
I tried tinkering with the CSC files and factory resets on stock recovery to reapply same. No luck, although I might have been able to relock it to another network, didn't bother testing. (Fixing these files also eliminates any re-locking possibilities on factory reset.)
After some research on other methods and programs for the SGS I, II and III, I managed to pull it off. There are some slight variations across models, but I got the right mix for this one. I've since called, texted and used cellular data with my Virgin Mobile Canada SIM, and it also took my T-Mobile USA SIM without complaint and roamed on Rogers.
Requirements
Working ADB installation
Hex editor
Root (could also be done with CWM on an unrooted ROM.)
Instructions
Backup the /efs partition (ideally with a tar archive as it preserves ownership and permissions information)
Open nv_data.bin in a hex editor.
Go to offset 0x181469
Change the value from 01 to 00
Search for 302720 (Rogers) or an appropriate AT&T MNC/MCC combination (try 310410 or 310380) as applicable.
This should bring you to a series of MNC/MCC pairs. (Which should match those found in your original CSC customer.xml file.) For information, the strings in my file started from offset 0x180069 and read: 30272030237030272#30237#00101#99999#999990001010001012
Overwrite the strings by changing them to xFF
Push the modified nv_data.bin into place. On the stock kernel: push to /sdcard/ first, then adb shell, su, cp to /efs/ and chown radio.radio /efs/nv_data.bin
Reboot the phone
ADB shell, su, then cat /efs/nv.log
The log should spit out a pair of error messages like this:
Wed Aug 29 10:45:04 2012: MD5 fail. orignal md5 '9e1e52346ec8bc3ea07988c967dab04c' computed md5 'd931816e4be7d60a3e41f6fddc27e2e4' (rild)
Wed Aug 29 10:45:05 2012: backup NV restored.
Copy the freshly computed, lightly salted, md5 hash. Paste it over the old one in nv_data.bin.md5
Push both the previously modified nv_data.bin and nv_data.bin.md5 back to /efs/ and don't forget to chown them both again.
Reboot (although on second thought, shutting down, inserting a foreign SIM and turning the phone back on should work)
Done! Confirm the unlock works with a "foreign" SIM, and for bonus points edit the CSC customer.xml file, setting the <NbNetworkLock> property to 0 and deleting the networks listed immediately below.
Goodbye,
Darkshado
Click to expand...
Click to collapse
I tried this, but when looking at the nv.log it doesn't says the new md5 .
when changing the MNC/MCC I see there are 3 5-digit number which should be turned over to 0xFF as string or as hex value? Do I also have to substitute the large last number?
lol samsung accedently unlocked my phone
Luisrcastros: What ROM are you running? Does the nv.log report changes in the NV files and restoring the backup?
The last numbers in the MNC MCC codes are actually standard test MNC and MCCs that a carrier would want the phone to work with in addition to their network. You'll want to overwrite the whole set (54 bytes in the case of the Rogers lock) with 0xFF.
glide relocked ICS
Darkshado said:
Luisrcastros: What ROM are you running? Does the nv.log report changes in the NV files and restoring the backup?
The last numbers in the MNC MCC codes are actually standard test MNC and MCCs that a carrier would want the phone to work with in addition to their network. You'll want to overwrite the whole set (54 bytes in the case of the Rogers lock) with null characters (0xFF).
Click to expand...
Click to collapse
Darkshado: I got a Rogers unlocked glide, then updated to the ATT ICS, it locked the phone. So I´m trying to do the hack on ICS 4.0.4, yes the nv.log report says it´s restoring the nv file from the backup. When I open the nv_data.bin I found your exactly same data.
should I also put FF to the rogers data (302720)
Do you think this will work?
By the way, if anyone has Rogers 2.3 android unlocked, don't try the ATT firmware or you will get locked.
nv.log says:
date: cracking detected
date: NV backup has been rebuilt
date: NV restored
Done
After taking back to stock and root my Rogers captivate glide I was finally able to unlock my phone just by following the instructions from this thread. (hex edit and stuff)
Thanks a lot for the help. This works but you need the rogers kernel and root, you can't unlock with AT&T's kernel.
I'll try to upgrade again to AT&T ICS and let you know if it relocks .
[OBSOLETE THREAD]
This thread is obsolete. A solution was found, which is posted here:
http://forum.xda-developers.com/g4/help/method-to-root-lg-g4s-model-h735-lg-g4-t3248030
Please use the new thread for discussions.
------------------------
Original thread:
------------------------
Hi,
I have been trying to root the LG G4S (H735), also known as "LG G4 Beat".
I tried two things:
Approach 1
I tried the method posted by konsolen in this thread:
http://forum.xda-developers.com/g4/general/lg-g4s-world-root-lg-devices-t3231759
but it didn't work for me. I tried several times with varying approaches, but the boot process always gets stuck on the LG logo.
Approach 2
I also tried to inject the root as suggested in this thread for the G4:
http://forum.xda-developers.com/g4/help/rooting-lg-h735-g4-beat-t3192491
I've used the Inject_Root_G4.zip from this link, which I believe is the same shared elsewhere:
https://mega.nz/#!BIxUzbqI!nt2YnGnGQlSiBQ-Ar-c-q7oDMIEsg6xd0Kmek-q0clg
And I get the same problem - stuck on the LG logo when booting.
For anyone who wants to reproduce Approach 2 to maybe find a solution:
1. Start up LGFlashTool2014. You can follow instructions in thread by konsolen (see Approach 1 above). You can use his .kdz file as well. Important: Pull out your USB cable as soon as the green letters COMX (with a number instead of X) appear on the phone. My flashtool actually didn't display the progress percentage, but apparently this at 9%. It doesn't matter if you don't see the percentage though, I've verified with this KDZ image that if you pull the cable at the very moment the green letters appear, nothing is corrupted. The phone will still display 0%. Leave it as it is after you unplugged the cable.
2. Kill your flash tool with the windows task manager. After it closed, you can plug the phone back in and open a windows command line in the folder where your Send_Command.exe is (you can download the package in konsolen's instructions which contains Send_Command.exe as well).
3. Open the console to your phone with
Code:
Send_Command.exe \\.\COMX.
(with your number instead of X)
You will have to do steps 1-3 every time you want to get this console, for example to run all the dd commands below.
4. Calculate the dd parameters and backup your system partition into a .img file. There is an excellent guide by dominik-p for how to determine your individual dd parameters:
http://forum.xda-developers.com/g4/help/how-to-determine-dd-parameters-lg-g4-t3184867
5. Keep a copy of your system.img somewhere safe, you can use it to restore your system if something goes wrong. So don't use this original in the next steps!
6. Copy the .img file to a linux system and mount it. I'm guessing who is trying this knows how to do this. Anything you change in the folder you mounted the image on, will be saved in the image. You can then use this updated image to overwrite your original system partition, again with dd (as described in the thread by dominik-p) using your parameters. So here's the crucial bit: You get root access to your system files via linux. When you know the right things to mess with, you can root your phone with the updated image. Injecting the root as done in step 8 is one way to change the system on the G4 in order to root it.
7. [Optional] If you are new to this, you may want to do a simple test before you continue.
Create a testfile (test.txt) on the mounted system partition. Then copy the .img file back to your phone and try to "dd" it back over your system partition.
Then, check if you see the test file on your system partition -- you may have to reboot the phone after the dd command (and log back in with Send_Command.exe) in order to see the updates.
8. Inject root with the Inject_Root_G4.zip on the mounted folder of the image on your linux system. You can follow instructions (Step 2) here:
http://forum.xda-developers.com/g4/general/lg-g4-100-root-success-directives-root-t3180586
9. Copy the new img file to your phone and "dd" it over your system partition, using your own dd parameters.
10. Reboot the phone (you can also just type LEAVE in the Send_Command.exe console).
Now, it should be rooted - if it worked for you!
If it worked for you, that's great. It didn't for me, it got stuck on the LG logo in the boot process again. So I had to write my original system.img back onto my system partition to get the phone back.
I did get the following errors in Step 8 above, though I did try anyway to use the resulting image. The errors may have something to do with my problem, but it may also be because the inject root is for the G4, not the G4s.
Code:
sudo ./autoroot.sh
cp: cannot create regular file ‘operatingtable/lib64/libsupol.so’: No such file or directory
chmod: cannot access ‘operatingtable/lib64/libsupol.so’: No such file or directory
chcon: cannot access ‘operatingtable/lib64/libsupol.so’: No such file or directory
chmod: cannot access ‘operatingtable/bin/app_process64_original’: No such file or directory
chcon: cannot access ‘operatingtable/bin/app_process64_original’: No such file or directory
chmod: cannot access ‘operatingtable/bin/app_process_init’: No such file or directory
chcon: cannot access ‘operatingtable/bin/app_process_init’: No such file or directory
If anyone finds a solution to this, or has any ideas what could be tried, I would be very interested to hear it. I'm new to rooting phones and don't have much experience beyond what I did in the last days.
Cheers
Jennifer
jen.magnolis said:
4. Calculate the dd parameters and backup your system partition into a .img file. There is an excellent guide by @dominik-p for how to determine your individual dd parameters:
http://forum.xda-developers.com/g4/help/how-to-determine-dd-parameters-lg-g4-t3184867
Click to expand...
Click to collapse
Happy that my guide has helped you
As I said here:
http://forum.xda-developers.com/g4/help/rooting-lg-h735-g4-beat-t3192491/page5
Everyone who is interested to inject root must edit the autoroot.sh from the inject.zip and use the correct files from SuperSU
More information about the files:
https://su.chainfire.eu
Maybe you have to use other files. Not the files from the inject.zip
Download the Update-SuperSU zip from http://download.chainfire.eu/supersu
Copy the files you need to the "su" folder of the extracted inject.zip
For information which files are needed read the "update-binary" file from the SuperSU zip.
(located here META-INF/com/google/android/update-binary)
Good luck everyone :good:
Thanks again for the links! I'll try again soon, when I get time for it, and report the results here
By the way, here's the ls -lR of my system.
Ok, no problem, take your time.
I've got also lot of other work to do...
I just read your system.txt (thanks)
According to these lines:
Code:
lrwxr-xr-x. 1 root 2000 13 Aug 24 02:05 app_process -> app_process32
-rwxr-xr-x. 1 root 2000 13588 Aug 24 02:05 app_process32
It seems that the firmware is 32 bit.
More info about your firmware is in /system/build.prop
So you have to take the right lines from update-binary and copy them and edit the autoroot.sh
Please don't ask me which lines. It's a bit difficult... (you have to understand the logic in update-binary)
Then copy the files from the right folder (arm?) to the "su" folder.
Sorry. I'm out now here for the next time. I have a H815 and happy with it.
I think you will find the solution. :good:
Custom Recoverys
Hi All
Are there any custom recovery's for the G4 beat/G4s
Thanks
Thanks dominik-p for your help. Good luck with your other work, don't worry I won't distract you with asking questions You already helped a lot.
benji5688, you can check for official firmware (.kdz file) on this link, pasting your IMEI instead of YOUR-IMEI in the link below.
http://csmg.lgmobile.com:9002/csmg/b2c/client/auth_model_check2.jsp?esn=YOUR-IMEI
I did not find any for mine there, but I did find it on
http://devtester.ro/projects/lg-firmwares/
Which brought me to this link where I could find mine:
http://pkg02.azure.gdms.lge.com/dn/downloader.dev?fileKey=FW703UV132GQAUP7A0ED99N/H73510c_00.kdz
but you should look for your specific model.
jen.magnolis said:
Hi,
I have been trying to root the LG G4S (H735), also known as "LG G4 Beat".
I tried two things:
Click to expand...
Click to collapse
LOL
I did the exact same thing as you, and really the EXACT, I also contacted dominik-p for the same problem you got with the bs. LOL
Was about to do the same thing you did here too just told that to dominik-p lol.
You post is great, well detailled. Hope someone found something
But got something different. my phone is the LGH731 LG G4 Vigor from Videotron in Canada.
If someone need files or system.img LINK
That's not the exact same thing as the post owner but i'm pretty sure the root method will be. (DON'T use this system.img to inject in you H735) it's from a H731 and they don't have the same partition size.
Ha, that's funny, and you got the same problem of course (frozen logo boot).
We will find a solution. It's just a matter of time. I'm a bit pressed for work in the next days but I'll get back into it around mid week. I think the main problem was, as I suspected and also as dominik-p pointed out, we've been using the wrong inject files. And the G4s is 32 bit so obviously it won't work with 64 bit libs.
First thing I'll try is using the other files from the link dominik-p shared. I'll also read the guide and try to understand which files need to be changed to gain root access in general, i.e. learn the basics of how to root. Then I think/hope I'll be able to fix this. And finally get to move all my stuff onto SD and get my storage back
Meanwhile, if you get any new results, let me know.
Cheers
jen.magnolis said:
Ha, that's funny, and you got the same problem of course (frozen logo boot).
We will find a solution. It's just a matter of time. I'm a bit pressed for work in the next days but I'll get back into it around mid week. I think the main problem was, as I suspected and also as dominik-p pointed out, we've been using the wrong inject files. And the G4s is 32 bit so obviously it won't work with 64 bit libs.
First thing I'll try is using the other files from the link dominik-p shared. I'll also read the guide and try to understand which files need to be changed to gain root access in general, i.e. learn the basics of how to root. Then I think/hope I'll be able to fix this. And finally get to move all my stuff onto SD and get my storage back
Meanwhile, if you get any new results, let me know.
Cheers
Click to expand...
Click to collapse
Yes i'm trying this today (the 32-64 bits thing)
Custom recovery
What does this file do though?
Is it a custom recovery or is it the stock rom?
Thanks Benji
benji5688 said:
What does this file do though?
Is it a custom recovery or is it the stock rom?
Thanks Benji
Click to expand...
Click to collapse
It's the stock ROM. It can be used for recovery, depending what your problem is. If you destroyed your ROM by trying to root, you can recover with this.
If you mess with something in your system partition (where the Android OS is installed), you'd need a copy of your individual system partition (like a "backup") to restore. This highly depends on your phone/version, so you have to do this backup yourself. You can follow the instructions with the dd parameters, linked to from the main thread.
Are there any custom recoverys
Hi
Are there any custom recovery available, I want to get Xposed.
Can anyone make one?
Thanks for all the help
benji5688 said:
Hi
Are there any custom recovery available, I want to get Xposed.
Can anyone make one?
Thanks for all the help
Click to expand...
Click to collapse
I far as I know to get Xposed you need to be rooted... Well there is no root method availaible, well you can try the methods that Jen explained here but I doubt they will work... if yes, you lucky ****
Is the g4s running marshmallow? Is so you would need to use a compatible su install.
Sent from my VS986 using XDA Free mobile app
larsdennert said:
Is the g4s running marshmallow? Is so you would need to use a compatible su install.
Sent from my VS986 using XDA Free mobile app
Click to expand...
Click to collapse
No the problem is really just changing the 64 bits command to make then use the 32 bits ones
I manage everything except this one
Code:
chcon --reference=operatingtable/bin/app_process32 operatingtable/bin/app_process64_original
I agree with xsteacy, this will most likely not work, that's why we opened this discussion
We just have to find the right files to use (instead of the 64 bit ones).
I will get back onto the subject by Wednesday when I have time.
I solved it! My phone is rooted
I asked someone to test my script before I post the results. Hang on there, tomorrow I'll post the solution.
Good times!
jen.magnolis said:
I solved it! My phone is rooted
I asked someone to test my script before I post the results. Hang on there, tomorrow I'll post the solution.
Good times!
Click to expand...
Click to collapse
0.0 OH!?
Ok I'm putting it out there for others to test as well.
Please report if it worked so I can take this into account before updating the main thread instructions.
In the attached .zip file there is a README with instructions.
Note: Thanks goes to @konsolen who shared instructions on how to open the COM port on the H735.
The script in konsolens post is essentially the upater-binary script of the SuperSU package, but with a few modifications.
That may have been necessary on konsolens phone, but it didn't work on mine. For me, using the original script worked.
However, the zip file has to be extracted manually with busybox before the updater-binary script is started. I am not
sure if busybox absolutely needs to be in the /sbin folder, but that's where I saw elsewhere that it belonged, so
I moved it over there in my script. I haven't tested this with busybox being elsewhere.
Thanks goes also to @dominik-p for sharing the link to excellent documentation and for his instructions on how
to make a backup (with dd) of your system, in case anything goes wrong.
UPDATE: I did all commands in root_lgh375.sh manually when I found it already worked, so please report if all is good with the script, but I think it should be, it only does what I did manually.
Congratulations @jen.magnolis
Well done