Develop Bugs

ext4 extraction from system.sin issues

Hi,
As you probably know, ext4 image can be extracted from system.sin but cannot be mounted. When trying to mount it, it fails with :
[ 1476.821582] EXT4-fs (loop0): bad geometry: block count 262144 exceeds size of device (144631 blocks)
I open this thread just to share what I did around the issue and maybe have some helpful quotes about it
Here is what I did (under linux)
# First create an zero filled file. Size is system partition size (262144 blocks of 4096 each)
dd if=/dev/zero of=/home/xperia/virtualfs bs=4096 count=262144
# Attach file to loopback
sudo losetup /dev/loop0 /home/xperia/virtualfs
# Format it with same features as system partition on phone
sudo mkfs.ext4 -O has_journal,^ext_attr,^dir_index,^flex_bg,^huge_file,resize_inode,filetype,extent,sparse_super,large_file,^uninit_bg,^dir_nlink,^extra_isize -v /dev/loop0
# Write extracted system.sin.ext4 extracted image to loopback
sudo dd if=system.sin.ext4 of=/dev/loop0
# Mount filesystem
sudo mount /dev/loop0 /mnt
It can be mounted and I can have folder structure but I can't work with files. Editing default.prop gives me a non readable file.
But we can go a step ahead as we can now mount the image.
Still some issues have to be worked out.

The poit is, why we cant mount system.img on ICS but we can on GB?
maybe someone can contact with sony t oask
im extracting the .sin to .img like always but its impossible to mount.. what are you using to extract the .sin to a .ext4?
BTW, thanks for the info, i've been trying to modify system.img since ICS appeared.
EDIT: of, ext4 can be extracte with flashtool ~.~
maybe we need to read something from system.partinfo

Yakandu said:
The poit is, why we cant mount system.img on ICS but we can on GB?
maybe someone can contact with sony t oask
im extracting the .sin to .img like always but its impossible to mount.. what are you using to extract the .sin to a .ext4?
BTW, thanks for the info, i've been trying to modify system.img since ICS appeared.
EDIT: of, ext4 can be extracte with flashtool ~.~
maybe we need to read something from system.partinfo
Click to expand...
Click to collapse
Yes Flashtool can extract image from system.sin.
partinfo is partition information used by loader in flashmode to identify where to flash image on phone. (Something like start nand address of system partition)

so, any ideas why ext4 cant be mounted? maybe its encrypted or something..

Sorry for double post, i found a solution
Flash the system through a .ftf with flashtools
Flash a custom kernel with recovery (or the nozomi recovery)
Backup nandroid
We get a system.ext4.tar ··· move it to your developement folder
Create a folder (mkdir system)
Enter nautilus with root acces
Extract system files to the created folder
Modify whatever you want
Make a flashable system.img with: "./mkuserimg.sh -s /system ./system.img ext4 ./temp 1024M"
AND ITS WORKING!

Yakandu said:
Sorry for double post, i found a solution
Flash the system through a .ftf with flashtools
Flash a custom kernel with recovery (or the nozomi recovery)
Backup nandroid
We get a system.ext4.tar ··· move it to your developement folder
Create a folder (mkdir system)
Enter nautilus with root acces
Extract system files to the created folder
Modify whatever you want
Make a flashable system.img with: "./mkuserimg.sh -s /system ./system.img ext4 ./temp 1024M"
AND ITS WORKING!
Click to expand...
Click to collapse
This solution is already known
But my goal is to be able to mod a system partition without having to flash it before. And more, understand why extracted system image cannot be mounted and how to work this out

oh, ok xD
i didnt know that solution, its new for me

Yakandu said:
Sorry for double post, i found a solution
Flash the system through a .ftf with flashtools
Flash a custom kernel with recovery (or the nozomi recovery)
Backup nandroid
We get a system.ext4.tar ··· move it to your developement folder
Create a folder (mkdir system)
Enter nautilus with root acces
Extract system files to the created folder
Modify whatever you want
Make a flashable system.img with: "./mkuserimg.sh -s /system ./system.img ext4 ./temp 1024M"
AND ITS WORKING!
Click to expand...
Click to collapse
Have you already tried flashing this img on your device? I have already tried this solution twice but didn't succeed (@Spectre51 that's why I haven't replied your PM yet). system.img was succesfully created but I got boot loop when I flashed it on my device.

Hi Androxyde,
I figured it out, basically we have to dig further in sin format as new ext4 sins skips part of the file. See my thread for more details.
PS: Thanks for flashtool, it's a great tool!
LeTama

letama said:
Hi Androxyde,
I figured it out, basically we have to dig further in sin format as new ext4 sins skips part of the file. See my thread for more details.
PS: Thanks for flashtool, it's a great tool!
LeTama
Click to expand...
Click to collapse
:good:

[dev]How to Un/Re/Pack a Boot.blob and unyaff a boot.img

Technically i have to give credit to scott crossler
www.scottsroms.com
for showing me the method
and then i came upon turges
faq
Thanks Turge and Scott and whomever created these blobpacktools
but since i keep getting pms
and im sure you do to
scott
Here are the steps for repacking the boot.img. Some involve running the commands via cygwin, others involve running them via the Windows Command Prompt.
The instructions for installing cygwin, extracting and repacking the boot.img were found here: http://www.freeyourandroid.com/guide...ot-img-windows
Once you have setup cygwin, extract the attached files in a folder under your "home" folder in cygwin.
Also unzip blob tools into the same folder as your boot.blob
1.
Code:
copy boot.blob to the same folder and run the following via
the Windows Command Prompt to extract the boot.img from the boot.blob:
BlobUnpack.exe boot.blob
ren boot.blob.LNX boot.img
which will create boot.img
2.
Code:
From the cygwin bash terminal window,
switch to the same folder and run the following
to extract the ramdisk from the boot.img:
./extractboot boot.img
You now have an out/ramdisk folder
that contains the files you want to edit.
3.
Code:
Once done, repack the ramdisk and kernel into boot_new.img
with the following command (via cygwin once again):
./packboot
4.
Code:
then from the Command Prompt repack boot_new.img
into boot2.blob using the following:
blobpack -s boot2.blob LNX boot_new.img
5.
Code:
You can now flash the boot.blob to the staging
partition via a command in updater-script:
Code:
package_extract_file("/boot.blob", "/dev/block/mmcblk0p4");
or by using adb while in recovery/android:
Code:
dd if=/sdcard/boot2.blob of=/dev/block/mmcblk0p4

Lastly the rundown is like this
if you want to take a ota blob
and extract the contents for a raw base
and a raw kernel
1
take the ota and extract the blob file and place
in your folder with blobtools
2. then run
Code:
blobunpack.exe blob
Which now creates
Blob.APP =System.img (can be renamed system.img and unyaffed in the kitchen)or straight cygwin
Blob.sos=Recovery Img
Blob.Ebt=Bootloader information
Blob.Lnx=kernel (can also just be renamed boot.img and unyaffed in kitchen)
Blob.pt=Partition info
so to repack lets say your custom remade image
and your custom kernel
and a recovery of your choice
run
Code:
blobpack.exe -s blob lnx boot.img sos twrp.blob app system.img
then simply take the blob replace in the ota file
and flash in recovery
and it should flash a rom packed as a blob

Hi!
...also you can flash the new boot.blob via fastboot mode
>fastboot-i 0x0B05 flash boot boot.blob
:good:

Call me stupid, but what does repacking the boot.img do? I never pm'ed you, but what would we gain from this. a lil lost

unpacking a boot.img allows you to take a stock already built kernel
and make specific changes to the ramdisk
more specifically
default.prop
can make kernel insecure
debuggable
bootanimation enabled
blah blah blah
and init.rc
but also
cardhu
and goldfish.rc
and init.trace
and init.usb
then repacked and good to flash

seanzscreams said:
Lastly the rundown is like this
if you want to take a ota blob
and extract the contents for a raw base
and a raw kernel
1
take the ota and extract the blob file and place
in your folder with blobtools
2. then run
Code:
blobunpack.exe blob
Which now creates
Blob.APP =System.img (can be renamed system.img and unyaffed in the kitchen)or straight cygwin
Blob.sos=Recovery Img
Blob.Ebt=Bootloader information
Blob.Lnx=kernel (can also just be renamed boot.img and unyaffed in kitchen)
Blob.pt=Partition info
so to repack lets say your custom remade image
and your custom kernel
and a recovery of your choice
run
Code:
blobpack.exe -s blob lnx boot.img sos twrp.blob app system.img
then simply take the blob replace in the ota file
and flash in recovery
and it should flash a rom packed as a blob
Click to expand...
Click to collapse
Hi!
For a linux (Ubuntu) machine you can easily unpack blob.APP
> sudo mkdir mnt
> sudo mount -o loop blob.APP mnt
- now in your mnt directory , you will have /system ! :good:

Hi,
My TF300tl can't unlock bootloader. so can I use this way to pack custom ROM ( cm11, liplop...) as official ROM to flash for my tablet ?

konnichiwa said:
Hi,
My TF300tl can't unlock bootloader. so can I use this way to pack custom ROM ( cm11, liplop...) as official ROM to flash for my tablet ?
Click to expand...
Click to collapse
I wouldn't think so, as the ROM would have to be signed to be official

[Q][KERNEL] Not able to unpack some boot.img

The tool I use is KITCHEN for unpacking boot.img
Yesterday i encountered a problem while unpacking boot.img file
Code:
Press Enter to continue
Kernel found at offset 131072 in boot.img
Setting offset=131072 in mkbootimg.c, line 76
Setting offset=131072 in mkbootimg.c, line 109
Setting offset=131072 in extract-kernel.pl, line 23
Setting offset=131072 in extract-ramdisk.pl, line 23
Extracting kernel ...
Extracting ramdisk ...
Error: No ramdisk folder found!
Contents of bootimg_050313_133308:
total 3340
-rw-r--r-- 1 user None 3419532 May 3 13:33 zImage
Press Enter to continue
Got an error. Showing No ramdisk folder found. Is there any other way to unpack such boot.img??
Tried a lot searching on Google about this but didnt find any solution.
Someone who play with kernels everyday help me out please

Anyone??
Does anyone know about lzma compression? I guess such boot.img are compressed using lzma algorithm. How to unpack and re-pack such boot.img?
Plz someone help
Sent from my LT18i using xda app-developers app

Have you tried another method?

XperienceD said:
Have you tried another method?
Click to expand...
Click to collapse
Yep i did. Now able to unpack and re-pack lzma compressed boot.img files
For extracting boot.img-ramdisk.gz (LZMA compressed only) should type
Code:
lzma -dc ../boot.img-ramdisk.gz | cpio -i
All the Credit goes the original Dev.:good:
Reference used : http://forum.xda-developers.com/showthread.php?t=1659584&highlight=lzma

rohan170890 said:
Yep i did. Now able to unpack and re-pack lzma compressed boot.img files
For extracting boot.img-ramdisk.gz (LZMA compressed only) should type
Code:
lzma -dc ../boot.img-ramdisk.gz | cpio -i
All the Credit goes the original Dev.:good:
Reference used : http://forum.xda-developers.com/showthread.php?t=1659584&highlight=lzma
Click to expand...
Click to collapse
helo bro .. i am facing the same prblm like ramdisk folder not found while unpacking boot.img ... will u plzz help me to unpack it
here is the boot.img file http://www.mediafire.com/download/781fb7713efj719/boot.img

[BOOT IMAGE] Stock boot with su.d & init.d support | 20.05.2016

As the title states this is a stock boot.img with init.d support.
Download >>> https://mega.nz/#!Nwx0BD5T!TZB0ngp3spi3myFAFw7gtx0z8zu7O2BRLv2UC2HTJ4M
XDA:DevDB Information
[BOOT IMAGE] Stock boot with su.d & init.d support, Kernel for the Elephone P9000
Contributors
Jonny
Kernel Special Features:
Version Information
Status: Stable
Stable Release Date: 2016-05-20
Created 2016-05-18
Last Updated 2016-05-20

this cant work . sry

skeleton1911 said:
this cant work . sry
Click to expand...
Click to collapse
Should do, same way I used to fire init.d on other devices (M9). Of course with SuperSU installed init.d is kind of deprecated as su.d is a better solution.

Jonny said:
Should do, same way I used to fire init.d on other devices (M9). Of course with SuperSU installed init.d is kind of deprecated as su.d is a better solution.
Click to expand...
Click to collapse
no sorry i dont work.
look:
in init.rc you wrote that
Code:
service sysinit /system/xbin/busybox run-parts /system/etc/init.d
class main
oneshot
user root
group root
that is going to sysinit . but sysinit service is not present in in system, check it yourself
if you would use this . it would work at boot
Code:
service[COLOR="Red"] userinit[/COLOR] /system/xbin/busybox run-parts /system/etc/init.d
oneshot
class late_start
user root
group root
and users have to install busybox and add the init.d folder into system/etc manual
set permissions to 755 or 777 for the init,d folder and the scripts they want to use

Ah cheers, I forgot to add the sysinit binary. Tbh though I think I'm going to look more into su.d as it seems more reliable in where in the boot process it executes the script :good:

Link updated. New zip flashes and installs busybox and creates the su.d and init.d folders with correct permissions. This one now supports both init.d and su.d (recommended).

Jonny said:
Link updated. New zip flashes and installs busybox and creates the su.d and init.d folders with correct permissions. This one now supports both init.d and su.d (recommended).
Click to expand...
Click to collapse
now it works . great job

Jonny said:
As the title states this is a stock boot.img with init.d support.
Click to expand...
Click to collapse
What tools did you use to repack the kernel and ramdisk ? I've used nearly ten tools with a non working boot image after modifying default.prop only.
Please advise about any tricks to do that.
Thanks.

nmset said:
What tools did you use to repack the kernel and ramdisk ? I've used nearly ten tools with a non working boot image after modifying default.prop only.
Please advise about any tricks to do that.
Thanks.
Click to expand...
Click to collapse
What did you edit in the boot image?
Sent from my Elephone P9000 using XDA Labs

Jonny said:
What did you edit in the boot image?
Click to expand...
Click to collapse
I unpacked the boot image, then the ramdisk, edited default .prop changing ro.adb.secure from 1 to 0.
Repacked the ramdisk with
find . | cpio --owner root:root -ov -H newc | gzip -9 > ../ramdisk.cpio.gz
After repacking the boot image with many tools, no way to get a working one.

nmset said:
I unpacked the boot image, then the ramdisk, edited default .prop changing ro.adb.secure from 1 to 0.
Repacked the ramdisk with
find . | cpio --owner root:root -ov -H newc | gzip -9 > ../ramdisk.cpio.gz
After repacking the boot image with many tools, no way to get a working one.
Click to expand...
Click to collapse
It's editing that line, I've tried it previously myself and it just ends up with a boot image that doesn't work.
Sent from my Elephone P9000 using XDA Labs

Jonny said:
It's editing that line, I've tried it previously myself and it just ends up with a boot image that doesn't work.
Click to expand...
Click to collapse
If I just unpack the original boot image and the ramdisk, and repack everything without any modifications, the resulting boot image is not functional.
If I unpack the original boot image, and do not unpack the ramdisk, then repack the kernel and ramdisk, the resulting boot image works perfectly.
It seems related with the ramdisk format, or its header, or addresses and offsets, or whatever, I wish you could share how you got a working boot image.
Thanks.

nmset said:
If I just unpack the original boot image and the ramdisk, and repack everything without any modifications, the resulting boot image is not functional.
If I unpack the original boot image, and do not unpack the ramdisk, then repack the kernel and ramdisk, the resulting boot image works perfectly.
It seems related with the ramdisk format, or its header, or addresses and offsets, or whatever, I wish you could share how you got a working boot image.
Thanks.
Click to expand...
Click to collapse
I use Android Image Kitchen, but I've still had the same results as you when editing that line

Jonny said:
I use Android Image Kitchen, but I've still had the same results as you when editing that line
Click to expand...
Click to collapse
Code:
find . | cpio -o -a --reproducible -R 0:0 -H newc | gzip -9 > ../ramdisk.cpio.gz
That did the trick.
(As a sidenote, I did not have the expected result, i.e, a root shell with 'adb shell', after 'adb root', one more paranoid regression from Google.)
:crying:

nmset said:
Code:
find . | cpio -o -a --reproducible -R 0:0 -H newc | gzip -9 > ../ramdisk.cpio.gz
That did the trick.
(As a sidenote, I did not have the expected result, i.e, a root shell with 'adb shell', after 'adb root', one more paranoid regression from Google.)
:crying:
Click to expand...
Click to collapse
For a root shell type 'adb shell' the just type 'su' and accept the superuser prompt on your device.
Adb root is needed for doing the adb remount command to push and pull certain files to /system

Oreo: fstab.qcom in ramdisk

After extracting the ramdisk from the stock boot image of OSS5.0 / Android O 8.0 for Oneplus3, I noticed that fstab.qcom file is no longer there in the ramdisk. Until OSS4.5.1 / Android N 7.1 this file was present and could be edited to set the flag for data partition to encryptable and to also remove the verity flag ...both of which I found to be very useful.
Appreciate if someone can please help me understand what has changed in the Android O 8.0 and what would be the method to achieve the above?

Looking at https://forum.xda-developers.com/oneplus-3t/how-to/disable-dm-verity-force-encryption-op3t-t3688748 and https://forum.xda-developers.com/attachment.php?attachmentid=4302571&d=1507993390, it appears that the fstab.qcom file has moved to /system/vendor/etc/fstab.qcom in Oreo in keeping with Android O / 8.0 specifications. Changing that file means modifying the system partition, which I don't mind as I like to modify the hosts file as the barest minimum change even in my daily use device. But still wondering if the same can be achieved by Magisk and how. Appreciate if someone can help me understand this.

Today's learning:
1. Android O kernel specifications include early mounting of some partitions and Oneplus 3 specifies the system partition in its device tree blobs (dtb).
2. These dtb are part of (...appended to) the real kernel image and not on a separate partition / blob.
3. There are 13 dtb appended to Oneplus 3 kernel and each of them has an entry relevant to fstab which mounts system with the verify flag.
4. Again, in keeping with Android O specifications, fstab.qcom (...now located in the /vendor/etc/ directory) does not include a line for the system partition (...commented out) as mounting the system partition is already taken care of through the dtb in the kernel.
5. That means system modifications cannot be done until the dtb are cleaned of verify flag .... or perhaps the whole of the code mounting the system partition in dtb is deleted and then fstab.qcom is restored in the ramdisk.
Haven't yet tried this and it will be helpful if someone more knowledgeable can confirm that these are the steps to be done to modify the system partition.

@rk2612 great findings and write up!
Just saw your post at magisk beta thread. I'm facing same problem on xperia device with Oreo, and I think we need to change the flag as you stated there.
I've already tried flashing magisk, but dm-verity is still being triggered and phone falls in a bootloop after it reboots.
I'd like to try this method out on my xperia, but I don't know how to convert dtb into dts, and vice versa. Any help on this would be great! Thanks in advance!!

