[Tool] Signing tool for pre 3.2.4 booloaders - Kindle Fire HDX 7" & 8.9" Original Android Develop

[Tool] Signing tool for pre 3.2.4 booloaders - Kindle Fire HDX 7" & 8.9" Original Android Develop

I am proud to present you my image signing tool called Cuber.
The name is an abbreviation of Cube Root finder. This is basically what the tool does.
About
This is a tool that checks and signs recovery/boot images for Little Kernel bootloaders missing the patch for for CVE-2014-0973.
Who is vulnurable?
Kindle Fire HDX tablets with firmware versions older than 3.2.4. On 3.2.4 it is NOT working.
Probably many devices using pre 13 June 2014 Little Kernel bootloaders. (no guarantees)
Requirements on an Ubuntu system:
Code:
gcc
libmpc-dev
libmpfr-dev
libgmp3-dev
libssl-dev
python
python-pip
Also the following python package is required:
Code:
gmpy2
install it using pip:
Code:
sudo pip install gmpy2
Installation
Download the source code from https://github.com/Verteo/Cuber to your desired folder, go to the folder and run make.
Usage
Code:
./cuber -check path/to/image.img
checks if the image would pass the signature verification
Code:
./cuber -sign path/to/input/image.img path/to/output/image.img
creates a signature for the given image and creates a new signed at the specified location
The files prodcert.pem and signature.py are required by the application to work
Why python?
It is easier to handle bignums in python than in c++.
The exploit
https://www.codeaurora.org/projects...tion-leads-to-signature-forgery-cve-2014-0973
The bootloader is not properly checking the number of bytes decrypted from the signature. This allows us insert to garbage bytes and create a forged signature.
A decrypted (cubed) PKCS#1 v1.5 padded signature starts with 00 01 PS 00.
PS is the padding string and consists at least of 8 FF bytes
After the start of the signature comes the 32 byte long SHA256 image hash.
So the decrypted signature should look something like this:
Code:
00 01 FF FF FF FF FF FF FF FF 00 xx xx xx xx xx
xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx
xx xx xx xx xx xx xx xx xx xx xx .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
Where xx is the hash and the .. are the garbage bytes.
The garbage byte can have an arbitrary value. We use them to create a perfect cube root.
Example
Hash of example image:
Code:
A9 07 1C A3 31 43 16 F7 2E 9A FF B3 31 46 A6 EC 60 6E DE 42 45 9E 4C 9B 6B 5F B0 E1 97 1C 33 85
Desired cubed signature:
Code:
00 01 FF FF FF FF FF FF FF FF 00 A9 07 1C A3 31
43 16 F7 2E 9A FF B3 31 46 A6 EC 60 6E DE 42 45
9E 4C 9B 6B 5F B0 E1 97 1C 33 85 .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
Generated signature:
Code:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 32 CB FD 4A 7A
DC 79 05 58 41 75 78 07 60 1D 4F D5 09 9A 22 ED
4A F3 B3 46 62 94 03 A0 78 BF AE E1 FF 07 49 B4
98 C9 C7 F6 96 A1 66 E1 3A D0 8A 97 9D 82 4D 64
08 4E 91 B1 D3 F8 EB 97 81 57 92 97 D3 F2 E5 D5
6F A4 6C DC 91 79 11 A4 9F 23 83 4E A4 84 20 C0
Generated signature cubed:
Code:
00 01 FF FF FF FF FF FF FF FF 00 A9 07 1C A3 31
43 16 F7 2E 9A FF B3 31 46 A6 EC 60 6E DE 42 45
9E 4C 9B 6B 5F B0 E1 97 1C 33 85 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 8D C2 E5 F5 65 19 0A BA 69 BA
14 29 BE 83 F4 2E 61 04 3E 1E 59 79 3C C6 D6 D8
D0 59 D1 46 E4 D4 86 B8 D4 A0 C1 2F 3A 4C 72 F7
F4 14 E7 CF CE 3F 5D A3 53 25 D6 7B 7B 83 AF 66
B8 42 A7 06 79 7C 31 69 51 43 F6 83 B2 29 65 81
F5 B0 9D 93 77 6B BA 83 52 C0 F0 68 93 AF 65 9E
19 F2 EC 9D 9A 76 90 30 15 5F F5 B5 88 EB 89 FE
CB DC 3A 4E D7 71 32 E3 10 FF 39 C0 C0 73 47 71
A2 C4 07 7A 3C E2 F7 96 68 A3 C8 35 40 33 02 A5
AA 4E CB BB AC 56 DB 98 F2 50 76 BD A7 82 6E C3
AC 34 F4 E9 E7 87 99 43 B4 6E 94 67 F6 6C 00 00
As you may notice this is valid signature.
Disclaimer
I'm not an expert at cryptography, my statements may be false or incomplete.

