[MOD] Bootimage ADB Unsecure Patcher

[AdrianDC]

#include <std_disclaimer.h>
/*
 * Your warranty is now void.
 *
 * I am not responsible for bricked devices, dead SD cards,
 * thermonuclear war, or you getting fired because the alarm app failed. Please
 * do some research if you have any concerns about features included in this ROM
 * before flashing it! YOU are choosing to make these modifications, and if
 * you point the finger at me for messing up your device, I will laugh at you.
 */

Bootimage ADB Unsecure Patcher

Android Bootimage ADB Unsecure Patcher is made to ease the development of ROMs.
Its purpose is to modify the ramdisk to set ADB into an unsecure mode,
in order to debug Android ROMs on clean / bringup boots without doing an 'eng' build.
It means adb can be used without any permissions to run logcat or other commands.

The project implements the logic from the MultiROM injection (originally by Tasssadar),
finds the bootimage of your device (boot naming similar to Chainfire's boot detection),
and applies the needed modifications to the ramdisk's default.prop configurations.

The objective of Bootimage ADB Unsecure Patcher is therefore to simply enable unsecure adb
on a regular ROM's bootimage for developers and users who would require it.

Developers no longer need to recompile a bootimage or full ROM with 'eng' pressets,
nor do users need to edit their bootimages with unsecure adb settings if they really need it.

The patcher needs to be flashed again after a ROM / bootimage update.

This is originally based on my bootimagedebuggable function from android_development_shell_tools.
The project also uses my version of libbootimg to support Sony ELF bootimages.​

Bootimage Debug Addition Patcher

Another part was added to this project: Bootimage Debug Addition allows developers
to debug unbootable Android builds by providing the following items:

• Complete logcat service to /data/debug.logcat.txt
• Kernel messages exported to /data/debug.kernel.txt
• Runtime properties to /data/debug.properties.txt
• Detailed tree of / to /data/debug.roottree.txt

Rebooting to recovery and reading the file contents can help resolving issues rather than guessing.
The patcher is called "bootimage_debug_addition", while the revert is called "bootimage_debug_removal".

For builds running with enforced sepolicies, you might need to flash Universal Kernel Permissive Patcher too.​

Downloads (Unlocked Bootloader only)

bootimage_adb_secure.zip : https://github.com/AdrianDC/bootimage_adb_patcher/blob/master/release/bootimage_adb_secure.zip
bootimage_adb_unsecure.zip : https://github.com/AdrianDC/bootimage_adb_patcher/blob/master/release/bootimage_adb_unsecure.zip
bootimage_debug_addition.zip : https://github.com/AdrianDC/bootimage_adb_patcher/blob/master/release/bootimage_debug_addition.zip
bootimage_debug_removal.zip : https://github.com/AdrianDC/bootimage_adb_patcher/blob/master/release/bootimage_debug_removal.zip​

Other related useful projects

Universal Kernel Permissive Patcher - http://forum.xda-developers.com/-/-t3506338​

Source code

Project sources - https://github.com/AdrianDC/bootimage_adb_patcher (branch master)
libbootimg sources - https://github.com/multirom-dev/libbootimg (branch master)​

Bootimage ADB Unsecure Patcher created also thanks to :

- Tasssadar for the original MultiROM sources
- The MultiROM-Dev team for our evolution of MultiROM
- Chainfire for the boot detection
- Everyone involved in testing it​

XDA:DevDB Information
Bootimage ADB Unsecure Patcher, Tool/Utility for the Android General

Contributors
AdrianDC

Version Information
Status: No Longer Updated

Created 2017-06-07
Last Updated 2019-08-06

 

[AdrianDC]

Reserved

Changelog

Bootimage Debug Addition Patcher - 12/06/2017
===========================================
* Complete logcat service to /data/debug.logcat.txt
* Kernel messages exported to /data/debug.kernel.txt
* Runtime properties to /data/debug.properties.txt
* Detailed tree of / to /data/debug.roottree.txt

Bootimage Debug Addition Patcher - 11/06/2017
===========================================
* Initial public release on XDA

Bootimage ADB Unsecure Patcher - 11/06/2017
===========================================
* Update release to support Oreo system default properties

Bootimage ADB Unsecure Patcher - 05/06/2017
===========================================
* Initial public release on XDA

 

[kirito9]

Nice work, any chance adding support for MTK devices with /dev/bootimg path? The boot detection by chainfire doesn't detect it. Any other information you need I can provide.

 

[AdrianDC]

Nice work, any chance adding support for MTK devices with /dev/bootimg path? The boot detection by chainfire doesn't detect it. Any other information you need I can provide.

I never had to work on MTK devices for now.
Is it only a question of different path, with a regular !ANDROID bootimage structure, or something else specifically to handle ?

If only the path, can easily be added. Please try the versions I pushed on a separate "staging" branch and let me know.
If valid, I can do the same for Kernel Permissive Patcher too.

 

[kirito9]

I never had to work on MTK devices for now.
Is it only a question of different path, with a regular !ANDROID bootimage structure, or something else specifically to handle ?

If only the path, can easily be added. Please try the versions I pushed on a separate "staging" branch and let me know.
If valid, I can do the same for Kernel Permissive Patcher too.

It's the path and also requires an mtk header appended to the boot.img or it won't boot. I'll try the separate versions.

 

[kirito9]

I never had to work on MTK devices for now.
Is it only a question of different path, with a regular !ANDROID bootimage structure, or something else specifically to handle ?

If only the path, can easily be added. Please try the versions I pushed on a separate "staging" branch and let me know.
If valid, I can do the same for Kernel Permissive Patcher too.

The path you added helped me figure out how to allow Chainfire's boot detection can be used to detect the dev/bootimg. I had to modify it like bootimg BOOTIMG as I saw the others like that.

So boot image detection is working but I don't think your binary file can unpack the MTK bootimage or it could be another error. There's not enough logging to say at which point the script fails.

Magisk also uses Chainfire's boot detection so I was also able to add the dev/bootimg path to the Magisk script and it got to the point of the unpacking as well. It also doesn't support this MTK boot.img.

@osm0sis was able to use his mkmtkhdr binary to support the unpacking/repacking of this particular boot.img. Maybe implementing in some way can add support for my device :fingers-crossed:.

 

[AdrianDC]

I was expecting this.
It means (without much surprise) that our MultiROM libbootimg was never ported for and used on an MTK device.

A year ago I added full support for Sony ELF bootimages structures.
You might want to look into it and see if you can identify what's needed for MTK.

However if it's a lot to do / change, as we never needed it and none of us owning an MTK,
I'm not sure it'd be done, especially only for a Dev helper tool rather than MultiROM itself.

At least you can check what I do in my scripts and apply the same thing to a decompiled mtk bootimage.

 

[drei.liter.milch]

I was expecting this.
It means (without much surprise) that our MultiROM libbootimg was never ported for and used on an MTK device.

A year ago I added full support for Sony ELF bootimages structures.
You might want to look into it and see if you can identify what's needed for MTK.

However if it's a lot to do / change, as we never needed it and none of us owning an MTK,
I'm not sure it'd be done, especially only for a Dev helper tool rather than MultiROM itself.

At least you can check what I do in my scripts and apply the same thing to a decompiled mtk bootimage.

MTK-support would be great..

 

[kirito9]

I was expecting this.
It means (without much surprise) that our MultiROM libbootimg was never ported for and used on an MTK device.

A year ago I added full support for Sony ELF bootimages structures.
You might want to look into it and see if you can identify what's needed for MTK.

However if it's a lot to do / change, as we never needed it and none of us owning an MTK,
I'm not sure it'd be done, especially only for a Dev helper tool rather than MultiROM itself.

At least you can check what I do in my scripts and apply the same thing to a decompiled mtk bootimage.

If it isn't a challenge then it isn't fun . I'll try to see if I can follow what was done for the libbootimg and see if I can get what is needed for MTK.

Also the libbootimg sources in the first post link needs changing to this libbootimg.

 

[gerald017]

this is great its making life easier

 

[Moyster]

The path you added helped me figure out how to allow Chainfire's boot detection can be used to detect the dev/bootimg. I had to modify it like bootimg BOOTIMG as I saw the others like that.

So boot image detection is working but I don't think your binary file can unpack the MTK bootimage or it could be another error. There's not enough logging to say at which point the script fails.

Magisk also uses Chainfire's boot detection so I was also able to add the dev/bootimg path to the Magisk script and it got to the point of the unpacking as well. It also doesn't support this MTK boot.img.

@osm0sis was able to use his mkmtkhdr binary to support the unpacking/repacking of this particular boot.img. Maybe implementing in some way can add support for my device :fingers-crossed:.

MTK boot.img headers are only for old mt65xx, that's not needed on newer mtk platforms I think you should consider making a mt65xx specific version of this tool (great tool btw, was looking for something similar ) because it's only (no offense) useful for a couple people still working on mt65xx (and mt65xx with 3.4 will probably never see Ng/Oc due to the egl/mali blobs crashing asap as devices enter suspend).

I was expecting this.
It means (without much surprise) that our MultiROM libbootimg was never ported for and used on an MTK device.

A year ago I added full support for Sony ELF bootimages structures.
You might want to look into it and see if you can identify what's needed for MTK.

However if it's a lot to do / change, as we never needed it and none of us owning an MTK,
I'm not sure it'd be done, especially only for a Dev helper tool rather than MultiROM itself.

At least you can check what I do in my scripts and apply the same thing to a decompiled mtk bootimage.

Mtk got a lot better, kirito has a mt65xx device as far as I know, most if not all platforms after mt6592 (meizu mx4 period) have vanilla boot.img, I'm pretty sure I saw some mtk devices (mt67xx) use MultiROM, so there shouldn't be any need for modifications (except for old undev'ed mt65xx SoCs)

 

[iamfarhanansari]

I was expecting this.
It means (without much surprise) that our MultiROM libbootimg was never ported for and used on an MTK device.

A year ago I added full support for Sony ELF bootimages structures.
You might want to look into it and see if you can identify what's needed for MTK.

However if it's a lot to do / change, as we never needed it and none of us owning an MTK,
I'm not sure it'd be done, especially only for a Dev helper tool rather than MultiROM itself.

At least you can check what I do in my scripts and apply the same thing to a decompiled mtk bootimage.

Can you explain in simple language
What is this for.
Someone suggest me to flash this as my phone (codename merlin) was not booting after flashing somefeak kernel

 

[bigrammy]

Mtk got a lot better, kirito has a mt65xx device as far as I know, most if not all platforms after mt6592 (meizu mx4 period) have vanilla boot.img, I'm pretty sure I saw some mtk devices (mt67xx) use MultiROM, so there shouldn't be any need for modifications (except for old undev'ed mt65xx SoCs)

Yes your correct 98% of MTK devices now use the standard format boot.img.
There are exceptions like the Lenovo TAB 2 A10-70 but it's a pretty easy process convert the old format .img to the newer one and they still work just fine on device. Converting my Sony C4 from a 64bit .ELF to a standard format boot.img was a little more challenging but I got there in the end.
If you need any help @kirito9 converting your boot.img to the standard format drop me a PM :good:

 

[Moyster]

Yes your correct 98% of MTK devices now use the standard format boot.img.
There are exceptions like the Lenovo TAB 2 A10-70 but it's a pretty easy process convert the old format .img to the newer one and they still work just fine on device. Converting my Sony C4 from a 64bit .ELF to a standard format boot.img was a little more challenging but I got there in the end.
If you need any help @kirito9 converting your boot.img to the standard format drop me a PM :good:

Ha, sorry I didn't mention mtk tablets because I'm so lost with their mt81xx / mt76xx mt89xx, tho a10-70 ran with a mt8165 which is the 2014 generation (around mt6752 release, then they later refreshed their socs and release the mt6753/35 in 2015).
Most if not all mtk SoCs released after 2015/mt67xx work fine on vanilla boot.img, mt65xx and mt81xx (which are =<2014), still needs it

Since OP tool works fine, the only "really needed" thing is a small software to convert vanilla boot.img <-> mediatek headers boot.img, this way if you want to use OP tool with an old mediatek kernel, all it takes is to pre-convert / reconvert (actually, using any kitchen supporting mtk headers to unpack / repack old mtk kernels works just fine, not sure if there's a need for a dedicated tool )

 

[bigrammy]

Ha, sorry I didn't mention mtk tablets because I'm so lost with their mt81xx / mt76xx mt89xx, tho a10-70 ran with a mt8165 which is the 2014 generation (around mt6752 release, then they later refreshed their socs and release the mt6753/35 in 2015).
Most if not all mtk SoCs released after 2015/mt67xx work fine on vanilla boot.img, mt65xx and mt81xx (which are =<2014), still needs it

Since OP tool works fine, the only "really needed" thing is a small software to convert vanilla boot.img <-> mediatek headers boot.img, this way if you want to use OP tool with an old mediatek kernel, all it takes is to pre-convert / reconvert (actually, using any kitchen supporting mtk headers to unpack / repack old mtk kernels works just fine, not sure if there's a need for a dedicated tool )

You sure do your homework Moyster 100% correct :laugh:
I agree the OP should not have to alter their code to support the <2014 boot.img when it's so easy to convert it to a standard/vanilla format. :good:

:highfive:

 

[CosmicDan]

Necro post!

Is anybody still using this for modern devices (Oreo) and it still works for adb on boot for initial bring up? Would save me reinventing the wheel if so, I have some porting work ahead of me.

 

[AdrianDC]

Necro post!

Is anybody still using this for modern devices (Oreo) and it still works for adb on boot for initial bring up? Would save me reinventing the wheel if so, I have some porting work ahead of me.

I always am while doing debugging & testings.

I released an update today on something I'm currently working upon, it adds Oreo support for most of the "recent" devices,
feel free to go along and test it, and to participate in the sources if you need something additional.

I also added a new part to the project, meant to ease unbooting builds debugging by automatically logging to /data/logcat.txt as a service.
We often do it manually for development purposes but let's do it automatically for anyone who would need it.

 

[CosmicDan]

I always am while doing debugging & testings.

I released an update today on something I'm currently working upon, it adds Oreo support for most of the "recent" devices,
feel free to go along and test it, and to participate in the sources if you need something additional.

I also added a new part to the project, meant to ease unbooting builds debugging by automatically logging to /data/logcat.txt as a service.
We often do it manually for development purposes but let's do it automatically for anyone who would need it.

Cool stuff. I also compiled a "god mode" adbd binary that I can inject to initramfs, the idea being that it runs as root even on user builds, but for some reason it doesn't work on Oreo anymore. Might just need to update my sources for 8.1 or something, or I missed a compiler flag somewhere, but I'm thinking the init might not be actually running adbd in the right permissions. Tried anything like that?

 

[jimbo1qaz]

Moto g5 plus, stock rom 7.0 + magisk 16.6. When connecting I get error:

error: device unauthorized.
This adb server's $ADB_VENDOR_KEYS is not set
Try 'adb kill-server' if that seems wrong.
Otherwise check for a confirmation dialog on your device.

 

[AnonVendetta]

@CosmicDan: Would you mind uploading a patched standalone adbd god mode binary? I Googled your name like "adbd god cosmicdan", only found some references on XDA and GitHub, but they appear to be device-specific. Would such a binary be universal (work on all commonly used CPU architectures/Android versions)? I think your patch is for ARM64, and I do own 2 ARM64 devices, but also a handful of older phones that are armv7a/32 bit.

Thanks!