[MOD] Bootimage ADB Unsecure Patcher

Search This thread

AdrianDC

Recognized Developer
Dec 22, 2009
2,206
12,950
Île-de-France
adriandc.github.io
logo.png


Code:
#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)



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

Recognized Developer
Dec 22, 2009
2,206
12,950
Île-de-France
adriandc.github.io
Reserved

Changelog
Code:
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
 
Last edited:

kirito9

Inactive Recognized Contributor
Oct 30, 2013
3,125
1,355
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

Recognized Developer
Dec 22, 2009
2,206
12,950
Île-de-France
adriandc.github.io
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.
 
  • Like
Reactions: ze7zez

kirito9

Inactive Recognized Contributor
Oct 30, 2013
3,125
1,355
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

Inactive Recognized Contributor
Oct 30, 2013
3,125
1,355
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:.
 
Last edited:

AdrianDC

Recognized Developer
Dec 22, 2009
2,206
12,950
Île-de-France
adriandc.github.io
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

Senior Member
Dec 27, 2016
155
76
Mönchengladbach
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..
 
  • Like
Reactions: Fedroid

kirito9

Inactive Recognized Contributor
Oct 30, 2013
3,125
1,355
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 :p. 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.
 
Last edited:
  • Like
Reactions: Professor Woland

Moyster

Senior Member
Aug 25, 2016
306
1,448
github.com
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 :D) 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

Senior Member
Apr 11, 2016
709
481
20
pratapgarh
plus.google.com
Xiaomi Poco X2
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

Senior Member
Apr 8, 2011
2,933
2,542
huddersfield
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. :D
If you need any help @kirito9 converting your boot.img to the standard format drop me a PM :good:
 
  • Like
Reactions: kirito9

Moyster

Senior Member
Aug 25, 2016
306
1,448
github.com
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. :D
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 :p )
 

bigrammy

Senior Member
Apr 8, 2011
2,933
2,542
huddersfield
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 :p )
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

Senior Member
Jun 19, 2009
5,855
7,685
34
Sydney
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

Recognized Developer
Dec 22, 2009
2,206
12,950
Île-de-France
adriandc.github.io
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

Senior Member
Jun 19, 2009
5,855
7,685
34
Sydney
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

Member
Jan 28, 2012
45
3
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

Senior Member
Apr 29, 2016
858
321
Portland, OR
@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!
 

Top Liked Posts

  • There are no posts matching your filters.
  • 38
    logo.png


    Code:
    #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)



    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
    6
    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.
    5
    Reserved

    Changelog
    Code:
    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
    5
    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 :D) 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)
    4
    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:.
Our Apps
Get our official app!
The best way to access XDA on your phone
Nav Gestures
Add swipe gestures to any Android
One Handed Mode
Eases uses one hand with your phone