Database Info

[TUT] Simple way to add Flash Disk (a.k.a "Internal Storage") to your own ROM

[TUT] Simple way to add Flash Disk (a.k.a "Internal Storage") to your own ROM
It's so long time, no one answer this question "How to add Flash Disk to own-cook ROM?", so I tried to find it out myself and I had found 2 different ways to do that.
As promised, or just a way to say thanks to all this community, I will share the way which more simple than the other.
It worked with Universal devices and may work with others, too!
* What you need?
1. Your ROM file (OS.nb, a.k.a nk.nba, nk.fat), different kitchens use different file names.
2. Any HEX editor, I use XVI32 here.
3. My Flash Disk image template.
* How it work?
The maximum size for a Universal OS ROM is 63 MB (66.060.288 Bytes), normally, we use less than this size for our ROM, the remain size is useless at all, so we make it useful by partitioning it.
* Which things to modify?
- Nothing in your SYS and/or OEM.
- boot.rgu in your XIP (only if it is not XIP-ready )
- First 512 Bytes of your ROM file (called Master Boot Record) (only if it is not MBR-ready )
- First 512 Bytes of my Flash Disk template file (called Boot Sector or Boot Record), it is a must edit thing to do (determine the size of Flash Disk)
* Here we go!
1. Download my file below, extract it and your nk.nbf into the same folder.
2. Run HTC64, decode your nk.nbf into two files (nk.prj and nk.fat).
3. Run HEX editor (XVI32), open nk.fat and write down two values (or just remember if you can) RED value (from $1E6 to $1E8 [or from $1F6 to $1F8 if they are not all 00]) and BLUE value (from $1EA to $1EB [or from $1FA to $1FB if they are not all 00]).
- Note: I use luca16thebig 1.4.9 BETA1 ROM for example, values may different from your ROM or this ROM after rebuilt.
00000000 ...
...
000001E0 41 88 04 FF 41 F7 80 88 01 00 80 6F 00 00 00 00
000001F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA
Click to expand...
Click to collapse
4. Close the file nk.fat and don't save if there is anything changed. Open VNIntFlashDisk.template (also in HEX editor).
Match two RED and BLUE values which you have writen down into two place RED (from $1C to $1E) and BLUE (from $13 to $14). Double check if the values are corrected and fixed into its places and save the template.
- Note: I have already done it with luca16thebig 1.4.9 BETA1 ROM's values, so just goto next step
00000000 ...
00000010 02 00 02 80 6F F8 0C 00 3F 00 FF 00 80 88 01 00
Click to expand...
Click to collapse
5. Run combine.bat from my package, your original ROM file will be saved as nk.fat.original. The file nk.fat now is Flash Disk ready!
6. Run HTC64, re-encode two files (nk.prj and nk.fat) into nk.nbf and we are done!
* What is RED and BLUE values mean?
All two values are in HEX and reversed order, in this example we have:
- RED value is 80 88 01, so its true value is 1.88.80h, change it into decimal number, we have 100.480. It is the number of used sectors (1 sector = 512 Bytes). And... luca16thebig 1.4.9 BETA1 ROM's original size is 51.445.760 Bytes = 100.480 sectors x 512 Bytes.
- BLUE value is 80 6F, its true value is 6F.80h, in decimal is 28.544. It is the number of free sectors, so our Flash Disk size is 28.544 sectors x 512 Bytes = 14.614.528 Bytes ~ 14 MB.
- As you known, OS ROM maximum size is 66.060.288 Bytes = 51.445.760 Bytes + 14.614.528 Bytes.
If your ROM is MBR-ready, each time you rebuilt the ROM, all two values will automatically adjusted in MBR and you just match these values into my Flash Disk template. That all!
- Note: luca16thebig 1.4.9 BETA1 ROM is XIP-ready and MBR-ready. So, if your ROM doesn't work with this instruction, post your 512 Bytes MBR and your boot.rgu file here. I will analyse and make instructions how to make them ready.
When I release this instruction, I tried to make all things clearly from basic to advance but it seem so hard to... eat! So, I did it in reversed order, let you can do it first, then explain and/or clarify. More details will be add later (only when someone needed)!
Link: VNIntFlashDisk.rar

Questions and answers
* What is XIP-ready?
- boot.rgu in your XIP already have Flash Disk related key and values, they are:
[HKEY_LOCAL_MACHINE\System\StorageManager\Profiles\TRUEFFS_DOC\FATFS]
"FormatTfat"=dword:1
"EnableWriteBack"=dword:1
"MountAsROM"=dword:0
"MountHidden"=dword:0
"Folder"="Flash Disk"
Click to expand...
Click to collapse
- Note: no space in key [HKEY_LOCAL_MACHINE\System\StorageManager\Profiles\TRUEFFS_DOC\FATFS], I don't know why there is a space before TRUEFFS_DOC, please manually delete that space when copy!
* What is MBR-ready?
MBR of your ROM already have Flash Disk partition, there are 4 partition slots in MBR.
00000000 ...
...
000001B0 __ __ __ __ __ __ __ __ __ __ __ __ __ __ 11 11
000001C0 11 11 11 11 11 11 11 11 11 11 11 11 11 11 22 22
000001D0 22 22 22 22 22 22 22 22 22 22 22 22 22 22 33 33
000001E0 33 33 33 33 33 33 33 33 33 33 33 33 33 33 44 44
000001F0 44 44 44 44 44 44 44 44 44 44 44 44 44 44 55 AA
Click to expand...
Click to collapse
- The last 2 bytes (55 AA) is a signature, it means END OF MBR.
- 5th byte of each slot is value for partition type, some mostly used values are:
+ 20 - BOOT: just a name, it isn't actually a boot partition and your MBR can be without it.
+ 23 - RAWFS: your XIP partition.
+ 25 - IMGFS: your SYS + OEM partition.
+ 00 - none: free slot, all value in this slot should be 00, too.
+ 01, 04, 06 - FATFS: our Flash Disk here! In some other devices, it's called "Internal Storage".
There are some other values but that's another matter!
So, if your MBR have a FATFS partition type in last used slot, you have a MBR-ready ROM.
- Two non-MBR-ready cases: (with and without BOOT partition slot)
00000000 ...
...
000001B0 __ __ __ __ __ __ __ __ __ __ __ __ __ __ 11 11
000001C0 11 11 20 11 11 11 11 11 11 11 11 11 11 11 22 22
000001D0 22 22 23 22 22 22 22 22 22 22 22 22 22 22 33 33
000001E0 33 33 25 33 33 33 33 33 33 33 33 33 33 33 00 00
000001F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA
Click to expand...
Click to collapse
00000000 ...
...
000001B0 __ __ __ __ __ __ __ __ __ __ __ __ __ __ 11 11
000001C0 11 11 23 11 11 11 11 11 11 11 11 11 11 11 22 22
000001D0 22 22 25 22 22 22 22 22 22 22 22 22 22 22 00 00
000001E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000001F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA
Click to expand...
Click to collapse
BLUE free slot must be entered manually (by HEX caculating) to make them MBR-ready! But... how to HEX caculate values? Maybe later with a MBR sample!

VNInt said:
It's so long time, no one answer this question "How to add Flash Disk to own-cook ROM?", so I tried to find it out myself and I had found 2 different ways to do that.
As promised, or just a way to say thanks to all this community, I will share the way which more simple than the other.
It worked with Universal devices and may work with others, too!
* What you need?
1. Your ROM file (OS.nb, a.k.a nk.nba, nk.fat), different kitchens use different file names.
2. Any HEX editor, I use XVI32 here.
3. My Flash Disk image template.
* How it work?
The maximum size for a Universal OS ROM is 63 MB (66.060.288 Bytes), normally, we use less than this size for our ROM, the remain size is useless at all, so we make it useful by partitioning it.
* Which things to modify?
- Nothing in your SYS and/or OEM.
- boot.rgu in your XIP (only if it is not XIP-ready )
- First 512 Bytes of your ROM file (called Master Boot Record) (only if it is not MBR-ready )
- First 512 Bytes of my Flash Disk template file (called Boot Sector or Boot Record), it is a must edit thing to do (determine the size of Flash Disk)
* Here we go!
1. Download my file below, extract it and your nk.nbf into the same folder.
2. Run HTC64, decode your nk.nbf into two files (nk.prj and nk.fat).
3. Run HEX editor (XVI32), open nk.fat and write down two values (or just remember if you can) RED value (from $1E6 to $1E8) and BLUE value (from $1EA to $1EB).
- Note: I use luca16thebig 1.4.9 BETA1 ROM for example, values may different from your ROM or this ROM after rebuilt.
4. Close the file nk.fat and don't save if there is anything changed. Open VNIntFlashDisk.template (also in HEX editor).
Match two RED and BLUE values which you have writen down into two place RED (from $1C to $1E) and BLUE (from $13 to $14). Double check if the values are corrected and fixed into its places and save the template.
- Note: I have already done it with luca16thebig 1.4.9 BETA1 ROM's values, so just goto next step
5. Run combine.bat from my package, your original ROM file will be saved as nk.fat.original. The file nk.fat now is Flash Disk ready!
6. Run HTC64, re-encode two files (nk.prj and nk.fat) into nk.nbf and we are done!
- Note: luca16thebig 1.4.9 BETA1 ROM is XIP-ready and MBR-ready. So, if your ROM doesn't work with this instruction, post your 512 Bytes MBR and your boot.rgu file here. I will analyse and make instructions how to make them ready.
More details will be add later (only when someone needed)
Link: VNIntFlashDisk.rar
Click to expand...
Click to collapse
Very Useful!!THX You!!Post More details,PLZ

very very good news thank you

WOW
guys it's just to hard to handle for me
I'll give it a try....thx for the info....
ps: VNInt, could you just add Luca's ROM with flash disk? that would be great....
Got me 13.90MB Flash disk!!!!...
Thanks VNInt.....

I can't download the file from www.4shared.com
who can apply another download link
thanks

VNInt said:
* Which things to modify?
- Nothing in your SYS and/or OEM.
- boot.rgu in your XIP (only if it is not XIP-ready )
- First 512 Bytes of your ROM file (called Master Boot Record) (only if it is not MBR-ready )
- First 512 Bytes of my Flash Disk template file (called Boot Sector or Boot Record), it is a must edit thing to do (determine the size of Flash Disk)
Click to expand...
Click to collapse
1st let me thank you for your post. it will be quite useful in the future.
2 questions just to clarify:
- how to find if rom is XIP ready or not?
- how to find if rom is MBR ready?
Maybe these are dumb questions, sory for that.
Cheers.

ultravox said:
- how to find if rom is XIP ready or not?
- how to find if rom is MBR ready?
Click to expand...
Click to collapse
Yeah! You asked must-answer questions!
When I release this instruction, I tried to make all things clearly from basic to advance but it seem so hard to... eat! So, I did it in reversed order, let you can do it first, then explain and/or clarify.
* XIP-ready: boot.rgu in your XIP already have Flash Disk related key and values, they are:
[HKEY_LOCAL_MACHINE\System\StorageManager\Profiles\TRUEFFS_DOC\FATFS]
"FormatTfat"=dword:1
"EnableWriteBack"=dword:1
"MountAsROM"=dword:0
"MountHidden"=dword:0
"Folder"="Flash Disk"
Click to expand...
Click to collapse
* MBR-ready: MBR of your ROM already have Flash Disk partition, there are 4 partition slots in MBR.
00000000 ...
...
000001B0 __ __ __ __ __ __ __ __ __ __ __ __ __ __ 11 11
000001C0 11 11 11 11 11 11 11 11 11 11 11 11 11 11 22 22
000001D0 22 22 22 22 22 22 22 22 22 22 22 22 22 22 33 33
000001E0 33 33 33 33 33 33 33 33 33 33 33 33 33 33 44 44
000001F0 44 44 44 44 44 44 44 44 44 44 44 44 44 44 55 AA
Click to expand...
Click to collapse
- The last 2 bytes (55 AA) is a signature, it means END OF MBR.
- 5th byte of each slot is value for partition type, some mostly used values are:
+ 20 - BOOT: just a name, it isn't actually a boot partition and your MBR can be without it.
+ 23 - RAWFS: your XIP partition.
+ 25 - IMGFS: your SYS + OEM partition.
+ 00 - none: free slot, all value in this slot should be 00, too.
+ 01, 04, 06 - FATFS: our Flash Disk here! In some other devices, it's called "Internal Storage".
There are some other values but that's another matter!
So, if your MBR have a FATFS partition type in last used slot, you have a MBR-ready ROM.
- Two non-MBR-ready cases: (with and without BOOT partition slot)
00000000 ...
...
000001B0 __ __ __ __ __ __ __ __ __ __ __ __ __ __ 11 11
000001C0 11 11 20 11 11 11 11 11 11 11 11 11 11 11 22 22
000001D0 22 22 23 22 22 22 22 22 22 22 22 22 22 22 33 33
000001E0 33 33 25 33 33 33 33 33 33 33 33 33 33 33 00 00
000001F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA
Click to expand...
Click to collapse
00000000 ...
...
000001B0 __ __ __ __ __ __ __ __ __ __ __ __ __ __ 11 11
000001C0 11 11 23 11 11 11 11 11 11 11 11 11 11 11 22 22
000001D0 22 22 25 22 22 22 22 22 22 22 22 22 22 22 00 00
000001E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000001F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA
Click to expand...
Click to collapse
BLUE free slot must be entered manually (by HEX caculating) to make them MBR-ready!
* Updated to second #2 post!

VNInt said:
* What is XIP-ready?
- boot.rgu in your XIP already have Flash Disk related key and values, they are:
- Note: no space in key [HKEY_LOCAL_MACHINE\System\StorageManager\Profiles\TRUEFFS_DOC\FATFS], I don't know why there is a space before TRUEFFS_DOC, please manually delete that space when copy!
* What is MBR-ready?
MBR of your ROM already have Flash Disk partition, there are 4 partition slots in MBR.
- The last 2 bytes (55 AA) is a signature, it means END OF MBR.
- 5th byte of each slot is value for partition type, some mostly used values are:
+ 20 - BOOT: just a name, it isn't actually a boot partition and your MBR can be without it.
+ 23 - RAWFS: your XIP partition.
+ 25 - IMGFS: your SYS + OEM partition.
+ 00 - none: free slot, all value in this slot should be 00, too.
+ 01, 04, 06 - FATFS: our Flash Disk here! In some other devices, it's called "Internal Storage".
There are some other values but that's another matter!
So, if your MBR have a FATFS partition type in last used slot, you have a MBR-ready ROM.
- Two non-MBR-ready cases: (with and without BOOT partition slot)
BLUE free slot must be entered manually (by HEX caculating) to make them MBR-ready! But... how to HEX caculate values? Maybe later with a MBR sample!
Click to expand...
Click to collapse
how to HEX caculate values?

yanqichun9527 said:
how to HEX caculate values?
Click to expand...
Click to collapse
Do not only ask, just follow my instruction, if it do not work for you or your MBR are not ready, post your 512 bytes MBR and your boot.rgu here!
I will use them as samples to continue.

Excellent tutorial VNint..Thanks!

VNInt said:
Do not only ask, just follow my instruction, if it do not work for you or your MBR are not ready, post your 512 bytes MBR and your boot.rgu here!
I will use them as samples to continue.
Click to expand...
Click to collapse
It's Ready I think.Just Want To Know Answer

yanqichun9527 said:
It's Ready I think.Just Want To Know Answer
Click to expand...
Click to collapse
OK! As we know, values are saved in reversed order and maximum size is 1.F8.00h sectors, in decimal is 129.024 sectors = 66.060.288 Bytes (1 sector = 512 Bytes).
From now, we work with HEX only.
* Some definitions:
1. Value from $1x6 (4 Bytes) (x is C, D, E or F) is address offset of partition's first sector a.k.a number of used sectors by all previous partitions.
2. Value from $1xA (4 Bytes) (x is C, D, E or F) is number of sectors in partition a.k.a size of partition.
* Some formularies:
number of used sectors = size of last partition + address offset of last partition
size of your partition = maximum size - number of used sectors
In your sample:
number of used sectors = 1.BA.00h + 1A.80h = 1.D4.80h
size of your partition = 1.F8.00h - 1.D4.80h = 80.23h

lol how about to remove them from roms?

mr4r4n said:
lol how about to remove them from roms?
Click to expand...
Click to collapse
So easy! Just zero-fill FATFS slot in your MBR!

Nice tutorial VNInt.

Sorry
I have stupid Question....
Can we have Internal Device Storage Memory more than usually?
For example, ROM from VNInt has Internal Memory ~41MB, Storage ~9.9MB & Flashdisk ~21MB. Can we combine all of the memory (internal,storage & flashdisk) to One Place memory, so we can have Internal memory 41 + 9.9 + 21 = ~73MB? ..
Sorry 4 my bad English & my stupid Question

aladin said:
Sorry
I have stupid Question....
Can we have Internal Device Storage Memory more than usually?
For example, ROM from VNInt has Internal Memory ~41MB, Storage ~9.9MB & Flashdisk ~21MB. Can we combine all of the memory (internal,storage & flashdisk) to One Place memory, so we can have Internal memory 41 + 9.9 + 21 = ~73MB? ..
Sorry 4 my bad English & my stupid Question
Click to expand...
Click to collapse
The answer is NO, but this is an exciting idea!
I will try some hack to get it true if it can be!

aladin said:
Sorry
I have stupid Question....
Can we have Internal Device Storage Memory more than usually?
For example, ROM from VNInt has Internal Memory ~41MB, Storage ~9.9MB & Flashdisk ~21MB. Can we combine all of the memory (internal,storage & flashdisk) to One Place memory, so we can have Internal memory 41 + 9.9 + 21 = ~73MB? ..
Sorry 4 my bad English & my stupid Question
Click to expand...
Click to collapse
My Stupid Question has answered... look at this
Code:
http://forum.xda-developers.com/showthread.php?t=468776
My Question Again. How to make it?

aladin said:
My Stupid Question has answered... look at this
Code:
http://forum.xda-developers.com/showthread.php?t=468776
My Question Again. How to make it?
Click to expand...
Click to collapse
* Yeah! He got it hacked!
* How it work? This trick is made by repartitioning DiskOnChip.
- This is original DOC layout: (mtty/task 28)
Binary0 Size: 0x100000
FAT0 Size: 0x4000000 (67108864 bytes = 64 MB) (63 MB maximum ROM and Flash Disk size + 1 MB splash image)
FAT1 Size: 0xA00000 (10485760 bytes = 10 MB Extended ROM size)
FAT2 Size: 0x2C70000 (46596096 bytes = 44 MB Storage size)
All Size: 0x7770000
FAT0_ADDR=0x100000,FAT1_ADDR=0x4100000,FAT2_ADDR=0x4B00000
- And this is modified DOC layout after Cotulla's ROM:
Binary0 Size: 0x100000
FAT0 Size: 0x2A00000 (44040192 bytes = 42 MB maximum ROM size)
FAT1 Size: 0x40000 (262144 bytes = 256 KB Extended ROM resized but hidden away)
FAT2 Size: 0x4C20000 (79822848 bytes = 76 MB Storage gained size)
All Size: 0x7760000
FAT0_ADDR=0x100000,FAT1_ADDR=0x2B00000,FAT2_ADDR=0x2B40000
* How to make it?
There is a DOC repartitioning tool released by mamaich before with his source code. I'm trying to got it work unattendedly, so hard now.

[Hack] Root Phones ("exploit needless" method)

