Develop Bugs

[SOLVED] Sales Code changed after flashing JPC

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?

[GUIDE] How to check md5sums on files

This information may be old news for experienced users but those new to android may find it useful.
When downloading a new ROM that you would like to flash, it is always possible for corruption to occur. Either in the download itself or in storing it to the SD card. In order to address this issue, most ROMs put out by developers also include an MD5SUM for that ROM. This MD5SUM is used to verify that all of the bits in the file came across right.
Below are instructions on how to verify if the file that you have on your SD card on the phone is not corrupted.. These instructions assume that the file is located at the root of the SD card (as would be needed for flashing ROMs but not necessarily for Recovery Images).
All lines will automatically start with the $ symbol, you need not type this in. Every line ends by pressing the enter key, do not include the quotation marks. The command to show a directory is ls (lower case L and lower case S). this is done in the example to make sure that you use the correct file name when calling the md5sum command.
Open Terminal Emulator
Type "cd /sdcard" and press Enter
Type "ls" or "ls *.zip" to only show zip files and press Enter
This will provide a list of files at the root of the sd card.
Type "md5sum <filename>" substituting the name of the file listed in the ls command for <filename>.
An MD5SUM value will be calculated and displayed. Verify this value against what is published by the developer. If it is correct, go ahead and flash, if not try redownloading the file and repeat. If you continue to get a different MD5SUM value, try downloading it from a different (perhaps mirrored) site
In my example below, I combined the ls command to show only zip files (so that you can see it all on one screen)
http://twitpic.com/39cc3y
Alternatively, you can call the md5sum command with the *.zip or *.img argument and get an md5sum for all files of those types.
For additional information on md5sums, check out this link http://forum.xda-developers.com/showthread.php?t=706705

awesome!

Thank you for helping new people like me who are just entering the Android game.
Sent from my HTC Glacier using XDA App

check md5 file on pc
download a program called teradata
can be found here:
http://www.codesector.com/teracopy.php
install program
open md5 file
ta-da, this will tell you if the files are ok or not

QMAN101 said:
This information may be old news for experienced users but those new to android may find it useful.
When downloading a new ROM that you would like to flash, it is always possible for corruption to occur. Either in the download itself or in storing it to the SD card. In order to address this issue, most ROMs put out by developers also include an MD5SUM for that ROM. This MD5SUM is used to verify that all of the bits in the file came across right.
Below are instructions on how to verify if the file that you have on your SD card on the phone is not corrupted.. These instructions assume that the file is located at the root of the SD card (as would be needed for flashing ROMs but not necessarily for Recovery Images).
All lines will automatically start with the $ symbol, you need not type this in. Every line ends by pressing the enter key, do not include the quotation marks. The command to show a directory is ls (lower case L and lower case S). this is done in the example to make sure that you use the correct file name when calling the md5sum command.
Open Terminal Emulator
Type "cd /sdcard" and press Enter
Type "ls" or "ls *.zip" to only show zip files and press Enter
This will provide a list of files at the root of the sd card.
Type "md5sum <filename>" substituting the name of the file listed in the ls command for <filename>.
An MD5SUM value will be calculated and displayed. Verify this value against what is published by the developer. If it is correct, go ahead and flash, if not try redownloading the file and repeat. If you continue to get a different MD5SUM value, try downloading it from a different (perhaps mirrored) site
In my example below, I combined the ls command to show only zip files (so that you can see it all on one screen)
http://twitpic.com/39cc3y
Alternatively, you can call the md5sum command with the *.zip or *.img argument and get an md5sum for all files of those types.
For additional information on md5sums, check out this link http://forum.xda-developers.com/showthread.php?t=706705
Click to expand...
Click to collapse
Wow, thank you for that! I've been wondering wtf an md5sum is. Now I know.

missing info
Thanks for posting this information - very well written and appears to leave no steps out.
One thing I have to say about a lot of the instructions that are posted about modding - they leave out important step(s) that would be needed to complete the process. Usually it's something that's easily overlooked; what the screen should look like after completing a step, prior to starting the next step. One example, that messed me up (in the past), is partitioning: many instructions gave examples on partitioning, but don't say how to configure the partition (primary, extended, etc)... I had to figure out why my android G1 wasn't working exactly as advertised, because the instructions I found were incomplete.
I think that's why video instructions are awesome - although through bad editing they can suck too.
It's hard work writing instructions, and I thank the people who do, but please write down everything.
This post is just a tangent brought on by reading the original, very well written post.

How did I miss your great post!!! Nice little write up for me checking files on the go.
-John

And for the mac users out there you simply need to open a terminal and type:
md5 <filename>

Or you can get afv (android file verifyer) from the market and just click on the file to generate the md5. Easier if you do it all the time

ahh thanks for spilling the beans
i keep getting "error checking md5sums" when restoring a nandroid back up
I think my SD card is buggered. Its nearly 18 months old and a hell of a lot of transfers on and off it. Maybe time to replace.

