Database Info

[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
OR​2. 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)

Xperia J: fast+snappy stock kernel JB (11.2.A.0.21)

Xperia J: fast+snappy stock kernel JB (11.2.A.0.21)
The following guide shows how to build the stock sources for you
stock xperia j phone with JB.
When Foxcon adopted the drivers for the xperia j they left in
a huge amount of debug which slows down your phone.
When we finally build our own kernel (Chapter 7)
we optimize it by:
- optimizing kernel for speed (not size)
- remove a huge amount of debug from the drivers
- remove kernel core debug
- remove debug_fs
- build without module support
In my opinion the kernel feels much more snappier afterwards.
The system reacts much more fluent on user inputs and sound
has less hangs than before.
Let me hear how it feels for you and if you like it or not
Maybe you have further modifications. So please post it here.
The last section describes how you can build your own kernel patch files.
0. Prerequisites
1. Extracting the current boot image
2. Splitting the image into kernel, ramdisk and cmdline
3. Unpack the ramdisk
4. Build the sony kernel with the original kernel configuration (.config)
5. Build a new boot image
6. Flash the new boot image to the phone
7. Now for the FUN part: TUNE the sony kernel with the attached patch-file
A: Howto build a patch file by comparing a
fresh extracted kernel sources with your edited sources:
0. Prerequisites
==================
- Device needs to be rooted and bootloader unlocked !!!
- Device needs to be up to date with latest Jelly Bean release 11.2.A.0.21 !!!
- A linux machine as working environment
- free ARM compiler, lite version, EABI, URL:
sourcery.mentor.com/sgpp/lite/arm/portal/release2322
- latest Xperia Jlo sources, URL:
developer.sonymobile.com/downloads/xperia-open-source-archives/open-source-archive-for-build-11-2-a-0-21/
- phyton script 'mkelf.py' to re-/build parition image, URL:
dl-developer.sonymobile.com/tools/image_generation_script_for_Xperia_smartphones.zip
- another basic guide, URL:
developer.sonymobile.com/2011/05/06/how-to-build-a-linux-kernel
1. Extracting the current boot image
======================================
- Install Andrdoid SDK.
- Then add a path to your .bashrc file of your linux host:
linux-w49x:~/my_kernel # echo "export PATH=/root/adt-bundle-linux-x86-20130219/sdk/platform-tools:$PATH" >> ~/.bashrc
linux-w49x:~/my_kernel # . ~/.bashrc
- Enable "USB-Debugging" in the phone seetings
- Start the phone and connect via USB to your linux machine
- At first we copy the sony boot image to the sdcard of the device:
linux-w49x:~ # adb shell
[email protected]:/ $ su
[email protected]:/ # dd if=/dev/block/mmcblk0p3 of=/sdcard/sony_boot.img
40960+0 records in
40960+0 records out
20971520 bytes transferred in 2.078 secs (10092165 bytes/sec)
- Read kernel config of your current kernel and store it on sdcard, too:
[email protected]:/ $ su
[email protected]:/ # cat /proc/config.gz > /sdcard/sony_config.gz
130|[email protected]:/ $ exit
130|[email protected]:/ $ exit
- Transfer both to your linux PC:
linux-w49x:~ # adb pull /sdcard/sony_boot.img
linux-w49x:~ # adb pull /sdcard/sony_config.gz
2. Splitting the image into kernel, ramdisk and cmdline
========================================================
- Basically the image consists of:
* 4k singed sin header with a ?x509? certificate
* kernel
* ramdisk
* cmdline parameters for the kernel
* a lot of empty space (~15 MB)
- Hexdump the image to make it human readable:
linux-w49x:~ # hexdump -C sony_boot.img > dump
linux-w49x:~ # head dump
00000000 7f 45 4c 46 01 01 01 61 00 00 00 00 00 00 00 00 |.ELF...a........|
00000010 02 00 28 00 01 00 00 00 00 80 20 00 34 00 00 00 |..(....... .4...|
00000020 00 00 00 00 00 00 00 00 34 00 20 00 03 00 00 00 |........4. .....|
00000030 00 00 00 00 01 00 00 00 00 10 00 00 00 80 20 00 |.............. .| <== Byte 9/10/11: is kernel start (after 4k sin header)
00000040 00 80 20 00 68 70 3c 00 68 70 3c 00 00 00 00 00 |.. .hp<.hp<.....| <== Byte 9/10/11: is kernel length
00000050 00 00 00 00 01 00 00 00 68 80 3c 00 00 00 40 01 |........h.<[email protected]| <== Byte 9/10/11: is ramdisk start
00000060 00 00 40 01 c6 1b 15 00 c6 1b 15 00 00 00 00 80 |[email protected]| <== Byte 9/10/11: is ramdisk length
00000070 00 00 00 00 04 00 00 00 2e 9c 51 00 00 00 00 00 |..........Q.....| <== Byte 9/10/11: is cmdline start
00000080 00 00 00 00 00 02 00 00 00 02 00 00 00 00 00 20 |............... | <== Byte 9/10/11: is cmdline length (512 characters)
00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
- Now read the addresses from behind:
00 10 00 => is 0x001000
68 70 3c => is 0x3c7068
68 80 3c => is 0x3c8068
c6 1b 15 => is 0x151bc6
2e 9c 51 => is 0x519c2e
00 02 00 => is 0x000200
- NOTE: THE NUMBERS WILL BE DIFFERENT FOR YOUR st26i DEVICE !!!
- Use 'dd' to split sony_boot.img into its single parts.
- BUT use the correct numbers from your kernel here:
linux-w49x:~ # dd skip=$((0x001000)) count=$((0x3c7068)) bs=1 if=sony_boot.img of=sony_kernel.img
3960936+0 records out
3960936 bytes (4.0 MB) copied, 66.2326 s, 59.8 kB/s
linux-w49x:~ # dd skip=$((0x3c8068)) count=$((0x151bc6)) bs=1 if=sony_boot.img of=sony_ramdisk.img.gz
1383366+0 records in
1383366+0 records out
1383366 bytes (1.4 MB) copied, 23.1965 s, 59.6 kB/s
linux-w49x:~ # dd skip=$((0x519c2e)) count=$((0x000200)) bs=1 if=sony_boot.img of=sony_cmdline.img
512+0 records in
512+0 records out
512 bytes (512 B) copied, 0.00931558 s, 55.0 kB/s
3. Unpack the ramdisk
=======================
- First unzip ramdisk (should start with 0x1f 0x8b )
linux-w49x:~ # hexdump -C sony_ramdisk.img.gz | head
00000000 1f 8b 08 00 a0 a8 50 51 00 03 ec 3d 69 73 db b8 |......PQ...=is..|
00000010 92 f9 fa f4 2b b0 72 ea cd d8 ab 83 92 cf 64 ca |....+.r.......d.|
00000020 5b 2b 5b b4 ad 7a b6 e4 91 e4 1c b5 f5 4a a1 48 |[+[..z.......J.H|
00000030 48 42 99 57 78 58 f1 ce e4 bf 6f 37 c0 03 a4 a8 |HB.WxX....o7....|
00000040 83 49 66 6a 76 ca aa 38 a6 c0 ee 46 a3 bb d1 68 |.Ifjv..8...F...h|
00000050 a0 01 58 39 55 4e 95 96 a2 28 ea 61 eb 4c 85 df |..X9UN...(.a.L..|
00000060 ca 51 4b ed 2a c5 9f 37 c7 ad a3 ab f6 71 f7 38 |.QK.*..7.....q.8|
00000070 57 7e 16 fd 6e af c1 4b ca 1b af 14 b9 be 2b 8e |W~..n..K......+.|
00000080 dc ea 1c ad c1 6b 65 bf 25 5f b7 d4 d7 4a e8 85 |.....ke.%_...J..|
00000090 f4 89 da 81 d1 98 3b a6 31 63 fe a2 e1 e9 af 5e |......;.1c.....^|
linux-w49x:~ # gunzip sony_ramdisk.img.gz
- Now again, the resulting sony_ramdisk.img should start with 0x30 0x37 0x30.
- Now extract cpio archive to a directory:
linux-w49x:~ # mkdir ramdisk
linux-w49x:~ # cd ramdisk/
linux-w49x:~/ramdisk # cpio -i < ../sony_ramdisk.img
4444 blocks
linux-w49x:~/ramdisk # ls
charger init init.qcom.ril.path.sh init.s1.rc logo.rle sys
data init.Sony.rc init.qcom.sh init.target.rc logo.rle.org system
default.prop init.goldfish.rc init.qcom.usb.rc init.trace.rc proc ueventd.Sony.rc
dev init.qcom.class_core.sh init.qcom.usb.sh init.usb.rc res ueventd.goldfish.rc
fstab.msm7627a init.qcom.class_main.sh init.rc init.usbmode.sh sbin ueventd.rc
- OPTIONAL: You can now modify the ramdisk to your needs... we will
repack it later from here.
4. Build the sony kernel with the original kernel configuration (.config)
===========================================================================
In this section we will just rebuild the sony kernel with its default config.
This step is optional. You might want to SKIP THIS STEP and continue dircetly
with building the optimized kernel (Chapter 7)
- Install the mentioned ARM compiler from Mentor (for URL, see top of page)
- Extract the kernel config we fetched from the device:
linux-w49x:~ # gunzip sony_config.gz
- Extract the sony kernel:
linux-w49x:~ # tar -xf 11.2.A.0.21.tar.bz2
- Add the config to the kernel base directory:
linux-w49x:~ # cp sony_config ./kernel/.config
linux-w49x:~ # cd kernel
linux-w49x:~/kernel # ARCH=arm CROSS_COMPILE=/root/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_EABI/bin/arm-none-eabi- make oldconfig
- OPTIONAL: reconfigure the kernel OR skip this step:
linux-w49x:~/kernel # ARCH=arm CROSS_COMPILE=/root/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_EABI/bin/arm-none-eabi- make menuconfig
- Because the ARM compiler is pretty strict, edit the kernel Makefile in "kernel/Makefile":
- Change this part....
ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
KBUILD_CFLAGS += -Os
else
KBUILD_CFLAGS += -O2
endif
- .. by appending this to the flags:
ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
KBUILD_CFLAGS += -Os $(call cc-disable-warning,maybe-uninitialized,) $(call cc-disable-warning,implicit-function-declaration,) $(call cc-disable-warning,strict-prototypes,) $(call cc-disable-warning,unused-function,) $(call cc-disable-warning,unused-variable,)
else
KBUILD_CFLAGS += -O2 $(call cc-disable-warning,maybe-uninitialized,) $(call cc-disable-warning,implicit-function-declaration,) $(call cc-disable-warning,strict-prototypes,) $(call cc-disable-warning,unused-function,) $(call cc-disable-warning,unused-variable,)
endif
- Finally we build the kernel:
linux-w49x:~/kernel # ARCH=arm CROSS_COMPILE=/root/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_EABI/bin/arm-none-eabi- make
- Time to grab a BIG 0xCOFFEE
5. Build a new boot image
===========================
- Collect the new kernel:
linux-w49x:~ # cp ~/kernel/arch/arm/boot/zImage my_kernel.img
- Pack a new ramdisk (or just take exsiting one)
linux-w49x:~ # cd ramdisk
linux-w49x:~/ramdisk # find . | cpio --quiet -H newc -o | gzip > ../my_ramdisk.img.gz
linux-w49x:~/ramdisk # cd ..
- Pack everything together using mkelf.py from sony (URL, see above):
linux-w49x:~ # python mkelf.py -o my_boot.img [email protected] [email protected],ramdisk [email protected],cmdline
6. Flash the new boot image to the phone
==========================================
- power off device
- vol up + attach usb = fastboot
linux-w49x:~ # fastboot flash boot ./my_boot.img
linux-w49x:~ # fastboot reboot
- If anything goes wrong you can always flash the extraced image using:
linux-w49x:~ # fastboot flash boot ./sony_image.img
linux-w49x:~ # fastboot reboot
7. Now for the FUN part: TUNE the sony kernel with the attached patch-file
=============================================================================
- Basically we disable "module support" as we have none
- Disable A LOT OF DEBUG: debugfs and various debug statments in MSM drivers
- Tune vibration period to be more gentle
- Optimize kernel size for speed and not for size
- Remove kernel and user space process debug infos
- Make sure you unpack the stock sony kernel sources. The sources need to be
fresh and clean!!!
linux-w49x:~ # tar -xf 11.2.A.0.21.tar.bz2
linux-w49x:~ # cd kernel/
- patch the performance tweaks to it. The perf_tweak.patch is appended to this post:
linux-w49x:~/kernel # patch -p3 < ../perf_tweak.patch
patching file ./kernel/power/earlysuspend.c
patching file ./Makefile
patching file ./arch/arm/mach-msm/smd_pkt.c
patching file ./arch/arm/mach-msm/sdio_cmux.c
patching file ./arch/arm/mach-msm/reset_modem.c
patching file ./arch/arm/mach-msm/qdsp5v2/mi2s.c
patching file ./arch/arm/mach-msm/qdsp5v2/audio_out.c
patching file ./arch/arm/mach-msm/modem_notifier.c
patching file ./arch/arm/mach-msm/msm_cpr-debug.c
patching file ./arch/arm/mach-msm/smd_rpcrouter.c
patching file ./arch/arm/mach-msm/ipc_router.c
patching file ./arch/arm/mach-msm/bam_dmux.c
patching file ./arch/arm/mach-msm/qdsp6/msm_q6vdec.c
patching file ./arch/arm/mach-msm/rmt_storage_client.c
patching file ./arch/arm/mach-msm/include/mach/debug_mm.h
patching file ./arch/arm/mach-msm/clock.c
patching file ./arch/arm/mach-msm/sdio_dmux.c
patching file ./arch/arm/mach-msm/msm_cpr.h
patching file ./arch/arm/mach-msm/qdsp5/audio_mp3.c
patching file ./arch/arm/mach-msm/qdsp5/audmgr.c
patching file ./arch/arm/mach-msm/qdsp5/audio_acdb.c
patching file ./arch/arm/mach-msm/qdsp5/audio_lpa.c
patching file ./arch/arm/mach-msm/pm2.c
patching file ./arch/arm/mach-msm/sdio_ctl.c
patching file ./arch/arm/mach-msm/clock-debug.c
patching file ./arch/arm/mach-msm/board-msm7627a-display.c
patching file ./arch/arm/mach-msm/vreg.c
patching file ./arch/arm/mach-msm/board-tamsui-jlo.c
patching file ./arch/arm/mach-msm/clock.h
patching file ./net/netfilter/xt_socket.c
patching file ./include/linux/vibrator_class.h
patching file ./include/linux/bma250.h
patching file ./drivers/media/common/tuners/xc4000.c
patching file ./drivers/tty/serial/msm_serial_hs.c
patching file ./drivers/vibrators/fih_vibrator.c
patching file ./drivers/vibrators/vibrator_class.c
patching file ./drivers/video/msm/msm_fb.c
patching file ./drivers/video/msm/mipi_orise.c
patching file ./drivers/bluetooth/bluesleep.c
patching file ./drivers/usb/otg/msm_otg.c
patching file ./drivers/usb/otg/msm72k_otg.c
patching file ./drivers/usb/gadget/f_diag.c
patching file ./drivers/usb/gadget/u_ctrl_hsuart.c
patching file ./drivers/usb/gadget/f_rmnet_smd_sdio.c
patching file ./drivers/usb/gadget/u_serial.c
patching file ./drivers/usb/gadget/u_bam.c
patching file ./drivers/usb/gadget/f_rmnet_smd.c
patching file ./drivers/input/keyboard/fih_gpio_keys.c
patching file ./drivers/input/keyboard/fih_power_key.c
patching file ./drivers/input/touchscreen/cyttsp_core.c
patching file ./drivers/input/sensor/qpdss702.c
patching file ./drivers/leds/fih_led.c
patching file ./drivers/net/wireless/bcmdhd/wl_linux_mon.c
patching file ./drivers/net/wireless/bcmdhd/Makefile
patching file ./drivers/net/wireless/bcmdhd/dhd_custom_gpio.c
patching file ./drivers/power/fih_bq27520_fuelgauger.c
patching file ./drivers/power/fih_msm_battery.c
patching file ./drivers/gpu/msm/adreno_postmortem.c
patching file ./drivers/gpu/msm/adreno.c
patching file ./drivers/rtc/rtc-msm.c
patching file ./.config
linux-w49x:~/kernel # ARCH=arm CROSS_COMPILE=/root/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_EABI/bin/arm-none-eabi- make
===> repeat steps 5) and 6) but use our new zImage.
A: Howto build a patch file by comparing a
fresh extracted kernel sources with your edited sources:
=========================================================
- Compare two kernel directories and create a patch from it:
linux-w49x:~ # export BASEDIR=$PWD
linux-w49x:~ # cd kernel/
linux-w49x:~/kernel # rm $BASEDIR/perf_tweak.patch
linux-w49x:~/kernel # find -name '*.c' -o -name '*.h' -o -name 'Makefile' -o -name '.config' | xargs [email protected] diff -upN $BASEDIR/kernel/@ $BASEDIR/my_kernel/@ >> $BASEDIR/perf_tweak.patch

Great Tutorial for Xperia J custom Kernel
Thanks .. Really helpful .
numbers were different in mine
dd skip=$((0x001000)) count=$((0x3da520)) bs=1 if=sony_boot.img of=sony_kernel.img
dd skip=$((0x3db520)) count=$((0x11a498)) bs=1 if=sony_boot.img of=sony_ramdisk.img.gz
dd skip=$((0x4f59b8)) count=$((0x000200)) bs=1 if=sony_boot.img of=sony_cmdline.img
I am with locked bootloader ( 1 week old JLo ) will do it as soon I unlock it.
I will also include swap support in kernel config and test .

omg it's so complicated...
have anyone finished it? Will it be released as flashable version ?

Lol ye makes me dizzy!

work on xperia J
this work on xperia J with bootloader locked

For simplicity's sake I like to build my kernels with CyanogenMod, but I'll check out your patch for some useful edits. :good:

Don't want to necro bump threads but....
Massive thanks to OP
I'd been messing around for the last day with trying to compile the .31 stock kernel from source.
Successfully used the above guide to dump the .31 kernel from phone add overclock to .31 source code (from Vengeance 1.42 source) compile, make boot.img and flash. :laugh:

Can I use this patch for the newest JB kernel? will it work?

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

[Tool] Signing tool for pre 3.2.4 booloaders

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.

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.