[Hack] Root Phones ("exploit needless" method)
How I root any ROM on (almost?) any Android Phone
My Phone simply needs to fullfill one requirement:
I MUST be able to flash the recovery.img standalone!
Chapter One: unpack, edit and repack recovery.img
I will use these Linux programs:
split bootimg (Thanks to William Enck)
mkbootimg (compiled from AOSP source)
...the former splits the recovery.img into kernel and ramdisk...
...the latter repack all togheteher...
...For example I'll try these commands on a clockworkmod recovery from an HTC desire (I download 5.0.2.0-bravo from ClockWorkMod)...
Linux Side:
Code:
[email protected] $ split_bootimg.pl recovery-clockwork-5.0.2.0-bravo.img
Page size: 2048 (0x00000800)
Kernel size: 1831224 (0x001bf138)
Ramdisk size: 1291948 (0x0013b6ac)
Second size: 0 (0x00000000)
Board name:
Command line: no_console_suspend=1 msmsdcc_sdioirq=1 wire.search_count=5
Writing recovery-clockwork-5.0.2.0-bravo.img-kernel ... complete.
Writing recovery-clockwork-5.0.2.0-bravo.img-ramdisk.gz ... complete.
[email protected] $
I write down parameters needed later on:
Page Size = 2048
Command line = 'no_console_suspend=1 msmsdcc_sdioirq=1 wire.search_count=5'
HexEditing Lookout of recovery.img header:
Code:
[email protected] $ hexedit recovery-clockwork-5.0.2.0-bravo.img
00000000 41 4E 44 52 4F 49 44 21 38 F1 1B 00 00 80 00 20 ANDROID!8......
00000010 AC B6 13 00 00 00 00 21 00 00 00 00 00 00 F0 20 .......!.......
00000020 00 01 [COLOR=#0000ff][B]00[/B][/COLOR] [COLOR=red][B]20[/B][/COLOR] 00 08 00 00 00 00 00 00 00 00 00 00 ... ............
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000040 6E 6F 5F 63 6F 6E 73 6F 6C 65 5F 73 75 73 70 65 no_console_suspe
00000050 6E 64 3D 31 20 6D 73 6D 73 64 63 63 5F 73 64 69 nd=1 msmsdcc_sdi
00000060 6F 69 72 71 3D 31 20 77 69 72 65 2E 73 65 61 72 oirq=1 wire.sear
00000070 63 68 5F 63 6F 75 6E 74 3D 35 00 00 00 00 00 00 ch_count=5......
I use the highlighted address ordered as follows:
base = 0x20000000
Now I simply repack alltoghether.. just to check new file vs old one:
Code:
[email protected] $ mkbootimg --kernel recovery-clockwork-5.0.2.0-bravo.img-kernel --ramdisk recovery-clockwork-5.0.2.0-bravo.img-ramdisk.gz --base 0x20000000 --pagesize 2048 --cmdline 'no_console_suspend=1 msmsdcc_sdioirq=1 wire.search_count=5' -o recovery_new.img
[email protected] $
[email protected] $ diff recovery-clockwork-5.0.2.0-bravo.img recovery_new.img
[email protected] $
No warnings, binary files don't differ...
Editing ramdisk:
Code:
[email protected] $ mkdir ramdisk
[email protected]ndalf $ cd ramdisk/
[email protected] $ gunzip -c ../recovery-clockwork-5.0.2.0-bravo.img-ramdisk.gz | cpio -i
4294 blocks
[email protected] $ ls -l
totale 144
drwxrwx--x 2 doc doc 4096 23 nov 23.56 data
-rw-r--r-- 1 doc doc 2615 23 nov 23.56 [B]default.prop[/B]
drwxr-xr-x 2 doc doc 4096 23 nov 23.56 dev
drwxr-xr-x 2 doc doc 4096 23 nov 23.56 etc
-rwxr-x--- 1 doc doc 94372 23 nov 23.56 init
-rwxr-x--- 1 doc doc 691 23 nov 23.56 init.rc
drwxr-xr-x 2 doc doc 4096 23 nov 23.56 proc
drwxr-xr-x 3 doc doc 4096 23 nov 23.56 res
drwxr-x--- 2 doc doc 4096 23 nov 23.56 sbin
drwxr-xr-x 2 doc doc 4096 23 nov 23.56 sys
drwxr-xr-x 3 doc doc 4096 23 nov 23.56 system
drwxr-xr-x 2 doc doc 4096 23 nov 23.56 tmp
-rw-r--r-- 1 doc doc 0 23 nov 23.56 ueventd.goldfish.rc
-rw-r--r-- 1 doc doc 4027 23 nov 23.56 ueventd.rc
[email protected] $
I'm going to modify one line of default.prop from
Code:
...
ro.secure=[B]1[/B]
...
to
Code:
...
ro.secure=[B]0[/B]
...
WARNING: clockworkmod recoveries could already have ro.secure set to 0
Repack ramdisk:
Code:
[email protected] $ find . | cpio -o -H newc | gzip > ../recovery-clockwork-5.0.2.0-bravo.img-ramdisk.gz
4295 blocks
[email protected] $ cd ..
[email protected] $
Repack recovery.img (as showed before):
Code:
[email protected] $ mkbootimg --kernel recovery-clockwork-5.0.2.0-bravo.img-kernel --ramdisk recovery-clockwork-5.0.2.0-bravo.img-ramdisk.gz --base 0x20000000 --pagesize 2048 --cmdline 'no_console_suspend=1 msmsdcc_sdioirq=1 wire.search_count=5' -o recovery_new.img
[email protected] $
Chapter Two: flash recovery.img to phone
I own a Samsung Galaxy Next, so I need to create an Odin Ready Archive and so on...
Different phone brands need different flash methods, I bet...
Chapter Three: Rooting
I need android sdk and I try android debug bridge...
...on a not rooted phone:
Code:
(i686) [email protected] $ adb shell
[B]$[/B] su
Permission denied
[B]$[/B]
...and on a rooted one:
Code:
(i686) [email protected] $ adb shell
[B]$[/B] su
[B]#[/B]
Now, starting the phone in recovewry mode with ro.secure=0, connecting with "adb shell" I find:
Code:
[email protected] $ adb shell
#
Already a root shell! No exploit needed!
Take a look to /system:
Code:
# mount
...
/dev/block/mmcblk0p3 /system ext4 [B]rw[/B],relatime,barrier=1,data=ordered 0 0
...
WOW! already "read-write" mounted... (if not mounted I can easily remount it "rw"... I'm root!)
Now, having su binary, Superuser.apk and busybox in the linux working directory:
Linux side:
Code:
[email protected] $ adb push su /system/xbin
417 KB/s (22228 bytes in 0.051s)
[email protected] $ adb push su /system/bin
529 KB/s (22228 bytes in 0.041s)
[email protected] $ adb push busybox /system/xbin
5061 KB/s (1674712 bytes in 0.323s)
[email protected] $
Anyway it should be better to make a backup of old su binary before overwriting it (adb pull /system/bin/su su-old)
"adb shell":
Code:
# chown root.shell /system/bin/su
# chmod 06755 /system/bin/su
# chown root.shell /system/xbin/su
# chmod 06755 /system/xbin/su
# chmod 04755 /system/xbin/busybox
#
WARNINNG: ordered commands
Linux:
Code:
[email protected] $ adb push com.noshufou.android.su-1.apk /system/app/Superuser.apk
5198 KB/s (843503 bytes in 0.158s)
[email protected] $
"adb shell":
Code:
# chmod 644 /system/app/Superuser.apk
#
THAT'S ALL FOLKS!​
reboot system now!
...
Code:
[email protected] $ adb shell
$ su
#
Enjoy!
...no exploit needed...
...
...Simply Linux Way of Hacking!...

Doc,
I dont get any command line: ...
in stock recovery/boot image.
can i just edit the default.prop of stock recovery img and flash it as PDA? or one package?
also does this not work when done to the boot.img?

roofrider said:
...I dont get any command line: ...
in stock recovery/boot image.
Click to expand...
Click to collapse
Command Line is optional, and usually - for example - you don't get anyone on Samsung Galxy Phone... for the HTC used in the example, instead, there was one, needed to tune the boot parameters on runtime...
can i just edit the default.prop of stock recovery img and flash it as PDA? or one package?
Click to expand...
Click to collapse
Surely you can! This Thread is exactly what you said: "change one file in stock recovery image"... all the rest is explanation on how I did it...
also does this not work when done to the boot.img?
Click to expand...
Click to collapse
Loud and Clear! Boot works in the same way but I prefer not to unsecure the system too much... cause any app could gain root privileges without asking for whenever she wants...
...whilst I'm the only one who decide to enter Recovery Mode...

Hi.
Even I can read on /tmp/recovery.log:
Code:
[property list]
ro.secure=0
ro.allow.mock.location=0
I get a normal user prompt on adb shell when phone is recovery boot.
So I guess I need some more tunning for make this work on a Samsung Galaxy Mini.
Thanks anyway. I've learnt how to build images with this post :good:

Galaxi Mini too!
XiR_ said:
Hi.
Even I can read on /tmp/recovery.log:
Code:
[property list]
ro.secure=0
ro.allow.mock.location=0
I get a normal user prompt on adb shell when phone is recovery boot.
So I guess I need some more tunning for make this work on a Samsung Galaxy Mini.
Thanks anyway. I've learnt how to build images with this post :good:
Click to expand...
Click to collapse
I own a Galaxy Mini too and I just get the same issue while testing Gingerbread 2.3.6 S5570XWKTN; my previous release was S5570XIKQC (2.3.4) where I got easy superuser rights on connection...
Maybe there is something more to check for...
Actually I have two simple workarounds to root, anyway, the working system as explained above:
I flash an old Recovery (2.3.4)! no real need to bump to 2.3.6 other then "on working system" (here there is my one: CODE_S5570XIKQC_recovery.tar.md5)
I flash (my current option) a CWM based recovery (here there is my one, freshly compiled from Mebitek Cyanogen 7.2 Unofficial Source: CODE_S5570CYANO_recovery.tar.md5 - CWM 5.0.2.8)
2.3.6 XWKTN
Testing Gb 2.3.6 XWKTN I got another unusual issue (unconfirmed on the network...):
After root, when I power on the phone I get the binaries
/system/xbin/su
/system/xbin/busybox
always deleted...
I workarounded it modifying the boot image:
I changed permissions of
/sbin
folder
Code:
# ls -l /
...
drwxr-x[B][COLOR="Red"]r[/COLOR][/B]-[B][COLOR="Red"]x[/COLOR][/B] 2 root root 0 Jan 1 1970 sbin
...
to give every user "exec rights" on it, then I put there both binaries!
Eh eh... I know that the system PATH first look there for commands:
Code:
# set | grep ^PATH
PATH=[B][COLOR="Red"]/sbin[/COLOR][/B]:/vendor/bin:/system/sbin:/system/bin:/system/xbin
#
Last:
I also put in 2.3.6 recovery /sbin folder the last "su" binary (source from GitHub)...
On execution I get "SegFault", but Root privileges Anyway:
Code:
$ su
Segmentation Fault
#
...amazing...

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?

[Without PC] Unpack, Edit, Repack boot.img

Hello friends, I'm back again with something I wish to share with you all. I have compiled three files to work flawlessly for ARM devices which will allow users to unpack, edit, and repack their boot.img without the use of a PC and all straight from their device.
---unmkbootimg, mkbootfs, mkbootimg---
Click here for the source on my Github.
Hey guys, since I have made this thread a while back there has been a LOT of changes made to the resource. For starters, it is now a multi call binary. In addition, I have updated mkbootfs for better support, mkbootimg.c has dt support, unmkbootimg.c has dt support, bootimg.h has dt support, as well as adding dtbtool, and dtc. Lets not also forget about lz4 for those whos ramdisks are not gz compressed. I am continuously making changes to the source and the op attachment will not be kept up to date. To stay up to date you will need to build the multi call binary from the source provided by the link above. Just simply run: make multi.
Note:
-- The mkbootimg binary is based upon the AOSP with some added modifications to work in conjunction with unmkbootimg.
-- The unmkbootimg binary is based on the original mkbootimg source but with reverse engineering to compliment its helpful use in extraction and thus providing the needed command to rebuild properly.
-- The mkbootfs binary is based on the source provided within the dsixda kitchen to insure the proper structural repacking of the ramdisk, etc.
Requirements:
-- BusyBox (cpio, gunzip and gzip is mandatory)
-- /System Write Permissions (Does not need to be a modified kernel)
-- Terminal Emulator
-- ES File Explorer (or similar)
-- Hex Editor (or use of DD)
-- Unzip boot_manipulation.zip on your device and copy the three files over to /system/bin. Those three files inside the .zip will be named unmkbootimg, mkbootfs and mkbootimg.
-- EDIT: I have included a flashable zip for these files.
-- Set permissions to rwxr-xr-x (755) on each binary. Note: The flash zip does this already.
-- Open up your android terminal emulator.
-- Now go ahead and pull your boot.img from your device (or use another one if you wish). Here is an example:
Code:
[email protected]:/ # [COLOR="Red"]dd if=/dev/block/mmcblk0p20 of=/data/local/tmp/boot.img[/COLOR]
dd if=/dev/block/mmcblk0p20 of=/data/local/tmp/boot.img
32768+0 records in
32768+0 records out
16777216 bytes transferred in 1.496 secs (11214716 bytes/sec)
[email protected]:/ #
-- Open up your boot.img with the Hex Editor and look for: ANDROID!. Remove everything before it so that the ANDROID! header is the first to be read then save it over top of the boot.img. NOTE: This is only required if you are using a stock boot.img. Here is an example:
Code:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 [COLOR="red"]A5 F0 BA B7 B0 43 E3 F8 3C E1 63 55 AE 75 C6 69 ¥ðº·°Cãø<ácU®uÆi[/COLOR]
00000010 [COLOR="red"]11 27 16 2F 51 48 E5 41 6F ED E1 7D C9 61 FB 3B .'./QHåAoíá}Éaû;[/COLOR]
00000020 [COLOR="red"]5F 45 49 EE 48 79 6E 4E FB DE 18 FC A0 F4 9A C3 _EIîHynNûÞ.ü*ôšÃ[/COLOR]
00000030 [COLOR="red"]43 11 35 67 AD 7E 2F D8 F6 E8 B1 4D 7D E0 45 B6 C.5g.~/Øöè±M}àE¶[/COLOR]
00000040 [COLOR="red"]E2 08 5F 0B 56 7F 45 71 3D 38 E2 C4 76 3E 53 EE â._.V.Eq=8âÄv>Sî[/COLOR]
00000050 [COLOR="red"]A4 3D 83 9F A2 BE D5 F4 75 5D B5 08 4E CC 9B BC ¤=ƒŸ¢¾Õôu]µ.NÌ›¼[/COLOR]
00000060 [COLOR="red"]7F 7A 9E 3D 4B 19 1B 91 6D FB 82 A0 B5 A8 38 88 .zž=K..‘mû‚*µ¨8ˆ[/COLOR]
00000070 [COLOR="red"]25 07 B5 1B 74 A2 03 62 BE 78 FA 33 96 A0 32 70 %.µ.t¢.b¾xú3–*2p[/COLOR]
00000080 [COLOR="red"]05 56 50 EF 88 C1 F3 73 E4 C5 73 6A 4E F8 CA 0A .VPïˆÁósäÅsjNøÊ.[/COLOR]
00000090 [COLOR="red"]D7 EF 2A 7F 09 30 21 BF 63 61 35 9A 9B 8A 62 42 ×ï*..0!¿ca5š›ŠbB[/COLOR]
000000A0 [COLOR="red"]28 C2 78 08 B0 CD 94 5F 7E EC F6 BA AD E6 AE 23 (Âx.°Í”_~ìöº.æ®#[/COLOR]
000000B0 [COLOR="red"]3E FD D8 A0 F1 F6 6D E2 D9 1E 2C E5 9F 91 84 92 >ýØ*ñömâÙ.,埑„’[/COLOR]
000000C0 [COLOR="red"]2E F0 6E 3C 1D 2B 1A D5 61 18 B2 F4 E0 66 B5 2F .ðn<.+.Õa.²ôàfµ/[/COLOR]
000000D0 [COLOR="red"]AE 97 9F F8 53 65 CE ED 68 43 4B 2B D5 A1 B6 D9 ®—ŸøSeÎíhCK+Õ¡¶Ù[/COLOR]
000000E0 [COLOR="red"]7D 36 CE A9 CC EC F4 5A 07 D8 99 5A 91 CC 8F 71 }6ΩÌìôZ.Ø™Z‘Ì.q[/COLOR]
000000F0 [COLOR="red"]A1 8D D7 82 C3 20 AB 7A 07 68 10 2D CC F6 A8 F9 ¡.ׂà «z.h.-Ìö¨ù[/COLOR]
00000100 41 4E 44 52 4F 49 44 21 08 D6 56 00 00 80 40 80 ANDROID!.ÖV..€@€
00000110 0E F0 07 00 00 80 80 81 00 00 00 00 00 00 30 81 .ð...€€.......0.
00000120 00 01 40 80 00 08 00 00 00 00 00 00 00 00 00 00 [email protected]€............
00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
-- Please note, HTC uses a 256 bit signature prior to the ANDROID! magic found in the boot.img. This may vary with other devices so keep that in mind. To remove the 256 bit junk so the boot.img is read properly you can use a hex editor and delete it or you can use DD. The following dd command I will be using is based on K2_CL in regards to the partition for our boot.img. Please make necessary adjustments to this command by insuring you know the location and where abouts of your own boot.img; Example:
Code:
dd bs=256 skip=1 if=/dev/block/mmcblk0p20 of=/data/local/tmp/boot.img
-- Alright, so we have the unmkbootimg, mkbootfs and mkbootimg located in /system/bin. We have pulled our boot.img and removed the junk before the magic android value: ANDROID!. Let's continue.
-- Go back to your android terminal emulator and change directories to /data/local/tmp. Here is an example:
Code:
[email protected]:/ # [COLOR="red"]cd /data/local/tmp[/COLOR]
cd /data/local/tmp
[email protected]:/data/local/tmp #
-- Now run unmkbootimg. Here is an example:
Code:
[email protected]:/data/local/tmp # [COLOR="red"]unmkbootimg -i boot.img[/COLOR]
unmkbootimg -i boot.img
kernel written to 'kernel' (5690888 bytes)
ramdisk written to 'ramdisk.cpio.gz' (521735 bytes)
To rebuild this boot image, you can use the command:
mkbootimg --base 0 --pagesize 2048 --kernel_offset 0x80408000 --ramdisk_offset 0x81808000 --second_offset 0x81300000 --tags_offset 0x80400100 --cmdline 'console=ttyHSL0,115200,n8 user_debug=31' --kernel kernel --ramdisk ramdisk.cpio.gz -o boot.img
[email protected]:/data/local/tmp #
-- Before you go any futher, copy all text within your android terminal emulator and paste it in to a text document. I personally use 920 Text Editor from the play store. You will do this so when the time comes you can open it back up and copy/paste the command to rebuild your boot.img as listed (This will save you some time).
-- Congratulations, you have done well so far. By typing and entering the command 'ls', you can see what all is in your directory. Here is an example:
Code:
[email protected]:/data/local/tmp # [COLOR="red"]ls[/COLOR]
ls
boot.img
init.rc
kernel
ramdisk.cpio.gz
[email protected]:/data/local/tmp #
-- Now lets create a folder and lets call it ramdisk. Here is an example:
Code:
[email protected]:/data/local/tmp # [COLOR="red"]mkdir ramdisk[/COLOR]
mkdir ramdisk
[email protected]:/data/local/tmp #
-- Now lets change directories to that ramdisk folder. Here is an example:
Code:
[email protected]:/data/local/tmp # [COLOR="red"]cd ramdisk[/COLOR]
cd ramdisk
[email protected]:/data/local/tmp/ramdisk #
-- Go ahead and extract ramdisk.cpio.gz. Here is an example:
Code:
[email protected]:/data/local/tmp/ramdisk # [COLOR="red"]gunzip -c ../ramdisk.cpio.gz | cpio -i[/COLOR]
isk.cpio.gz | cpio -i <
1851 blocks
[email protected]:/data/local/tmp/ramdisk #
-- Congratulations, you have done well so far. By typing and entering the command 'ls', you can see what all is in your directory. Here is an example:
Code:
[email protected]:/data/local/tmp/ramdisk # [COLOR="red"]ls[/COLOR]
ls
cwkeys
data
default.prop
dev
fstab.k2_cl
init
init.goldfish.rc
init.qcom.rc
init.qcom.sh
init.rc
init.target.rc
init.target.recovery.rc
init.trace.rc
init.usb.rc
proc
sbin
sys
system
ueventd.goldfish.rc
ueventd.rc
ueventd.target.rc
[email protected]:/data/local/tmp/ramdisk #
-- Now feel free at this point to make your edits within the ramdisk folder. When complete then come back and we shall finish the job.
-- Go ahead and move back out of the ramdisk folder by the following command:
Code:
[email protected]:/data/local/tmp/ramdisk # [COLOR="Red"]cd ..[/COLOR]
cd ..
[email protected]:/data/local/tmp #
-- You should now be in /data/local/tmp/.
-- Lets go ahead and repack the contents found in the ramdisk folder. Here, we will make use of the mkbootfs binary. Please take note that your original is named 'ramdisk.cpio.gz'. Here we will be repacking and renaming it to 'myramdisk.gz'. Here is an example:
Code:
[email protected]:/data/local/tmp # [COLOR="red"]mkbootfs ./ramdisk | gzip > myramdisk.gz[/COLOR]
mkbootfs ./ramdisk | gzip > myramdisk.gz
[email protected]:/data/local/tmp #
-- Open up your saved text file as instructed earlier and scroll to where you see this:
Code:
To rebuild this boot image, you can use the command:
mkbootimg --base 0 --pagesize 2048 --kernel_offset 0x80408000 --ramdisk_offset
0x81808000 --second_offset 0x81300000 --tags_offset 0x80400100 --cmdline 'conso
le=ttyHSL0,115200,n8 user_debug=31' --kernel kernel --ramdisk ramdisk.cpio.gz -o
boot.img
-- Look for --ramdisk ramdisk.cpio.gz and INSURE you change it to --ramdisk myramdisk.gz. Also go ahead and change boot.img to modboot.img. Now copy the mkbootimg command and paste it in to your android terminal emulator. Press enter.
-- There are multiple ways you can apply the new boot.img. The smartest way would be to use fastboot so that you may boot the image vice flashing it in case you screwed something up on your own accord. However, I personally will write the boot.img straight to the boot partition using dd, then I reboot the device. If you wish to do the same then that is fine.
-- Now you have your new Modded Boot Image. Enjoy, and as always... CLICK THANKS if this was helpful to you and....
--- Happy Hunting!!!

