Related
********NOTE*********
i have included a few of the tools you will need as attachments to this post. I will not take any credit for these programs as i was not the developer for them... these people work too hard to have anyone steal their credit... please give credit where credit is due!Your nv_data.bin file and its matching nv_data.bin.md5 files are located on your phone in /efs/
All references that i make to "sd card" or "/sdcard/" refer to your phone's internal SD Card, not an external SD card that you may have installed.
I have created a windows batch file that you can run and it will extract your entire /efs/ folder from your phone to your PC. I am currently working on the batch script to move the edited nv_data.bin files back to your/efs/ folder and do the other adb stuff.
attached is the EFS Extractor.zip file that contains the ADB files and the batch script.
The product code for your AT&T Captivate is: SGH-I897ZKAATT
WARNING… I AM NOT RESPONSIBLE IF YOU BREAK YOUR PHONE FOLLOWING ANY OF THESE INSTRUCTIONS
The Attached EFS Extractor.zip file contains the necessary adb file and a couple batch files. "retrieve efs.bat" copies your entire /efs/ folder to your PC in a folder called /efs_bkup/ in the directory where you unzipped the file and ran the batch program from. The file "update nv_data.bat" takes your edited nv_data.bin file from the root directory where you ran the .bat file from and places in in your phone's /efs/ folder and removes the old copies from your phone... when it is done, it will power cycle your phone.
To fix your nv_data.bin, you will have to have access to the following tools:
A hex editor (search google for hex editors, they have tons of them that are free… I use one called HexEdit and i have it attached)
GalaxyS_One-Click_Root_All_Models (available via XDA-Developers... attached)
ADB (Android Debugging Bridge) This is available by getting the Android SDK at the Android Developers Website (http://developer.android.com/sdk/index.html) or if you downloaded the Galaxy S One Click Root, it is in the directory where you unzipped the files.
BusyBox – Search the google market for “BusyBox”. It will appear and will be the free one from stericson (i have included the .apk as an attachement)
Odin One-Click Downloader (available from XDA)… make sure you get the correct one. There are 2 versions. If you batch number is 1008 then you need the one with the 3-button fix, if you batch number is greater than 1008 then you should need the regular one. Your batch number is written on the sticker on your phone under your battery on the left side right under the words “S/N” where your serial number is listed.
Samsung Kies Mini (gotten from Samsung website)
Download the attached EFS Extractor .zip file. It contains everything you need to copy your /efs/ folder to your PC
Now for what you need to do to get your phone’s nv_data.bin back to normal:
Flash back to stock and then do a master clear using Odin One Click
put phone into USB debugging mode and also check the setting to "stay awake"
connect phone to PC and root and install busybox
extract the attached EFS Extractor.zip file and run the "retrieve efs.bat" file. This will copy your entire /efs/ folder from your phone to your PC in a direcotry called ./efs_bkup/
Using the Hex Editor, edit the file ./efs_bkup/efs/nv_data.bin on your PC to have the correct product code SGH-I897ZKAATT. do an ASCII search for "SGH" to locate the line in the file that contains your product key. then save the edited file to ./nv_data.bin (the root directory where you extracted your ZIP file to on your PC)
run the file "update nv_data.bat" to copy your corrected nv_data.bin to your phone's efs folder and chown it and reboot your phone
change USB Settings on phone back to Kies then open Kies Mini and connect phone.
you should now be able to connect to Kies Mini and not have unregistered device... now would be a good time to back_up your /EFS/ folder... you can now either do Odin One-Click and a master clear, or flash a different rom. You should do Odin if you want to use Kies to get updates to be 100% stock to remove your root and busybox.
The general overview what what you need to do is this for those of you that want to know and/or use other tools to do this
Copy your /efs/nv_data.bin file from your phone to your PC
Use a hexeditor to modify the line in the nv_data.bin file that contains the productcode to contain your correct product code
delete any nv_data.* files from your /efs/ folder on your phone
copy the corrected nv_data.bin file from your PC to your /efs/ folder on your phone
busybox chown 1001:1001 /efs/nv_data.bin
reboot phone
Done!
Now, when you backup your /efs/ folder to your PC you may see files like nv_data.bak and nv_data.bak.md5. Using a hexeditor, open the nv_data.bak file and look at the line that has the product code (ASCII values starting wtih SGH)... if the product code in the .bak file is correct, then delete the nv_data.bin and nv_data.bin.md5 from your /efs/ folder on your phone and reboot your phone. Your phone should then create new .bin and .bin.md5 files from the .bak and .bak.md5 files that will have the proper productcode. You can also optionally rename the .bak and .bak.md5 files on your PC to be .bin and .bin.md5 and copy them to your /efs/ folder on your phone.
You can view what Kies is reading your productcode as by opening your windows registry editor Start>Run>regedit[enter]
Connect phone to PC in Kies(Firmware) mode
Navigate to HKEY_CURRENT_USER/Software/Samsung/KiesMini/FUS
Look at the key "PRODUCTKEY" and what it's value is... if it is correct, then you are good. If not, then something went wrong somewhere.
If you have issues please post the issues you are having and I will update as necessary.
Here is a link to a different thread that contains a program and instructions for restoring your unlock codes if that is what you are trying to do. The .jar (java program is written in frech, but it only asks for the codes you want to use for your unlock codes... i did not make this program so I cannot help you with it.
http://forum.xda-developers.com/showpost.php?p=8983897&postcount=103
Tried to trim this down a little as there are a ton of steps, let me know if any of this is incorrect.
1. Flash back to stock rom, and do a master clear using the Odin3 One-Click Downloader by designgears
2. Root using one-click-root and install busybox, turn on usb development mode + stay awake, and connect to your PC.
3. Open a command prompt window and navigate to the directory where you extracted the one-click-root. Run the following commands:
a. adb shell
b. su
c. cp /efs/nv_data.bin /sdcard/nv_data.bin
d. cp /efs/nv_data.bin /sdcard/nv_data.bin.copy (incase there is a problem)
e. rm /efs/nv_data.*
4. Exit your adb.exe window, mount your phone on your PC and navigate to the internal card. Edit the nv_data.bin with a hexeditor (bpsoft.com) and search (ascii) for "SGH-" (without the quotes)
5. It may be something like SGH-I897ZKATOR or SGH-I897ZKATMB. You need to change this to SGH-I897ZKAATT then save the file, and unmount your phone.
6. Disconnect usb data cable from pc to phone, re-enable usb development mode + stay awake, reconnect.
7. Open a command prompt window and navigate to the directory where you extracted the one-click-root. Run the following commands:
a. adb shell
b. su
c. cp /sdcard/nv_data.bin /efs/nv_data.bin
d. busybox chown 1001:1001 /efs/nv_data.bin
8. Power cycle
Hi hansomni. l've been down this road. Were you successfull with creating Nv_data.bak this way and restoring with that. For example editing nv_data.bak and making a corresponding md5 file and only placing those files in your efs folder and restarting your phone
I had problems creating this file. i would always get an incorrect iemi. This is why i recommend using nv_data repair.zip posted in the tmo vibrant unlock thread not only can you recreate the correct product code but also fix the fffffffff for unlock code.
Have you checked this outhttp://forum.xda-developers.com/showpost.php?p=8983897&postcount=103
mattbeau said:
Hi hansomni. l've been down this road. Were you successfull with creating Nv_data.bak this way and restoring with that. For example editing nv_data.bak and making a corresponding md5 file and only placing those files in your efs folder and restarting your phone
I had problems creating this file. i would always get an incorrect iemi. This is why i recommend using nv_data repair.zip posted in the tmo vibrant unlock thread not only can you recreate the correct product code but also fix the fffffffff for unlock code.
Have you checked this outhttp://forum.xda-developers.com/showpost.php?p=8983897&postcount=103
Click to expand...
Click to collapse
yeah... i have been successful using the steps i outlined... like i said in the original post, this is only to get your product code fixed... i don;t have an unlocked phone so i don't know if that program works... i did use it to check it out, but it is written in frech or something and it never copied the "patched" nv_data files back to my phone... i had to do it manually and still the product code from the created files were wrong. Others say that they have had success using it, but i never did. I took a buch of stuff from a buch of posts on this site to compile the guide here for restoring product codes only.
the .bak files are your backup files that get generated sometimes... usually those files have your correct unlock codes and productcode... to restore them, just delete the non .bak files and remove the .bak extension from the backups... then copy them to your /efs/ folder and powercycle and you should be good. you should keep all your orignial files from your /efs/ folder in a safe place though so you have them to fall back on if you need to. I have never had the .bak files in my /efs/ folder so i haven't ever been that lucky.
devz3r0 said:
Tried to trim this down a little as there are a ton of steps, let me know if any of this is incorrect.
1. Flash back to stock rom, and do a master clear using the Odin3 One-Click Downloader by designgears
2. Root using one-click-root and install busybox, turn on usb development mode + stay awake, and connect to your PC.
3. Open a command prompt window and navigate to the directory where you extracted the one-click-root. Run the following commands:
a. adb shell
b. su
c. cp /efs/nv_data.bin /sdcard/nv_data.bin
d. cp /efs/nv_data.bin /sdcard/nv_data.bin.copy (incase there is a problem)
e. rm /efs/nv_data.*
4. Exit your adb.exe window, mount your phone on your PC and navigate to the internal card. Edit the nv_data.bin with a hexeditor (bpsoft.com) and search (ascii) for "SGH-" (without the quotes)
5. It may be something like SGH-I897ZKATOR or SGH-I897ZKATMB. You need to change this to SGH-I897ZKAATT then save the file, and unmount your phone.
6. Disconnect usb data cable from pc to phone, re-enable usb development mode + stay awake, reconnect.
7. Open a command prompt window and navigate to the directory where you extracted the one-click-root. Run the following commands:
a. adb shell
b. su
c. cp /sdcard/nv_data.bin /efs/nv_data.bin
d. busybox chown 1001:1001 /efs/nv_data.bin
8. Power cycle
Click to expand...
Click to collapse
Yeah, looking at it quickly it looks like all the instructions are correct... maybe abbreviated too much... Thanks for that... i will update with instuctions similar.... i have to remember that there are those folks that have never used adb or know what it is. I will credit you in my update tomorrow. I am used to where i work we have people that use computers that don;t know how to power them on and off so they just leave them on all the time... i have to be very specific on my instructions that i tell them so they can understand... a two second task becomes an all-day event. Just something i am used to doing.
I will be working on a dos script (.bat) file that will do most of the adb stuff so then the users only need a few things to do and just let the scripts take care of the rest.
hansonmi said:
yeah... i have been successful using the steps i outlined... like i said in the original post, this is only to get your product code fixed... i don;t have an unlocked phone so i don't know if that program works... i did use it to check it out, but it is written in frech or something and it never copied the "patched" nv_data files back to my phone... i had to do it manually and still the product code from the created files were wrong. Others say that they have had success using it, but i never did. I took a buch of stuff from a buch of posts on this site to compile the guide here for restoring product codes only.
the .bak files are your backup files that get greated sometimes... usually those files have your correct unlock codes and productcode... to restore them, just delete the non .bak files and remove the .bak extension from the backups... then copy them to your /efs/ folder and powercycle and you should be good. you should keep all your orignial files from your /efs/ folder in a safe place though so you have them to fall back on if you need to.
Click to expand...
Click to collapse
You dont even need to change the extenaion of those files if you power cycle your phone with just .Bak files. Your phone will recreate the nv_data.bin and md5 from those .Bak files and create a log file
Yeah i know the java program is in french. But its only asking you what two codes you want to use for unlocking your phone ( ahh google translate)
And yes the first time i tried the program i had trouble too. I think it helps if you have a good busybox version.
Believe me the easier you can make it the better it will be for everyone. Now if we could just get everyone to back up that folder before flashing anything we wouldnt even need to go down that road. Thanks for your help in this. Ill leave this thread alone now sorry if im intruding. Pm me if you need any help
mattbeau said:
You dont even need to change the extenaion of those files if you power cycle your phone with just .Bak files. Your phone will recreate the nv_data.bin and md5 from those .Bak files and create a log file
Yeah i know the java program is in french. But its only asking you what two codes you want to use for unlocking your phone ( ahh google translate)
And yes the first time i tried the program i had trouble too. I think it helps if you have a good busybox version.
Believe me the easier you can make it the better it will be for everyone. Now if we could just get everyone to back up that folder before flashing anything we wouldnt even need to go down that road. Thanks for your help in this. Ill leave this thread alone now sorry if im intruding. Pm me if you need any help
Click to expand...
Click to collapse
Yeah... the problem is that not everyone knew to do it before flashing as a lot of the ROM pages don't say it (I was one of them that never knew about it)... i knew what the java was saying but since i don't have an unlocked phone, i had no way of testing it to see if it worked for me or not... and on top of that it didn't work with restoring my productcode (i know that becuase i couldn't use Kies until i did things manually)... I tell people to rename the files, becuse i am assuming they copy the contents of their /efs/ folder to a PC or something... then they just have to delete the nv_data files from /efs/ on their phone, and rename the .bak files on their PC and copy them back to their phone's /efs/ so they still have a copy of their original files saved on their PC... plus i don't like relying on the phone doing the renaming because if it doesn't no one will know what went wrong...
Working on Windows Batch (.bat) script
I will be working on doing a windows .bat script that will do most of the dirty work for you... it may take a couple days because where i work the end of the year is the busiest time for me and i don't have a lot of time between work during the week.
I will make the script an attachment and will hopefully be able to zip with the abd files to make life a little easier for everyone.
Thanks for the input everyone.
What line
Could someone that has successfully done this post what line in the hex file the product code is found on. All I get is string not found??? Thanks
Worked great, followed steps exactly as outlined didn't have any problems. Thanks again for this, I've been wanting to have a proper backup of efs folder with correct product code, but could never change it back.
Slowazz28 said:
Could someone that has successfully done this post what line in the hex file the product code is found on. All I get is string not found??? Thanks
Click to expand...
Click to collapse
I used hexedit, and if the line number is in first column it begins on line 188010. I did notice when searching a second time to get line number, that I had to have sgh- in all caps, and once i got string not found, I closed program reopened and searched again using caps (SGH-) it worked several times. Hopes this helps.
Big thanks for posting this.
I'll give this a shot prior to flashing Axura 2.5.
Thanks hansonmi! I got it updated with kies. I done it a lil diffent using root explorer to move files around and used hexeditor to edit files and root explorer to copy back.
great guide.
wish this would have been around the first time i ran into this problem as it was a headache when it happened and the threads and advice on fixing were so fragmented within the forum threads.
The only thing i did differently was that i didn't use ADB on a pc at all during the process (I completed the process using both Root Explorer and Terminal Emulator on my phone and copying files to pc via mounting the phone and its storage as disk drives).
(PS before doing any of this i backup up my efs folder first to my external SD using root explorer and then to my pc via mounting the phones storage)
1. I had already copied my nv_data.bin file to external SD when backing up EFS folder.
2. Connected to pc via usb and mounted for storage (with debugging on)
3. copid nv_data to pc
4. used PsPad to edit the nv_data file in accordance with previous instruction in this thread. (I highly recommend PSpad as a hex editor. Its nice that you can switch back and forth between hex and text editor views) See PS in the end for using PSpad hex editor to find the line you need to edit. That seemed to be the only thing that needed clarified.
5. copy nv_data.bin back to the root directory of external sd
6. use root explorer to move newly edited nv_data from external sd back to original EFS folder.
7. Delete the nv_data..bin.md5 file..i left the backup from efs folder
7. delete any nv_data.baks from efs folder
8. Now the use of Termainl Emulator (download from market). Busybox must be installed as well
9. Open terminal emulator execute following commands:
SU
busybox chown 1001:1001 /efs/nv_data.bin
reboot
(reference to step 4 using hex editor)
PS - These are the steps for editing the hex code and starting with step first step assuming you have copied the nv_data.bin to your PC
1. Open PsPad (or other hex editor)
2. Open nv_data.bin in hex editor mode
3. Go to line 188000 (using search modes you will likely have to enter $00188000 or 00188000) Using PsPad you would do the following:
Select SEARCH from top tool bar. Select GOTO LINE.......then enter $00188000
4. You will see yTMB....SGH_i897ZKATMB (or yTOR....SGH-ZKATOR).
5. Replace that first TMB or TOR with ATT then replace ZKATMB or ZKAATOR with KZAATT
6. Save
7. Now you should have a proper nv_data.bin
HBeezy said:
I used hexedit, and if the line number is in first column it begins on line 188010. I did notice when searching a second time to get line number, that I had to have sgh- in all caps, and once i got string not found, I closed program reopened and searched again using caps (SGH-) it worked several times. Hopes this helps.
Click to expand...
Click to collapse
Ok that worked great except when I get to that line it says productcode several times then a bunch of x's then 11 0's but no SGH- so not sure where to put it in at. The 0's start on line 1880f0 and end on line 188100 ??? Appreciate the help
Slowazz28 said:
Ok that worked great except when I get to that line it says productcode several times then a bunch of x's then 11 0's but no SGH- so not sure where to put it in at. The 0's start on line 1880f0 and end on line 188100 ??? Appreciate the help
Click to expand...
Click to collapse
what hex editor are you using?
i recommend downloading the free PSpad Hex/Txt editor.
1. Open your nv_data file using FILE then OPEN IN HEX EDIT
2. use SEARCH from toolbar commands....GOTO LINE from search menu....options after opening in hex edit mode
3. then search for $00188000
you should see the line you need to edit.
The nice thing about PSPAD is that you can also open the binary file in a Text mode. If you have trouble finding it in the hex editor mode try the following.
1. open PSpad. Goto FILE then OPEN (vs. open in hex edit). This will open in a text editor view/mode.
2. goto SEARCH and select INCREMENTAL SEARCH
3. type SGH and search
(you could also do all the hex editing without moving files to pc if you wanted using HEX EDITOR from market...though for most the PC hex editors might be easier)
if you want to use the android hex editor app to do all the editing on your phone...do the following:
THERE ARE 3 Total Lines you will need to edit:
00188008
00188010
00188020
1. Use Root Explorer to copy nv_data.bin from efs folder to the root directory on your external sd.
2. Use Hex Editor App to open the copy from your external SD.
3. One Open click the capacitive menu button and select jump to address
4. Enter 0188008
This will take you to line 00188008
5. Edit the last or 8th Block so it reads 41.
6. Enter 0188010
7. This will take you to line 00188010. Edit the first two blocks of this line. Replace the #'s so that both of the first two blocks contain 54. (look to the text at the right of screen the first two letter should have changed to TT. To recap you need to edit Block 1 and Block 2 of line 0018010:
LINE 0018010
Block 1 = 54
Block 2 = 54
(text @ right should now read TT....SG)
8. Now look down to line 0018020 and look at the line. If you at the line and to the far right text you will see ATOR or ATMB if your nv_is messed up.
9. You may need to edit blocks 2-4. They should read as follows:
LINE 00188020
Block 2 = 41
Block 3 = 54
Block 4 = 54
(the text at the right of your screen should now read AATT....)
10. Save the file and move it back to efs using root explorer.
PS: Here are how the following lines should read (the ones in bold are the only ones you have to edit as line 00188018 will already be correct):
00188008|2e|34|00|00|00|00|ff|41|.4....A
00188010|54|54|00|00|00|00|53|47|TT....SG
00188018|48|2d|49|38|39|37|5a|4b|H-I897ZK
00188020|41|41|54|54|00|00|00|00|AATT....
bames said:
what hex editor are you using?
i recommend downloading the free PSpad Hex/Txt editor.
1. Open your nv_data file using FILE then OPEN IN HEX EDIT
2. use SEARCH from toolbar commands....GOTO LINE from search menu....options after opening in hex edit mode
3. then search for $00188000
you should see the line you need to edit.
The nice thing about PSPAD is that you can also open the binary file in a Text mode. If you have trouble finding it in the hex editor mode try the following.
1. open PSpad. Goto FILE then OPEN (vs. open in hex edit). This will open in a text editor view/mode.
2. goto SEARCH and select INCREMENTAL SEARCH
3. type SGH and search
(you could also do all the hex editing without moving files to pc if you wanted using HEX EDITOR from market...though for most the PC hex editors might be easier)
if you want to use the android hex editor app to do all the editing on your phone...do the following:
THERE ARE 3 Total Lines you will need to edit:
00188008
00188010
00188020
1. Use Root Explorer to copy nv_data.bin from efs folder to the root directory on your external sd.
2. Use Hex Editor App to open the copy from your external SD.
3. One Open click the capacitative menu button and select jump to address
4. Enter 0188008
This will take you to line 00188008
5. Edit the last or 8th Block so it reads 41.
6. Enter 0188010
7. This will take you to line 00188010. Edit the first two blocks of this line. Replace the #'s so that both of the first two blocks contain 54. (look to the text at the right of screen the first two letter should have changed to TT. To recap you need to edit Block 1 and Block 2 of line 0018010:
LINE 0018010
Block 1 = 54
Block 2 = 54
(text @ right should now read AT....SG)
8. Now look down to line 0018020 and look at the line. If you at the line and to the far right text you will see ATOR or ATMB if your nv_is messed up.
9. You may need to edit blocks 2-4. They should read as follows:
LINE 00188020
Block 2 = 41
Block 3 = 54
Block 4 = 54
(the text at the right of your screen should now read AATT....)
10. Save the file and move it back to efs using root explorer.
PS: Here are how the following lines should read (the ones in bold are the only ones you have to edit as line 00188018 will already be correct):
00188008|2e|34|00|00|00|00|ff|41|.4....A
00188010|54|54|00|00|00|00|53|47|AT....SG
00188018|48|2d|49|38|39|37|5a|4b|H-I897ZK
00188020|41|41|54|54|00|00|00|00|AATT....
Click to expand...
Click to collapse
Ok, So my nv_data.bin must be fubared cause I don't even have lines 188008 or 188018. They go by 10's like 188000, 188010, 188020, ect. And the text to the right of line 188010 starts TT....SG not AT....SG
File
I didn't back this up from my first flash to a custom ROM. Stated at the beginning it says this is likely unfixable. I have run Axura, Cog and Perception Roms (not in that order). Not sure if that makes a difference. Is this still fixable? The problem I have (using new market) is apps are either
A) Installed and not showing so on the market
B) I have them installed and they disappear & have to reinstall them from the market only to have them disappear from my phone again
C) Unable to download them (such as Pocket Legends)
Any feedback is appreciated.
Thanks
Slowazz28 said:
Ok, So my nv_data.bin must be fubared cause I don't even have lines 188008 or 188018. They go by 10's like 188000, 188010, 188020, ect. And the text to the right of line 188010 starts TT....SG not AT....SG
Click to expand...
Click to collapse
my bad
the 188010 should start TT i will correct my original.
but you should be able to find lines 188008 an 18 though you wont need to do anything with 18. Did you try looking at it with the android hex editor app from market?
You won't see the 008 and 018 lines if your using a hex editor on PC you will only see the lines by by 10's.
The section you are referring to are for Using Android Hex Editor App on your phone.
-----------------------
if your using a hex editor on your PC you should see the following when corrected:
188000 | FFFF | FFFF | 5245 | 5630 | 2E34 | 0000 | 0000 | FF41 |
188010 | 5454 | 0000 | 0000 | 5347 | 482D | 4938 | 3937 | 5A4B |
188020 | 4141 | 5454 | 0000 | 0000 | 0000 | 0150 | 024E | 034E |
Slowazz28 said:
Could someone that has successfully done this post what line in the hex file the product code is found on. All I get is string not found??? Thanks
Click to expand...
Click to collapse
It really depends on the editor you are using and you have to make sure you are searching for ASCII...
in the edit that i use, it is line 188010
I whipped this up because I wanted to associate a program with APK files so that I could
Have a friendly Android guy on my apk files
be able to double click the apk files and have them installed
be able to associate the program with that file type in FireFox so it will install them
install multiple APK files at the same time
It's made with AutoIT and assumes that you have the SDK installed under C:\android-sdk-windows\ if that's not the case you can edit the script. I have the /K argument enabled which will leave the command line open, you can change that to /c and it will close it.
Code:
$quot = Chr(34)
Dim $list = ""
For $i = 1 to $CmdLine[0]
RunWait(@ComSpec & " /k " & "C:\android-sdk-windows\tools\adb.exe install " & $quot & $CmdLine[$i]& $quot)
Next
oh Wow. Great idea. I think some more instruction is in order tho.... how to make work
I've updated this to support the new keys in android 4.2.2 and have the adb server bundled into the autoit file. it's all included in the ZIP archive.
Code:
#Region
#AutoIt3Wrapper_Icon=Google-Android.ico
#EndRegion
$quot = Chr(34)
FileInstall("adb.exe", @TempDir & "\adb.exe", 1)
FileInstall("AdbWinApi.dll", @TempDir & "\AdbWinApi.dll", 1)
FileInstall("AdbWinUsbApi.dll", @TempDir & "\AdbWinUsbApi.dll", 1)
Dim $list = ""
For $i = 1 To $cmdline[0]
RunWait(@ComSpec & " /k " & @TempDir & "\adb.exe install -r " & $quot & $cmdline[$i] & $quot)
Next
FileDelete(@TempDir & "\adb.exe")
FileDelete(@TempDir & "\AdbWinApi.dll")
FileDelete(@TempDir & "\AdbWinUsbApi.dll")
how to make it work: you can use my pre-compiled exe or compile your own. Then you either double click a .apk and select the exe as the program to open them or drag a apk onto the exe. It will launch a command line window and run the install. If it works it will tell you. If it doesn't, it will tell you why.
Nice script bro! work like a charm
Script is standalone : you can download latest version without upgrading from previous version
v1.6 > Big update on 3G+ tweak addon, more powerful and much faster
Build.prop Worktool - A powerful but safe build.prop manager/editor
Hi !
Okay guys, since I know how powerful the build.prop can be, I love to play with it.
But I was bored to edit using Root Explorer, or using ADB command-line...
So... Let me present you my outrageously complicated (internally) script to manage your build.prop right from your computer, with ease, fun and safety !
GENERAL :
For any Windows NT kernel (Developped under Windows 7 x64... so should work everywhere )
Portable and ready to use - No installation required, all files included (ADB with drivers also)
Lightweight (<3Mb unzipped, because of ADB very big lol)
Tested on XPERA x10i but should work on ANY Android powered device (if your ROM uses a build.prop located into /system/)
KEY FEATURES :
Easy open/edit your build.prop in your default text editor
Backup creation/management
Save backup on your computer and/or on your device
Safe (Automatic backup generator - Manages up to 2 backup files, exhaustive log file)
Automatic permissions management
Add-on capability : possible to add automated installation scripts to tweak your build.prop
List of present add-ons : 3G+ enhancement tweak
Very clean : deletes all temporary files, auto start/stop ADB server and kills the process when useless
Convenient : direct access to this thread, easy to use
v1.6+ : (beta) Build.prop XPlorer, to check with ease your build.prop
I based the main script on my 3G+ enhancement script, available on the official thread.
** As usual... Use at your own risk **
Test, comment, criticize, if you find anything, just drop a comment or PM
FAQ
FAQ- Supported devices
It is first developped for Sony Ericsson XPERIA x10, but it should work on any Android device with these requirements :
* Rooted
* File system is mounted Read/Write.
* Build.prop is located into /system/ and named "build.prop"
Sony Ericsson XPERIA x10 : fully working
Samsung Galaxy S2 : half working (file system is read-only...)
- How it's working ?
The script works generally in this way :
It downloads from your device your build.prop and creates two temporary backups.
Then, it opens one of the temporary backup into notepad, to let you edit all you want.
Once file closed/saved, the file is reconfigured automatically, then sent back to your device.
The script allows you next to keep, on wish, the remaining backup and to reboot your device.
- Is this safe ?
The script makes a backup of your build.prop every time you try to access it. There's also human-friendly log file to help you identify problems with ease.
There is also NO automatic upload to your device : the script will always ask you before if you want to upload the new build.prop to your device. Even if you upload it, backup is stored and can even be stored safely on your device for future use.
- Is this all automatic ?
Yes. The script makes backups by itself, reboot your device for you (if you wish), and of course change permissions. But don't worry : it will ask your approval for any important process
- The 3G tweak makes my connection unstable !
The Manager is based on my 3G+ enhancement script, using "Full Mode". In the original script, there is also a "Lite Mode" for some networks (like AT&T) I included in v1.3.
To make your network stable, the script will disable the two lines below :
ro.ril.enable.dtm=1 (will be turned to 0)
ro.ril.enable.a53=1 (will be turned to 0)
To get full details about the 3G+ tweak, check the thread :
http://forum.xda-developers.com/showthread.php?t=951765
Why is there "so many" different batch files ?
It's easier for me to improve/maintain the batch by splitting it into different functions. There's a main script, and subroutines called when needed.
Of course, all the subroutines, including addons, are programmed to be run only from main script. You can run any subroutine separately, but it will mostly crash and create useless files not being deleted. Always run the main script, and do no try to run separately subroutine - not dangerous, but 100% useless/buggy.
- It's not working.
* Make sure your device is :
** ROOTED,
** Full external access to system (su command) [if not, will drop errors like "Operations not permitted" or "file system is mounted read only")
** USB Debugging is enabled,
** Connected using USB and all USB drivers are installed/working.
* You might need administrative privileges in Windows to fully run the program.
* If you're running your device from recovery, you may need to mount /system/ folder before running the script (Partition tools > Mount /system).
- It's still not working.
* Drop a message in the official thread.
* If you get errors about file system Read only, try to run your device in Recovery mode, and fix permissions.
- Will the script create lots of files/make a big drive footprint ?
I hate programs creating lots of temp files. So, the script was developped to create files AND to clean/remove them all once everything is done. Even if it crashes without removing files, you just need to restart the script - it will clean all previous temporary files.
If ADB is run, it WILL be fully closed once everything is done. Server will be killed, then ADB process (named adb.exe) will be killed. Your system will be as clean as it was before running the script.
The script is of course fully portable : there's no installation needed. You can put the script where you want, but you just need to keep all script files/folders in the same folder.
In a future release, I'll add something to purge the log file.
- Which OS is supported ?
It's developped in Windows 7 x64. You should be able to fully run it on any 2000+ Windows NT OS.
As it is NT script, it will work only on Windows computer. It will also not work properly on pure DOS (it's using NT commands and Windows-related commands not included in older Windows NT systems, like NT4).
Report if you tested it on other Microsoft OS (NT 4, Windows 95, 98 or 2000, Dos 6.22...)
- I wanna contribute.
Just right click the .cmd/bat files, edit them with Notepad or anything you want
You can also send me a message (thread or PM) if you notice some piece of code I can improve with other commands (I don't know DOS commands enough )
v1.0 (11/5/2011) = initial release
v1.1 (13/5/2011) = removed BFC tags, updated error 2 (ADB get-state, to help you identify problem), removed 3G tweak returns error 3 if not present (addon = not necessary), added template.bat to create add-ons, improved launcher.bat (add-on primitive detection), added add-on installation detector (displays backup/reboot options only when add-on was installed), corrected folder "\" bug
v1.2 (13 may formely 14/5/2011) = added automated deleter/file checker for 3G+ tweak. Still early stage but looks to work. Automated batch thanks to http://www.dostips.com
v1.3 (16/5/2011) = added 3G+ enhancement lite mode (for networks like AT&T) and removed 1 step on auto deletion, fixed bug of false error when trying to download from device a build.prop.bak not existing, added management options to Backup (send local backup to device, delete backup on device), solved backup internal error
v1.4 (29/5/2011) = fixed window console size, enhanced menus, faster script closing, log file generator, several bugs fixed, enhanced help (readme in Notepad, direct open XDA thread in Firefox), added adb.exe process killer
v1.5 (6/6/2011) = added console title, fixed some menu bugs, updated Readme, weblinks now open in the default user browser, build.prop will now open in default notepad editor, improved interface, fixed unexpected exit bug, added contact me using default email (still experimental)
v1.6 (15/6/2011) = improved ADB process killing, deeply improved 3G tweak script with sed and no more TXT file, readme opens in your default editor, improved interface, updated template, unified common subroutines into BAKengine.bat, user-friendly explorer of build.prop (not great for now), deleted Substengine (deprecated), "0" in menues now refers to Go Back/Exit, improved missing engines detection, added general temp/log file purger/deleter ** To celebrate The Legend of Zelda series 25th Anniversary, my script is now tagged "Powered by Hyrule DOS"
DETAILLED 3G Addon update :
- detects presence of previous installation and files
- Sed command : fastest detection and subtitute of lines
- Optimized for fastest operation and fully clean build.prop file
- Several stuff...
External SED support thanks to GNU Utilities for win32 @ http://unxutils.sourceforge.net/
v1.7 (26/7/2011) = fixed no deletion of TEMP folder/files, fixed ADB command not found, new entries for XPlorer
Known bugs :
* (Main) Will not detect if build.prop.bak and build.prop.old are the same (not very important, I'll improve this later)
* Report anything you find
Developper/Advanced user addendum
(Write in progress)
Backup management
The script creates up to two backups, localed in main directory :
- build.prop.bak
- build.prop.old
Build.prop.old is generated if the script detects there's an existing build.prop.bak, to avoid accidental loss of it.
Build.prop.old is the final backup, and WILL BE DELETED if detected. The script manages backups like this :
1. If an existing build.prop.bak is present...
>> Script will detect for build.prop.old presence - if it exists, it will be deleted,
>> the build.prop.bak will be renamed to build.prop.old.
2. If there is no build.prop.bak detected...
>> Script will generate a build.prop.bak.
ADB Error detection
Error 2 (device not connected) works using a trick - it's not really related to device state.
In fact, the script will attempt to connect your device to download your build.prop. Once it is done - or not - the script checks if a local build.prop file was created. If it's not present, it means ADB encountered an error - about 90% because device is not connected - and will display error 2.
Keep in mind then there is small chance that your error does NOT come of device not connected : administrative privileges missing (don't allow the script to create the file), drivers buggy, ...)
Hi,
I cant use your WorkTool V1.6
It says ADB cmd not found.
v1.7 out, sorry for delay, I prepared it few days ago then I forgot to upload ^^
Really good work
Perceval from Hyrule said:
FAQ- Supported devices
It is first developped for Sony Ericsson XPERIA x10, but it should work on any Android device with these requirements :
* Rooted
* File system is mounted Read/Write.
* Build.prop is located into /system/ and named "build.prop"
Sony Ericsson XPERIA x10 : fully working
Samsung Galaxy S2 : half working (file system is read-only...)
- How it's working ?
The script works generally in this way :
It downloads from your device your build.prop and creates two temporary backups.
Then, it opens one of the temporary backup into notepad, to let you edit all you want.
Once file closed/saved, the file is reconfigured automatically, then sent back to your device.
The script allows you next to keep, on wish, the remaining backup and to reboot your device.
- Is this safe ?
The script makes a backup of your build.prop every time you try to access it. There's also human-friendly log file to help you identify problems with ease.
There is also NO automatic upload to your device : the script will always ask you before if you want to upload the new build.prop to your device. Even if you upload it, backup is stored and can even be stored safely on your device for future use.
- Is this all automatic ?
Yes. The script makes backups by itself, reboot your device for you (if you wish), and of course change permissions. But don't worry : it will ask your approval for any important process
- The 3G tweak makes my connection unstable !
The Manager is based on my 3G+ enhancement script, using "Full Mode". In the original script, there is also a "Lite Mode" for some networks (like AT&T) I included in v1.3.
To make your network stable, the script will disable the two lines below :
ro.ril.enable.dtm=1 (will be turned to 0)
ro.ril.enable.a53=1 (will be turned to 0)
To get full details about the 3G+ tweak, check the thread :
http://forum.xda-developers.com/showthread.php?t=951765
Why is there "so many" different batch files ?
It's easier for me to improve/maintain the batch by splitting it into different functions. There's a main script, and subroutines called when needed.
Of course, all the subroutines, including addons, are programmed to be run only from main script. You can run any subroutine separately, but it will mostly crash and create useless files not being deleted. Always run the main script, and do no try to run separately subroutine - not dangerous, but 100% useless/buggy.
- It's not working.
* Make sure your device is :
** ROOTED,
** Full external access to system (su command) [if not, will drop errors like "Operations not permitted" or "file system is mounted read only")
** USB Debugging is enabled,
** Connected using USB and all USB drivers are installed/working.
* You might need administrative privileges in Windows to fully run the program.
* If you're running your device from recovery, you may need to mount /system/ folder before running the script (Partition tools > Mount /system).
- It's still not working.
* Drop a message in the official thread.
* If you get errors about file system Read only, try to run your device in Recovery mode, and fix permissions.
- Will the script create lots of files/make a big drive footprint ?
I hate programs creating lots of temp files. So, the script was developped to create files AND to clean/remove them all once everything is done. Even if it crashes without removing files, you just need to restart the script - it will clean all previous temporary files.
If ADB is run, it WILL be fully closed once everything is done. Server will be killed, then ADB process (named adb.exe) will be killed. Your system will be as clean as it was before running the script.
The script is of course fully portable : there's no installation needed. You can put the script where you want, but you just need to keep all script files/folders in the same folder.
In a future release, I'll add something to purge the log file.
- Which OS is supported ?
It's developped in Windows 7 x64. You should be able to fully run it on any 2000+ Windows NT OS.
As it is NT script, it will work only on Windows computer. It will also not work properly on pure DOS (it's using NT commands and Windows-related commands not included in older Windows NT systems, like NT4).
Report if you tested it on other Microsoft OS (NT 4, Windows 95, 98 or 2000, Dos 6.22...)
- I wanna contribute.
Just right click the .cmd/bat files, edit them with Notepad or anything you want
You can also send me a message (thread or PM) if you notice some piece of code I can improve with other commands (I don't know DOS commands enough )
v1.0 (11/5/2011) = initial release
v1.1 (13/5/2011) = removed BFC tags, updated error 2 (ADB get-state, to help you identify problem), removed 3G tweak returns error 3 if not present (addon = not necessary), added template.bat to create add-ons, improved launcher.bat (add-on primitive detection), added add-on installation detector (displays backup/reboot options only when add-on was installed), corrected folder "\" bug
v1.2 (13 may formely 14/5/2011) = added automated deleter/file checker for 3G+ tweak. Still early stage but looks to work. Automated batch thanks to http://www.dostips.com
v1.3 (16/5/2011) = added 3G+ enhancement lite mode (for networks like AT&T) and removed 1 step on auto deletion, fixed bug of false error when trying to download from device a build.prop.bak not existing, added management options to Backup (send local backup to device, delete backup on device), solved backup internal error
v1.4 (29/5/2011) = fixed window console size, enhanced menus, faster script closing, log file generator, several bugs fixed, enhanced help (readme in Notepad, direct open XDA thread in Firefox), added adb.exe process killer
v1.5 (6/6/2011) = added console title, fixed some menu bugs, updated Readme, weblinks now open in the default user browser, build.prop will now open in default notepad editor, improved interface, fixed unexpected exit bug, added contact me using default email (still experimental)
v1.6 (15/6/2011) = improved ADB process killing, deeply improved 3G tweak script with sed and no more TXT file, readme opens in your default editor, improved interface, updated template, unified common subroutines into BAKengine.bat, user-friendly explorer of build.prop (not great for now), deleted Substengine (deprecated), "0" in menues now refers to Go Back/Exit, improved missing engines detection, added general temp/log file purger/deleter ** To celebrate The Legend of Zelda series 25th Anniversary, my script is now tagged "Powered by Hyrule DOS"
DETAILLED 3G Addon update :
- detects presence of previous installation and files
- Sed command : fastest detection and subtitute of lines
- Optimized for fastest operation and fully clean build.prop file
- Several stuff...
External SED support thanks to GNU Utilities for win32 @ http://unxutils.sourceforge.net/
v1.7 (26/7/2011) = fixed no deletion of TEMP folder/files, fixed ADB command not found, new entries for XPlorer
Known bugs :
* (Main) Will not detect if build.prop.bak and build.prop.old are the same (not very important, I'll improve this later)
* Report anything you find
Click to expand...
Click to collapse
Hey mate...
lovely piece of work..!
saved me hours at my work...
thanks a lot works flawlessly on
sony xperia tipo dual with cm 10
Ur da bomb
As you probably already know, you are DA BOMB, BABY!
I just [snicker] used your tool to save my rather idiotic...er, 'brain' from suffering through a dumb, hard night re-flashing SlimKat 4.4.2 back onto my LG Optimus G e970 just to fix something I should've never done to begin with (change screen density to make it easier to read, of course, but without really knowing what I was doing)...
aherm...well, anyway, here I sit at a pre-midnight hour thanking you profusely, sir, because, as I said at the start...
UR DA BOMB!!!
Here's hoping you get bored a lot more often...it's a keeper, fer sure.:victory:
Good work dude... Nice toolkit, loved it very much... I am integrating your tool into my new upcoming toolkit. Dont worry i am not gonna steal it, will just use it. Will surely give you proper credits for that
Does this work with the stock recovery without root?
My device: Xperia XA2
thanks for this useful helper. i know how to modify build.prop - thats not the reason why i came here. what i don't know is the meaning of all this different entries in build.prop for example ro.expect.recovery_id - which there was a catalog with information about included in a build.prop Tweak GUI
sorry but the program cant detect/ acces build.prop
my device is rooted, has debugging on and is connected via USB
plz help
This is a modification to set the time the screen will stay awake when waking to the lockscreen from sleep, NOT the screen timeout, screen timeout delay, or screen turned off delay which can be changed through setttings. I started looking into this after someone asked in the Q&A forum if CM7 had an option to change this which it does not. The default timeout is 5 seconds, but if you would like the lockscreen to be shown for longer(or shorter) before the screen turns off again, follow this guide. If you'd like to change this but don't know if you can or want to, send me a PM and I'll try and make the mod for you to install or maybe I'll even learn how to put it into a flashable zip. This mod requires root!
After searching around for where this value is set, I came across a thread on another forum which led me to android.policy.jar but I still needed to know which smali/java file to edit. The Android source helped locate the setting and usage of this value in KeyguardViewMediator.java. Near the beginning the defaults are defined(10s if KB open & 5s otherwise):
Code:
/**
* The default amount of time we stay awake (used for all key input)
*/
protected static final int [COLOR="Green"][B]AWAKE_INTERVAL_DEFAULT_MS = 5000[/B][/COLOR];
/**
* The default amount of time we stay awake (used for all key input) when the keyboard is open
*/
protected static final int AWAKE_INTERVAL_DEFAULT_KEYBOARD_OPEN_MS = 10000;
However, in the decoded smali version of this file, changing the values in these definitions don't affect anything. That's why when we edit the smali file later, we change the value where the DEFAULT_MS variable is actually used in the pokeWakelock method:
Code:
public void pokeWakelock() {
pokeWakelock(mKeyboardOpen ?
AWAKE_INTERVAL_DEFAULT_KEYBOARD_OPEN_MS : [COLOR="Green"][B]AWAKE_INTERVAL_DEFAULT_MS[/B][/COLOR]);
}
----------------------------------------
I've only tested this on my Eris running GSB v3.1 - Gingerbread 2.3.4 - CM 7.1.0 RC0. Be sure to make a NAND backup and a backup of android.policy.jar as I can't guarantee this will work for you. If you have problems or just want to switch back to the original 5s timeout, replace the modified android.policy.jar with the backup, wipe cache & dalvik, and reboot or restore from the NAND backup you created.
So how does one go about modifying this wakeup timeout...
For Windows users, download APK Manager, extract it to your preferred location and then follow my step-by-step instructions in this post.
For Mac OSX and Linux users, download apktool from here. You will need both apktool*.tar.bz2 and your OS(linux/macos) specific dependencies(apktool-install-OS-*.tar.bz2). Unpack both and place those files(apktool.jar/apktool/aapt) in /usr/local/bin or wherever as long as it is in your PATH.
Now we need to get android.policy.jar off the phone and onto the computer. ADB is probably the easiest way:
Code:
adb pull /system/framework/android.policy.jar
Next, we want to decode android.policy.jar using apktool:
Code:
apktool d android.policy.jar out
If working correctly, apktool should say "I: Baksmaling..." & "I: Copying assets and libs...". It should also have created the directory "out" that contains "apktool.yml" and a "smali" directory.
Using your favorite text editor, open "out/smali/com/android/internal/policy/impl/KeyguardViewMediator.smali" as it contains the timeout value to modify. Look for ".method public pokeWakelock()V" and but be careful not to be looking at ".method public pokeWakelock(I)V" instead. The method should be near the end and starts at line 2864/3288 in mine. Inside the method there will be two lines starting with "const/16". The first represents AWAKE_INTERVAL_DEFAULT_KEYBOARD_OPEN_MS so we don't need to worry about it for the Eris. The hex value(0x####) in the second is the value for AWAKE_INTERVAL_DEFAULT_MS. The default interval is 5s = 5000ms = 0x1388. Since this value is a 16-bit signed integer value, the max value that can be set is 32767 which makes it a couple seconds over 30. If you change it to a value greater than the max, it will be interpreted as a negative value and your screen will not wake up...trust me, I tried. You can use this decimal to hex converter to determine the hex value you need to replace 1388. For example, 10s would be 0x2710 or 0x7530 for 30s. Make the change and save the file.
To build android.policy.jar with the modification:
Code:
apktool b out
If the build worked correctly, apktool will say "I: Checking whether sources has changed..." & "I: Smaling..." & "W: Could not find resources" & "I: Building apk file...". It should also create the directories "build" and "dist" inside of "out". The "dist" directory holds the modified android.policy.jar file.
The next step is signing the modified android.policy.jar with the testkey. Signing tools: Mac <> Phone <> Linux users can chime in on the easiest way(s) they've found.
All that's left is to replace the original with the mod:
Code:
adb remount #mounts system as r/w
adb push out/dist/android.policy-signed.jar /system/framework/android.policy.jar
adb shell chmod 644 android.policy.jar #permissions = rw-r--r--
adb reboot recovery
#wipe both cache & dalvik-cache
#reboot
Finished! Enjoy your new wake timeout
MongooseHelix said:
This is a modification to set the time the screen will stay awake when waking to the lockscreen from sleep, NOT the screen timeout, screen timeout delay, or screen turned off delay which can be changed through setttings. I started looking into this after someone asked in the Q&A forum if CM7 had an option to change this which it does not. The default timeout is 5 seconds, but if you would like the lockscreen to be shown for longer(or shorter) before the screen turns off again, follow this guide. If you'd like to change this but don't know if you can or want to, send me a PM and I'll try and make the mod for you to install or maybe I'll even learn how to put it into a flashable zip. This mod requires root!
After searching around for where this value is set, I came across a thread on another forum which led me to android.policy.jar but I still needed to know which smali/java file to edit. The Android source helped locate the setting and usage of this value in KeyguardViewMediator.java. Near the beginning the defaults are defined(10s if KB open & 5s otherwise):
Code:
/**
* The default amount of time we stay awake (used for all key input)
*/
protected static final int [COLOR="Green"][B]AWAKE_INTERVAL_DEFAULT_MS = 5000[/B][/COLOR];
/**
* The default amount of time we stay awake (used for all key input) when the keyboard is open
*/
protected static final int AWAKE_INTERVAL_DEFAULT_KEYBOARD_OPEN_MS = 10000;
However, in the decoded smali version of this file, changing the values in these definitions don't affect anything. That's why when we edit the smali file later, we change the value where the DEFAULT_MS variable is actually used in the pokeWakelock method:
Code:
public void pokeWakelock() {
pokeWakelock(mKeyboardOpen ?
AWAKE_INTERVAL_DEFAULT_KEYBOARD_OPEN_MS : [COLOR="Green"][B]AWAKE_INTERVAL_DEFAULT_MS[/B][/COLOR]);
}
----------------------------------------
I've only tested this on my Eris running GSB v3.1 - Gingerbread 2.3.4 - CM 7.1.0 RC0. Be sure to make a NAND backup and a backup of android.policy.jar as I can't guarantee this will work for you. If you have problems or just want to switch back to the original 5s timeout, replace the modified android.policy.jar with the backup, wipe cache & dalvik, and reboot or restore from the NAND backup you created.
So how does one go about modifying this wakeup timeout...
First off, download apktool from here. You will need both apktool*.tar.bz2 and your OS(linux/macos/windows) specific dependencies(apktool-install-OS-*.tar.bz2). Unpack both and place the three files(apktool.jar/apktool/aapt) in /usr/local/bin for linux or mac(use sudo for root access) and to the Windows directory for windows.
Now we need to get android.policy.jar off the phone and onto the computer. ADB is probably the easiest way:
Code:
adb pull /system/framework/android.policy.jar
Next, we want to decode android.policy.jar using apktool:
Code:
apktool d android.policy.jar out
If working correctly, apktool should say "I: Baksmaling..." & "I: Copying assets and libs...". It should also have created the directory "out" that contains "apktool.yml" and a "smali" directory.
Using your favorite text editor, open "out/smali/com/android/internal/policy/impl/KeyguardViewMediator.smali" as it contains the timeout value to modify. Look for ".method public pokeWakelock()V" and but be careful not to be looking at ".method public pokeWakelock(I)V" instead. The method should be near the end and starts at line 2864/3288 in mine. Inside the method there will be two lines starting with "const/16". The first represents AWAKE_INTERVAL_DEFAULT_KEYBOARD_OPEN_MS so we don't need to worry about it for the Eris. The hex value(0x####) in the second is the value for AWAKE_INTERVAL_DEFAULT_MS. The default interval is 5s = 5000ms = 0x1388. Since this value is a 16-bit signed integer value, the max value that can be set is 32767 which makes it a couple seconds over 30. You can use this decimal to hex converter to determine the hex value you need to replace 1388. For example, 10s would be 0x2710 or 0x7530 for 30s. Make the change and save the file.
To build android.policy.jar with the modification:
Code:
apktool b out
If the build worked correctly, apktool will say "I: Checking whether sources has changed..." & "I: Smaling..." & "W: Could not find resources" & "I: Building apk file...". It should also create the directories "build" and "dist" inside of "out". The "dist" directory holds the modified android.policy.jar file.
The next step is signing the modified android.policy.jar with the testkey. Signing tools: Mac <> Phone <> Windows & Linux users can chime in on the easiest way(s) they've found.
All that's left is to replace the original with the mod:
Code:
adb remount #mounts system as r/w
adb push out/dist/android.policy-signed.jar /system/framework/android.policy.jar
adb shell
cd /system/framework
chown 0:0 android.policy.jar #owner:group = root:root
chmod 644 android.policy.jar #permissions = rw-r--r--
#reboot into recovery
#wipe both cache & dalvik-cache
#reboot
Finished! Enjoy your new wake timeout
Click to expand...
Click to collapse
Nice work on this.. thanks for sharing
Anyone developed an easy way to make these changes? An app of some sort perhaps?
This is so when we push the off button, and the lockscreen pops up it stays on for 5000 miliseconds before it goes back off? or so when we push the end button it takes 5000 miliseconds before it turns on?
nevermind reread, The length the lock screen stays on very interesting.
Hey something like this with the lights on - off script should make your phone turn on off the leds, this way we could have the orange and green leds work when charging and so on so forth for the sense 3.5, just an idea probably wrong place for it anyways
Thanks, this worked perfectly on my Desire HD. Lockscreen time out was super annoying when changing songs in my car.
Great work TY!!!
Part 1 (thanks to a new character limit...)
By now many of you know that the small file on the NST/G which contains web certificates (/system/etc/security/cacerts.bks) is slowly becoming out-of-date. The first important certificate to expire was for Amazon and that crippled the Kindle app until member @tshoulihane worked out a way to update the expired certificate. In 2020, one of the certificates needed to negotiate syncing of books with FBReader expired and I finally took the plunge and figured out how to update the certificate for that. Although @tshoulihane had provided directions in the original post, I was too dense to follow them correctly. Now, as promised, I am providing what I hope is an overly-explicit set of instructions (my specialty) so that anyone can do this, even when I am dead (!).
This guide is for Windows (10, in my case). If you're not using Windows you may be much happier but you'll have to figure this out for yourself. If you are using Windows, you know that we will have to wait for some of that happiness in the next life ;-)
Assembling the tools
jdk-6u45 (download-32 bit, download-64 bit). Oracle now requires a sign-up, etc., to get at these old files, so I have archived them.
bcprov-jdk15on-146.jar (download). This old file is required to make all the magic happen.
Setting up the tools
Install jdk-6u45, using defaults--unless you have some specific reason for changing things. Don't worry if you have other JDK versions installed. They can coexist. Once the JDK is installed, use Windows File Explorer to locate the installation, something like Program Files/Java/jdk1.6.0_45 (that could be Program Files (x86) if you installed the 32-bit version). Find the sub-folder "lib". If there isn't one, create it. Inside that folder create another folder, "ext" (if it doesn't already exist). Place in that folder the jar file you downloaded. So, just to be clear, you should end up with:
(64-bit) Program Files/Java/jdk1.6.0_45/lib/ext/bcprov-jdk15on-146.jar
(32-bit) Program Files (x86)/Java/jdk1.6.0_45/lib/ext/bcprov-jdk15on-146.jar
Looking at cacerts.bks (optional)
If you want to see what the "innards" of your cacerts.bks file looks like copy out /system/etc/security/cacerts.bks from your device to your PC (use some readily accessible directory like "Documents" or "Downloads"--someplace you have rights).
Open a Windows command prompt window. Execute the following:
Code:
cd C:\Program Files\Java\jdk1.6.0_45\bin
[for 32-bit: cd C:\Program Files (x86)\Java\jdk1.6.0_45\bin]
Windows 10 allows you to paste text into the command prompt window. I suggest you copy the following command to a text editor, adjust it to your situation, and paste into the command prompt window. Then hit Enter. The text is perilous to type and you can get very frustrated by small errors.
Code:
keytool.exe -keystore C:\Users\nmyshkin\Documents\cacerts.bks -storetype BKS -provider org.bouncycastle.jce.provider.BouncyCastleProvider -providerpath "C:\Program Files\Java\jdk1.6.0_45\lib\ext\bcprov-jdk15on-146.jar" -storepass changeit -v -list > C:\Users\nmyshkin\Documents\calist.txt
Note that a path which contains spaces requires the use of quotation marks or you will get an error. You would need to replace "nmyshkin\Documents" with whatever path is correct for you.
The resulting text file (calist.txt) contains a list of all of the certificates and information about them, including their expiration dates.
Housekeeping
Some time ago I came across a Honeycomb ROM (last stop before ICS and cacerts which update on the fly) and extracted its cacerts.bks file, reasoning that it would be more up-to-date than our version. This proved to be true (the Amazon certificate, for example, has not yet expired), and there were also many more certificates--not a bad thing. There were also a lot of dead certificates. So for a sort of baseline, I have attached a zipped copy of that file with all the dead stuff removed. It also has a functioning Amazon certificate and the update for FBReader book sync. You're welcome.
The good stuff follows in the next post...
Part 2
How do you remove dead certificates?
Note: ALWAYS keep a backup copy of your cacerts.bks file. If you mess up, you need to be able to go back. Also, before returning an updated cacerts.bks file to your device, you should have made a complete device backup. A faulty cacerts.bks file will cause a bootloop. The only recovery is a forced shutdown (not easy in itself) and a restoration of the nandroid backup with NookManager or similar.
Let's pretend that you have a dead certificate and a check of the calist.txt file created as described above reveals that its "alias" is 27. Certificates sometimes have ridiculously complicated names so in the cacerts.bks file they are often given numerical aliases. Here's how to get rid of one (presumably before you replace it):
Open a command prompt window and execute the following:
Code:
cd C:\Program Files\Java\jdk1.6.0_45\bin
[for 32-bit: cd C:\Program Files (x86)\Java\jdk1.6.0_45\bin]
Copy the text below and adjust the paths for your situation, then copy and paste the result into the command prompt window. Press Enter.
Code:
keytool.exe -keystore C:\Users\nmyshkin\Documents\cacerts.bks -storetype BKS -provider org.bouncycastle.jce.provider.BouncyCastleProvider -providerpath "C:\Program Files\Java\jdk1.6.0_45\lib\ext\bcprov-jdk15on-146.jar" -storepass changeit -v -delete -alias 27
You would need to replace "nmyshkin\Documents", the alias number, and potentially "Program Files" (if you are using 32 bit) to customize the command.
Importing/updating a certificate
Well, this is the "real deal". Someday that Amazon certificate is going to expire again and render the Kindle app useless (assuming Amazon doesn't abandon it first). Or something else may crop up that you'd like to fix (like the FBReader issue I mentioned earlier). To some extent, this may also address website access issues, but most--if not all--of those are more broadly SSL related and that is another kettle of fish altogether.
Importing a certificate is no more difficult than any of the other operations already described (once you have the command written out!). The difficulty is in obtaining the certificate to import! Here is where these instructions get a little squishy because they are initially based on information obtained from your PC's browser (and even its version). I happen to use an up-to-date version of Firefox so that's how I am approaching this. If you use a different browser, you will have to figure out this part on your own, but Googling will doubtless help.
Let's say the Amazon certificate has expired (again...). My first best guess is that the same certificate(s) used on Amazon.com are used for the Kindle app. So I head on over to Amazon.com with Firefox. When I arrive I note that there is a little "lock" symbol just before the "https:...." in the url line. Mousing over this symbol I see "Verfied by: DigiCert Inc." So it's some kind of DigiCert certificate. Clicking on the lock symbol I see site information for Amazon including "Connection Secure" which can be expanded to show "Verified by DigiCert Inc." and at the bottom of that little window is "More information". Clicking there gives me a lot more stuff, but what I want is just the "Security" tab where I can see "View Certificate". Aha! Clicking on that reveals that there are at least two certificates, DigiCert Global CA G2 and DigiCert Global Root G2. I may need only one, but it's safer to have both. Still, I need actual copies of the certificates. In an older version of Firefox you could click on the lock and get to a place where you could export copies of the certificates. No more. That was too easy. Now it's like this:
1. Navigate to the site (Amazon.com) and discover which certificates are used, as described above
2. Open the browser menu to access "Options"
3. Click on "Privacy and Security" in the left-hand menu
4. Scroll down to "Certificates"
5. This takes you to a window in which you want the last option, "Authorities"
5. Scroll to find the certificate(s) discovered by the steps described above.
6. Click on the certificate and then on "Export". Accept the default file type (X.509 Certificate (PEM) (*.crt;*.pem)) and the ".crt" extension. Save.
7. Change the file extension on the saved certificate to ".cer".
OK! Do this for whatever certificate(s) you need. Now it's time to get them into the cacerts.bks file. Make sure the saved certificates are in some directory on your PC for which you have rights (like "Documents" or "Downloads").
Open a command prompt window and execute the following:
Code:
cd C:\Program Files\Java\jdk1.6.0_45\bin
[for 32-bit: cd C:\Program Files (x86)\Java\jdk1.6.0_45\bin]
Copy the text below and adjust the paths for your situation, then copy and paste the result into the command prompt window. Press Enter.
Code:
keytool.exe -storetype BKS -keystore "C:\Users\nmyshkin\Documents\cacerts.bks" -provider org.bouncycastle.jce.provider.BouncyCastleProvider -providerpath "C:\Program Files\Java\jdk1.6.0_45\lib\ext\bcprov-jdk15on-146.jar" -storepass changeit -importcert -alias Amazon -file "C:\Users\nmyshkin\Documents\DigiCertGlobalRootG2.cer"
You would need to replace "nmyshkin\Documents", potentially "Program Files", the alias string or number as well as the certificate file name to customize. The "alias" is a number in our cacerts.bks file, but you can use a string instead. Otherwise, you need to choose a number that is not already used or use the same number(s) for the expired certificate(s) that you previously removed.
You will see a series of things scroll through the window, stopping at a confirmation dialog. You need to enter "yes" to accept the certificate.
Repeat if there are additional certificates to import/update.
The Proof in the Pudding
IF you have done these steps correctly, you should be good to go. You need to move the revised cacerts.bks file back to your NST/G (/system/etc/security/cacerts.bks). Be sure the file permissions are set to rw-r--r--, then reboot. If you get stuck in a bootloop you goofed. Try to interrupt the boot sequence with the power button. Eventually you will succeed and can restore a backup using something like NookManager. Try again
Hi, thank you for all your help as always nmyshkin, my how do i connect it to the nook?
I do all the steps, but I am lost on how to replace the system directory in the nook with the cacert.bks file so that the kindle app could log-in throught the NTGS.
vicus21 said:
Hi, thank you for all your help as always nmyshkin, my how do i connect it to the nook?
I do all the steps, but I am lost on how to replace the system directory in the nook with the cacert.bks file so that the kindle app could log-in throught the NTGS.
Click to expand...
Click to collapse
If you rooted with the updated NookManager, the cacerts.bks file is already updated. No need to do anything else.
As for the Kindle app, there are a few things you should know. When you try to log in you will get an error message. But if you check your email you will see that Amazon has sent you a one-time-password (OTP). Try that.
Here's where it gets a little complicated. If you have two-factor-verification turned on at Amazon, the OTP may fail. At least one XDA member has reported that if he added the OTP to his regular password, he was able to log in.
My most recent experience went something like this:
1. Try to log in. Get OTP via email.
2. Try OTP. It fails.
3. Check Amazon account...hmm..I don't have two-factor-verification (TFV) turned on. What gives?
4. Turn on TFV.
5. Turn off TFV.
6. Try to log in. Get OTP via email.
7. Try OTP. It works!
I don't have TFV turned on (I don't own a smart phone). But Amazon didn't seem to recognize that until I turned it on and then turned if off.
It would be nice if the other member is correct and you just append the OTP to your regular password to log in. Let us know!