i use mand5 and it has an option to google search that checksum. Makes it convenient when devs post the checksum in the OP of their thread because then the search will find it and i can clearly see it's right, 4ext recovery also calculates md5s as well

Another excellent program for verifying checksums on Windows based PCs is Hashcheck. After installation, you'll find a new tab in the properties window of any file which will generate many different types of checksums and contains a box you can type or paste an existing checksum such as one posted with the download. It integrates cleanly with most versions of Windows. You can even use it to create a .md5 checksum file that can be opened to verify the file at any time. This is one of the first applications I install on a clean Windows installation.
And whoever suggested teracopy, it seems to run quite buggy on certain PC setups with mid-transfer freezes and such even on.a fresh Windows installation. SuperCopier is another alternative free file copy/transfer application that I've never seen fail on any of the systems I've used and which has quite similar.functionality to teracopy. Granted, I've only tried a limited number of PCs, but that number continues to grow as I'm basically the technical go-to guy in my family and neighborhood due to my background as a current software programming major.
Sent from my HTC Glacier using Tapatalk

Sorry, double post. My fat fingers hit quote instead of modify.
Sent from my HTC Glacier using Tapatalk

Hash Droid
The app called Hash Droid works perfect for me.
If I helped please press thanks.

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

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

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

very exciting news!!!!!!!

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

hi can anyone build a app

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

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

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

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

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

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

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

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

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

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

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

thanks i will try this later

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

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

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

TWRP and MD5 Checking during flashing

Anyone familiar with how TWRP goes about checking for MD5SUM matching on a file that is being flashed?
Like, do you need to have a .md5 with the same name as the .zip you're flashing? or what is the structure required?
I've tried googling this, but i haven't gotten anywhere, mainly just stuff about md5 and nandroids.

Not sure about your question but the Md5 can be checked with root explorer -long press package of choose-tap properties

After a little research and testing, this is what worked for me.
If all you have is the MD5 hash, then put it in a text file in the same directory as the zip you want to flash. The format should look like this:
Code:
1234567890abcdef1234567890 *app-20120905-final.zip
If the zip is named, for example:
app-20120905-final.zip
Click to expand...
Click to collapse
then that is what goes in the file after the asterisk ( * ).
Also, in this case, the text file you create should be named:
app-20120905-final.zip.md5
Click to expand...
Click to collapse
Hope this helps.
Edit: I just realized how old this thread was. However, I did not find any answers to this question when searching, so hopefully this is still of use to someone.

Thanks for the reply.
I ended up a few weeks ago going to #twrp or #openrecovery (can't remember which) and asked them, and was pointed to a guide:
md5sum some_file.zip > some_file.zip.md5
Sent from my Galaxy Nexus using Tapatalk 2

Yeah. My method was for those not comfortable at terminal, let alone in Linux at all. Glad you got it figured out
Sent from my LTEvo using XDA Premium.

THANKS FOR THIS!!!
i can finally make use of TWRP's MD5 check!

bilbo524 said:
After a little research and testing, this is what worked for me.
If all you have is the MD5 hash, then put it in a text file in the same directory as the zip you want to flash. The format should look like this:
Code:
1234567890abcdef1234567890 *app-20120905-final.zip
If the zip is named, for example:
then that is what goes in the file after the asterisk ( * ).
Also, in this case, the text file you create should be named:
Hope this helps.
Edit: I just realized how old this thread was. However, I did not find any answers to this question when searching, so hopefully this is still of use to someone.
Click to expand...
Click to collapse
Thanks for this, helped me a lot making sure my file was correct and not responsible for the bootloop!

Also, the MD5 hash must be lowercase.

Is the asterix * compulsory?
Otherwise I have a simple one-liner using the Microsoft File Checksum Verifier tool to generate the same file that md5sum does.
Code:
fciv [file] | more +3 > [file].md5
Or in a quick 5-minute batch file I threw together (which allowed me to process the asterix in it):
Code:
@echo off
for %%f in (*.zip) do (
echo Processing [%%~nf.zip] ...
fciv "%%~nf.zip" | more +3 > %%~nf.zip.md5
set LINEONE=1
for /f "tokens=1" %%A in (%%~nf.zip.md5) do (
if %LINEONE% EQU 1 (
echo md5: %%A
echo | set /p mdfive=%%A *%%~nf.zip > %%~nf.zip.md5
) else (
set /a LINEONE = %LINEONE% + 1
)
)
)
echo Done.
pause

Whosat said:
Is the asterix * compulsory?
Click to expand...
Click to collapse
The asterisk indicates the file to be checked is a binary file (as opposed to a text file).
From `man md5sum`:
The sums are computed as described in RFC 1321. When checking, the
input should be a former output of this program. The default mode is
to print a line with checksum, a character indicating input mode ('*'
for binary, space for text), and name for each FILE.
Click to expand...
Click to collapse

[HOW-TO] Bit-flip (nv_data.bin) unlock for the SGH-I927(R), keeps the IMEI valid!

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 .