Database Info

Signing boot images for Android Verified Boot (AVB) [v8]

Various Android devices support Android Verified Boot (AVB). A part of this is more commonly known as dm-verity, which verifies system (and vendor) partition integrity. AVB can however also verify boot images, and stock firmwares generally include signed boot images. Of course this does not mean that all signed boot images are using AVB, many OEMs have their own signature verification scheme.
Note: AOSP is moving towards the use of avbtool (taken from Brillo), the following is the old way for signing boot images.
Bootloaders might or might not accept unsigned boot images, and might or might not accept boot images signed with our own keys (rather than the OEM's keys). This depends on the device, bootloader version, and bootloader unlock state.
For example, with the bootloader unlocked, the Google Pixel (and XL) devices accepted unsigned boot images up to (but not including) the May 2017 release. From the May 2017 release onwards, the boot images must be signed if flashed (booted works without), but may be signed with your own key rather than the OEM's.
Note: The situation changes when you re-lock the bootloader. I have not tested this, but documentation implies that (one of) the keys used in the current boot image must be used for future flashes until it is unlocked again.
Generating custom signing keys
The following openssl commands generate all the keys we need. Execute them line-by-line rather than copying the whole block, as you will be asked for input.
Code:
# private key
openssl genrsa -f4 -out verifiedboot.pem 2048
openssl pkcs8 -in verifiedboot.pem -topk8 -outform DER -out verifiedboot.pk8 -nocrypt
# public key
openssl req -new -x509 -sha256 -key verifiedboot.pem -out verifiedboot.x509.pem
openssl x509 -outform DER -in verifiedboot.x509.pem -out verifiedboot.x509.der
For future signings, you do not need the .pem files, and they can safely be deleted once the .pk8 and .der files are generated. In AOSP's implementation, they were never even written to disk in the first place.
Security-wise, documentation states it is advisable to use a different set of keys for each device you support; though obviously this doesn't matter much if the device is running with the bootloader in unlocked state.
Signing the boot image
Download the attached BootSignature.jar file (built from AOSP sources), and sign the boot image using the keys generated above with the following commands:
Code:
java -jar BootSignature.jar /boot boot.img verifiedboot.pk8 verifiedboot.x509.der boot_signed.img
java -jar BootSignature.jar -verify boot_signed.img
Instead of /boot, /recovery and other values may be used. Their use should be obvious.
From Android
Attached is also BootSignature_Android.jar, which is a version ProGuard-reduced against SDK 21 and then dexed. Provided /system is mounted as is usual on Android (on the Pixel (XL), TWRP mounts this differently by default!), it can be used like this:
Code:
dalvikvm -cp BootSignature_Android.jar com.android.verity.BootSignature /boot boot.img verifiedboot.pk8 verifiedboot.x509.der boot_signed.img
dalvikvm -cp BootSignature_Android.jar com.android.verity.BootSignature -verify boot_signed.img
The base command can be extended as follows to make it able to run without any precompiled files present on the device:
Code:
/system/bin/dalvikvm -Xbootclasspath:/system/framework/core-oj.jar:/system/framework/core-libart.jar:/system/framework/conscrypt.jar:/system/framework/bouncycastle.jar -Xnodex2oat -Xnoimage-dex2oat -cp BootSignature_Android.jar com.android.verity.BootSignature ...
Flashable ZIP
Attached is also VerifiedBootSigner.zip, this is a flashable ZIP for FlashFire/TWRP/etc that signs the currently flashed boot image, if it isn't signed already. You can simply flash this after installing a SuperSU version or custom boot image or whatever that doesn't sign the boot image itself already.
I've tried to make it very portable (borrowing ample script from the SuperSU ZIP, as well as its signing keys), but I have only tested it on my Pixel XL.
Note that it does depend on Android files in the system partition, so if (aside from the unsigned boot image) your system isn't functional, the ZIP may not work either.
If the boot image is already signed when you flash the ZIP, it will offer to abort or force re-sign.
If you place custom.pk8 and custom.x509.der files inside the ZIP, these keys will be used for flashing instead of SuperSU's default keys. Additionally, /tmp/avb/custom.pk8 and /tmp/avb/custom.x509.der will override any keys from the ZIP.
There is some more documentation in the update-binary file inside the ZIP as well.
Note: If you're using TWRP's manual slot selection on the Pixel (XL), you must be using TWRP-v3.1.0-RC2 or newer, or it will not work as expected.
Todo
- test what happens when the bootloader is re-locked on multiple devices supporting AVB
- test what happens when dm-verity is kept enabled on a custom/modified boot image with a different image signature than dm-verity signature

-reserved-
*finally my dream come true, btw, nice job on doing this, keep it up man*

Super great

Great write up! So I take it we can no longer distribute kernel images without first integrating them into the boot image and then signing it? That negates the whole point of being able to flash the kernel individually with fastboot!

thank God Chanifire hasnt left us entirely!!!

This gives me hope my Pixel isn't dev dead. Thank you, CF!

@Chainfire you not going to reply but still, you are responsible i have faith in Android... Development is most of the times happens because of you ....It always revolves around you ... One man army i would say. Thank you for all your works. We all owe you a lot...

Is it possible to create the signature for boot bundle with openssl alone (i.e. without this BootSignature.jar ) ?

Wasn't self-signing boot images already kind of possible?

cr2 said:
Is it possible to create the signature for boot bundle with openssl alone (i.e. without this BootSignature.jar ) ?
Click to expand...
Click to collapse
Not just with openssl, no. How the boot signature works is not properly documented, but of course you could read the source in AOSP and make your own version.
mirhl said:
Wasn't self-signing boot images already kind of possible?
Click to expand...
Click to collapse
Apart from both of these things talking about signatures, they are unrelated. However, self-signing images has been supported for quite a while on several devices, it just wasn't required. CopperheadOS - as far as I know - is the only project that has actively been using it until now.

is it possible to sign the boot image in recovery?
Hi @Chainfire ! Thank you for this great find (and for everything else what you have done for us during the last years )!!
I would like to ask one question... Do you think it would be possible to sign the boot image on the fly in recovery? For example when changing the recovery image, before flashing the boot image back?
Your instructions use "dalvikvm" on android, and I ran the command successfully under a running android system. But what about recovery ?
I would be interested in your thoughts on this
Or am I completely wrong, and images "dumped" via dd can't be signed and flashed back?
I would really appreciate if you could point me in the right direction, how it could be possible to do this. (create an executable instead of the BootSignature.jar file? leave this, because it is not possible? start a java vm under recovery? ....)
Thanks in advance!

gubacsek said:
Hi @Chainfire ! Thank you for this great find (and for everything else what you have done for us during the last years )!!
I would like to ask one question... Do you think it would be possible to sign the boot image on the fly in recovery? For example when changing the recovery image, before flashing the boot image back?
Your instructions use "dalvikvm" on android, and I ran the command successfully under a running android system. But what about recovery ?
I would be interested in your thoughts on this
Or am I completely wrong, and images "dumped" via dd can't be signed and flashed back?
I would really appreciate if you could point me in the right direction, how it could be possible to do this. (create an executable instead of the BootSignature.jar file? leave this, because it is not possible? start a java vm under recovery? ....)
Thanks in advance!
Click to expand...
Click to collapse
Yes, this is possible - I have already tested this on my PIxel XL. SuperSU ZIP will do exactly this in a future update, and @Dees_Troy is also aware of all of this, so I assume TWRP will be updated to do this sooner or later as well.
If I can find the time I'll make a ZIP that does this.

Chainfire said:
Yes, this is possible - I have already tested this on my PIxel XL. SuperSU ZIP will do exactly this in a future update, and @Dees_Troy is also aware of all of this, so I assume TWRP will be updated to do this sooner or later as well.
If I can find the time I'll make a ZIP that does this.
Click to expand...
Click to collapse
Okay! I am very curious about how you solve it... Until then, I'll experiment a bit further
Can't wait to see your result!
Thanks! And have a very nice weekend!

I have attached a flashable ZIP to the opening post. Just flash it after SuperSU / custom boot image / whatever to fix the current boot image.
gubacsek said:
Okay! I am very curious about how you solve it... Until then, I'll experiment a bit further Can't wait to see your result!
Click to expand...
Click to collapse

Chainfire said:
I have attached a flashable ZIP to the opening post. Just flash it after SuperSU / custom boot image / whatever to fix the current boot image.
Click to expand...
Click to collapse
Thank you so much, it worked beautifully on my VZW Pixel with the May update.

:good: working fine on the May update with May bootloader, FK, TWRP and SuperSU
Outstanding as usual!

Chainfire said:
I have attached a flashable ZIP to the opening post. Just flash it after SuperSU / custom boot image / whatever to fix the current boot image.
Click to expand...
Click to collapse
I almost got it I could install TWRP and root but only by signing the boot images on my laptop...
I had a few errors (mounting /system did create a /system/system mount point, and I tried to copy the dalvikvm binary to the zip ), and I wouldn't ever have thought of clearing LD_LIBRARY_PATH
Thank you very much for this solution, and your time spent on this! I learnt a lot today
Nice job!

Chainfire said:
Various Android devices support Android Verified Boot (AVB). A part of this is more commonly known as dm-verity, which verifies system (and vendor) partition integrity. AVB can however also verify boot images, and stock firmwares generally include signed boot images. Of course this does not mean that all signed boot images are using AVB, many OEMs have their own signature verification scheme.
Note: AOSP is moving towards the use of avbtool (taken from Brillo), the following is the old way for signing boot images.
Bootloaders might or might not accept unsigned boot images, and might or might not accept boot images signed with our own keys (rather than the OEM's keys). This depends on the device, bootloader version, and bootloader unlock state.
For example, with the bootloader unlocked, the Google Pixel (and XL) devices accepted unsigned boot images up to (but not including) the May 2017 release. From the May 2017 release onwards, the boot images must be signed if flashed (booted works without), but may be signed with your own key rather than the OEM's.
Note: The situation changes when you re-lock the bootloader. I have not tested this, but documentation implies that (one of) the keys used in the current boot image must be used for future flashes until it is unlocked again.
Generating custom signing keys
The following openssl commands generate all the keys we need. Execute them line-by-line rather than copying the whole block, as you will be asked for input.
For future signings, you do not need the .pem files, and they can safely be deleted once the .pk8 and .der files are generated. In AOSP's implementation, they were never even written to disk in the first place.
Security-wise, documentation states it is advisable to use a different set of keys for each device you support; though obviously this doesn't matter much if the device is running with the bootloader in unlocked state.
Signing the boot image
Download the attached BootSignature.jar file (built from AOSP sources), and sign the boot image using the keys generated above with the following commands:
Instead of /boot, /recovery and other values may be used. Their use should be obvious.
From Android
Attached is also BootSignature_Android.jar, which is a version ProGuard-reduced against SDK 21 and then dexed. Provided /system is mounted as is usual on Android (on the Pixel (XL), TWRP mounts this differently by default!), it can be used like this:
Flashable ZIP
Attached is also VerifiedBootSigner.zip, this is a flashable ZIP for FlashFire/TWRP/etc that signs the currently flashed boot image, if it isn't signed already. You can simply flash this after installing a SuperSU version or custom boot image or whatever that doesn't sign the boot image itself already.
I've tried to make it very portable (borrowing ample script from the SuperSU ZIP, as well as its signing keys), but I have only tested it on my Pixel XL.
Note that it does depend on Android files in the system partition, so if (aside from the unsigned boot image) your system isn't functional, the ZIP may not work either.
Todo
- test what happens when the bootloader is re-locked on multiple devices supporting AVB
- test what happens when dm-verity is kept enabled on a custom/modified boot image with a different image signature than dm-verity signature
Click to expand...
Click to collapse
So are Samsungs latest devices now using this. Reason I ask is because in the S8 and Tab S3 stock firmware there is a META-DATA folder in the AP firmware tar. Inside is a fota.zip containing various folders with all sorts of utilities and files, one of which is BootSignature.jar.
It seems it is required to flash the META-DATA folder with the boot.img in ODIN or it will not boot. So I'm guessing the boot.img is being signed as part of the flashing process?

ashyx said:
So are Samsungs latest devices now using this. Reason I ask is because in the S8 and Tab S3 stock firmware there is a META-DATA folder in the AP firmware tar. Inside is a fota.zip containing various folders with all sorts of utilities and files, one of which is BootSignature.jar.
It seems it is required to flash the META-DATA folder with the boot.img in ODIN or it will not boot. So I'm guessing the boot.img is being signed as part of the flashing process?
Click to expand...
Click to collapse
Possibly. Which S8 are you talking about? I thought there was already working TWRP for S8 Exynos that didn't require anything special?

Chainfire said:
Possibly. Which S8 are you talking about? I thought there was already working TWRP for S8 Exynos that didn't require anything special?
Click to expand...
Click to collapse
New S8. Qualcomm Snapdragon 835 MSM8998 bootloader locked versions.
It's got an eng kernel available, but it's a no go with your s7 script due to no adb write access.
https://forum.xda-developers.com/galaxy-s8/how-to/rd-carrier-switch-root-snapdragon-t3597473/page54

[Patch] Persistent automatic disabling SELinux in any kernel

Warning: SELinux – important security feature.
After disabling it you obliviously make Android less secure. Use it on your own risk.
Why it needed?
SELinux can prevent work some mods, like Viper. Or you can have own reasons.
Executing in Terminal "setenforce 0" or via scripts / apps turns SELinux off only after booting: this is not good.
This solution disables SELinux directly in kernel.
Compatible with any MIUI or custom ROM.
How it works
After flashing ZIP creates kernel dump, then it repacks with new command line androidboot.selinux=permissive and writes back.
Into /system/bin copied script.sh and two binaries: mkbootimg and unpackbootimg plus auto-restore script (addon.d)
Last required for keeping and launching that files at every ROM update. This works only on custom ROM's, on MIUI you need re-apply patch manually.
Note: on previous phone at some rare unknown conditions after updating ROM kernel repackaging ended with error and device can't boot.
In this case enter recovery and restore boot from backup or flash boot.img from ROM via fastboot / TWRP.
How to install
1. Once flash attached ZIP
2. Then flash required mods
How to delete
1. Delete file /system/addon.d/99-selinux.sh (and other, that belong to mods that not work with SELinux)
2. Flash current ROM
P.S. This patch probably will work on any device (at least with custom ROM because stock kernel can use different structure).
Rare, but may be required change path to boot partition in script.sh: /dev/block/bootdevice/by-name/boot, twice.

Hi does this method still work in Android 10 and newer?
Great job. This is exactly what I was searching for!

lebigmac said:
does this method still work in Android 10 and newer?
Click to expand...
Click to collapse
Very likely, don't know for sure because still on Pie. Try yourself and share result

When I run this command:
Code:
cat /proc/cmdline
I get this result:
Code:
BOOT_IMAGE=/boot/vmlinuz-5.0.0-13-generic root=UUID=XXXXX-XXXX-XXXX-XXXX-XXXXXXXXX ro quiet splash vt.handoff=1
Maybe in Android 10 and newer they moved the androidboot.selinux=permissive parameter to somewhere else kind of like how they moved the system partition into the super image?

lebigmac said:
Maybe in Android 10 and newer they moved parameter to somewhere else
Click to expand...
Click to collapse
Parameter not present by default.
It's not clear if you tried to flash ZIP. If yes and got no result: probably script can't handle changes in boot.img structure because it was created 4 years ago. Try some tool on PC to unpack boot and add line manually.

[PX5][Android 10] Patched recovery

This is the Android 10 recovery image by HCT (version 10.3.1) patched to skip signature checking on .zip files
Tested on MTCE_LM (Eunavi). Use at your own risk
It can be flashed from a root shell (either adb or via terminal emulator) by performing the following steps
1. upload recovery via adb
Code:
adb push hct_recovery_patched.img /sdcard/
2. flash recovery
Code:
# backup current recovery
dd if=/dev/block/by-name/recovery of=/sdcard/recovery_backup.img
# write new recovery
dd if=/sdcard/hct_recovery_patched.img of=/dev/block/by-name/recovery
NOTE: If you do not disable the "flash_recovery" service in /init.rc, AND you have a stock kernel, recovery will be restored to the original version after rebooting.
There are 3 ways to avoid this:
- Flash magisk (or a modified kernel) while in recovery. The patch will then fail to apply and recovery won't be overwritten
- Disable "flash_recovery" by doing "adb remount" and editing /init.rc (comment out the following)
Code:
service flash_recovery /system/bin/install-recovery.sh
class main
oneshot
- Neuter the service by either:
- removing /system/bin/install-recovery.sh​- replacing /system/bin/install-recovery.sh with a dummy script​- removing /system/recovery-from-boot.p​

Woo-hoo, after hundreds of rubbish posts in the MTCD forums, we have a real development post!
Great work and thanks for sharing this, these forums need more like you.

Thanks for the kind comment!
I have to admit that it was frustrating to see the lack of information sharing on this forum, and the pervasive pay-per-use model.
I spent a lot of time just getting Android 10 installed (starting from Android 9), and i had to bring the head unit to my desk as working in the car was rather hard and all i achieved was a brick.
I unfortunately had to bring it back in the car now (can't sit on my desk forever) but, now that i figured out how to make bootable recoveries, i was wondering how hard it could be to have TWRP or at least a hassle-free recovery to install Android 10 from Android 9.
As a first step, this recovery makes it possible to install Magisk or other zip files without doing it manually within adb.
Cheers!

Your work is really good!
Thanks a lot for it.
Now you can also modify ROM's without signatur errors when installing.
Wouldn't it be good if we had an app like the ModInstaller ?
So a one click installation of the recovery without shell or adb.

I have now built an app.
And now need help.
Namely, in the app is the recovery and the script.
Unfortunately, the flash process is not started.
It always comes only the first message from the script.
The app is open source and the script and the recovery are in res/raw.
In the attach you will find the finished app and pictures.
If someone has a solution, he can write me or make a pull request on Github.
Source code:
GitHub - jamal2362/RK33XX-Custom-Recovery-Installer: Application for flashing custom recovery on Rockchip Android Head-Units.
Application for flashing custom recovery on Rockchip Android Head-Units. - GitHub - jamal2362/RK33XX-Custom-Recovery-Installer: Application for flashing custom recovery on Rockchip Android Head-Units.
github.com
The script:
RK33XX-Custom-Recovery-Installer/script at master · jamal2362/RK33XX-Custom-Recovery-Installer
Application for flashing custom recovery on Rockchip Android Head-Units. - RK33XX-Custom-Recovery-Installer/script at master · jamal2362/RK33XX-Custom-Recovery-Installer
github.com

First of all, congrats for the work!
DISCLAIMER:
I don't own ModInstaller, i have never bought a copy of it and i don't intend to do so.
Analysis is purely done from Youtube videos, open source code analysis and existing and openly available binary images.
I was working to figure out how to make a FLOSS alternative to ModInstaller.
The issues i found in all my attempts are the following:
- A6 recovery is the only one that can boot from SD Card (which can then be used to flash A9 -> A10 with the 2SD trick)
- (it took me a long time to pull these information together and unbrick my unit)​- The A6 recovery is unable to directly flash A10 RKAF/RKFW images (sdupdate.img) due to the code being too old
- a failure will be observed while writing super.img. This happens because the device needs to be repartitioned, and the A6 recovery is not doing it correctly​- A9 recovery is buggy. Booting it with no system installed will result in a black screen.
- it will only boot succesfully after being written by the A6 flash tool, which writes the "misc" partition with the recovery commands to run (the "hint" i get from this is that the misc partition is important)​- A10 recovery can't be loaded by the A6 recovery. I always got a black screen after flash. Is it a flash issue? is it an issue with the recovery itself? hard to know
Theory: maybe the recovery could be written over the kernel partition? ("boot")
This way, the recovery will always run after being flashed instead of requiring an explicit "enter recovery" trigger (buttons, misc partition, etc.)
Besides these experiments, in parallel, i did some bug fixing to this repository: https://github.com/liftoff-sr/rockchip-tool/commits/master (i'm "smx-smx")
That allows me to unpack nad repack "sdupdate.img" , "reduced recovery images" and "full IMG files".
With those tools. i tried to swap "recovery.img" in the A6 image, but i always got the black screen upon booting from SD.
Either A9/A10 breaks sdboot or the bootloader crashes before it gets there.
Since this also happens when being flashed, this could either be a bug in the flashing program or a bug in the boot stack (which fails to run recovery perhaps due to a dirty state of the internal flash). It's hard to know for sure without having a UART connection with the board.
BUT, we have an alternative, in the form of the recovery built-in ISP flash tool.
This is the code that reads "sdupdate.img" from the SD Card and flashes it
After reading the recovery source code, i realised that this code can only be triggered correctly when booting from the SD card.
It detects this state by reading /proc/cmdline and probing for specific values (https://github.com/rockchip-android...6f72b7d3123dab27135ac41d55029/sdboot.cpp#L206)
This means the bootloader can (and will) pass those arguments under specific conditions (https://github.com/rockchip-linux/u...c873f178c/arch/arm/mach-rockchip/board.c#L358)
If you check here https://github.com/rockchip-linux/u...3f178c/arch/arm/mach-rockchip/boot_mode.c#L47 you can see the magic word that needs to be written to the "misc" partition in order to trigger that code.
Note that, besides the well known "sdboot", "usbboot" is also possible.
I'm not sure if the ROM can physically boot from USB, but the bootloader and recovery do support (according to code) passing the flag to enable flashing from USB.
So, recapping, there are these ways we can try:
a - try to overwrite "boot" with "recovery" (but it might not work due to the partitioning layout, e.g. jumping from A6 -> A10)
- note: uboot might also need to be written when doing this.
b - making a modified "sdupdate.img" that flashes recovery on top of boot, and all the other core partitions like "misc", "uboot", "trust", "vbmeta"
c - writing "misc" from android in order to triggers the "rkfwupdate" mode
d - taking a dump of the first portion of the flash in various states (A6, A8, A9, A10), and having a "dd" that writes it back to the beginning of the flash (i suspect this is how ModInstaller does it)
Considering cases "b" and "c" depend on a recovery that can write them correctly (and the A6 one is buggy), this leaves us with "a" and "d"
Considering that ModInstaller does it in one shot, and doesn't seem to matter about the partitioning layout, i believe "d" might be the most viable option...
Using the "rockchip-tool" repository i linked from github, the partition table can be dumped from any .img file
You can observe "Image/parameter.txt" from the extracted firmware
This is the partition table from A6's recovery:
[email protected](uboot)
[email protected](trust)
[email protected](misc)
[email protected](resource)
[email protected](kernel)
[email protected](dtb)
[email protected](dtbo)
[email protected](vbmeta)
[email protected](boot)
[email protected](recovery)
[email protected](backup)
[email protected](security)
[email protected](cache)
[email protected](system)
[email protected](metadata)
[email protected](vendor)
[email protected](oem)
[email protected](frp)
[email protected](userdata)
And this is the partition table from A9's recovery
[email protected](uboot)
[email protected](trust)
[email protected](misc)
[email protected](resource)
[email protected](kernel)
[email protected](dtb)
[email protected](dtbo)
[email protected](vbmeta)
[email protected](boot)
[email protected](recovery)
[email protected](backup)
[email protected](security)
[email protected](cache)
[email protected](system)
[email protected](metadata)
[email protected](vendor)
[email protected](oem)
[email protected](frp)
[email protected](userdata)
Notice how uboot, trust, misc, resource, kernel, dtb, and others live in the same space. (2000, 4000, 6000, 8000, 10000, ...)
What we could do is create a raw blob that spans that address range, and "dd" it directly to /dev/mmcblk0 at the right offset.
So i would focus on converting recovery images to raw blobs, with recovery-as-kernel so it boots straight away on the first try.

Bump a real thread.

Is it possible to convert it to a file installed by SDDiskTool?

marchnz said:
Bump a real thread.
Click to expand...
Click to collapse
I created a flashing tool to flash recovery within Android, using Rockchip's own code: https://forum.xda-developers.com/t/...chip-firmware-flash-tool-for-android.4458299/

blala said:
I created a flashing tool to flash recovery within Android, using Rockchip's own code: https://forum.xda-developers.com/t/...chip-firmware-flash-tool-for-android.4458299/
Click to expand...
Click to collapse
This file hct_recovery.patched.img does not appear to be installed via rkupdate

sadaghiani said:
Is it possible to convert it to a file installed by SDDiskTool?
Click to expand...
Click to collapse
It needs to be converted, yes
I'll take a look this afternoon

blala said:
It needs to be converted, yes
I'll take a look this afternoon
Click to expand...
Click to collapse
Is it possible to create a boot image that includes moded recovery & magisk and moded kernel ?

If by image you mean firmware image then yes, it can be done with https://github.com/liftoff-sr/rockchip-tool
But what i would recommend is the modded recovery only, with the magisk .zip to use in Recovery
Otherwise you risk flashing a kernel that doesn't match with kernel modules or is otherwise not fully compatible with the installed system

blala said:
If by image you mean firmware image then yes, it can be done with https://github.com/liftoff-sr/rockchip-tool
But what i would recommend is the modded recovery only, with the magisk .zip to use in Recovery
Otherwise you risk flashing a kernel that doesn't match with kernel modules or is otherwise not fully compatible with the installed system
Click to expand...
Click to collapse
boot.img file included recovery+magisk+kernel

Flashing a boot.img (Kernel, for example) in an Android mobile phone via adb shell
Flashing a boot.img (Kernel, for example) in an Android mobile phone via adb shell - script.sh
gist.github.com

MTCD has separate boot and recovery partitions.
Perhaps you can adapt both recovery/kernel to be in the same image but the bootloader won't know about that (and will always boot from "recovery" partition)

Development boot.img for SM-A127F and SM-A125F with the touch and MTP fixed

Here is a few boot.img files (tarred for Odin and zipped) intended to be used together with GSI systems (e.g. LineageOS) which suffer from the non-functional touchscreen after the wake-up and the non-functional MTP (USB file transfer). The boot.img files contain the recompiled stock kernel taken from Samsung Open Source with only a couple of the most necessary fixes. 99.9% unaltered, 100% open-source
All credits for the touchscreen fix go to manteiga25, he's done an amazing job on figuring this all out, still from his solution which includes additional performance tweaks I've taken the absolute bare minimum so that the problem is no longer present. Also huge thanks to Osvaldo Costa for the wonderful bootimgtool.
NOTE: If you did not yet flash any non-stock boot.img or recovery.img you may get the bootloop after flashing of any of these files (except for the orig's). That bootloop is caused by bootloader refusing to boot the VB-unsigned kernel together with the rest of the VB-signed components. The only solution (unfortunately) is the full factory reset, so you'll have to lose your user data; everything else, including the GSI will remain intact, but you'll have to set it up from scratch.
UPDATE 01/09/23: added the version based on A127FXXU7CVL2 (Android 13) version of the kernel.
UPDATE 01/11/23: added the fixed kernels for SM-A125F.
UPDATE 03/16/23: added the version based on A127FXXU5BVF3 (Android 12) version of the kernel.
Files for SM-A127F:
boot_sm-a127f-u4_fixed.zip: A127FXXU4AUK1-based kernel, Ilitek ili9881x fix, MTP fix
boot_sm-a127f-u5_fixed.zip: A127FXXU5BVF3-based (Android 12) kernel, Ilitek ili9881x fix, MTP fix
boot_sm-a127f-u7_fixed.zip: A127FXXU7CVL2-based (Android 13) kernel, Ilitek ili9881x fix, MTP fix
orig_boot_sm-a127-u4.zip: the original unaltered A127FXXU4AUK1 boot.img for undo
orig_boot_sm-a127-u5.zip: the original unaltered A127FXXU5BVF3 boot.img for undo
orig_boot_sm-a127-u7.zip: the original unaltered A127FXXU7CVL2 boot.img for undo
src_sm-a127f_fix.zip: all the altered source files
Files for SM-A125F:
boot_sm-a125f-u2_fixed_v1.zip: A125FXXU2BVB4-based kernel, Ilitek ili9881x fix, MTP fix
boot_sm-a125f-u2_fixed_v2.zip: A125FXXU2BVB4-based kernel, Ilitek ili9881x fix, Novatek nt36525 fix, MTP fix
orig_boot_sm-a125-u2.zip: the original unaltered A125FXXU2BVB3 boot.img for undo
src_sm-a127f-fix_v2.zip: all the altered source files
v1 should be easy on battery, but v2 will probably eat more because it basically disables the power saving features of the touchscreen chip (unfortunately that's the only solution at the kernel side).
If you don't trust me or if you're in desperate need of a more recent kernel, here are the steps how to rebuild it all yourself (for SM-A127F on Debian 11):
Download the kernel source from Samsung Open Source (A127FXXU3AUJ5)
Unpack SM-A127F_RR_Opensource.zip and Kernel.tar.gz inside
Unpack SM-A127F_RR_Opensource_A127FXXU4AUK1.zip into the same dir (overwriting the files)
Unpack the attached source.tar.gz, it contains only the changed files and build.sh facilitating compilation
From root: apt install clang-9 gcc-9-aarch64-linux-gnu
Remove any other versions of clang. Then cd /usr/bin; ln -s clang clang-9; ln -s clang++ clang++-9; ln -s clang-cpp clang-cpp-9
Back in the Kernel dir, run build.sh and wait for the kernel to compile
Download bootimgtool and compile it (just "make")
Download the stock firmware
Extract boot.img from AP_A127FXX[...].tar.md5 (unpack using tar, ignore the .md5) to the root dir of your Kernel
bootimgtool disassemble boot.img
cp Kernel/arch/arm64/boot/Image kernel
bootimgtool create -o boot.img
Flash boot.img as is using Heimdall or pack into .tar and flash using Odin
For SM-A125F you'll need to use the Google's patched Clang and GCC instead, and there is no way around that except for lots and lots of additional include paths for the Mediatek drivers (and even that does not guarentee that it will be compiled successfully).

uluruman said:
Here is the boot.img (tarred for Odin) intended to be used together with GSI systems (e.g. LineageOS). It contains the recompiled stock U4 kernel taken from Samsung Open Source with only a couple of the most necessary fixes, namely the freezing touchscreen and the non-functional MTP. 99.9% unaltered, 100% open-source.
All credits for the touchscreen fix go to manteiga25, he's done an amazing job on figuring this all out, still from his solution which includes additional performance tweaks I've taken the absolute bare minimum so that the problem is no longer present. Also huge thanks to Osvaldo Costa for the wonderful bootimgtool.
If you don't trust me here are the steps how to rebuild it all yourself (on Debian 11):
Download the kernel source from Samsung Open Source (A127FXXU3AUJ5)
Unpack SM-A127F_RR_Opensource.zip and Kernel.tar.gz inside
Unpack SM-A127F_RR_Opensource_A127FXXU4AUK1.zip into the same dir (overwriting the files)
Unpack the attached source.tar.gz, it contains only the changed files and build.sh facilitating compilation
From root: apt install clang-9 gcc-9-aarch64-linux-gnu
Remove any other versions of clang. Then cd /usr/bin; ln -s clang clang-9; ln -s clang++ clang++-9; ln -s clang-cpp clang-cpp-9
Back in the Kernel dir, run build.sh and wait for the kernel to compile
Download bootimgtool and compile it (just "make")
Download the stock firmware
Extract boot.img from AP_A127FXX[...].tar.md5 (unpack using tar, ignore the .md5) to the root dir of your Kernel
bootimgtool disassemble boot.img
cp Kernel/arch/arm64/boot/Image kernel
bootimgtool create -o boot.img
Flash boot.img as is using Heimdall or pack into .tar and flash using Odin
Click to expand...
Click to collapse
Amazing work. Love to see developers still working on this device. Does it work with SM-A125F?

Allehandro said:
Amazing work. Love to see developers still working on this device. Does it work with SM-A125F?
Click to expand...
Click to collapse
You can try, it may work, but most likely will bootloop. SM-A125F is based on a Mediatek SoC, SM-A127F is based on Exynos, which has a different kernel config.

uluruman said:
You can try, it may work, but most likely will bootloop. SM-A125F is based on a Mediatek SoC, SM-A127F is based on Exynos, which has a different kernel config.
Click to expand...
Click to collapse
I don't want to risk it as it is my main device and don't want to have to restore the device later on. Thanks though.

I've finally managed to compile the SM-A125F kernel (A125FXXU2BVB4 - SM-A125F_EUR_RR): somehow it turned out to be MUCH harder than that for SM-A127F, as nearly everything there is designed for only one specific toolchain, plus the non-Samsung s_mtp driver did not compile, so I had to take it from A127F's source. Anyway, I've ported the same fixes and here is the experimental boot.img. As I don't have SM-A125F I cannot test it, so I need someone to test it. Also attached is the original U2 boot.img: in case it does not work you just flash the original.

Amazing bro! Mad respect!!!!
I will soon put this baby to the test and see what's made of!!!
I can flash this using ODIN (PDA) directly over the current LOS GSI right?
Also, do you plan to include this kernel in your gsi building script so that the boot img of the gsi will be this one?
One other issue that I seemed to also have in my phone was the proximity sensor was not working e.g. when I was in call the screen would remain on....

axy_david said:
Amazing bro! Mad respect!!!!
I will soon put this baby to the test and see what's made of!!!
I can flash this using ODIN (PDA) directly over the current LOS GSI right?
Also, do you plan to include this kernel in your gsi building script so that the boot img of the gsi will be this one?
One other issue that I seemed to also have in my phone was the proximity sensor was not working e.g. when I was in call the screen would remain on....
Click to expand...
Click to collapse
Yes, flash using Odin. GSI should not be affected in any way. If anything does wrong I've also attached the original A127FXXU4AUK1 boot.img, so that you could revert the changes.
Currently I'm struggling to make the same fixed boot.img for my second phone, which is SM-A325F, and I cannot: even if I just unpack and repack back the same boot.img using any tool, including the Google's official mkbootimg, it causes the bootloop. So all of this is currently experimental.

uluruman said:
Currently I'm struggling to make the same fixed boot.img for my second phone, which is SM-A325F, and I cannot: even if I just unpack and repack back the same boot.img using any tool, including the Google's official mkbootimg, it causes the bootloop. So all of this is currently experimental.
Click to expand...
Click to collapse
This issue is sorted out: one cannot flash a custom boot.img over the signed stock one and don't do the full factory reset afterwards. Only after the factory reset the system boots with the unsigned boot partition. Interestingly enough, Download allows flashing such an image without any warnings (in contrast to flashing up_param.bin) but the system just refuses to boot.

uluruman said:
This issue is sorted out: one cannot flash a custom boot.img over the signed stock one and don't do the full factory reset afterwards. Only after the factory reset the system boots with the unsigned boot partition. Interestingly enough, Download allows flashing such an image without any warnings (in contrast to flashing up_param.bin) but the system just refuses to boot.
Click to expand...
Click to collapse
is it possible to fix the proximity sensor?

axy_david said:
is it possible to fix the proximity sensor?
Click to expand...
Click to collapse
There is no physical proximity sensor in this phone, but with the latest firmware you can normally use the Phone app. Now it normally reacts on touching the top part of the screen with your ear and blanks the screen. The screen does not blank on approaching the screen but only on touching it.

uluruman said:
Here is the boot.img (tarred for Odin) intended to be used together with GSI systems (e.g. LineageOS). It contains the recompiled stock U4 kernel taken from Samsung Open Source with only a couple of the most necessary fixes, namely the freezing touchscreen and the non-functional MTP. 99.9% unaltered, 100% open-source.
If the fixed boot.img does not work for you for some reason, I've also attached the original U4 boot (taken from the SM-A127F_NPB_A127FXXU4AUK1 firmware) so you could revert the changes.
All credits for the touchscreen fix go to manteiga25, he's done an amazing job on figuring this all out, still from his solution which includes additional performance tweaks I've taken the absolute bare minimum so that the problem is no longer present. Also huge thanks to Osvaldo Costa for the wonderful bootimgtool.
If you don't trust me or if you're in desperate need of a more recent kernel, here are the steps how to rebuild it all yourself (on Debian 11):
Download the kernel source from Samsung Open Source (A127FXXU3AUJ5)
Unpack SM-A127F_RR_Opensource.zip and Kernel.tar.gz inside
Unpack SM-A127F_RR_Opensource_A127FXXU4AUK1.zip into the same dir (overwriting the files)
Unpack the attached source.tar.gz, it contains only the changed files and build.sh facilitating compilation
From root: apt install clang-9 gcc-9-aarch64-linux-gnu
Remove any other versions of clang. Then cd /usr/bin; ln -s clang clang-9; ln -s clang++ clang++-9; ln -s clang-cpp clang-cpp-9
Back in the Kernel dir, run build.sh and wait for the kernel to compile
Download bootimgtool and compile it (just "make")
Download the stock firmware
Extract boot.img from AP_A127FXX[...].tar.md5 (unpack using tar, ignore the .md5) to the root dir of your Kernel
bootimgtool disassemble boot.img
cp Kernel/arch/arm64/boot/Image kernel
bootimgtool create -o boot.img
Flash boot.img as is using Heimdall or pack into .tar and flash using Odin
P.S.: the U5 kernel sources are suspicously segregated between RR (rest of the world), EUR, CIS and CIS-SER (Russia). It's quite interesting what are the differences?
Click to expand...
Click to collapse
Can you make one for A127F/DSN U7? (I don't have linux)

just tested on my phone latest U7 or s7???? nevertheless it bootloops

axy_david said:
just tested on my phone latest U7 or s7???? nevertheless it bootloops
Click to expand...
Click to collapse
it only works for u4 currently.

TheWorldYT said:
Can you make one for A127F/DSN U7? (I don't have linux)
Click to expand...
Click to collapse
I will, hold on.

just tested on my phone latest U7 or s7???? nevertheless it bootloops
TheWorldYT said:
it only works for u4 currently.
Click to expand...
Click to collapse
damn, and I can't downgrade, im using A127FXXS7BVK1 the latest update for europe really

axy_david said:
just tested on my phone latest U7 or s7???? nevertheless it bootloops
damn, and I can't downgrade, im using A127FXXS7BVK1
Click to expand...
Click to collapse
same thing.
also:
uluruman said:
I will, hold on.
Click to expand...
Click to collapse
axy_david said:
just tested on my phone latest U7 or s7???? nevertheless it bootloops
damn, and I can't downgrade, im using A127FXXS7BVK1 the latest update for europe really
Click to expand...
Click to collapse
uluruman said he will create one.

axy_david said:
just tested on my phone latest U7 or s7???? nevertheless it bootloops
damn, and I can't downgrade, im using A127FXXS7BVK1 the latest update for europe really
Click to expand...
Click to collapse
Done! ) See the update in the first post.
I've used the A127FXXU7CVL2 version source but it should work anyway because it's also U7-based (anyway there is no alternative - Samsung provides only that U7-based kernel). The only thing that theoretically can be needed is the factory reset: at least with my SM-A325F that was the case of the weird boot loop - the Verified Boot protection being voided (the warranty void bit being set) caused the bootloader to refuse loading the kernel.

uluruman said:
Done! ) See the update in the first post.
I've used the A127FXXU7CVL2 version source but it should work anyway because it's also U7-based (anyway there is no alternative - Samsung provides only that U7-based kernel). The only thing that theoretically can be needed is the factory reset: at least with my SM-A325F that was the case of the weird boot loop - the Verified Boot protection being voided (the warranty void bit being set) caused the bootloader to refuse loading the kernel.
Click to expand...
Click to collapse
Thank you!

uluruman said:
I've finally managed to compile the SM-A125F kernel (A125FXXU2BVB4 - SM-A125F_EUR_RR): somehow it turned out to be MUCH harder than that for SM-A127F, as nearly everything there is designed for only one specific toolchain, plus the non-Samsung s_mtp driver did not compile, so I had to take it from A127F's source. Anyway, I've ported the same fixes and here is the experimental boot.img. As I don't have SM-A125F I cannot test it, so I need someone to test it. Also attached is the original U2 boot.img: in case it does not work you just flash the original.
Click to expand...
Click to collapse
Can u make flashable zip for fix touch and mtp for a125f cause i think it dndt work after flashing only boot.img in twrp,still i found out that the baseband version is still bv5 instead of bv4 i hope you fix that bro because i want to install gsi

uluruman said:
Here is the boot.img (tarred for Odin) intended to be used together with GSI systems (e.g. LineageOS). It contains the recompiled stock U4 kernel taken from Samsung Open Source with only a couple of the most necessary fixes, namely the freezing touchscreen and the non-functional MTP. 99.9% unaltered, 100% open-source.
If the fixed boot.img does not work for you for some reason, I've also attached the original U4 boot (taken from the SM-A127F_NPB_A127FXXU4AUK1 firmware) so you could revert the changes.
All credits for the touchscreen fix go to manteiga25, he's done an amazing job on figuring this all out, still from his solution which includes additional performance tweaks I've taken the absolute bare minimum so that the problem is no longer present. Also huge thanks to Osvaldo Costa for the wonderful bootimgtool.
UPDATE 01/09/23: added the version based on A127FXXU7CVL2 (Android 13) version of the kernel.
If you don't trust me or if you're in desperate need of a more recent kernel, here are the steps how to rebuild it all yourself (on Debian 11):
Download the kernel source from Samsung Open Source (A127FXXU3AUJ5)
Unpack SM-A127F_RR_Opensource.zip and Kernel.tar.gz inside
Unpack SM-A127F_RR_Opensource_A127FXXU4AUK1.zip into the same dir (overwriting the files)
Unpack the attached source.tar.gz, it contains only the changed files and build.sh facilitating compilation
From root: apt install clang-9 gcc-9-aarch64-linux-gnu
Remove any other versions of clang. Then cd /usr/bin; ln -s clang clang-9; ln -s clang++ clang++-9; ln -s clang-cpp clang-cpp-9
Back in the Kernel dir, run build.sh and wait for the kernel to compile
Download bootimgtool and compile it (just "make")
Download the stock firmware
Extract boot.img from AP_A127FXX[...].tar.md5 (unpack using tar, ignore the .md5) to the root dir of your Kernel
bootimgtool disassemble boot.img
cp Kernel/arch/arm64/boot/Image kernel
bootimgtool create -o boot.img
Flash boot.img as is using Heimdall or pack into .tar and flash using Odin
P.S.: the U5 kernel sources are suspicously segregated between RR (rest of the world), EUR, CIS and CIS-SER (Russia). It's quite interesting what are the differences?
Click to expand...
Click to collapse
Please create working flashable zip file for twrp for a125f cause i dont have pc i cant use odin,thank you

[GUIDE] Assurance Wireless KonnectONE Moxee m2160 (MH-T6000) Rooting Guide

Assurance Wireless
KonnectONE Moxee m2160
4G-LTE Smartphone
Model No. MH-T6000
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Rooting Guide​
OVERVIEW:
This guide outlines simplified instructions for rooting the Assurance Wireless Moxee MH-T6000 4G-LTE smartphone. To cater this guide to new and inexperienced members, I have provided a stock boot image pre-patched with the Magisk v26.1 systemless root solution.
PREREQUISITES:
First and foremost, you need an unlocked bootloader. If your bootloader is not yet unlocked, complete that task and then return here. XDA hosts a plethora of how-to guides on standard bootloader unlocking. You will also need a Windows PC or laptop running the Minimal ADB & Fastboot Tools (link provided below). It should be noted that this guide can be carried out on a Mac or Linux computer as well; however, for purposes of this guide, I am focusing solely on a Windows setup. It is highly recommended that your device be running firmware build number MH-T6000V1.0.OB010, with the March 5, 2023 security patch level. As OTA updates are rolled out for this device, I will try to keep this guide updated with a patched boot image that corresponds with the latest firmware build.
Finally, you will need the factory supplied, or a quality equivalent USB-A to USB-C charging/syncing cable.
DISCLAIMER:
By proceeding further, you are assuming sole responsibility for the integrity and operability of your smartphone. Rooting your device is a task that carries with it the inherent risk of bricking or otherwise rendering your phone inoperable. While this guide has been thoroughly tested on my own device, you have been warned. Proceed at your own risk.
INSTRUCTIONS:​
Download the ADB & Fastboot tools from the link below and install the program on your PC or laptop;​
Open your Windows File Explorer, navigate to your C: drive, Program Files x86, and locate the Minimal ADB & Fastboot folder. Copy this folder and paste it to your desktop. (This step is not required, but is recommended for easier access of the ADB & Fastboot path);​
Download the patched boot image from the below link and save the image in your ADB & Fastboot folder. Note: the filename for the patched boot image is patched_boot.img. The flashing commands assume that you leave the filename unchanged;​
Boot your phone into fastboot mode by first powering your device off, and then holding the power and volume down keys simultaneously until fastboot mode appears on your device display;​
Connect your smartphone to your Windows computer using the factory supplied or a quality equivalent USB-A to USB-C charging/syncing cable;​
Open your ADB & Fastboot folder and double click cmd-here.exe to open a command window. Execute this command to verify a proper fastboot connection:
Code:
fastboot devices
If properly connected, the command window will return an alphanumeric string consistent with your device serial number;​
Once a proper connection has been verified, execute this command:
Code:
fastboot flash boot patched_boot.img
Now execute:
Code:
fastboot reboot
Upon reboot, open your app drawer and tap on the Magisk app or its placeholder stub. Ensure you are connected to the internet, grant any permissions, and follow any prompts given by Magisk to update to the full version in order to complete the root environment setup. Magisk may reboot your device during this process.​
That's it. You're now rooted via the Magisk v26.1 systemless root solution.​
IMPORTANT NOTE:
In the unfortunate event that you get stuck in a boot loop or brick your device using this guide, my guide on unbricking this smartphone will get you back up and running fairly quickly. This guide can be used to restore both soft bricked and hard bricked devices. You can then return here and give rooting another go.
Moxee MH-T6000 Unbricking Guide​DOWNLOADS:
• Minimal ADB & Fastboot v1.4.3
• Magisk Patched Boot Image
THANKS & MENTIONS:
A huge thanks and shout-out to @omb714.1980 for donating the Moxee smartphone that made this rooting guide possible. You are a scholar and a gentleman, good sir. Thanks also to KonnectONE support specialist Faith Flores for releasing to me the factory firmware for this device.​

Viva La Android said:
Assurance Wireless
Moxee MH-T6000 4G-LTE
View attachment 5893661
Rooting Guide​
OVERVIEW:
This guide outlines simplified instructions for rooting the Assurance Wireless Moxee MH-T6000 4G-LTE smartphone. To cater this guide to new and inexperienced members, I have provided a stock boot image pre-patched with the Magisk v26.1 systemless root solution.
PREREQUISITES:
First and foremost, you need an unlocked bootloader. If your bootloader is not yet unlocked, complete that task and then return here. You will also need a Windows PC or laptop running the Minimal ADB & Fastboot Tools (link provided below). It should be noted that this guide can be carried out on a Mac or Linux computer as well; however, for purposes of this guide, I am focusing solely on a Windows setup. It is highly recommended that your device be running firmware build number MH-T6000V1.0.OB010, with the March 5, 2023 security patch level. Finally, you will need the factory supplied, or a quality equivalent USB-A to USB-C charging/syncing cable.
DISCLAIMER:
By proceeding further, you are assuming sole responsibility for the integrity and operability of your smartphone. Rooting your device is a task that carries the inherent risk of bricking or otherwise rendering your phone inoperable. While this guide has been thoroughly tested on my own device, you have been warned. Proceed at your own risk.
INSTRUCTIONS:​
Download the ADB & Fastboot tools from the link below and install the program on your PC or laptop;​
Open your Windows File Explorer, navigate to your C: drive, Program Files x86, and locate the Minimal ADB & Fastboot folder. Copy this folder and paste it to your desktop. (This step is not required, but is recommended for easier access of the ADB & Fastboot path);​
Download the patched boot image from the below link and save the image in your ADB & Fastboot folder;​
Boot your phone into fastboot mode by first powering your device off, and then holding the power and volume down keys simultaneously until fastboot mode appears on your device display;​
Connect your smartphone to your Windows computer using the factory supplied or a quality equivalent USB-A to USB-C charging/syncing cable;​
Open your ADB & Fastboot folder and double click cmd-here.exe to open a command window. Execute this command to verify a proper fastboot connection:
Code:
fastboot devices
If properly connected, the command window will return an alphanumeric string consistent with your device serial number;​
Once a proper connection has been verified, execute this command:
Code:
fastboot flash boot patched_boot.img
Now execute:
Code:
fastboot reboot
Upon reboot, open your app drawer and tap on the Magisk app or its placeholder stub. Ensure you are connected to the internet, grant any permissions, and follow any prompts given by Magisk to update to the full version in order to complete the root environment setup. Magisk may reboot your device during this process.​
That's it. You're now rooted via the Magisk v26.1 systemless root solution.​
DOWNLOADS:
• Minimal ADB & Fastboot v1.4.3
• Magisk Patched Boot Image
THANKS & MENTIONS:
A huge thanks and shout-out to @omb714.1980 for donating the Moxee smartphone that made this rooting guide possible. You are a scholar and a gentleman, good sir. Thanks also to the KonnectONE support team for releasing to me the factory firmware for this device.​
Click to expand...
Click to collapse
Lol. Now you post this. After unsuccessfully scouring the internet for the stock firmware. I finally did the same as you and simply reached out to konnectone and asked for it. I just came here to see if there was anyone here that is by far more knowledgeable than myself (not hard) interested to have the firmware and would post a guide like this one. Well done!
Would you happen to have a twrp recovery compiled for this device by chance? Or if not but planning on it would you let me know please. I would appreciate it!

scottfan81 said:
Lol. Now you post this. After unsuccessfully scouring the internet for the stock firmware. I finally did the same as you and simply reached out to konnectone and asked for it. I just came here to see if there was anyone here that is by far more knowledgeable than myself (not hard) interested to have the firmware and would post a guide like this one. Well done!
Would you happen to have a twrp recovery compiled for this device by chance? Or if not but planning on it would you let me know please. I would appreciate it!
Click to expand...
Click to collapse
I just got KonnectONE to agree to release firmware a couple of days before you mentioned having firmware. It's been a long wait indeed.
I don't have source code to compile TWRP; only the firmware. I will be attempting to port a TWRP build for this phone very soon. My legal battle with KonnectONE was in regards to source code under the General Public License 2.0. Because they were ultimately unable to provide kernel source, their legal team and support department finally acquiesced to provide firmware to device owners upon written request. I compromised for the firmware release, but was not able to get kernel source code for building TWRP. I am pretty confident that a ported TWRP can be ironed out as a stable build. I already have the base build selected.

Thank you so much! I have 3 of these devices and been waiting lol. I see the stock kernel has hot-plug . What's some good tuning profiles? I tried to debloat permanently with LP but it didn't work. I think it's read-only so I flashed the magisk overlay for rw and going to play. We definitely need TWRP! I see a port may be in the works. Awesome. Thanks again

Viva La Android said:
I just got KonnectONE to agree to release firmware a couple of days before you mentioned having firmware. It's been a long wait indeed.
I don't have source code to compile TWRP; only the firmware. I will be attempting to port a TWRP build for this phone very soon. My legal battle with KonnectONE was in regards to source code under the General Public License 2.0. Because they were ultimately unable to provide kernel source, their legal team and support department finally acquiesced to provide firmware to device owners upon written request. I compromised for the firmware release, but was not able to get kernel source code for building TWRP. I am pretty confident that a ported TWRP can be ironed out as a stable build. I already have the base build selected.
Click to expand...
Click to collapse
They never replied when I emailed them about it several months ago . This is so awesome. I got rid of most of the lag with kernel manager. Kudos

Argonon said:
They never replied when I emailed them about it several months ago . This is so awesome. I got rid of most of the lag with kernel manager. Kudos
Click to expand...
Click to collapse
Several months ago they weren't releasing firmware to the public. I got it released by battling with them over open source code and I ultimately compromised for factory firmware. It was only recently made public.
Yeah I've noticed a nice performance boost too with some debloating and sone kernel tweaks. I'm using EX Kernel Manager. Keep in mind this device uses dynamic partitioning (super.img). As such, even with root, it isn't always possible to mount /system r/w. I extracted the super.img on a PC and then mounted /system, /vendor and /product, debloated, and then repacked and reflashed super img.

Awesome. I don't have a good pc now unfortunately. I do have viper4android repackaged version with driver and effects pre-installed. I used smart pack kernel manager to tweak kernel. The device is very useable now! I have a Blu View 3 android 11 mtk device id love to root but can't even unlock bootloader. Maybe I should look into emailing them

Argonon said:
Awesome. I don't have a good pc now unfortunately. I do have viper4android repackaged version with driver and effects pre-installed. I used smart pack kernel manager to tweak kernel. The device is very useable now! I have a Blu View 3 android 11 mtk device id love to root but can't even unlock bootloader. Maybe I should look into emailing them
Click to expand...
Click to collapse
BLU won't unlock your bootloader. It is locked per contractual agreement with the branded carrier of the phone. However, if it's MediaTek, you may be able to use MTK Client to exploit the bootloader into an unlocked state.

Viva La Android said:
Several months ago they weren't releasing firmware to the public. I got it released by battling with them over open source code and I ultimately compromised for factory firmware. It was only recently made public.
Yeah I've noticed a nice performance boost too with some debloating and sone kernel tweaks. I'm using EX Kernel Manager. Keep in mind this device uses dynamic partitioning (super.img). As such, even with root, it isn't always possible to mount /system r/w. I extracted the super.img on a PC and then mounted /system, /vendor and /product, debloated, and then repacked and reflashed super img.
Click to expand...
Click to collapse
Would you plz share your super.img ? I'm on latest firmware and have attached screenshot of build etc.... I understand if you can't or don't want to. Can I pull mine since I'm rooted? Problem is I have a old Chromebook that I installed endeavor os on its arch based Linux but I don't have much hard drive space to do work

Viva La Android said:
Several months ago they weren't releasing firmware to the public. I got it released by battling with them over open source code and I ultimately compromised for factory firmware. It was only recently made public.
Yeah I've noticed a nice performance boost too with some debloating and sone kernel tweaks. I'm using EX Kernel Manager. Keep in mind this device uses dynamic partitioning (super.img). As such, even with root, it isn't always possible to mount /system r/w. I extracted the super.img on a PC and then mounted /system, /vendor and /product, debloated, and then repacked and reflashed super img.
Click to expand...
Click to collapse
Would you plz share your super.img ? I'm on latest firmware and have attached screenshot of build etc.... I understand if you can't or don't want to. Can I pull mine since I'm rooted? Problem is I have a old Chromebook that I installed endeavor os on its arch based Linux but I don't have much hard drive space to do work
Viva La Android said:
I just got KonnectONE to agree to release firmware a couple of days before you mentioned having firmware. It's been a long wait indeed.
I don't have source code to compile TWRP; only the firmware. I will be attempting to port a TWRP build for this phone very soon. My legal battle with KonnectONE was in regards to source code under the General Public License 2.0. Because they were ultimately unable to provide kernel source, their legal team and support department finally acquiesced to provide firmware to device owners upon written request. I compromised for the firmware release, but was not able to get kernel source code for building TWRP. I am pretty confident that a ported TWRP can be ironed out as a stable build. I already have the base build selected.
Click to expand...
Click to collapse
I have 3 of these devices. I surly can test TWRP port if needed

Argonon said:
Would you plz share your super.img ? I'm on latest firmware and have attached screenshot of build etc.... I understand if you can't or don't want to. Can I pull mine since I'm rooted? Problem is I have a old Chromebook that I installed endeavor os on its arch based Linux but I don't have much hard drive space to do work
I have 3 of these devices. I surly can test TWRP port if needed
Click to expand...
Click to collapse
Sure. I don't mind sharing my super.img. I'll need to upload it and then I'll message you a link. It's pretty much exactly 2.5 GB in file size, so I'll first compress it to a zip before uploading.

The edited one. Just clarifying so appreciated

Argonon said:
The edited one. Just clarifying so appreciated
Click to expand...
Click to collapse
I don't yet have all my mods made to the /super partition in that regard. Having encountered some force close issues with certain apps, I debloated from scratch and and have now begun my kernel tweaks and edits to the.varuous .prop files. So when finished, I'll share both my boot.img and super.img.

Just the stock super.img would be fine then. I think I can figure how to decompile, debloat and recompile then flash.

Argonon said:
Just the stock super.img would be fine then. I think I can figure how to decompile, debloat and recompile then flash.
Click to expand...
Click to collapse
MH-T6000 super.img unmodified

I was experimenting and flashed the super.img with dsu side loader apk as a gsi lol. The app description said can replace various partitions and I was just trying to get system rw on the dsu loader. I know that makes no sense. What windows 11 compatible software do you recommend to unpack, repack etc? I see a few magisk modules but not quite sure how to use. Like ro2rw magisk module

Viva La Android said:
MH-T6000 super.img unmodified
Click to expand...
Click to collapse
Thank you!

Argonon said:
Thank you!
Click to expand...
Click to collapse
When I have completed debloating, kernel tweaks and .prop files edits of the OS, I'll share my modified super.img and boot.img. I have a TWRP v3.6.0 port build that is currently booting properly on this phone. But, I have bugs to work out on logical partition mounting, as well as the backup & restore functionality.

Argonon said:
I was experimenting and flashed the super.img with dsu side loader apk as a gsi lol. The app description said can replace various partitions and I was just trying to get system rw on the dsu loader. I know that makes no sense. What windows 11 compatible software do you recommend to unpack, repack etc? I see a few magisk modules but not quite sure how to use. Like ro2rw magisk module
Click to expand...
Click to collapse
Check out CRB Android Kitchen here on XDA. Great for unpacking / repacking partition images, including super.img.

Viva La Android said:
When I have completed debloating, kernel tweaks and .prop files edits of the OS, I'll share my modified super.img and boot.img. I have a TWRP v3.6.0 port build that is currently booting properly on this phone. But, I have bugs to work out on logical partition mounting, as well as the backup & restore
Click to expand...
Click to collapse
Have you had anymore luck with this