I started working on the phone with the intention of upgrading it to make it faster and unlocking the sim. The T-mobile contract has been over for a long while now, they will not unlock it themselves for whatever reason. I committed a faux pas many on here many like to bash on (for good reason), no backup. I was going to after rooting but I used ODIN to flash the Bali 3.0.2.8 cwm and the screen turned into rainbow static when I tried rebooting, so I continued on to cm7 and then cm9. Worked great, and the SIM asked for unlock code.
I tried using script methods to unlock it but it kept telling me busybox wasn't installed right, I tried other versions and eventually saw a post saying it was only meant for gingerbread, so I flashed to that. Same problem, couldn't find the file or directory, so I looked myself and discovered there was no bml3 file. Restored a stock gb version with ODIN, the bml3 was 0.00mb. OK, so I looked at the hex code method, opened the nv_data bin and found the 8 digits and put them in. Incorrect, 9 attempts remaining. Tried again in case I mistyped; incorrect, 8 attempts remaining. I read that without an image backup or backup of the original nv_data or md5 I was screwed since the one I had was corrupt/generic/etc. I found one person saying he changed the FF 01 to FF 00 part in hex editor, according to him the SIM would (and mine did) stop asking to unlock. So that was progress. Since the SIM I want to use isn't activated yet I put in an activated AT&T SIM and was able to receive a test call. But the IMEI is still zero'ed out, apparently due to efs corruption.
So I have no efs or nv_data backups. I've been reading on forums how to restore the IMEI (I know it since it's right under the battery), one that can show you what I've been looking into is the article "Backup and Restore Lost IMEI on Samsung Galaxy Devices without Root" (I wrote the title because idk if url posting is allowed). Only problem: that's for the galaxy s3, when I type *#7284# I only have options for UART: PDA and MODEM and the same two options for USB. So I don't know how to use the NV-items_reader_writer tool to copy the corrupt nv_data.bin and rewrite the IMEI in the form it understands to get it back to the original state.
Can anyone help, or just pm others that can? Am I going in the right direction? I know there are lots of forums with similar posts but it's taking a lot of time to read and sort through them all
Try and search for 1-Click Gremlin remover in this forum. Or use Heimdall or Odin to go back to stock it might help.
If and only If, all fail, try the following tools at your own risk, they are meant to S3 but galaxy phones are similar (also make a backup of the efs directory, even if it is corrupted just in case):
First you have to use NV generator by putting your IMEI number and generate a text file contains hexadecimal numbers for NV data.
Then use the NV writer tool and flash the text file you generated using your IMEI.
I hope it works. Good luck :good:
Edit: Replaced SGS3 NV IMEI with the safer one per FB suggestion
Note that you need the 'nv.txt' to be able to generate hex numbers, otherwise it will crash.
I was able to generate the IMEI text file. The nv writer tool kept saying connected or does not exist depending on which com I used and if it was in download mode or not, if it connected I tried writing and it said "phone does not answer". Booted up normally (not download mode), double checked debugging mode was enabled, and I finally got it to connect to one- COM6- and it began writing, with the response:
Writing NV-items from a file:
Unsuccessfully written NV-items:
00550 (0x0226) - Unknown error
Done.
Realized I was on a stock gingerbread without root again since stock froyo flashback booted to S logo, vibrated, and looped again. Used superoneclick to root successfully. Clicked write again, phone does not answer, disconnect and connected, clicked write, received same unsuccessful write message from above. Reading more forums. Can this be placed manually or pushed by adb/terminal? Where in the efs folder or nv_data is this being written?
You can do it manually using hex editor if you know the memory offset, but I don't suggest it. If you wanna try anyway make backup. Sorry I can't think of something else to help you. I only tried this on S2 and S3. My S4G never had imei problems. But I recall that I unlocked it using hex editor by modifying the nv_data. Most likely the imei number is stored in the same file.
Edit: Besides, although it might be illegal to use a phone with empty IMEI number. Think of it as an advantage, the phone still works, receive and send calls, and the NSA wont be able to track you nor google :> The only problem with empty IMEI is intermittent 4g/3g connection.
Fbis251 had a nefty little app in playstore that will unlock for ya.
Sgs4g unlocker if I recall correctly.
Lol. True. I didn't know about the nv_gen tool though so I did make progress, thanks Rebel_X. I'll see if I can replace the hex formatted IMEI in the nv_data manually. That is where I manually changed 01 to 00 to unlock it.
@champ1919 it is technically unlocked now, an AT&T SIM worked. It's simply that the IMEI is zero'ed out and I've read some carriers don't like this/ data works intermittently as Rebel mentioned.
Once unlocked, always unlocked. Flash stock gb and see if it comes back. That has worked for others.
Holy carp I fixed it! Manual editing the nt_data.bin works.
I read that line 550 is where the IMEI hex is, when I viewed it in one editor (named HxD) it said line 00005500, so I clicked view>offset base>hexadecimal and it turns into 00000550. It's all FF FF FF... no zeros. Replaced it with my original IMEI (remember future readers, this can't change it to a different one) in hex format calculated form the sgs3_nv_gen tool. The NV-item_reader_writer tool would not push it successfully as noted before. Deleted nt_data.bin and nt_data.bin.bak under efs/root/afs/settings using root explorer (directory may be different in ics and up), placed my version of edited nt_data.bin, rebooted. IMEI restored. Backing this sucker up now...
http://imgur.com/wKO5Cjm
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
All hex IMEI starts with 08 #A apparently. Rest of personal data is marked out.
Upgraded to CM9. IMEI still correct, SIM still unlocked.
@asmarinian: I am happy for you
asmarinian said:
Holy carp I fixed it! Manual editing the nt_data.bin works.
I read that line 550 is where the IMEI hex is, when I viewed it in one editor (named HxD) it said line 00005500, so I clicked view>offset base>hexadecimal and it turns into 00000550. It's all FF FF FF... no zeros. Replaced it with my original IMEI (remember future readers, this can't change it to a different one) in hex format calculated form the sgs3_nv_gen tool. The NV-item_reader_writer tool would not push it successfully as noted before. Deleted nt_data.bin and nt_data.bin.bak under efs/root/afs/settings using root explorer (directory may be different in ics and up), placed my version of edited nt_data.bin, rebooted. IMEI restored. Backing this sucker up now...
http://imgur.com/wKO5Cjm
All hex IMEI starts with 08 #A apparently. Rest of personal data is marked out.
Click to expand...
Click to collapse
I have a few nv_data files from previous SGS4G phones I had and had been wondering what the offset was. I'll have to look into this too since I finally wound up finding the offset to the Unlock code (0x146E).
You can read more about it here:
https://github.com/fbis251/sgs4g-unlock-code-finder
Wouldn't be a bad idea to modify the program to add an IMEI number reader.
Thanks for the information!
---------- Post added at 06:41 PM ---------- Previous post was at 06:15 PM ----------
Rebel_X said:
Try and search for 1-Click Gremlin remover in this forum. Or use Heimdall or Odin to go back to stock it might help.
If and only If, all fail, try the following tools at your own risk, they are meant to S3 but galaxy phones are similar (also make a backup of the efs directory, even if it is corrupted just in case):
First you have to use NV generator by putting your IMEI number and generate a text file contains hexadecimal numbers for NV data.
Then use the NV writer tool and flash the text file you generated using your IMEI.
I hope it works. Good luck :good:
Click to expand...
Click to collapse
I checked SGS3-IMEI-NV-Gen.exe with VirusTotal and 40/50 antivirus programs flagged it as a virus. I'd be very wary about running this on your computer.
https://www.virustotal.com/en/file/...126102bb576a5d7d7800b049/analysis/1393510440/
FBis251 said:
I checked SGS3-IMEI-NV-Gen.exe with VirusTotal and 40/50 antivirus programs flagged it as a virus. I'd be very wary about running this on your computer.
https://www.virustotal.com/en/file/...126102bb576a5d7d7800b049/analysis/1393510440/
Click to expand...
Click to collapse
I have this file for quite for a long time, ESET never complained about it. If anything, other AV reports it as most probably a false positive. But nothing prevents you from running it in a sand box.
asmarinian said:
Holy carp I fixed it! Manual editing the nt_data.bin works.
I read that line 550 is where the IMEI hex is, when I viewed it in one editor (named HxD) it said line 00005500, so I clicked view>offset base>hexadecimal and it turns into 00000550. It's all FF FF FF... no zeros. Replaced it with my original IMEI (remember future readers, this can't change it to a different one) in hex format calculated form the sgs3_nv_gen tool. The NV-item_reader_writer tool would not push it successfully as noted before. Deleted nt_data.bin and nt_data.bin.bak under efs/root/afs/settings using root explorer (directory may be different in ics and up), placed my version of edited nt_data.bin, rebooted. IMEI restored. Backing this sucker up now...
http://imgur.com/wKO5Cjm
All hex IMEI starts with 08 #A apparently. Rest of personal data is marked out.
Click to expand...
Click to collapse
Can you please help me with this problem im working on a client phone and the IMEI turn to all zeros and don't find a way to fix it, how did you get your IMEI number back
banziitox24 said:
Can you please help me with this problem im working on a client phone and the IMEI turn to all zeros and don't find a way to fix it, how did you get your IMEI number back
Click to expand...
Click to collapse
Check on the sticker under the battery, that's where mine was. Just fyi don't post it on here for the world to see. If you find it, write it down or type it in a text editor, then let me know you've got it. I'll write up what I did step by step for you to follow.
asmarinian said:
Check on the sticker under the battery, that's where mine was. Just fyi don't post it on here for the world to see. If you find it, write it down or type it in a text editor, then let me know you've got it. I'll write up what I did step by step for you to follow.
Click to expand...
Click to collapse
Ok I wrote it down already what's next?
Credit goes out to lots of knowledgeable people all over the internets.
1. Once you know your IMEI you have to rearrange it into hexadecimal format. EXAMPLE: Say your IMEI is 954091051099226, break it up into two digit groupings. The start of an IMEI is always 08, and your first number will be followed by an 'A'. Each subsequent group of two digits is then reversed. The example IMEI in hexadecimal will be 08 9A 45 90 01 15 90 29 62.
2. Using a root explorer, go to efs/root/afs/settings and copy nv_data.bin to your computer for editing.
3. Download and install a hex editor. I used HxD and found it easiest to use. The link from cnet is http://download.cnet.com/HxD-Hex-Editor/3000-2352-10891068.html
4. Open nv_data.bin in HxD. On the top menu toolbar click view>offset base>hexadecimal. Scroll down through the file until you find offset 550, which will appear as 00000550. Type your IMEI in hexadecimal format into this line, overwriting the FF's. Fill in the remaining FF's in the line with zeros. Using the example IMEI, this would appear as [08 9A 45 90 01 15 90 29 62 00 00 00 00 00 00 00]. Fill in 7 lines of FF's below the line with your IMEI with all zeros. It should now appear like this:
08 9A 45 90 01 15 90 29 62 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Save the file. Make a copy on your phone storage.
5. Navigate back to efs/root/afs/settings and delete the existing nv_data.bin and nv_data.bin.bak.
6. Copy your modified nv_data.bin into efs/root/afs/settings.
7. Reboot and check under phone information if your IMEI has been reset.
Rebel_X said:
I have this file for quite for a long time, ESET never complained about it. If anything, other AV reports it as most probably a false positive. But nothing prevents you from running it in a sand box.
Click to expand...
Click to collapse
I wound up running the program in a sandbox.
The file you uploaded attempts to run a .bat file in a temp directory by calling cmd.exe to run it.
The bat file
Code:
@echo off
set ztmp=C:\Users\<USERNAME>\AppData\Local\Temp\ztmp
set MYFILES=C:\Users\<USERNAME>\AppData\Local\Temp\afolder
set bfcec=t17061.exe
attrib +h C:\Users\<USERNAME>\AppData\Local\Temp\ztmp
@echo off
CLS
cd %MYFILES%
"SGS3 IMEI.exe"
CLS
The EXE file created along with the .bat file is actually an ASCII file which contains the following text
Code:
RCHELICOPTERFTW
It also creates a new folder under
C:\Users\<USERNAME>\AppData\Local\Temp\afolder
which contains the SGS3 IMEI.exe program and a text file which contains:
Code:
[NV items]
[Complete items - 1, Items size - 128]
00550 (0x0226) - OK
XX XX XX XX XX XX XX XX XX00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
When I ran THAT exe through virustotal I got these results, which DO seem like false positives, unlike the EXE you uploaded which triggered 80% of the virus scanners, this one only triggers 2/45.
https://www.virustotal.com/en/file/...f7c17482773d478539e99148/analysis/1377777759/
I guess I can send the SGS3 IMEI.exe file to you so you can post a link to that one instead?
FBis251 said:
I guess I can send the SGS3 IMEI.exe file to you so you can post a link to that one instead?
Click to expand...
Click to collapse
It's easier/faster than the manual method. I'm sure some people just get spooked by false positives so I wanted the manual method for turning their IMEI into hexadecimal formal laid out. I just ignored the false positive on mine it since I know a lot of exe's and bat's that edit files get flagged more often. I do appreciate having someone who knows what they're doing analyzing it in sandbox mode though, thanks!
FBis251 said:
I have a few nv_data files from previous SGS4G phones I had and had been wondering what the offset was. I'll have to look into this too since I finally wound up finding the offset to the Unlock code (0x146E).
You can read more about it here:
https://github.com/fbis251/sgs4g-unlock-code-finder
Wouldn't be a bad idea to modify the program to add an IMEI number reader.
Thanks for the information!
---------- Post added at 06:41 PM ---------- Previous post was at 06:15 PM ----------
I checked SGS3-IMEI-NV-Gen.exe with VirusTotal and 40/50 antivirus programs flagged it as a virus. I'd be very wary about running this on your computer.
https://www.virustotal.com/en/file/...126102bb576a5d7d7800b049/analysis/1393510440/
Click to expand...
Click to collapse
If I actually knew more about what I was doing I probably would have set the com ports up properly and just used qpst the right way or the nv-item rw program. 550 appears to be an offset used in at least some other models and brands, could be whichever contain the ability to use the qualcomm tool. I'm sure they all exist in company documentation and manuals. Being only a user, and not even a programmer at that, I don't have the knowledge or means to reliably find certain information and first hand sources very often. That said if you download and install the qpst tool (I searched for QPST v2.7.378.zip), open RF NV Manager 1.4.32, click Option>Customized NV Item List you will see every offset value and what they are for.
Also, I glanced over the last sentence about the false positive too quickly, if you want to upload the edited version without the false positive trigger that'd be great!
asmarinian said:
Credit goes out to lots of knowledgeable people all over the internets.
1. Once you know your IMEI you have to rearrange it into hexadecimal format. EXAMPLE: Say your IMEI is 954091051099226, break it up into two digit groupings. The start of an IMEI is always 08, and your first number will be followed by an 'A'. Each subsequent group of two digits is then reversed. The example IMEI in hexadecimal will be 08 9A 45 90 01 15 90 29 62.
2. Using a root explorer, go to efs/root/afs/settings and copy nv_data.bin to your computer for editing.
3. Download and install a hex editor. I used HxD and found it easiest to use. The link from cnet is http://download.cnet.com/HxD-Hex-Editor/3000-2352-10891068.html
4. Open nv_data.bin in HxD. On the top menu toolbar click view>offset base>hexadecimal. Scroll down through the file until you find offset 550, which will appear as 00000550. Type your IMEI in hexadecimal format into this line, overwriting the FF's. Fill in the remaining FF's in the line with zeros. Using the example IMEI, this would appear as [08 9A 45 90 01 15 90 29 62 00 00 00 00 00 00 00]. Fill in 7 lines of FF's below the line with your IMEI with all zeros. It should now appear like this:
08 9A 45 90 01 15 90 29 62 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Save the file. Make a copy on your phone storage.
5. Navigate back to efs/root/afs/settings and delete the existing nv_data.bin and nv_data.bin.bak.
6. Copy your modified nv_data.bin into efs/root/afs/settings.
7. Reboot and check under phone information if your IMEI has been reset.
Click to expand...
Click to collapse
Tried all this Step-By-Step and IMEI Number stills all zeros
IMEI: 000000000000000/04
Device: Samsung Galaxy S 4G T959V T-Mobile Variant
Android Version: 2.3.5
Baseband Version: T959VUVKJ1
Kernel Version: 2.6.35.7-T959VUVKJ1-CL611444
PLEASE HELP ME WITH THIS PROBLEM!!!!
Related
Hi
I have created the attachd word document with images on how to change page pool alongwith tools required
None of these tools are created by me and due respect and thanks to the creators of these tools.
Hope this is useful and request someone to upload to wiki site in html format
I am a newbie any modifications, suggestions let me know
Regards
rbalu72 said:
Hi
I have created the attachd word document with images on how to change page pool alongwith tools required
None of these tools are created by me and due respect and thanks to the creators of these tools.
Hope this is useful and request someone to upload to wiki site in html format
I am a newbie any modifications, suggestions let me know
Regards
Click to expand...
Click to collapse
NOPE!!!
The value must be reversed!
Example:
0x223500 - FF FF FF FF 00 00 00 00
Thanks Master Tomal for correction.
If I modify the document as below, would it convey the correct message?
In attached screen the values changed in blue rectangle should be changed as below
00 00 60 00 00 00 00 00 For 6MB Pagepool
00 00 56 00 00 00 00 00 For 5.6MB Pagepool
00 00 80 00 00 00 00 00 For 8MB Pagepool
FF FF FF FF 00 00 00 00 for 128MB devices
Attached is the revised document.
Let me know if there are any further modifications/suggestions..
Many thanks for your guidance.
why cannot download it??
PagePool changer
Thanks for the instructions!
I writed a little utility which are help to modify the NK.FAT file.
Place the PPSET.EXE with same directory with the NK.FAT file, and just run it. When the 64B0... signature found the can be selected the new settings.
Original NK.FAT saved as NK.BAK.
So guys in this post i'll show you how to remove ULDR partition from out ROMs to gain 3 MBs of space that was wasted in all of our earlier ROMs. But first, *SPECIAL* thanks to cmonex for helping me with this
Requirements:
1. A HEX editor
2. os.nb.payload (the one inside \ROM folder)
I've used the payload from our latest WM 6.1 ROM, so my base payload over here is 3.07.720.3 ROM. The removal of ULDR requires you to edit the MBR (master boot record) and MSFLSH50 regions in the payload. So be careful while editing otherwise there would problems in cooking or the deivce won't boot.
So, take HEX editor of your choice and open the payload. The MBR starts at offset 0x0 and ends at 0x1FF. You don't need to worry about whole of the MBR, just take a look at the following HEX strings:
Code:
[size="3"]
000001b0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [COLOR="DarkRed"][b]00 02 [/b][/COLOR]
000001c0h: [COLOR="darkred"][b]01 00 20 7F 01 30 02 00 00 00 7E 18 00 00 [/b][/COLOR][COLOR="Red"][b]00 00 [/b][/COLOR]
000001d0h: [COLOR="red"][b]01 31 23 7F 01 65 80 18 00 00 80 1A 00 00 [/b][/COLOR][COLOR="Blue"][b]00 00 [/b][/COLOR]
000001e0h: [COLOR="blue"][b]01 66 25 7F 81 DF 00 33 00 00 00 3D 03 00[/b] [/COLOR]00 00
000001f0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA[/size]
These 3 strings are actually 3 partitions, the first one is ULDR, 2nd one is XIP and 3rd one IMGFS. Now take a look at the following:
Code:
[SIZE="3"]00000200h: 4D 53 46 4C 53 48 35 30 00 00 00 00 38 00 00 00
00000210h: 00 00 00 00 00 00 00 00 00 00 00 00 [COLOR="DarkGreen"][b]66[/b][/COLOR] 00 00 00
00000220h: 80 00 00 00 00 00 01 00 00 00 00 00 01 00 00 00
00000230h: 00 00 00 00 00 00 00 00 7A 06 00 00 80 00 00 00
00000240h: 00 00 01 00 00 00 00 00 FF FF FF FF FF FF FF FF [/SIZE]
This is the MSFLSH50 region and the marked offset shows the logical block of IMGFS start. So, in order to remove the ULDR, we have to edit the MBR and MSLFSH50 regions in the marked areas.
The ULDR partition starts at 0x400 offset and ends at 0x30FFFF (XIP starts at 0x310000 in the shipped ROM for Elfins). Delete all the HEX bytes from 0x400 upto 0x30FFFF. Deletion of ULDR means start of logical blocks of XIP and IMGFS will go up. So the XIP will start at 0x400 instead of ULDR and IMGFS will start at 0x350000. Now you need to edit the MBR and MSFLSH50 regions to adjust for the new XIP and IMGFS start offsets. So using your HEX editor, change the MBR and FSFLSH50 regions as shown below:
Code:
[SIZE="3"]000001b0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [COLOR="Red"][B]00 02 [/B][/COLOR]
000001c0h: [COLOR="red"][B]01 31 23 7F 01 65 02 00 00 00 7E 1A 00 00 [/B][/COLOR][B][COLOR="Blue"]00 00 [/COLOR][/B]
000001d0h: [COLOR="blue"][B]01 66 25 7F 81 DF 80 1A 00 00 00 3D 03 00 [/B][/COLOR][COLOR="DarkRed"][B]00 00 [/B][/COLOR]
000001e0h: [COLOR="darkred"][B]00 00 00 00 00 00 00 00 00 00 00 00 00 00 [/B][/COLOR]00 00
000001f0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA [/size]
Code:
[SIZE="3"]
00000200h: 4D 53 46 4C 53 48 35 30 00 00 00 00 38 00 00 00
00000210h: 00 00 00 00 00 00 00 00 00 00 00 00 [B][COLOR="DarkGreen"]35[/COLOR][/B] 00 00 00
00000220h: 80 00 00 00 00 00 01 00 00 00 00 00 01 00 00 00
00000230h: 00 00 00 00 00 00 00 00 7A 06 00 00 80 00 00 00
00000240h: 00 00 01 00 00 00 00 00 FF FF FF FF FF FF FF FF [/SIZE]
Save the new os.nb.payload and copy into the \ROM folder of your kitchen replacing the original os.nb.payload. From now on use this payload as your template for cooking ROMs. Since, the XIP and IMGFS start offsets have changed, we need to make a few adjustments to the kitchen (Hybrid, Ervius' or bepe's kitchen) also. Note the following command in CreateROM.bat file inside the \Tools folder:
Code:
..\TOOLS\insert -i ..\ROM\out.bin -o OS.nb.payload -d 0x00310000 -s 0x00350000
This command inserts the new XIP (named out.bin) into the payload. Add REM before this command because insert.exe can't insert the xip at 0x400 for some reason. So there are 2 workarounds for this problem:
1. Use XIPPort.exe to insert the out.bin (created inside ROM folder) at 0x400
OR2. Use msflshtool.exe to insert the out.bin. For using this method, copy the msflshtool.exe to your \Tools folder and add the following command in your CreateROM.bat file in place of "insert.exe ..." command.
Code:
..\TOOLS\msflshtool OS.nb.payload -r ..\ROM\out.bin -p 0
After this step, you are ready to cook your new ROM with extra space of 3 MBs . Happy cooking
Hex Screenshots
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
This is like a scratch note - an easy accessed "guide".
Its purpose is to help everyone understand what are the numbers - bytes - that we are editing according to AMAN's guide for ULDR Removal.
As the title says it is a "hex view" at the latest Official Elfin 3.10.710.00 ROM
to figure out how all those hex-strings are related
and
to be able to change them, knowing what is going on!
Regards!
ababrekar said:
Awesome job brother . Hoping to see this kind of documentation for Diamonds too very soon
Click to expand...
Click to collapse
i would love to, but then u need to send me your Diamond for testing purposes
htctouchp said:
i would love to, but then u need to send me your Diamond for testing purposes
Click to expand...
Click to collapse
Promise me you will also tell me about those imgfs values for the xip playing guide and i'll send it right now
ababrekar said:
Promise me you will also tell me about those imgfs values for the xip playing guide and i'll send it right now
Click to expand...
Click to collapse
yeah i promise once i get the ULDR removed from ur diamond , i'll tell u about the imgfs values also
Yes! ULDR Removal for Elf/Elfins - Work!!!
htctouchp,
Thank you very much!!!
vadyarik said:
Yes! ULDR Removal for Elf/Elfins - Work!!!
htctouchp,
Thank you very much!!!
Click to expand...
Click to collapse
welcome
Good work!!
htctouchp said:
After this step, you are ready to cook your new ROM with extra space of 3 MBs . Happy cooking
Click to expand...
Click to collapse
Whaaaou!
GOOD WORK.
htctouchp said:
After this step, you are ready to cook your new ROM with extra space of 3 MBs . Happy cooking
Click to expand...
Click to collapse
Thanks for this, that's so great! I managed to get 74.9 Mb free storage on my Elf with a cleaned ROM.
A little addon to your great tutorial: If you have the last hybrid with the pagepool patch at the end, comment it or modify the offsets to match the new ones. My first flash was stuck on mobility screen because of this (or was it bad luck ?).
letama said:
A little addon to your great tutorial: If you have the last hybrid with the pagepool patch at the end, comment it or modify the offsets to match the new ones.
Click to expand...
Click to collapse
sorry, i didn't get it
Thanx for this new finding Aman!
It's great!
I noticed that after this ULDR removal, there is only one address that we find the pp pattern(03 15 A0 ...)!
Is it normal or did I mess it up?
htctouchp said:
sorry, i didn't get it
Click to expand...
Click to collapse
The offsets for the pp have been changed, so the script I wrote for the 2.2 Rom was aiming(&hexediting) the wrong offsets, resulting in a non-bootable rom..
Regards!
kokotas said:
Thanx for this new finding Aman!
It's great!
I noticed that after this ULDR removal, there is only one address that we find the pp pattern(03 15 A0 ...)!
Is it normal or did I mess it up?
Click to expand...
Click to collapse
yes, its perfectly normal. if u check the PP offsets of the original payload of any ROM, the first HEX string is in the region of ULDR and the 2nd in the region of the XIP. So obviously u can see only one HEX string now. And as i said in PP changer thread a few days ago that only 2nd HEX string is responsible for the PP change, so even if u don't remove the ULDR, u don't have to edit the 1st HEX string.
The offsets for the pp have been changed, so the script I wrote for the 2.2 Rom was aiming(&hexediting) the wrong offsets, resulting in a non-bootable rom..
Click to expand...
Click to collapse
ok, now i get it.
htctouchp said:
yes, its perfectly normal. if u check the PP offsets of the original payload of any ROM, the first HEX string is in the region of ULDR and the 2nd in the region of the XIP. So obviously u can see only one HEX string now. And as i said in PP changer thread a few days ago that only 2nd HEX string is responsible for the PP change, so even if u don't remove the ULDR, u don't have to edit the 1st HEX string.
ok, now i get it.
Click to expand...
Click to collapse
Can you guys give the PP offset for a 2.2 ULDR ROM, as wel as a 3.xx ULDR ROM? I'll need to add more checks for the Universal PP changer
htctouchp said:
yes, its perfectly normal. if u check the PP offsets of the original payload of any ROM, the first HEX string is in the region of ULDR and the 2nd in the region of the XIP. So obviously u can see only one HEX string now. And as i said in PP changer thread a few days ago that only 2nd HEX string is responsible for the PP change, so even if u don't remove the ULDR, u don't have to edit the 1st HEX string.
Click to expand...
Click to collapse
Found it:
htctouchp said:
will have to change again, coz the 1st HEX string is going to disappear forever
Click to expand...
Click to collapse
lol
It sounds like you did some magic...hehe
Question:
When I followed your instructions and reached to the point of deleting ULDR section, imgfs start offset was 0x350400
and I had to delete some "FF" above to make that 0x350000.
Have you any idea about what went wrong?
kokotas said:
Question:
When I followed your instructions and reached to the point of deleting ULDR section, imgfs start offset was 0x350400
and I had to delete some "FF" above to make that 0x350000.
Have you any idea about what went wrong?
Click to expand...
Click to collapse
0x350400 ? impossible....u must have missed something...try again.
dsixda said:
Can you guys give the PP offset for a 2.2 ULDR ROM, as wel as a 3.xx ULDR ROM? I'll need to add more checks for the Universal PP changer
Click to expand...
Click to collapse
for the 3.XX based nk.exe ULDR removed ROM, the offset is 0x45210. didn't check the 2.XX ROM though.
htctouchp said:
for the 3.XX based nk.exe ULDR removed ROM, the offset is 0x45210. didn't check the 2.XX ROM though.
Click to expand...
Click to collapse
Ok, the Universal PP Changer has been updated and tested with your ULDR hack. All 3.xx ROMs are now supported. I haven't been able to check on 2.xx ROMs without ULDR, however.
Thanks htctouchp!!!!
dsixda said:
Ok, the Universal PP Changer has been updated and tested with your ULDR hack. All 3.xx ROMs are now supported. I haven't been able to check on 2.xx ROMs without ULDR, however.
Thanks htctouchp!!!!
Click to expand...
Click to collapse
welcome!!
i think we don't need to work with 2.2X ROMs now. all the ROMs from now onwards are going to be based on 3.3X ROMs anyway.
All i'm hoping at the moment is that i removed the Bytes correctly .
"Delete all the HEX bytes from 0x400 upto 0x30FFFF"
I took that as a Starting from the beginning of 400 to the end of 30ffff.
Not directly my favourite stuff to do but what is there to loose
Well IF It Boots It Works. (Should have noted storage before, but looks better)
On page 67 of the Service Manual, it mentions "Turn the device power off and insert Diagnostic SD card. Press and hold Capture button, then press Power button to enter Diagnostic mode."
I'm thinking that the camera + power button will make the G1 boot off the SD Card.. this may be a way to run a hacked rev 30 on a locked rev 30 phone...
I will try some stuff tonight...
-Nikropht
that does seem interesting... im going to try to flash JF's img after in finishes downloading... i'll post results... along with my attempt to flash a signed rc29 update... cross your fingers i dont brick the damned phone
The Artemis device had this so-called "Diagnostic SD" mentioned. Im asuming therefore we could dossibly create one and flash our device with whatever firmware, akin to the "Pandora Battery" for PSP.
Worth exploring, but difficult to pull of without bricking... If it is possibly to flash a signed RC30 at any point using the current SD method, then at least we know we cannot brick the phone
the SPL bootloader (engineering and original) look for NBH files on the SD card.
DREADIAG.nbh
and
DREAIMG.nbh
As you can see, their purpose is clear. One is for booting diagnostics and the other is for flashing the firmware.
^^^so are you saying flashing DREAIMG.nbh is possible with this method?
damien667 said:
the SPL bootloader (engineering and original) look for NBH files on the SD card.
DREADIAG.nbh
and
DREAIMG.nbh
As you can see, their purpose is clear. One is for booting diagnostics and the other is for flashing the firmware.
Click to expand...
Click to collapse
So could we create a dreadiag.nbh from RC29?
Yes indeedy. However, we don't know the format of said nbh files. We're working on it still.
richbayliss said:
The Artemis device had this so-called "Diagnostic SD" mentioned. Im asuming therefore we could dossibly create one and flash our device with whatever firmware, akin to the "Pandora Battery" for PSP.
Worth exploring, but difficult to pull of without bricking... If it is possibly to flash a signed RC30 at any point using the current SD method, then at least we know we cannot brick the phone
Click to expand...
Click to collapse
its possible to flash update.zip so we won't brick the phone... the issue is that each update checks for something on the one previously installed... like mentioned in one of my other posts its a endless loop... we can change whatit looks for but then loose the signature...
Can we not use the info here
http://wiki.xda-developers.com/index.php?pagename=Hermes_NBH
To go the other way!?
richbayliss said:
Can we not use the info here
http://wiki.xda-developers.com/index.php?pagename=Hermes_NBH
To go the other way!?
Click to expand...
Click to collapse
ok... HAs anyone tried to extract DREAIMG.NBH just to see how its formated or structured??? If so we could compare it to the data listed for the hermes nbh format just to compare differences(if any) to see how closely they match... just a thought
If I could get a copy of the file I would give it a whirl... but cannot find it anywhere.
Guys,
NBH files are a proprietary format. They are like the update.zip, but different. We don't know how, as this is embedded into the SPL code that is all in binary format at the time (it's not been disassembled). No one except HTC and/or T-Mo will have these original files anyway. This means we're going to have to build one from scratch with reverse engineering of the spl (at least that's what it looks like as of now). That being said, there is no NBH file that is "found" on any file system of the G1. The NBH file contains files within itself that are flashed onto the NAND flash of the phone, like update.zip. The difference is that NBH files are not signed (that we know of yet), and the format in which they have to be assembled.
richbayliss said:
If I could get a copy of the file I would give it a whirl... but cannot find it anywhere.
Click to expand...
Click to collapse
I cant find it either.... its out there though... too many people have posted their experiments with it... if any has it or know where it is is located please post... thank...
DREAIMG.nbh is nowhere. People are just creating empty files with that filename to see what the bootloader will do.
damien667 said:
DREAIMG.nbh is nowhere. People are just creating empty files with that filename to see what the bootloader will do.
Click to expand...
Click to collapse
Yup. Well to be correct there are probably true DREAIMG.NBH files somewhere out there (at a htc repair center most likely), but they have not yet made their way into the hands of the hacking community.
True.
I would rick messing if there was an update.zip of the OTA RC30 as is now. So I could rescue myself.
Looking at the WinMo phones, they have NBH for a few devices, and it is common for all of them to put the OS partition at header 0x0400, even on the latest Diamond device. So I would risk trying a file with this IF I knew I wouldnt be bricking for life.
richbayliss said:
True.
I would rick messing if there was an update.zip of the OTA RC30 as is now. So I could rescue myself.
Looking at the WinMo phones, they have NBH for a few devices, and it is common for all of them to put the OS partition at header 0x0400, even on the latest Diamond device. So I would risk trying a file with this IF I knew I wouldnt be bricking for life.
Click to expand...
Click to collapse
there is an official rc30 update.zip out... however it does not seem to alter the os... i re-flahed my rc30 with it and i didnt have to re log into google and nothing was missing... all of my text messages were even intact
When you flash with update.zip, it does not affect the data partition (where all your settings and installed apps are located). It only changes radio, system, and boot partitions.
formar of DREAIMG.nbh:
0x200 bytes header,
then N images one by one(radio, hboot, recovery, boot, splash, sysfs, userfs)
header:
000: 48 00 00 00 54 00 00 00 43 00 00 00 49 00 00 00 │H...T...C...I...
010: 4D 00 00 00 41 00 00 00 47 00 00 00 45 00 00 00 │M...A...G...E...
020: 44 52 45 41 31 30 30 30 30 00 00 00 00 00 00 00 │DREA10000.......
030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │................
seems like simple "magic"
+0x40: 32 DD's - IMHO type descriptor's (type of each image, 00 if not used)
+0xC0: 32 DD's - offset of images
+0x140: 32 DD's - size of each image
+0x1C0: version?
1C0: 31 31 31 31 31 31 31 31 00 00 00 00 00 00 00 00 │11111111........
1D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │................
1E0: 30 2E 30 35 2E 30 2E 30 00 00 00 00 00 00 00 00 │0.05.0.0........
1F0: 47 65 6E 65 72 69 63 00 00 00 00 00 00 00 00 00 │Generic.........
Booting from the SD card is probably how you enter the manufacturers test mode RE: FACTORY_TEST Run as a manufacturer test application, running as the root user. "android.permission.FACTORY_TEST"
http://code.google.com/android/reference/android/Manifest.permission.html
FOR ALL K2 VARIANTS (K2_CL, K2_UL, K2_U, K2_PLC_CL)
Advantages
- No more hassle with htcdev, tokens, or unlock codes
- No more submitting your phones personal info to htc
- The ability to get back to 100% stock without any visual traces or records of having been S-Off or unlocking your bootloader.
PLEASE PAY CLOSE ATTENTION TO THIS TUTORIAL AS I WILL SHOW YOU HOW TO CHANGE THE FLAG FOR LOCK, RELOCK, UNLOCK, AND TAMPERED!!
I INSIST THAT YOU READ ALL OF THIS BEFORE YOU TAKE FURTHER ACTION - IF YOU FAIL TO FOLLOW INSTRUCTIONS THE ONLY ONE TO BLAME IS YOURSELF. AFTER YOU HAVE READ THIS TUTORIAL AND COME TO UNDERSTAND THIS PROCEDURE THEN BY ALL MEANS GO AHEAD AND CARRY OUT THE NECESSARY STEPS TO ACCOMPLISH WHATEVER GOALS YOU MAY CURRENTLY HAVE AT THIS TIME.
- This tutorial may be easier on the eyes if viewed by the actual web browser vice an app or phone device.
Many thanks to @old.splatterhand for being generous and providing me some files which allowed me to confirm this tutorial for all K2 variants.
Confirmed Working - Credits
Myself - K2_CL
@russellvone - K2_CL
Lordvincent 90 - K2_CL
@DrBassman - K2_CL
REQUIREMENTS FOR THIS TUTORIAL FOR THE PURPOSE OF LEARNING AND APPLYING IT
- This tutorial will be based on an already UNLOCKED Bootloader with TAMPERED flag
- Must be S-OFF
- Must be rooted
- Proper ADB and Fastboot files
- Hex editor (HxD)
- Knowledge of Hex and DD (aka - Data Destroyer)
If you do not know what DD is then please read the following which I extracted from WIKI for the simplicity of this tutorial - Otherwise, skip this and move along.
dd is a command on Unix and Unix-like operating systems whose primary purpose is to convert and copy a file.
On Unix, device drivers for hardware (such as hard disks) and special device files (such as /dev/zero and /dev/random) appear in the file system just like normal files; dd can also read and/or write from/to these files, provided that function is implemented in their respective driver. As a result, dd can be used for tasks such as backing up the boot sector of a hard drive, and obtaining fixed amount of random data. The dd program can also perform conversions on the data as it is copied, including byte order swapping and conversion to and from the ASCII and EBCDIC text encodings.
The name dd may be an allusion to the DD statement found in IBM's Job Control Language (JCL), where the initialism stands for "Data Description." The command's syntax resembles the JCL statement more than it does other Unix commands, so the syntax may have been a joke. Another explanation for the command's name is that "cc" (for "convert and copy", as in the command's description) was already taken by the C compiler.
The dd command is specified by IEEE Std 1003.1-2008, which is part of the Single UNIX Specification.
The command line syntax of dd differs from many other Unix programs, in that it uses the syntax option=value for its command line options, rather than the more-standard --option value or -option=value formats. By default, dd reads from STDIN and writes to STDOUT, but these can be changed by using the if (input file) and of (output file) options.
Usage varies across different operating systems. Also, certain features of dd will depend on the computer system capabilities, such as dd's ability to implement an option for direct memory access. Sending a SIGINFO signal (or a USR1 signal on Linux) to a running dd process makes it print I/O statistics to standard error once and then continue copying (note that signals may terminate the process on OS*X). dd can read standard input from the keyboard. When end-of-file (EOF) is reached, dd will exit. Signals and EOF are determined by the software. For example, Unix tools ported to Windows vary as to the EOF: Cygwin uses (the usual Unix EOF) and MKS Toolkit uses (the usual Windows EOF).
In spirit with the Unix philosophy, dd does one thing (and may be considered to do it "well" ). Unlike a sophisticated and highly abstracted utility, dd has no algorithm other than in the low-level decisions of the user concerning how to vary the run options. Often, the options are changed for each run of dd in a multi-step process to solve a computer problem.
The GNU variant of dd as supplied with coreutils on Linux does not describe the format of the messages displayed on standard output on completion. However, these are described by other implementations, e.g. that with BSD.
Each of the "Records in" and "Records out" lines shows the number of complete blocks transferred + the number of partial blocks, e.g. because the physical medium ended before a complete block was read, or a physical error prevented reading the complete block.
A block is a unit measuring the number of bytes that are read, written, or converted at one time. Command line options can specify a different block size for input/reading (ibs) compared to output/writing (obs), though the block size (bs) option will override both ibs and obs. The default value for both input and output block sizes is 512 bytes (the traditional block size of disks, and POSIX-mandated size of "a block"). The count option for copying is measured in blocks, as are both the skip count for reading and seek count for writing. Conversion operations are also affected by the "conversion block size" (cbs).
For some uses of the dd command, block size may have an effect on performance. For example, when recovering data from a hard disk, a small block size will generally cause the most bytes to be recovered. Issuing many small reads is an overhead and may be non-beneficial to execution performance. For greater speed during copy operations, a larger block size may be used. However, because the amount of bytes to copy is given by bs×count, it is impossible to copy a prime number of bytes in one go without going with one of two bad choices, bs=N count=1 (memory use) or bs=1 count=N (read request overhead). Alternative programs (see below) permit specifying bytes rather than blocks.
Click to expand...
Click to collapse
Let's get started shall we - the following commands highlighted in RED are your commands to execute:
- Go ahead and plug your device in to your PC with a USB cable.
- Open up CMD and change its directory to the location of your proper ADB and Fastboot files
- Establish a proper connection with your device. It should look something like this:
Code:
C:\Users\*******\Desktop\Android_tweak_software\HTC_fastboot_files>[COLOR="Red"][B]adb devices[/B][/COLOR]
List of devices attached
HT3********* device
C:\Users\*******\Desktop\Android_tweak_software\HTC_fastboot_files>
- If connection is established then direct to your devices' adb shell:
Code:
C:\Users\*******\Desktop\Android_tweak_software\HTC_fastboot_files>[COLOR="Red"][B]adb shell[/B][/COLOR]
[email protected]:/ #
- Go ahead and gain superuser rights to your devices' adb shell:
Code:
C:\Users\*******\Desktop\Android_tweak_software\HTC_fastboot_files>adb shell
[email protected]:/ # [COLOR="Red"][B]su[/B][/COLOR]
su
[email protected]:/ #
- Now we need to copy a partition (mmcblk0p7) to your sdcard using DD. Insure you do not make a typo:
Code:
C:\Users\*******\Desktop\Android_tweak_software\HTC_fastboot_files>adb shell
[email protected]:/ # su
su
[email protected]:/ # [COLOR="Red"][B]dd if=/dev/block/mmcblk0p7 of=/sdcard/mmcblk0p7.img[/B][/COLOR]
dd if=/dev/block/mmcblk0p7 of=/sdcard/mmcblk0p7.img
31155+0 records in
31155+0 records out
15951360 bytes transferred in 2.259 secs (7061248 bytes/sec)
[email protected]:/ #
- Now we need to pull this image (mmcblk0p7) to our pc:
Code:
C:\Users\*******\Desktop\Android_tweak_software\HTC_fastboot_files>adb shell
[email protected]:/ # su
su
[email protected]:/ # dd if=/dev/block/mmcblk0p7 of=/sdcard/mmcblk0p7.img
dd if=/dev/block/mmcblk0p7 of=/sdcard/mmcblk0p7.img
31155+0 records in
31155+0 records out
15951360 bytes transferred in 2.259 secs (7061248 bytes/sec)
[email protected]:/ # [COLOR="Red"][B]exit[/B][/COLOR]
exit
[email protected]:/ # [COLOR="Red"][B]exit[/B][/COLOR]
exit
C:\Users\*******\Desktop\Android_tweak_software\HTC_fastboot_files>[COLOR="Red"][B]adb pull /sdc
ard/mmcblk0p7.img[/B][/COLOR]
2523 KB/s (15951360 bytes in 6.172s)
C:\Users\*******\Desktop\Android_tweak_software\HTC_fastboot_files>
- Go ahead and repeat these steps for (mmcblk0p3).
- At this time go ahead and open up your hex editor (HxD) and at the top right change from hex in the drop down bar to dec - you will do this (if necessary) for all images pertaining to this tutorial.
- Drag\drop (mmcblk0p3.img) in to the hex editor (HxD).
- Now hit ctrl+F or go to the Search tab, then click on Find.
- Search for HTCU. You will see the following:
Code:
Offset(d) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15
000033728 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000033744 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000033760 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000033776 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[COLOR="Red"][B]000033792[/B] 00 00 00 00 [B]48 54 43 55[/B] 01 00 00 00 00 00 00 00 ....[B]HTCU[/B]........[/COLOR]
000033808 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000033824 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000033840 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000033856 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
- Drag\drop (mmcblk0p7.img) in to the hex editor (HxD).
- Now hit ctrl+G or go to the Search tab, then click on Goto....
- Search for DEC OFFSET 4265984.
- You will see something like this:
Code:
Offset(d) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15
04265920 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
04265936 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
04265952 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
04265968 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[COLOR="Red"][B]04265984[/B] [B]68 25 32 C6 02[/B] 00 00 00 00 00 00 00 00 00 00 00 [B]h%2Æ.[/B]...........[/COLOR]
04266000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
04266016 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
04266032 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
04266048 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
- Now that we have what we needed loaded and prepped we want to see what needs adjustment regarding lock, unlock, relock, and tampered.
- These two partitions are already stamped with the bootloader being unlocked as well as being tampered so finding what we are looking for makes it easy as seen above.
- mmcblk0p3 is the partition which determines if our device is locked, unlocked, or relocked.
- mmcblk0p7 is the partition which determines if our device is tampered with or not.
- Let's look at mmcblk0p3. We see in red, HTCU, which we already know means Unlocked, because as I mentioned in the beginning, this tutorial is based on an already unlocked bootloader and tampered device.
Code:
[COLOR="Red"][B]000033792[/B] 00 00 00 00 [B]48 54 43 55[/B] 01 00 00 00 00 00 00 00 ....[B]HTCU[/B]........[/COLOR]
- We want to lock or relock our device. To relock is, "HTCL". To Lock is, "00 00 00 00".
- Our goal is creating a dd command which will implement these changes for us to our partition already on our device.
- To lock:
Code:
echo -ne '\x00\x00\x00\x00' | dd of=/dev/block/mmcblk0p3 bs=1 seek=33796
- To relock:
Code:
echo -ne "HTCL" | dd of=/dev/block/mmcblk0p3 bs=1 seek=33796
- To unlock:
Code:
echo -ne "HTCU" | dd of=/dev/block/mmcblk0p3 bs=1 seek=33796
- The command for seek is what determines the decimal search of that partition when implementing the echo command from start to finish, from left to right as it writes it out. This is why earlier I told you to change it from hex to dec in your hex editor. If you look at seek=33796 and go back to your hex editor you will notice the dec offset says 33792 then underneath that it says 33808.
Code:
Offset(d) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15
000033792 00 00 00 00 48 54 43 55 01 00 00 00 00 00 00 00 ....HTCU........
000033808 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
- To determine the exact decimal location where the dd command will start writing to you must first look at the top of your hex editor where it shows '00 01 02 03 04 05, etc'. You will take the offset for 33792 and look at where HTCU begins then scroll to the top which in this case it aligns to '04', so we add 04 to the offset of 33792 which gives us a total of 33796. This becomes our seek (our starting point).
- Now that we have established this concept with mmcblk0p3.img, lets go and take a look at mmcblk0p7.img.
- We already know our device has been tampered with. If you search for tamper or tampered you will find results and these results eventually bring you to where we already are as mentioned above and if following along then what you are currently looking at on your pc.
- This one is really simple. Either your device is tampered or it is not. In this case we notice '02' which signifies the setup for being tampered.
Code:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00411800 68 25 32 C6 02 00 00 00 00 00 00 00 00 00 00 00 h%2Æ............
- Let's go ahead and change it to '00' with the following dd command:
Code:
echo -ne '\x00' | dd of=/dev/block/mmcblk0p7 bs=1 seek=4265988
- To restore back to tampered you will just replace 00 with 02.
(FOR K2_PLC_CL USERS, REPLACE 00 WITH 04, INSTEAD OF 02 - Credit goes to @DOrtego for notifying me of this)
- Now to show you how to execute these commands. I will only use one command for this example since it will be the same for all of them. The following in RED will be your commands to execute. A lot of these will be due to insuring you are set up prior to executing the dd command itself, so if you are already good to go then just seek for the dd command and follow along:
Code:
C:\Users\*******\Desktop\Android_tweak_software\HTC_fastboot_files>[COLOR="Red"][B]adb devices[/B][/COLOR]
List of devices attached
HT********** device
C:\Users\*******\Desktop\Android_tweak_software\HTC_fastboot_files>[COLOR="Red"][B]adb shell[/B][/COLOR]
[email protected]:/ # [COLOR="Red"][B]su[/B][/COLOR]
su
[email protected]:/ # [COLOR="Red"][B]echo -ne '\x00' | dd of=/dev/block/mmcblk0p7 bs=1 seek=4265988[/B][/COLOR]
ock/mmcblk0p7 bs=1 seek=4265988 <
1+0 records in
1+0 records out
1 bytes transferred in 0.012 secs (83 bytes/sec)
[email protected]:/ # [COLOR="Red"][B]exit[/B][/COLOR]
exit
[email protected]:/ # [COLOR="Red"][B]exit[/B][/COLOR]
exit
C:\Users\*******\Desktop\Android_tweak_software\HTC_fastboot_files>
I will also show you how to go back to S-ON, but you BETTER make sure you have your stock HBoot.img flashed, Stock Boot.img flashed, etc OR YOU WILL BRICK YOUR DEVICE INDEFINITELY!!!
YOU MUST FIRST BE IN FASTBOOT - THERE WILL BE NO USING ADB NOR A TERMINAL EMULATOR FOR THIS STEP
To go from radio S-OFF to radio S-ON enter the following :
Code:
[B]fastboot oem writesecureflag 3[/B]
To go from HBoot S-Off to HBoot S-On just flash a stock HBoot to remove the modified version.
Code:
[B]adb reboot bootloader[/B]
// booting in to bootloader
[B]fastboot devices[/B]
// establishing connection between device and PC
[B]fastboot oem rebootRUU[/B]
// booting in to RUU
[B]fastboot flash zip filename.zip[/B]
// .zip with stock HBoot image
[B]fastboot reboot-bootloader[/B]
// confirm mod S-Off HBoot now reads new S-On from stock HBoot
[B]fastboot reboot[/B]
// boot OS
So, there you have it everyone! Enjoy, and profit!
--- Happy Hunting!
Other users, what I did to confirm this was by pulling mmcblk0p3 and mmcblk0p7 for both versions and compared the results with a hex editor to determine these steps are valid for the K2_CL variant. Enjoy.
EDIT: Confirmed for ALL K2 variants
Sent from my C525c using XDA Premium 4 mobile app
And yes, I used my device as a guinea pig so of course it works
Sent from my C525c using XDA Premium 4 mobile app
Modding.MyMind said:
And yes, I used my device as a guinea pig so of course it works
Sent from my C525c using XDA Premium 4 mobile app
Click to expand...
Click to collapse
What if we wish to put *tampered* back?
Lol
Hmmm, I would have to look at that as I did not consider that as an option. However, having 'tampered' being displayed leaves traces so why would you want to lol.
Sent from my C525c using XDA Premium 4 mobile app
Complete joke, very well done sir.
Awesome find!
Yea, I knew it was ha! And thanks. Would like to see if this works for the other variants as well but I do not have what I need from them so either they will need to figure it out or become very brave with trying my steps lol.
Sent from my C525c using XDA Premium 4 mobile app
+sorry for the off topic+
but I decided to do a complete factory restore of my phone and accept an ota update to see if I could get to that clockworkmod like screen in stock recovery.
and it let me
first attempt it just installed the update without letting me into the clockworkmod like..........
so I simply deleted a system app accepted the next update, allowed to boot into recovery,
then once it got to the hated /!\ Red triangle, I just held volume+ then pressed power and it let me see the reason for the fail.
thought you would like to play with it
Awesome! Thanks.
Sent from my C525c using XDA Premium 4 mobile app
Maybe @old.splatterhand could look in to this with the K2_U and K2_UL variants .
And possibly add this finding to his index *cough**cough* haha
Sent from my C525c using XDA Premium 4 mobile app
Modding.MyMind said:
Awesome! Thanks.
Sent from my C525c using XDA Premium 4 mobile app
Click to expand...
Click to collapse
alrighty, just got into it again, used an app called quick boot and booted into recovery, again it would not let me in to CWM-like until it showed red triangle then had to hold volume+ then power, tried to apply a different zip (crossbreeder)
aborted,
I'm gonna do some playing myself!
I have added it to my Index, but i have to add much more, when its time.
@Modding.MyMind
confirmed working......
thanks again sir, very proud of your hard work!
Yea, will be uploading pictures soon enough so people can see it on my phone. Unfortunately, I won't be able to get a pic where it shows *tampered* because I already removed it lol (but hey, if it isn't there that is evidence in itself). But I can atleast provide pics where it shows locked (not relocked) and unlocked with S-Off.
I got other projects I am looking into as well. Hopefully, they too will be just as satisfying as this.
Sent from my C525c using XDA Premium 4 mobile app
Modding.MyMind said:
I got other projects I am looking into as well. Hopefully, they too will be just as satisfying as this.
Sent from my C525c using XDA Premium 4 mobile app
Click to expand...
Click to collapse
Just helped a fellow with the handle
Lordvincent 90
over on AndroidForums
sent him this way so he could use your find so he could his phone in for hardware repair.......
with out any traces of s-off!!!!
#already_awesome
oh yeah.... I'm on edge waiting for more!
very impressed with what you've brought so early in the game.
I'm rooting for ya \ /*_*\ /
russellvone said:
Just helped a fellow with the handle
Lordvincent 90
over on AndroidForums
sent him this way so he could use your find so he could his phone in for hardware repair.......
with out any traces of s-off!!!!
#already_awesome
oh yeah.... I'm on edge waiting for more!
very impressed with what you've brought so early in the game.
I'm rooting for ya \ /*_*\ /
Click to expand...
Click to collapse
I have added him to the OP under credits
Glad this served him well and soon others when it calls for it
Sent from my C525c using XDA Premium 4 mobile app
Reserved....
Sent from my C525c using XDA Premium 4 mobile app
russellvone said:
very impressed with what you've brought so early in the game.
Click to expand...
Click to collapse
Newbie on XDA forums, but as for androids... Especially K2_CL... Pretty much got the experience needed to get by and to grow. I focus most on mods, hence my name. Something about modding gets me pumped haha.
That's my Bio and I'm sticking to it.
Sent from my C525c using XDA Premium 4 mobile app
Modding.MyMind said:
Newbie on XDA forums, but as for androids... Especially K2_CL... Pretty much got the experience needed to get by and to grow. I focus most on mods, hence my name. Something about modding gets me pumped haha.
That's my Bio and I'm sticking to it.
Sent from my C525c using XDA Premium 4 mobile app
Click to expand...
Click to collapse
THAT'S WHAT I'M SCREAMING!
:beer: «--one for you
:beer: «--one for me
cheers!
#EDIT#
for some reason my beers look like smiley faces on tapatalk?¿
Pictures uploaded in OP. Take additional note that in both pictures you do not see *tampered* nor do you see *relocked*. Enjoy.
Sent from my C525c using XDA Premium 4 mobile app
Hello All,
I am trying to understand the commands send by LG Flashtool to Nexus-5 phones while flashing the device with new firmware.
I looked at the USB log while flashing the firmware and I found that the commands are starting with a 4 byte header (OPEN, HELO, READ, WRTE, etc), followed by data payload, 2 byte checksum (I think CRC-16) and a 4 byte tail. For example a READ command looks like the following:
52 45 41 44 11 00 00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 5B 87 00 00 AD BA BE BB
Splitting the command into sections
52 45 41 44 11 00 00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 5B 87 00 00 AD BA BE BB
READ ID Start address Size to read CRC-16? TAIL FLAG
The TAIL and the HEADER (READ) does not change as the commands data payload changes, but the CRC-16 value changes.
I am wondering if anyone can throw some light on how the check sum bytes are calculated? Are they using CRC-16? I tried some basic CRC-16 algorithm but I am not getting the same values. If CRC-16 is used then what is the polynomial and initial values used?
I hope someone knows how it works.
Thank you.
Cheers!
Can I just ask why you wanna know, like what are you trying to achieve?
Sent from my XT1526 using Tapatalk
soupysoup said:
Can I just ask why you wanna know, like what are you trying to achieve?
Sent from my XT1526 using Tapatalk
Click to expand...
Click to collapse
Hello XT1526,
I am working on a hobby project to use download mode commands to dump Nexus phone memories.
So, I am trying to generate custom commands that can be sent to the phone that will enable reading from and writing to sectors that I want to.
For Nexus-4 phones all the commands use an HDLC format (starting and ending with a 0x7e flag), so it was comparatively easy to figure out the command including the CRC-16 value. My assumption that the 2 bytes should be CRC values comes from the experience from Nexus-4.
When I looked at the Nexus-5 commands (from Flashtool log), there are commands that use HDLC format and then commands with headers like READ and HELO. And I cannot understand the CRC calculation and am kind of stuck!
Any help would be great !!
Cheers!
As a software engineer u have me interested...... I'll take a look
Sent from my XT1526 using Tapatalk
soupysoup said:
As a software engineer u have me interested...... I'll take a look
Sent from my XT1526 using Tapatalk
Click to expand...
Click to collapse
Hello soupysoup,
Thank you for spending your time on this!
Cheers.