MKBOOTIMG-TOOLS
GITHUB SOURCE:
https://github.com/ModdingMyMind/mkbootimg_tools​
Original Author: xiaolu (GITHUB SOURCE: https://github.com/xiaolu/mkbootimg_tools)
Heavily Modified By: @Modding.MyMind
This project is originally based from xiaolu. To make this compatible for ARM I modified the script, compiled some binaries such as file, bash, grep, gzip, lzma, xz, mkbootimg, etc.
-- This project uses busybox but due to how stripped and limited busybox is ultimately led to me having to compile a few binaries from source. These binaries must be part of the project in order for the project to be succesfull. For example, busybox grep will not always give accurate offsets for the android header. One of MANY bugs found with busybox.
This project supports device tree binaries found inside the Boot.img and Recovery.img.
This project supports multiple Ramdisk compressions.
-- This project will check the ramdisk compression and if it determines that the tool does not support that particular compression then it will display a hazard warning letting the user know that the compression is not supported and that the ramdisk currently cannot be decompressed or compressed until support has been officially added.
-- If the compression is supported it will display what type of compression the Ramdisk is and how many blocks it has when unpacked.
This project will determine your kernel size, ramdisk size, and TRUE OFFSETS (not just the standard mkbootimg.c offsets).
-- With respect to the offsets; You will learn that many available tools found available specifically handle images where the ANDROID! header is located at 0x0. Not all images are built like this from stock. This project will find the header, base, kernel offset, ramdisk offset, second offset, and tags offset. It will rebuild the image using DD to insure the android header is located at 0x0. The found offsets inside the image will be cross referenced to see if the OEM of that image built it using the standard mkbootimg.c. If it detects any offsets which are built using NON-standard offsets then it will display a warning as well as show you what the image TRUE offsets actually are. Those same offsets are then applied to properly rebuild your image to insure that it boots like it was intended to do.
-- The warning will let you know that you may modify mkbootimg.c with the NON-standard values if you wish to have a binary specific to your device. The offsets displayed are not the address. Because the offsets are determined and not the address this makes it possible for this project to not have to rebuild mkbootimg.c. When the project is used to rebuild your image using the mkbootimg args such as --ramdisk_offset, --kernel_offsets, etc, etc, this then tells mkbootimg.c to ignore the hardcoded offsets and only use the ones it has been instructed to use. This is even more successful by insuring the BASE is accurate and applying the base as one of the mkbootimg args (--base 0 <-- this is lazy and stupid).
The mkboot script requires two args whether unpacking the image or repacking the image.
-- mkboot boot.img bootfolder (This will unpack the image)
1. mkboot is the script.
2. boot.img is the actual image.
3. bootfolder will be created and become the project folder.
-- mkboot bootfolder newboot.img (This will repack the image)
1. mkboot is the script.
2. bootfolder is the project folder which has the needed files and information to repack.
3. This will be the name of the finished build.
UNPACK STANDARD IMAGE​
This image uses standard mkbootimg.c:
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot boot.img work
Unpack & decompress boot.img to work
kernel : zImage
ramdisk : ramdisk
page size : 2048
kernel size : 2529072
ramdisk size : 230255
base : 0x12200000
kernel offset : 0x00008000
ramdisk offset : 0x01000000
second_offset : 0x00f00000
tags offset : 0x00000100
cmd line : mem=471M console=ttyMSM2,115200n8 androidboot.hardware=thunderc lge.rev=10
Ramdisk is lzma format.
1436 blocks
Unpack completed.
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
REPACK STANDARD IMAGE​
Image repacked with standard mkbootimg.c:
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot work boot.img
mkbootimg from work/img_info.
kernel : zImage
ramdisk : new_ramdisk.lzma
page size : 2048
kernel size : 2529072
ramdisk size : 230029
base : 0x12200000
kernel offset : 0x00008000
ramdisk offset : 0x01000000
tags offset : 0x00000100
cmd line : mem=471M console=ttyMSM2,115200n8 androidboot.hardware=thunderc lge.rev=10
Kernel size: 2529072, new ramdisk size: 230029, boot.img: 2762752.
boot.img has been created.
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
UNPACK NON-STANDARD IMAGE​
This image uses non-standard mkbootimg.c:
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot recovery.img work
Unpack & decompress recovery.img to work
****** WARNING ******* WARNING ******* WARNING ******
This image is built using NON-standard mkbootimg!
RAMDISK_OFFSET is 0x01608000
You can modify mkbootimg.c with the above value(s)
****** WARNING ******* WARNING ******* WARNING ******
kernel : zImage
ramdisk : ramdisk
page size : 2048
kernel size : 5834192
ramdisk size : 4351685
base : 0x80600000
kernel offset : 0x00008000
ramdisk offset : 0x01608000
second_offset : 0x00f00000
tags offset : 0x00000100
cmd line : console=ttyHSL0,115200,n8 user_debug=31
Ramdisk is gzip format.
14837 blocks
Unpack completed.
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
REPACK NON-STANDARD IMAGE​
Image repacked with non-standard mkbootimg.c:
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot work recovery.img
mkbootimg from work/img_info.
kernel : zImage
ramdisk : new_ramdisk.gzip
page size : 2048
kernel size : 5834192
ramdisk size : 4358038
base : 0x80600000
kernel offset : 0x00008000
ramdisk offset : 0x01608000
tags offset : 0x00000100
cmd line : console=ttyHSL0,115200,n8 user_debug=31
Kernel size: 5834192, new ramdisk size: 4358038, recovery.img: 10194944.
recovery.img has been created.
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
UNPACK IMAGE WITH INCOMPATIBLE RAMDISK​
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot boot-1.img work
Unpack & decompress boot-1.img to work
kernel : zImage
ramdisk : ramdisk
page size : 2048
kernel size : 3580032
ramdisk size : 594701
base : 0x10000000
kernel offset : 0x00008000
ramdisk offset : 0x01000000
second_offset : 0x00f00000
tags offset : 0x00000100
cmd line :
****** HAZARD ******* HAZARD ******* HAZARD ******
Ramdisk is data format. Can't unpack ramdisk.
This tool currently does not support data.
****** HAZARD ******* HAZARD ******* HAZARD ******
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
REPACK IMAGE WITH INCOMPATIBLE RAMDISK​
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot work boot-1.img
mkbootimg from work/img_info.
****** HAZARD ******* HAZARD ******* HAZARD ******
Ramdisk is data format. Can't repack ramdisk.
This tool currently does not support data.
****** HAZARD ******* HAZARD ******* HAZARD ******
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse

mkbootimg updated in .zip file. Enjoy
I went through some mess to get it to work correctly lol.
Works like a champ now.
Sent from my K2_CL using Tapatalk

Modding.MyMind said:
mkbootimg updated in .zip file. Enjoy
I went through some mess to get it to work correctly lol.
Works like a champ now.
Sent from my K2_CL using Tapatalk
Click to expand...
Click to collapse
Did you compiled mkbootimg?
Please can you say me in detail the not-booting problem? It rebooted continuously between bootloader and bootanimation?
xpirt

xpirt said:
Did you compiled mkbootimg?
Please can you say me in detail the not-booting problem? It rebooted continuously between bootloader and bootanimation?
xpirt
Click to expand...
Click to collapse
Yea, I compiled it. The last one I compiled wasnt done correctly. The sha and rsa was corrupted. But I fixed it.
Sent from my K2_CL using Tapatalk

Modding.MyMind said:
Yea, I compiled it. The last one I compiled wasnt done correctly. The sha and rsa was corrupted. But I fixed it.
Sent from my K2_CL using Tapatalk
Click to expand...
Click to collapse
I understand. And the bootloop I said is exactly what happened when packed with old mkbootimg?
xpirt

@xpirt
No bootloop. It would boot once and show the splash screen. Then reboot straight in to the custom recovery. Basically what happen in the old mkbootimg was the source code having too many white spaces and some other syntax issues. I had to go through every single command line in every single file to fix it. Spent almost 15+ hours reworking the codes. Then I compiled it, placed it on my device in /data/local/tmp. Pulled my boot img from my partition using dd over to /data/local/tmp. Ran the steps to unpacking, editing, and then used the new mkbootimg to repack it. After completion I wrote the new boot.img over to the partition using dd. Then rebooted, worked flawlessly without any bugs, errors, or hiccups.
Sent from my K2_CL using Tapatalk

Modding.MyMind said:
@xpirt
No bootloop. It would boot once and show the splash screen. Then reboot straight in to the custom recovery. Basically what happen in the old mkbootimg was the source code having too many white spaces and some other syntax issues. I had to go through every single command line in every single file to fix it. Spent almost 15+ hours reworking the codes. Then I compiled it, placed it on my device in /data/local/tmp. Pulled my boot img from my partition using dd over to /data/local/tmp. Ran the steps to unpacking, editing, and then used the new mkbootimg to repack it. After completion I wrote the new boot.img over to the partition using dd. Then rebooted, worked flawlessly without any bugs, errors, or hiccups.
Sent from my K2_CL using Tapatalk
Click to expand...
Click to collapse
Ok. Good, I'll try it out
xpirt

xpirt said:
Ok. Good, I'll try it out
xpirt
Click to expand...
Click to collapse
Sounds good. If it is a stock boot.img then you will need to remove everything before the android magic value (ANDROID!). After that, have at it lol. I will be adding additional code later on that will automatically look for the android magic value and make the necessary changes to it so it reads properly. This will keep others from having to do it themselves. Until then, has to be done by the user since I have hard-coded the magic android value.
Sent from my K2_CL using Tapatalk

Also plan to edit the unpackbootimg file so it will automatically extract the ramdisk archive automatically with out the need of the user having to use the ramdisk.sh file or by manually inputing the commands to do so. Got other plans as well. So a lot of improvements and bonuses are to come. Gonna try and make this thing a beast for arm devices.
Sent from my K2_CL using Tapatalk

OP updated with more in depth instructions/examples. Also, I have taken out the ramdisk.sh file and have also removed the unpackbootimg file. I have implemented unmkbootimg and a remake of the mkbootimg file(s). Works like a boss and gives you all the information you need to rebuild your boot.img. Will work on ALL arm devices. Enjoy.

Added download link to open source. See OP.
Sent from my K2_CL using Tapatalk

OP has been updated. I have included an additional binary called mkbootfs to work in conjuction with the other two given the necessary structural building properties of the boot.img. I have tested this on A LOT of boot.img's and all have been successful. I have also updated the instructions for using these binaries on your android device. Enjoy.

sweet sweet victory!

russellvone said:
sweet sweet victory!
Click to expand...
Click to collapse
This project was a pain bro. I almost gave up on it. Was dancing on thin ice until I had a break through which pushed me to complete the task. Works beautifully now .
Sent from my K2_CL using Tapatalk

Modding.MyMind said:
This project was a pain bro. I almost gave up on it. Was dancing on thin ice until I had a break through which pushed me to complete the task. Works beautifully now .
Sent from my K2_CL using Tapatalk
Click to expand...
Click to collapse
This is awesome.
Can you share the source code for this?
Sent from my GT-I8730 using Tapatalk

PM Sent
Sent from my K2_CL using Tapatalk

Modding.MyMind said:
PM Sent
Sent from my K2_CL using Tapatalk
Click to expand...
Click to collapse
Thank you!
Sent from my GT-I8730 using Tapatalk

OP updated with four photo attachments.
Sent from my K2_CL using Tapatalk

(Probably n00bish) Question:
How do I compile the binaries from the source? By gcc or make?
Beamed from my Galaxy Express using Tapatalk

[GUIDE] How to unlock the bootloader (alternate method)

Well, this method is different from the paid method that forbidden by forum.
The alternate method is simply explained in Chinese at following website.
本方法的中文阐述：https://hikaricalyx.com/2018/04/03/nokia-7-bootloader-unlock-test/
Click to expand...
Click to collapse
As far as I know, this method tested on following models:
- Nokia 6.1 (TA-1054 only)
- Nokia 7
- Nokia 8
- Sharp Aquos S2
WARNING! THIS METHOD IS PRETTY COMPLICATED AND DANGEROUS!
I'M NOT RESPONSIBLE FOR BRICKING THE DEVICE! DO IT AT YOUR OWN RISK!
FIH made Android Phones with Android 7.x pre-installed can unlock the phone with the method I mentioned.
Preparations:
- Your phone must have Android 7.x running, or you're able to downgrade abl/xbl provided with Android 7.x firmware with other methods.
You can find an excuse at service point to let them downgrade for you, like "My work application is incompatible with Android 8.0" or something.
But Nokia 6.1 Android One Global Variant has Android 8.0 installed out of factory, so it's not likely possible.
Install following software on your PC.
- Patched OST LA 6.0.4: https://drive.google.com/open?id=1n91aYT9Di6_v4F3Wjlv8TjfeLc64AcYA
To install it properly, extract the archive and right click on setup.bat, run it with Administrator previleges. You may want to reinstall every Visual C++ Redistributable Runtime.
- QPST, the newer the better, I personally choose 2.7.460, the latest version should be 2.7.472.4. You can find it by simply Googling.
- A Hex editor. You can choose HxD or any other professional Hex Editor like UltraEdit.
And of course, the stock firmware for your phone. For example, I’ve posted the stock firmware for Nokia 7 on xda-developers Nokia 7 forum.
Since the guide involves the proprietary tool OST LA, it only works on Windows. I recommend you use latest Windows 10 stable release to finish the guide.
Minimal OS: Windows 7 Service Pack 1 with latest updates installed, both 32bit and 64bit are acceptable
Let’s get started.
Part 1: Before Unlocking
1. Backup your data on the phone, and logout your Google Account if you’ve logged in.
2. Enable Allow OEM Unlocking and USB Debugging to make following procedure convenient.
3. Extract early stock firmware or I'll upload required abl (to be added).
Part 2: Flash Service abl/xbl
You have multiple methods to flash abl/xbl.
If your phone is running Android 7.1, you can use old "Edit Phone Information" method I mentioned on Nokia 6 forum.
But let me tell you a method to flash service bootloader.
1. Enter fastboot mode (Download mode), and check which slot are you using.
Code:
fastboot getvar current-slot
I assume your current slot is A.
2. Now calculate the md5 checksum of your serial number. For example, the md5 checksum of PL2GAM1234567890 is 154b7ad463038ec186aafa5909505695.
If you have no idea about your serial number, execute this command:
Code:
fastboot devices
Expected output:
Code:
PL2GAM1234567890 fastboot
Of course your serial number can't be PL2GAM1234567890, I'm just making an example.
3. Execute these commands to flash service abl and xbl:
Code:
fastboot oem dm-verity 154b7ad463038ec186aafa5909505695
fastboot flash abl_a D:\C1N-0-0430-abl_service.elf
fastboot flash xbl_a D:\C1N-0-0430-xbl_service.elf
If the fastboot returns "unknown command" when executing first command, your phone is running Android 8.x.
Try to downgrade the abl with disassembly and wire trick to EDL.
You'll realize how to achieve that when reading Part 4.
Click to expand...
Click to collapse
The service abl and xbl are extracted from Nokia 7 stock firmware, which can be also used on Nokia 6.1.
4. Reload the service bootloader:
Code:
fastboot reboot-bootloader
Part 3: Enter EDL mode
Skip this part if you can use wire trick to trigger EDL mode.
Execute these commands:
Code:
fastboot oem dm-verity 154b7ad463038ec186aafa5909505695
fastboot oem reboot-edl
Part 4: Dump a partition
1. Check Device Manager, "Port (COM and LPT)" category to see if your phone is listed as HS-USB QDLoader 9008 (COMx).
If it's listed as HS-USB Diagnostics 9008 or QUSB__BULK in "Universal Serial Bus devices", you need to update the driver manually to HS-USB QDLoader 9008 (COMx), then force reboot your phone and re-enter the EDL mode.
2. Open QFIL, and load the firehose file from stock firmware.
If you're using Nokia 8, you'll also need to change the storage type to UFS in FireHose Configuration.
3. Click "Tools" - "Partition Manager", and click OK.
4. Find deviceinfo (not devinfo) partition, right click on it and click "Manage Partition", then click "Read Image". This will dump deviceinfo partition.
Dumped deviceinfo partition will be placed at "%AppData%\Qualcomm\QFIL\COMPORT_*" with filename like this:
ReadData_eMMC_Lun0_0xb828_Len2048_DT_15_04_2018_15_16_32.bin
5. Use a Hex Editor and jump to offset 0x5101, data will be looked like this:
Code:
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
00005000 02 50 ED 13 EF C4 07 C3 67 3B CC 83 E1 7F 0B 7E
00005010 CC 40 DD DF 66 6A E8 52 F4 E8 78 7C 8B 87 CC DC
00005020 0F 45 EE F7 E9 71 E6 B0 DE 53 6E 97 84 10 EA 15
00005030 F3 78 07 B4 30 87 29 E3 1B DF 96 31 DE 30 1B 46
00005040 EC D3 33 F5 19 1D 56 EE 0A 5A A9 48 8D A1 83 80
00005050 F6 BA 29 AC 1A 10 BF FD A9 64 D5 79 4D C2 AF 9B
00005060 BD 62 87 49 07 A6 CB 88 22 6D 8C 65 10 94 CD 2F
00005070 3B B7 0C C9 91 92 67 F5 02 17 32 55 4C 5E 8B E7
00005080 1B 4D 70 65 61 46 CB 63 F4 C3 EE F8 45 E0 8D 48
00005090 6B 1E 1C FB 0C 94 48 BB FE AF 01 98 4F 47 4D 3A
000050A0 2A 5F 7F 3E 1E 49 C9 6D 4A 11 A5 19 D6 F1 E7 91
000050B0 5D B6 C8 A4 FA AA 15 BB 69 5F 8B C8 72 2A DD A5
000050C0 D0 DC 8B 4E 33 C8 20 57 6D D5 B8 D4 BF 17 0E B1
000050D0 30 5B 3E 13 BC FF 08 10 4C E2 3E 12 9F 9A A6 54
000050E0 6B D8 DE 98 D4 D7 44 37 7C 6D 43 CA A4 BA D9 C7
000050F0 BB F1 1F 12 90 8D 0D 4B 1B 1E 04 69 69 FD 44 1B
00005100 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
If data exists between 0x5000 and 0x5100, you'll be able to use this method to unlock. Modify the value of 0x5101 to 0xFF like this:
Data above are shown for example. You can't use it and you must use your own deviceinfo.
Click to expand...
Click to collapse
Code:
00005100 06 FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00
6. Save it as deviceinfo_mod.bin to another place and use QFIL to write it back.
Click "Load Image" and choose your deviceinfo_mod.bin. This will write modified deviceinfo back to your phone.
7. Close QPST and reboot your phone to fastboot mode (Download mode).
Part 5: Unlock the phone
1. Remember to keep the OST LA opened to make sure your phone will stay at Download mode.
2. Execute following commands:
Code:
fastboot oem dm-verity 154b7ad463038ec186aafa5909505695
fastboot oem cert_timecount get
If the output cert_timecount is not zero, you can proceed. Otherwise... (Click to unhide)
execute these commands and check again:
Code:
fastboot flash deviceinfo D:\deviceinfo_mod.bin
fastboot reboot-bootloader
3. Then unlock your phone with following commands:
Code:
fastboot oem dm-verity 154b7ad463038ec186aafa5909505695
fastboot flashing unlock_critical
(Do confirmation on your phone)
fastboot oem dm-verity 154b7ad463038ec186aafa5909505695
fastboot oem unlock-go
(Do confirmation on your phone again)
Now your phone is fully unlocked with not serious typo:
Your device has been unlocker and cann't be trusted.
ID: PL2GAM1234567890
Your device will be continue in 5 seconds.
Click to expand...
Click to collapse
Part 6: Restore to stock
You may not be able to install further OTA update unless you switch the slot to previous build and update again, or reinstall stock firmware.
To switch the slot, check your current slot with this command (I assume the current slot is A):
Code:
fastboot --set-active=_b
Then reboot your phone and reinstall OTA update.
To reinstall stock firmware, follow the guide on Nokia 7 plus forum:
https://forum.xda-developers.com/nokia-7-plus/how-to/workaround-flashing-oreo-firmware-t3793791
Required service abl/xbl and firehose for Nokia 6.1 and Nokia 7:
https://drive.google.com/open?id=1lN24vWc8edc_i9BINRTyg-bsNpsKfqCs
Extract password is "WLBGFIH123" (without quotes)
Special thanks:
@heineken78 for Sharp Aquos S2 bootloader unlock

Hello and thanks for sharing.
One question: How can we extract the abl/xbl services as well as firehose from stock rom?
I have a Nokia 2 and would very much like to unlock it.
I did extract the source rom (and also boot.img, system.img, recovery.img), but i don't know how to get the abl/xbl services and firehose firmware.
Can you help me on that?
Thanks

Hi,
Today I was brave enough to risk and dump 200$(TA-1054) in the garbage.
I've followed the procedure up to the modified deviceinfo upload.
For me QFIL wasn't writing the modified bin file on the device unless it's in the folder %AppData%\Qualcomm\QFIL\COMPORT_ (working directory)
After writing it, though, the rest was up to the letter.
I'm currently updating to 8.0 and will post feedback how it works after the updates.
Also, for some reason, I don't have _b slot. Should I worry ?
C:\Program Files (x86)\Minimal ADB and Fastboot>fastboot --set-active=_b
Setting current slot to 'b'...
FAILED (remote: Invalid Slot Suffix)
finished. total time: -0.000s
Edit:
The phone is now updated to 8.1 august patch.
Everything I've tested since yesterday works as before, except wi-fi hotspot (I've read it's some 8.1 issue) mobile data. I'll do some testing to try and figure out where this problem came from.
Edit2:
For some reason mobile data is not working after installing august update. Restored it back to July update and everything seems to be ok(including wi-fi hotspot).