I'm not sure if this is an isolated problem, but I'm getting errors when I try to compile:
Code:
[email protected]:/Cuber-master# make
g++ -Iinclude Cuber.cpp -o Cuber -lcrypto
In file included from Cuber.h:7:0,
from Cuber.cpp:1:
bootimg.h:108:5: error: ‘uint32_t’ does not name a type
uint32_t insn;
^
bootimg.h:109:5: error: ‘uint32_t’ does not name a type
uint32_t res1;
^
bootimg.h:110:5: error: ‘uint64_t’ does not name a type
uint64_t text_offset;
^
bootimg.h:111:5: error: ‘uint64_t’ does not name a type
uint64_t res2;
^
bootimg.h:112:5: error: ‘uint64_t’ does not name a type
uint64_t res3;
^
bootimg.h:113:5: error: ‘uint64_t’ does not name a type
uint64_t res4;
^
bootimg.h:114:5: error: ‘uint64_t’ does not name a type
uint64_t res5;
^
bootimg.h:115:5: error: ‘uint64_t’ does not name a type
uint64_t res6;
^
bootimg.h:116:5: error: ‘uint32_t’ does not name a type
uint32_t magic_64;
^
bootimg.h:117:5: error: ‘uint32_t’ does not name a type
uint32_t res7;
^
Cuber.cpp: In function ‘int main(int, char**)’:
Cuber.cpp:18:30: error: ‘strcmp’ was not declared in this scope
if (strcmp(argv[1], "-check") == 0 && argc == 3){
^
Cuber.cpp:22:29: error: ‘strcmp’ was not declared in this scope
if (strcmp(argv[1], "-sign") == 0 && argc == 4) {
^
Cuber.cpp: In function ‘int check_image(char*)’:
Cuber.cpp:77:41: error: ‘memcpy’ was not declared in this scope
memcpy(hdr, image, sizeof(boot_img_hdr));
^
Cuber.cpp:83:45: error: ‘memcmp’ was not declared in this scope
if (memcmp((char*)hdr->magic, "ANDROID!", 8) != 0){
^
Cuber.cpp: In function ‘int sign_image(char*, char*)’:
Cuber.cpp:168:45: error: ‘memcmp’ was not declared in this scope
if (memcmp((char*)hdr->magic, "ANDROID!", 8) != 0){
^
Cuber.cpp:235:37: error: ‘memset’ was not declared in this scope
memset(signature, 0, SIGNATURE_SIZE);
^
Cuber.cpp:249:62: error: ‘memcpy’ was not declared in this scope
memcpy(image + imagesize_actual, signature, SIGNATURE_SIZE);
^
Cuber.cpp: In function ‘int verify_image(unsigned char*, unsigned char*, unsigned int)’:
Cuber.cpp:359:42: error: ‘memcmp’ was not declared in this scope
if (memcmp(plain_text, digest, hash_size) != 0) {
^
Cuber.cpp: In function ‘int create_signature(unsigned char*, unsigned char*)’:
Cuber.cpp:450:48: error: ‘memcpy’ was not declared in this scope
memcpy(outputbuffer + offset, buffer, filesize);
^
Makefile:2: recipe for target 'all' failed
make: *** [all] Error 1

Not sure if i should post here but can I say genius.... The people who develop here are extremely talented in what they do. To be on point. That is amazing work you have put together. Roots and cubing....my gosh...

@vortox: I submitted a pull request with the help of @TheReverend403, which notably fixes the errors I was facing above and some more.
https://github.com/Verteo/Cuber/pull/2

Thanks again vortox, great work

EncryptedCurse said:
@vortox: I submitted a pull request with the help of @TheReverend403, which notably fixes the errors I was facing above and some more.
https://github.com/Verteo/Cuber/pull/2
Click to expand...
Click to collapse
I merged them.
Thank you.

What are the chances this works on Amazon's Fire phone? I just picked one up dirt cheap and I would love to flash CM on it.

What is the possibility to run this on a Samsung galaxy s4 with a 4.3 bootloader?

dray said:
What are the chances this works on Amazon's Fire phone? I just picked one up dirt cheap and I would love to flash CM on it.
Click to expand...
Click to collapse
aromerblz said:
What is the possibility to run this on a Samsung galaxy s4 with a 4.3 bootloader?
Click to expand...
Click to collapse
(To both
If you're curious, just try it out. Worst case, you will need to restore your device (be sure that you know how to do this beforehand).

r3pwn said:
(To both
If you're curious, just try it out. Worst case, you will need to restore your device (be sure that you know how to do this beforehand).
Click to expand...
Click to collapse
Maybe an unsigned fire phone boot image might be signed with this?
Sent from my GT-i9100 running CM11

dray said:
What are the chances this works on Amazon's Fire phone? I just picked one up dirt cheap and I would love to flash CM on it.
Click to expand...
Click to collapse
SafinWasi said:
Maybe an unsigned fire phone boot image might be signed with this?
Sent from my GT-i9100 running CM11
Click to expand...
Click to collapse
Yes you can sign an image. You just need a vulnurable bootloader. The exploit was publicly fixed on 13 June and the first patched bootloader for the hdx tablets ( .3.2.4) was compiled on 20 June.

vortox said:
Yes you can sign an image. You just need a vulnurable bootloader. The exploit was publicly fixed on 13 June and the first patched bootloader for the hdx tablets ( .3.2.4) was compiled on 20 June.
Click to expand...
Click to collapse
Does the exploit work on MSM chipset phones?

I guess nobody has tested this yet since vortox created this specifically for our devices. It may work for other devices as well, but it can only be devolved by people who have those other devices

SafinWasi said:
Does the exploit work on MSM chipset phones?
Click to expand...
Click to collapse
It should work with other chipsets, as long as they use Qualcomm's Little Kernel bootloader.

vortox said:
It should work with other chipsets, as long as they use Qualcomm's Little Kernel bootloader.
Click to expand...
Click to collapse
How can I find which bootloader it uses?
Sent from my GT-i9100 running CM11

SafinWasi said:
How can I find which bootloader it uses?
Sent from my GT-i9100 running CM11
Click to expand...
Click to collapse
MOst, if not all, Qualcomm SoC devices use little kernel to boot android.

What about TrustZone kernels? And the stock boot image should pass the test for signature verification using --check,yeah?

SafinWasi said:
What about TrustZone kernels? And the stock boot image should pass the test for signature verification using --check,yeah?
Click to expand...
Click to collapse
I guess you would have to change the prodcert.pem certificate with your device one for that to work.

vortox said:
It should work with other chipsets, as long as they use Qualcomm's Little Kernel bootloader.
Click to expand...
Click to collapse
V,
according to the articles affected projects/products
Affected Projects
Android for MSM Firefox OS for MSM QRD Android
i will be trying this out for a locked device [msm] that i do not own but i have an unlocked equivalent.
that being said, i have a few questions,
can i just "port" the signature from another image via hex, if so/not the "magic" from OP should be similar/uniform
across devices ? if no, would you know a good rule of thumb for finding the signature ?
though i would be testing on an unlocked device, if in last_kmsg the signature check comes through as valid
can i assume the approach will succeed for the locked device?
i have alot more questions but, don't want to take up your time. thanks.
m
okay, a few more questions, the device i'm working for is 32bit,
in bootimg.h does this need to be modified?
Code:
#define KERNEL64_HDR_MAGIC 0x644D5241 /* ARM64 */
struct kernel64_hdr
{
uint32_t insn;
uint32_t res1;
uint64_t text_offset;
uint64_t res2;
uint64_t res3;
uint64_t res4;
uint64_t res5;
uint64_t res6;
uint32_t magic_64;
uint32_t res7;
};
#endif
and how/where do i find that info? also how do i obtain prodcert.pem for this device , or any device really.
in breaking down the recovery.img i find publiccert.pem.
Right now either way i slice it i get and invalid signature on a check of the stock recovery.img.
thanks.
m
also in signature.py , how to adjust for a samsung device and again where/how to acquire that data
Code:
def createsig():
# modulus of of amazon certificate
modulus = 0x00c88adfc863913d4e7a63680297db526bd5dfec3d62cba01b358691d5bf3c2599a7c036f70e3044bd04c8a0b4aabd6a1dab829a787c060fd58f0ecdbdda9ca7b08b1e8a3e1dc28e73c8b7d6f66ee39d260e0b7b4773d200c14a9167a5f5697008ea44cae2ecba0cc3ccf7678011ec871b0228db3ca64f4abc70cb954f5fe1816e4b1b7929b6625ba070d2d2e7df5fc30b6e412c9ee77a14fac94ef71d234ad30c29558830b690ca89601e5ad11eee1b087203a9e66d1a9bd5cc2bc060583f362cf854f7bf780abc6ed08fd393da72c7f07948c438421293da5ab261c976da5bfd1a86470eb4b8e4dc09f692124c64090bea03d62f8a5650d90e88cd6f7859
# PKCS#1 v1.5 fixed prefix
prefix = 0x0001FFFFFFFFFFFFFFFF000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
#load the hash from created file
f = open("hash.abc", "rb")
block = f.read(32)
hash = struct.unpack('>4Q', block)
hash0 = int(hash[0])<<192
hash1 = int(hash[1])<<128
hash2 = int(hash[2])<<64
hash3 = int(hash[3])
hash5 = hash0 + hash1 + hash2 + hash3
# get hash to right position
hash = hash5 << 1704
#create forged prefix
prefix = forge_prefix(prefix+hash, 86*8, modulus)
# write signature to file
pref = int(prefix)
file = open("signature.abc","wb")
file.write(long_to_bytes(pref, "big"))
createsig()

moonbutt74 said:
V,
according to the articles affected projects/products
Affected Projects
Android for MSM Firefox OS for MSM QRD Android
i will be trying this out for a locked device [msm] that i do not own but i have an unlocked equivalent.
that being said, i have a few questions,
Click to expand...
Click to collapse
I will try my best to answer them.
can i just "port" the signature from another image via hex, if so/not the "magic" from OP should be similar/uniform
across devices ? if no, would you know a good rule of thumb for finding the signature ?
Click to expand...
Click to collapse
This doesn't work as the the signature contains the encrypted hash of the image which is then encrypted and compared to the calculated hash of the image. Copying the signature will result in a signature mismatch and therefore an invalid image.
though i would be testing on an unlocked device, if in last_kmsg the signature check comes through as valid
can i assume the approach will succeed for the locked device?
Click to expand...
Click to collapse
I'm not sure about that approach. On the HDX and in LK reference code the signature shouldn't be checked if the device is unlocked.
okay, a few more questions, the device i'm working for is 32bit,
in bootimg.h does this need to be modified?
Code:
#define KERNEL64_HDR_MAGIC 0x644D5241 /* ARM64 */
struct kernel64_hdr
{
uint32_t insn;
uint32_t res1;
uint64_t text_offset;
uint64_t res2;
uint64_t res3;
uint64_t res4;
uint64_t res5;
uint64_t res6;
uint32_t magic_64;
uint32_t res7;
};
#endif
Click to expand...
Click to collapse
The HDX is 32bit, too. My application is written for 32bit images. ( I should add that in the description)
and how/where do i find that info? also how do i obtain prodcert.pem for this device , or any device really.
in breaking down the recovery.img i find publiccert.pem.
Click to expand...
Click to collapse
The prodcert.pem shouldn't matter in an exploitable implementation. It's just there because my code is almost a 1:1 copy of the LK code, which requires certificate.
Right now either way i slice it i get and invalid signature on a check of the stock recovery.img.
Click to expand...
Click to collapse
Could you send me the image?
also in signature.py , how to adjust for a samsung device and again where/how to acquire that data
Code:
def createsig():
# modulus of of amazon certificate
modulus = 0x00c88adfc863913d4e7a63680297db526bd5dfec3d62cba01b358691d5bf3c2599a7c036f70e3044bd04c8a0b4aabd6a1dab829a787c060fd58f0ecdbdda9ca7b08b1e8a3e1dc28e73c8b7d6f66ee39d260e0b7b4773d200c14a9167a5f5697008ea44cae2ecba0cc3ccf7678011ec871b0228db3ca64f4abc70cb954f5fe1816e4b1b7929b6625ba070d2d2e7df5fc30b6e412c9ee77a14fac94ef71d234ad30c29558830b690ca89601e5ad11eee1b087203a9e66d1a9bd5cc2bc060583f362cf854f7bf780abc6ed08fd393da72c7f07948c438421293da5ab261c976da5bfd1a86470eb4b8e4dc09f692124c64090bea03d62f8a5650d90e88cd6f7859
# PKCS#1 v1.5 fixed prefix
prefix = 0x0001FFFFFFFFFFFFFFFF000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
#load the hash from created file
f = open("hash.abc", "rb")
block = f.read(32)
hash = struct.unpack('>4Q', block)
hash0 = int(hash[0])<<192
hash1 = int(hash[1])<<128
hash2 = int(hash[2])<<64
hash3 = int(hash[3])
hash5 = hash0 + hash1 + hash2 + hash3
# get hash to right position
hash = hash5 << 1704
#create forged prefix
prefix = forge_prefix(prefix+hash, 86*8, modulus)
# write signature to file
pref = int(prefix)
file = open("signature.abc","wb")
file.write(long_to_bytes(pref, "big"))
createsig()
Click to expand...
Click to collapse
The only thing you may have to change would be the modulus, but shouldn't do that. The prefix is static and doesn't need to change and the hash of image is passed using a file created by the application.
You said you are using a Samsung device and as far as I know Samsung likes to create their own implementation of something. Without an analysis of the bootloader I'm not able to say if they are using a LK bootloader or if it is exploitable.

Related

[REQ]Capture ELF/ELFIN Device ID and CID ID (to help CyZeek)

Hi Everyone
I'm posting this to help out CyZeek.
To capture ELF/ELFIN Device ID and CID ID using MTTY and USB Monitor Lite on XP SP2 and Vista x64
You will need:
1. A demo copy of USB Monitor Lite
http://www.hhdsoftware.com (the demo is fully functional for 14 days).2. A Copy of MTTY (and you need to be basically familiar with it)
Put your Device into Boot Loader
Assuming your device is not already at the TSoD (Tricolour Screen of Death) - if it is skip this instruction and move on to the next section.
1. Press and hold your camera button
2. Press reset with stylus
3. Wait 5 seconds and release the camera button
Kill ActiveSync USB Connections - XP
1. Reboot your PC with without a mobile device connected to USB.
2. After your PC has rebooted Right Click the Active sync Icon in the system tray and select "Connection Settings"
3. Turn off USB
-or-
Kill ActiveSync USB Connections - Vista
Download and install MS Windows Mobile Device Centre from here: http://www.microsoft.com/windowsmobile/devicecenter.mspx
1. Reboot your PC with without a mobile device connected to USB.
2. After your PC has rebooted click Start -> All Programs -> Windows Mobile Device Centre
3. Hover over Mobile Device Settings and Click on Connection Settings.
4. Turn off Allow USB Connections
Connect Your Device to USB
1. Plug in the USB cable
Turn On Spoofing / packet capture
1. Install the demo version of USB Monitor Lite (DMS) and Start Device Monitoring Studio.
2. Connect your device which should be in TSoD (Tricolour Screen of Death) boot loader.
3. Click the item entitled "Pocket PC USB Sync" which activates the main screen
4. Double-Click the item entitled "Packet View" in the Session Configuration Screen.
5. Click the Start button in the selected processing region
You'll know you got this right because you will see two packets displayed:
PnP: Device Connected
Internal: Pipe Info Transfer6. Leave the USB Monitor running
Run up MTTY, Log In and Issue “getdevinfo” Command
For details on downloading MTTY and recovering from the TSoD see this thread: http://forum.xda-developers.com/showthread.php?t=347700
1. In "Open Port Setting" Dialog Set to Port = USB
2. Flow Cont = RTC/CTS
3. Click OK
4. When a new communication page opens press Enter and the Cmd> prompt will be displayed
5. Type password BsaD5SeoA <enter> (a lot of diagnostic info will be displayed).
Somewhere near the end you should see
g_cKeyCardSecurityLevel = FF
Which will tell you that you're CID LockedCheck that USB Monitor is running (you may need to press the "continue 14 day trial" button to get the capture to continue)6. Type getdevinfo and press <enter>
These commands are case sensitive!
Cmd>getdevinfo
HTCSELF030050œ=Ó HTCE7. Leave MTTY running
Swap Back to USB Monitor
1. Starting at the last packet in the list, double click each row whose Direction is "Up"
2. The 12th packet from the end of the list when I did mine had the device ID and CID packet shown below.
45 4C 46 30 33 30 30 35 30 00 00 00 00 00 00 00 ELF030050.......
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
54 2D 4D 4F 42 30 30 35 00 00 00 00 00 00 00 00 T-MOB005........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- -- ..............
Copy and paste the text into a text file and keep for future reference as the Device ID and CID ID are useful in determining the right ROM files to use as well as the wrong ones.
To Re-Enable Boot on a Good Device
Unless you tell the device where to boot from it will go back to boot loader every time so you need to re-enable boot from ROM.
These commands are case sensitive!1. Swap back to MTTY session
2. Type ruurun 0 <enter>
3. Type ResetDevice <enter>
Hope this helps.
Yours
Leon

Thank you Leon, im gonna post a link to this post a the rom compilation thread ( Elf/Elfin Original Roms Model Id & Cid Id List ), for the people who wants to make a request.

Any time, CyZeek
The work you're doing on ROMs DevIDs and CIDs is very important indeed, glad to help.
Yours
Leon

Thank you
After a long tima trying i managed to get the CID!
It worked fine!
Thank you
Question:
Any one knows if a non original rom ends the warranty if the device is malfunctioning?

filiperod said:
After a long tima trying i managed to get the CID!
It worked fine!
Thank you
Question:
Any one knows if a non original rom ends the warranty if the device is malfunctioning?
Click to expand...
Click to collapse
Yes it's against warranty terms. But, if your are using a cooked rom, and need service from HTC, just reflash with your original rom and no prob.

g_cKeyCardSecurityLevel = o
what does it mean?

...
5. Type password BsaD5SeoA <enter> (a lot of diagnostic info will be displayed).
Somewhere near the end you should see
g_cKeyCardSecurityLevel = FF
Which will tell you that you're CID LockedCheck that USB Monitor is running (you may need to press the "continue 14 day trial" button to get the capture to continue)...
no - in that case nothing happens, when I try to type in "getdevinfo" and execute - system tells me - "wrong password".
what can I try to do?

Just in case you misunderstood...
5.Type:> password BsaD5SeoA <=Don't copy/paste from here!
Press:> [ENTER]
...
...
&go on with Leon's process.
Regards!

did everything as stated however no success....each UP line basically has stuff similar this written only in it....
000079: Bulk or Interrupt Transfer (UP), 04.06.2008 18:34:21.699 +0.001. Status: 0x00000000
Pipe Handle: 0x846006ec (Endpoint Address: 0x82)
Get 0x1 bytes from the device

Dude you Rock
leondaphillips
you rock so hard that i feel the love here in Dunedin New Zealand
after harting round for days with vista drivers and all the random **** life(and computers) and now my phone hits me with i have acheaved CID nowing niss thanks to this thread here the sweet code:
45 4C 46 30 31 30 30 30 30 00 00 00 00 00 00 00 ELF010000.......
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
44 4F 50 4F 44 30 30 31 00 00 00 00 00 00 00 00 DOPOD001........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..............
phone is GSM vodafone Touch from singapore.thanks mate keep the howtos comeing.

Thankyou verymuch its a goodway

leondaphillips said:
Hi Everyone
I'm posting this to help out CyZeek.
4. When a new communication page opens press Enter and the Cmd> prompt will be displayed
5. Type password BsaD5SeoA <enter> (a lot of diagnostic info will be displayed).
Somewhere near the end you should see
g_cKeyCardSecurityLevel = FF
Which will tell you that you're CID Locked
Click to expand...
Click to collapse
Mine is FF, CID locked?
These commands are case sensitive!
Cmd>getdevinfo
HTCSELF030050œ=Ó HTCE
Click to expand...
Click to collapse
Cmd>getdevinfo
HTCSELF010050gUH¥HTCE
Cmd>
2. The 12th packet from the end of the list when I did mine had the device ID and CID packet shown below.
45 4C 46 30 33 30 30 35 30 00 00 00 00 00 00 00 ELF030050.......
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
54 2D 4D 4F 42 30 30 35 00 00 00 00 00 00 00 00 T-MOB005........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- -- ..............
Copy and paste the text into a text file and keep for future reference as the Device ID and CID ID are useful in determining the right ROM files to use as well as the wrong ones.
Click to expand...
Click to collapse
Mine at the 12th packet too
45 4C 46 30 31 30 30 35 30 00 00 00 00 00 00 00 ELF010050.......
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
48 54 43 5F 5F 45 31 31 00 00 00 00 00 00 00 00 HTC__E11........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..............

leondaphillips
you are a genius, it worked, a million thanks. I tried other way with MTTY, snoopypro & Hexer loads of times without success & I'd given up hope!

thanks .....
good gob

elf0100050
bstar502
any one have it

where can I find rom
Where can i find rom for htc p3450 elfin
ELF010050
HTC__001

leondaphillips said:
Hi Everyone
I'm posting this to help out CyZeek.
To capture ELF/ELFIN Device ID and CID ID using MTTY and USB Monitor Lite on XP SP2 and Vista x64
You will need:
1. A demo copy of USB Monitor Lite
http://www.hhdsoftware.com (the demo is fully functional for 14 days).2. A Copy of MTTY (and you need to be basically familiar with it)
Put your Device into Boot Loader
Assuming your device is not already at the TSoD (Tricolour Screen of Death) - if it is skip this instruction and move on to the next section.
1. Press and hold your camera button
2. Press reset with stylus
3. Wait 5 seconds and release the camera button
Kill ActiveSync USB Connections - XP
1. Reboot your PC with without a mobile device connected to USB.
2. After your PC has rebooted Right Click the Active sync Icon in the system tray and select "Connection Settings"
3. Turn off USB
-or-
Kill ActiveSync USB Connections - Vista
Download and install MS Windows Mobile Device Centre from here: http://www.microsoft.com/windowsmobile/devicecenter.mspx
1. Reboot your PC with without a mobile device connected to USB.
2. After your PC has rebooted click Start -> All Programs -> Windows Mobile Device Centre
3. Hover over Mobile Device Settings and Click on Connection Settings.
4. Turn off Allow USB Connections
Connect Your Device to USB
1. Plug in the USB cable
Turn On Spoofing / packet capture
1. Install the demo version of USB Monitor Lite (DMS) and Start Device Monitoring Studio.
2. Connect your device which should be in TSoD (Tricolour Screen of Death) boot loader.
3. Click the item entitled "Pocket PC USB Sync" which activates the main screen
4. Double-Click the item entitled "Packet View" in the Session Configuration Screen.
5. Click the Start button in the selected processing region
You'll know you got this right because you will see two packets displayed:
PnP: Device Connected
Internal: Pipe Info Transfer6. Leave the USB Monitor running
Run up MTTY, Log In and Issue “getdevinfo” Command
For details on downloading MTTY and recovering from the TSoD see this thread: http://forum.xda-developers.com/showthread.php?t=347700
1. In "Open Port Setting" Dialog Set to Port = USB
2. Flow Cont = RTC/CTS
3. Click OK
4. When a new communication page opens press Enter and the Cmd> prompt will be displayed
5. Type password BsaD5SeoA <enter> (a lot of diagnostic info will be displayed).
Somewhere near the end you should see
g_cKeyCardSecurityLevel = FF
Which will tell you that you're CID LockedCheck that USB Monitor is running (you may need to press the "continue 14 day trial" button to get the capture to continue)6. Type getdevinfo and press <enter>
These commands are case sensitive!
Cmd>getdevinfo
HTCSELF030050œ=Ó HTCE7. Leave MTTY running
Swap Back to USB Monitor
1. Starting at the last packet in the list, double click each row whose Direction is "Up"
2. The 12th packet from the end of the list when I did mine had the device ID and CID packet shown below.
45 4C 46 30 33 30 30 35 30 00 00 00 00 00 00 00 ELF030050.......
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
54 2D 4D 4F 42 30 30 35 00 00 00 00 00 00 00 00 T-MOB005........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- -- ..............
Copy and paste the text into a text file and keep for future reference as the Device ID and CID ID are useful in determining the right ROM files to use as well as the wrong ones.
To Re-Enable Boot on a Good Device
Unless you tell the device where to boot from it will go back to boot loader every time so you need to re-enable boot from ROM.
These commands are case sensitive!1. Swap back to MTTY session
2. Type ruurun 0 <enter>
3. Type ResetDevice <enter>
Hope this helps.
Yours
Leon
Click to expand...
Click to collapse
ive followed your instruction and got the ff-cid locked data.
ive tried everything but cannot make the gold card.with or without usb.

Hi
I have s621 in 3 color mode not eset and open with cid lock.
I have done all but I can not see my cid and Id.
My mtty like that what is wrong. ?
Thank you.
Code:
Cmd>password BsaD5SeoA
Pass.
+ SD Controller init
- SD Controller init
+StorageInit
SDInit+++
SDCmd1 Command response time-out. MMC_STAT = 80
SDCmd1 Command response time-out. MMC_STAT = 80
SDCmd1 Command response time-out. MMC_STAT = 80
SDCmd55 Command response time-out. MMC_STAT = 80
SDCmd55 Command response time-out. MMC_STAT = 80
SDCmd55 Command response time-out. MMC_STAT = 80
CMD55 failed
+ SD Controller init
- SD Controller init
+StorageInit
SDInit+++
SDCmd1 Command response time-out. MMC_STAT = 80
SDCmd1 Command response time-out. MMC_STAT = 80
SDCmd1 Command response time-out. MMC_STAT = 80
SDCmd55 Command response time-out. MMC_STAT = 80
SDCmd55 Command response time-out. MMC_STAT = 80
SDCmd55 Command response time-out. MMC_STAT = 80
CMD55 failed
g_cKeyCardSecurityLevel = FF
Type (0x1)(Operation mode flag): cOpModeFlag=(0x0).
Type (0x2)(Back color flag): cBackColorShowFlag=(0x1).
Type (0x5)(Background color value): g_wBColor=(0xC618) (0xC0C0C0).
HTCST

Thank you OP. I used your method and found the Device ID and CID of Telus HTC Touch Dual (Neon400, Canada). See below:
4E 45 4F 4E 34 30 30 30 00 00 00 00 00 00 00 00 NEON4000........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
54 4C 53 30 00 00 00 00 00 00 00 00 00 00 00 00 TLS0............
00 00 00 00 ....

Hello i have cant find device id and cid can any one help me see log and also Device Monitoring give cid 000000000............
HTCST
Cmd>getdevinfo
GetDeviceCID: Error - InitDecoder
HTCSXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXh{Â&HTCE
Cmd>
leondaphillips said:
Hi Everyone
I'm posting this to help out CyZeek.
To capture ELF/ELFIN Device ID and CID ID using MTTY and USB Monitor Lite on XP SP2 and Vista x64
You will need:
1. A demo copy of USB Monitor Lite
http://www.hhdsoftware.com (the demo is fully functional for 14 days).2. A Copy of MTTY (and you need to be basically familiar with it)
Put your Device into Boot Loader
Assuming your device is not already at the TSoD (Tricolour Screen of Death) - if it is skip this instruction and move on to the next section.
1. Press and hold your camera button
2. Press reset with stylus
3. Wait 5 seconds and release the camera button
Kill ActiveSync USB Connections - XP
1. Reboot your PC with without a mobile device connected to USB.
2. After your PC has rebooted Right Click the Active sync Icon in the system tray and select "Connection Settings"
3. Turn off USB
-or-
Kill ActiveSync USB Connections - Vista
Download and install MS Windows Mobile Device Centre from here: http://www.microsoft.com/windowsmobile/devicecenter.mspx
1. Reboot your PC with without a mobile device connected to USB.
2. After your PC has rebooted click Start -> All Programs -> Windows Mobile Device Centre
3. Hover over Mobile Device Settings and Click on Connection Settings.
4. Turn off Allow USB Connections
Connect Your Device to USB
1. Plug in the USB cable
Turn On Spoofing / packet capture
1. Install the demo version of USB Monitor Lite (DMS) and Start Device Monitoring Studio.
2. Connect your device which should be in TSoD (Tricolour Screen of Death) boot loader.
3. Click the item entitled "Pocket PC USB Sync" which activates the main screen
4. Double-Click the item entitled "Packet View" in the Session Configuration Screen.
5. Click the Start button in the selected processing region
You'll know you got this right because you will see two packets displayed:
PnP: Device Connected
Internal: Pipe Info Transfer6. Leave the USB Monitor running
Run up MTTY, Log In and Issue “getdevinfo” Command
For details on downloading MTTY and recovering from the TSoD see this thread: http://forum.xda-developers.com/showthread.php?t=347700
1. In "Open Port Setting" Dialog Set to Port = USB
2. Flow Cont = RTC/CTS
3. Click OK
4. When a new communication page opens press Enter and the Cmd> prompt will be displayed
5. Type password BsaD5SeoA <enter> (a lot of diagnostic info will be displayed).
Somewhere near the end you should see
g_cKeyCardSecurityLevel = FF
Which will tell you that you're CID LockedCheck that USB Monitor is running (you may need to press the "continue 14 day trial" button to get the capture to continue)6. Type getdevinfo and press <enter>
These commands are case sensitive!
Cmd>getdevinfo
HTCSELF030050œ=Ó HTCE7. Leave MTTY running
Swap Back to USB Monitor
1. Starting at the last packet in the list, double click each row whose Direction is "Up"
2. The 12th packet from the end of the list when I did mine had the device ID and CID packet shown below.
45 4C 46 30 33 30 30 35 30 00 00 00 00 00 00 00 ELF030050.......
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
54 2D 4D 4F 42 30 30 35 00 00 00 00 00 00 00 00 T-MOB005........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- -- ..............
Copy and paste the text into a text file and keep for future reference as the Device ID and CID ID are useful in determining the right ROM files to use as well as the wrong ones.
To Re-Enable Boot on a Good Device
Unless you tell the device where to boot from it will go back to boot loader every time so you need to re-enable boot from ROM.
These commands are case sensitive!1. Swap back to MTTY session
2. Type ruurun 0 <enter>
3. Type ResetDevice <enter>
Hope this helps.
Yours
Leon
Click to expand...
Click to collapse

[TUT] ULDR Removal for Elf/Elfins [ONLINE]

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)

[Q] Stuck on TWRP

I recently installed TWRP 2.5. I had backed up my system with it and everything was working fine. I recently went back to restore and it said I was successful. When I rebooted the tablet the TWRP comes up. now every time I reboot is the same. TWRP 2.5 starts. No matter what rom I try to install it reboots to the recovery.

Did you try usong the bootloader?
Sent from my GT-I9300 using xda app-developers app

danielbr14 said:
Did you try usong the bootloader?
Sent from my GT-I9300 using xda app-developers app
Click to expand...
Click to collapse
No, I'm not familiar with that program. I am kinda at a disadvantage because the tablet only boots to the TWRP recovery . Not allowing me to use a usb connection. The only thing I can do is remove the external sd card and copy files to it. Use the TWRP recovery to try to install, but then the tablet just boots back to the recovery.

The bootloader is like the bios of your computer it is what you need to unlock to install custom roms . you need to hold down the power button and when the tablet vibrates press the volume down than press the volume down button to navigate . choose the android logo and press the volume up button. Tell me if that helps.
Btw i didnt got notified when you replied me so it took me some time sorry
Sent from my GT-I9300 using xda app-developers app

danielbr14 said:
The bootloader is like the bios of your computer it is what you need to unlock to install custom roms . you need to hold down the power button and when the tablet vibrates press the volume down than press the volume down button to navigate . choose the android logo and press the volume up button. Tell me if that helps.
Btw i didnt got notified when you replied me so it took me some time sorry
Sent from my GT-I9300 using xda app-developers app
Click to expand...
Click to collapse
No, the bootloader is not working. Tried power / volume down / etc. but only the TWRP comes up.

Did you do a clean install.. It's sounds like your stuck on a bootloop???
X10a-Freedom

zorprime01 said:
Did you do a clean install.. It's sounds like your stuck on a bootloop???
X10a-Freedom
Click to expand...
Click to collapse
Don't think I know how to do that. I have tried installing different roms, and the recovery says successful, but when rebooting the tablet, The TWRP recovery comes up again.

A full install is when you drlete the dalcik and cache and the preform the installition if that doesnt help try to do a full internal storge wipe and then install the rom .
But dont forget to move all of your importent data to your sd card so you wont loose it
Sent from my GT-I9300 using xda app-developers app

danielbr14 said:
A full install is when you drlete the dalcik and cache and the preform the installition if that doesnt help try to do a full internal storge wipe and then install the rom .
But dont forget to move all of your importent data to your sd card so you wont loose it
Sent from my GT-I9300 using xda app-developers app
Click to expand...
Click to collapse
I always delete the caches. I have done the full storage wipe through the TWRP. then tried to instal roms, including the latest op system from asus.
Getting the same results as above. Even tried to re-install The TWRP recovery again.

Try getting adb shell access to your recovery (on Windows, you may need to install some drivers first).

_that said:
Try getting adb shell access to your recovery (on Windows, you may need to install some drivers first).
Click to expand...
Click to collapse
Not quite sure of that procedure, could you provide a good link on how to do it? Don't you need to plug the tablet into your computer and be recognized? I have the drivers for the tablet installed but because I can only boot into the TWRP recovery, My computer wont recognize it.

cnh56 said:
Not quite sure of that procedure, could you provide a good link on how to do it? Don't you need to plug the tablet into your computer and be recognized? I have the drivers for the tablet installed but because I can only boot into the TWRP recovery, My computer wont recognize it.
Click to expand...
Click to collapse
With the correct drivers, the computer should recognize the recovery's adb interface and you should be able to use "adb shell" to get a command prompt from your recovery. I can't help you with the drivers, but apparently this one should work: http://forum.xda-developers.com/showpost.php?p=41458912&postcount=2472 . You will also need to get adb binaries for your PC from somewhere.
Alternative: Try using the internal command terminal in TWRP - it's not very powerful but maybe it is enough and then you don't need to mess with the computer or drivers at all. Run the following command:
Code:
ls -l /dev/block/mmc*
and tell me if you see mmcblk0, mmcblk0p1, mmcblk0p2, mmcblk0p3, etc. up to mmcblk0p8 (and some more).

_that said:
With the correct drivers, the computer should recognize the recovery's adb interface and you should be able to use "adb shell" to get a command prompt from your recovery. I can't help you with the drivers, but apparently this one should work: http://forum.xda-developers.com/showpost.php?p=41458912&postcount=2472 . You will also need to get adb binaries for your PC from somewhere.
Alternative: Try using the internal command terminal in TWRP - it's not very powerful but maybe it is enough and then you don't need to mess with the computer or drivers at all. Run the following command:
Code:
ls -l /dev/block/mmc*
and tell me if you see mmcblk0, mmcblk0p1, mmcblk0p2, mmcblk0p3, etc. up to mmcblk0p8 (and some more).
Click to expand...
Click to collapse
Yes, I ran that internal command in TWRP and got these
/dev/block/mmcblk0
/dev/block/mmcblk0boot0
/dev/block/mmcblk0boot1,
/dev/block/mmcblk0p1
/dev/block/mmcblk0p10
/dev/block/mmcblk0p2
/dev/block/mmcblk0p3
/dev/block/mmcblk0p4
/dev/block/mmcblk0p5
/dev/block/mmcblk0p6
/dev/block/mmcblk0p7
/dev/block/mmcblk0p8
/dev/block/mmcblk0p9
/dev/block/mmcblk1
/dev/block/mmcblk1p1
What does that mean?

cnh56 said:
What does that mean?
Click to expand...
Click to collapse
That means your recovery can still see all the partitions of the internal storage, which is good, so we can proceed with the next command:
Code:
hexdump -C -n 512 /dev/block/mmcblk0p3
Ignore the hexadecimal numbers and read the text in the right column, if any. Does it look like this?
Code:
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200
or like this:
Code:
00000000 62 6f 6f 74 2d 72 65 63 6f 76 65 72 79 00 00 00 |boot-recovery...|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000040 72 65 63 6f 76 65 72 79 0a 2d 2d 77 69 70 65 5f |recovery.--wipe_|
00000050 64 61 74 61 0a 00 00 00 00 00 00 00 00 00 00 00 |data............|
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200
or differently?

_that said:
That means your recovery can still see all the partitions of the internal storage, which is good, so we can proceed with the next command:
Code:
hexdump -C -n 512 /dev/block/mmcblk0p3
Ignore the hexadecimal numbers and read the text in the right column, if any. Does it look like this?
Code:
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200
or like this:
Code:
00000000 62 6f 6f 74 2d 72 65 63 6f 76 65 72 79 00 00 00 |boot-recovery...|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000040 72 65 63 6f 76 65 72 79 0a 2d 2d 77 69 70 65 5f |recovery.--wipe_|
00000050 64 61 74 61 0a 00 00 00 00 00 00 00 00 00 00 00 |data............|
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200
or differently?
Click to expand...
Click to collapse
It looks like the first set of codes

cnh56 said:
It looks like the first set of codes
Click to expand...
Click to collapse
OK, no forced reboot to recovery, so your ROM is unhappy with something.
Which ROM did you try to install last?

_that said:
OK, no forced reboot to recovery, so your ROM is unhappy with something.
Which ROM did you try to install last?
Click to expand...
Click to collapse
Stock rom from asus. "US_epad-user-10.6.1.14.8.zip" I renamed it "Asus Update" Loded it into my ext.card and used TWRP to install it. After a while it says it was successful. I wiped the cache's and rebooted. Same ole...TWRP came up again.

cnh56 said:
Stock rom from asus. "US_epad-user-10.6.1.14.8.zip" I renamed it "Asus Update" Loded it into my ext.card and used TWRP to install it. After a while it says it was successful. I wiped the cache's and rebooted. Same ole...TWRP came up again.
Click to expand...
Click to collapse
If you don't have any important data on your device, try formatting the data partition. This will wipe all of your internal storage - apps, app data and /sdcard.

_that said:
If you don't have any important data on your device, try formatting the data partition. This will wipe all of your internal storage - apps, app data and /sdcard.
Click to expand...
Click to collapse
I did as instructed. Same result... Back to TWRP. Dammit!!! :crying:

When you reboot your device, do you see the boot animation before TWRP starts? Or does it go directly from the white ASUS logo to the blue curtains of TWRP?

TUTORIAL: Remove TAMPERED & RELOCKED flag / HBoot w/o unlock_code.bin

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

Calculating the CRC values in the commands send by LG Flashtool to Nexus-5

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.

Database Info

welcome