serajr said:
@rk2612...
I've already tried flashing magisk, but dm-verity is still being triggered and phone falls in a bootloop after it reboots.
I'd like to try this method out on my xperia, but I don't know how to convert dtb into dts, and vice versa. ...
Click to expand...
Click to collapse
Have you tried patching with Magisk Beta v1456? That seems to take care of the verity flag in the dtb of OnePlus 3.
On Ubuntu, you can install dtc (device tree compiler ...Refer http://manpages.ubuntu.com/manpages/xenial/man1/dtc.1.html ) to handle conversion from dtb to dts or vice versa.

rk2612 said:
Have you tried patching with Magisk Beta v1456? That seems to take care of the verity flag in the dtb of OnePlus 3.
On Ubuntu, you can install dtc (device tree compiler ...Refer http://manpages.ubuntu.com/manpages/xenial/man1/dtc.1.html ) to handle conversion from dtb to dts or vice versa.
Click to expand...
Click to collapse
Thank you bro!
Yes, I had, latest beta v1456!
Gonna try it out and report back here later!!

serajr said:
...
I'd like to try this method out on my xperia, ....
Click to expand...
Click to collapse
serajr said:
Thank you bro!
Yes, I had, latest beta v1456!
Gonna try it out and report back here later!!
Click to expand...
Click to collapse
According to https://github.com/topjohnwu/Magisk/blob/master/scripts/boot_patch.sh (...line 93 onwards) Sony devices may not be handled well by Magisk.

rk2612 said:
According to https://github.com/topjohnwu/Magisk/blob/master/scripts/boot_patch.sh (...line 93 onwards) Sony devices may not be handled well by Magisk.
Click to expand...
Click to collapse
Bro, this is an known issue for all xperia users. Always before we flash magisk (os SuperSU), we do need to convert xperia stock kernel (elf format) to boot.img (aosp format), and fastboot it!
And for the records, this is exactly what I've found with dtc:
Code:
firmware {
android {
compatible = "android,firmware";
fstab {
compatible = "android,fstab";
vendor {
compatible = "android,vendor";
dev = "/dev/block/platform/soc/7464900.sdhci/by-name/vendor";
type = "ext4";
mnt_flags = "ro,barrier=1,discard";
fsmgr_flags = "wait";
status = "disabled";
};
system {
compatible = "android,system";
dev = "/dev/block/platform/soc/7464900.sdhci/by-name/system";
type = "ext4";
mnt_flags = "ro,barrier=1,discard";
fsmgr_flags = "wait[B][COLOR="Red"],verify[/COLOR][/B]";
status = "ok";
};
};
};
};
Removed ,verify and conveted back to dtb. Gonna test it out (report you back later)!
Thank you!

i have a one plus 5T and i dont see an DTB files in the boot.img
can someone post a walk through on how to do this manually without magisk or supersu?
i know i can modify the fstab in system/vendor/etc
but what are the dtb files exactly? and where are they located / how are they extracted?

virtyx said:
i have a one plus 5T and i dont see an DTB files in the boot.img
can someone post a walk through on how to do this manually without magisk or supersu?
i know i can modify the fstab in system/vendor/etc
but what are the dtb files exactly? and where are they located / how are they extracted?
Click to expand...
Click to collapse
DTB are Device Tree Blobs / Binary and not files. These are appended to the kernel in the boot.img.
On Ubuntu, you can install dtc (device tree compiler ...Refer http://manpages.ubuntu.com/manpages/...an1/dtc.1.html ) to handle conversion from dtb to dts or vice versa.
You can also hex edit the boot.img and delete the text ",verify" at each instance it is found. Or use Linux command line to do that if you're familiar with that.
Sorry, don't have the spare time right now to write a detailed walk through. Maybe this weekend.

rk2612 said:
DTB are Device Tree Blobs / Binary and not files. These are appended to the kernel in the boot.img.
On Ubuntu, you can install dtc (device tree compiler ...Refer http://manpages.ubuntu.com/manpages/...an1/dtc.1.html ) to handle conversion from dtb to dts or vice versa.
You can also hex edit the boot.img and delete the text ",verify" at each instance it is found. Or use Linux command line to do that if you're familiar with that.
Sorry, don't have the spare time right now to write a detailed walk through. Maybe this weekend.
Click to expand...
Click to collapse
thank you
is it possible to extracat the DTB files on a windows machine?
i know after OS install the fstab is located at /system/etc/vendor which we can edit before first boot
but id prefer to edit the DTB files in the boot, and add mounting flags for each partition.

virtyx said:
thank you
is it possible to extracat the DTB files on a windows machine?
i know after OS install the fstab is located at /system/etc/vendor which we can edit before first boot
but id prefer to edit the DTB files in the boot, and add mounting flags for each partition.
Click to expand...
Click to collapse
I didn't look around for a windows tool to extract DTBs.
In Oreo, fstab file contains the mount points for all other partitions except /system and you can edit the fstab file as in previous android versions. The only partition which is mounted early through the DTBs is /system and you will see that the /system mount entry in fstab is commented out as that is not needed.
To mount /system with verity disabled, you will need to remove the flag "verify" from the DTBs. I'm attaching a text version of one of the 13 DTBs contained in OnePlus 3's boot image as an example. You will notice the following code
Code:
fsmgr_flags = "wait,verify"
...and you need to remove ",verify" to make it
Code:
fsmgr_flags = "wait"
To remove ",verify" from the DTBs, you can either:
1. Hex edit the boot image but this will leave the verity key in the ramdisk (...may work but I haven't tried).
2. (a) Unpack the boot image; (b) hex edit the kernel (to which dtbs are appended) and remove ",verify"; (c) extract ramdisk and remove verity.key; (d) repack ramdisk; and (e) repack the boot image: should work
3. (a) Unpack the boot image, (b) extract the dtb appended to kernel / zImage; (c) convert the dtb to dts (text format); (d) text edit the dts to remove ",verify"; (e) then reconvert dts to dtb; (f) append all the modified dtbs to the kernel; and finally (g) repack the boot image (...also remove the verity.key from the ramdisk before repacking the boot image): this would be the cleanest approach but more cumbersome.
Tools needed on Ubuntu machine with Python installed:
1. Unpack and repack boot image: use unpackbootimg and mkbootimg scripts (Python) from lineageos code: https://github.com/LineageOS/android_system_core/tree/cm-14.1/mkbootimg
2. Extract kernel and dtbs using python script: https://github.com/PabloCastellano/extract-dtb
3. Convert dtb to dts and back: use Ubuntu package dtc: http://manpages.ubuntu.com/manpages/xenial/man1/dtc.1.html

rk2612 said:
I didn't look around for a windows tool to extract DTBs.
In Oreo, fstab file contains the mount points for all other partitions except /system and you can edit the fstab file as in previous android versions. The only partition which is mounted early through the DTBs is /system and you will see that the /system mount entry in fstab is commented out as that is not needed.
To mount /system with verity disabled, you will need to remove the flag "verify" from the DTBs. I'm attaching a text version of one of the 13 DTBs contained in OnePlus 3's boot image as an example. You will notice the following code
Code:
fsmgr_flags = "wait,verify"
...and you need to remove ",verify" to make it
Code:
fsmgr_flags = "wait"
To remove ",verify" from the DTBs, you can either:
1. Hex edit the boot image but this will leave the verity key in the ramdisk (...may work but I haven't tried).
2. (a) Unpack the boot image; (b) hex edit the kernel (to which dtbs are appended) and remove ",verify"; (c) extract ramdisk and remove verity.key; (d) repack ramdisk; and (e) repack the boot image: should work
3. (a) Unpack the boot image, (b) extract the dtb appended to kernel / zImage; (c) convert the dtb to dts (text format); (d) text edit the dts to remove ",verify"; (e) then reconvert dts to dtb; (f) append all the modified dtbs to the kernel; and finally (g) repack the boot image (...also remove the verity.key from the ramdisk before repacking the boot image): this would be the cleanest approach but more cumbersome.
Tools needed on Ubuntu machine with Python installed:
1. Unpack and repack boot image: use unpackbootimg and mkbootimg scripts (Python) from lineageos code: https://github.com/LineageOS/android_system_core/tree/cm-14.1/mkbootimg
2. Extract kernel and dtbs using python script: https://github.com/PabloCastellano/extract-dtb
3. Convert dtb to dts and back: use Ubuntu package dtc: http://manpages.ubuntu.com/manpages/xenial/man1/dtc.1.html
Click to expand...
Click to collapse
ah i see
i guess i should really dual boot this machine haha
i found the mounting options in hex editor for the boot.img (/system and /vendor, i think 13 instances of both)
also the verity.key can be delete when unpacking the boot.img and repacking it with no verity.key.
thank you, i think im able to modify it on a windows machine, ill try it out as soon as a stable oreo comes out for the 1+5T

I already have the dtb edited. how can I add them back to the zImage or the boot.img?
Thank you very much

kenet said:
I already have the dtb edited. how can I add them back to the zImage or the boot.img?
Thank you very much
Click to expand...
Click to collapse
Actually the appending should be done like
Code:
cat zImage [I][U]<DTB_FILE_NAME>[/U][/I].dtb > zImage-dtb
So you can get a zImage with dtb