FORUMS
Remove All Ads from XDA

[MOD] Bootimage ADB Unsecure Patcher

2,161 posts
Thanks Meter: 12,646
 
By AdrianDC, Recognized Developer on 7th June 2017, 09:28 PM
Post Reply Email Thread


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)
bootimage_adb_secure.zip : https://github.com/AdrianDC/bootimag...adb_secure.zip
bootimage_adb_unsecure.zip : https://github.com/AdrianDC/bootimag...b_unsecure.zip
bootimage_debug_addition.zip : https://github.com/AdrianDC/bootimag...g_addition.zip
bootimage_debug_removal.zip : https://github.com/AdrianDC/bootimag...ug_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
The Following 34 Users Say Thank You to AdrianDC For This Useful Post: [ View ]
 
 
7th June 2017, 09:28 PM |#2  
AdrianDC's Avatar
OP Recognized Developer
Flag Île-de-France
Thanks Meter: 12,646
 
More
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
The Following 4 Users Say Thank You to AdrianDC For This Useful Post: [ View ]
8th June 2017, 02:30 PM |#3  
kirito9's Avatar
Recognized Contributor
Thanks Meter: 1,344
 
More
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.
8th June 2017, 11:21 PM |#4  
AdrianDC's Avatar
OP Recognized Developer
Flag Île-de-France
Thanks Meter: 12,646
 
More
Quote:
Originally Posted by 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.

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 Following User Says Thank You to AdrianDC For This Useful Post: [ View ]
9th June 2017, 01:51 AM |#5  
kirito9's Avatar
Recognized Contributor
Thanks Meter: 1,344
 
More
Quote:
Originally Posted by AdrianDC

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.
9th June 2017, 02:43 PM |#6  
kirito9's Avatar
Recognized Contributor
Thanks Meter: 1,344
 
More
Quote:
Originally Posted by AdrianDC

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 .
The Following 4 Users Say Thank You to kirito9 For This Useful Post: [ View ] Gift kirito9 Ad-Free
9th June 2017, 04:14 PM |#7  
AdrianDC's Avatar
OP Recognized Developer
Flag Île-de-France
Thanks Meter: 12,646
 
More
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.
The Following 4 Users Say Thank You to AdrianDC For This Useful Post: [ View ]
9th June 2017, 04:59 PM |#8  
Senior Member
Flag Mönchengladbach
Thanks Meter: 74
 
More
Quote:
Originally Posted by 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.

MTK-support would be great..
The Following User Says Thank You to drei.liter.milch For This Useful Post: [ View ] Gift drei.liter.milch Ad-Free
9th June 2017, 05:53 PM |#9  
kirito9's Avatar
Recognized Contributor
Thanks Meter: 1,344
 
More
Quote:
Originally Posted by 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.

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.
The Following User Says Thank You to kirito9 For This Useful Post: [ View ] Gift kirito9 Ad-Free
9th June 2017, 11:47 PM |#10  
Junior Member
Thanks Meter: 2
 
More
this is great its making life easier
The Following User Says Thank You to gerald017 For This Useful Post: [ View ] Gift gerald017 Ad-Free
25th June 2017, 04:55 PM |#11  
Senior Member
Thanks Meter: 1,447
 
More
Quote:
Originally Posted by kirito9

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 .

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).

Quote:
Originally Posted by 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.

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)
The Following 5 Users Say Thank You to Moyster For This Useful Post: [ View ] Gift Moyster Ad-Free
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes