I've come most recently from a Galaxy S4 with a locked bootloader using safestrap, and before that from an S3 with an unlocked bootloader.
On the S3, with it's unlocked bootloader I flashed roms without really worrying that much about kernals or rom "bases"
When I used safestrap I understood it was really important that the rom I was flashing was based on the "base" I was locked into by virtue of the particular OTA I was on.
Now that I have my verizon G2 i've rooted the 12b ota with ioroot and i'm about to install a recovery using freegee, but before I go forward I'd like to understand a little bit more how careful do I have to be to find out what "base" the rom i'm about to flash was built on/for? can install a rom or restore a backup that is based on a different verizon ota then my own? I understand tha Loki is a "bypass" and not a bootloader unlock, but I'm not really sure what that means.
Please enlighten me.
Unlike an actual bootloader unlock, Loki is dependent upon the kernel.
When you boot the phone, the bootloader loads the kernel into the memory and then verifies it. In that order. If the signature verification is successful, the bootloader proceeds with the boot process. If it does not, the boot process is aborted and a security error is displayed.
The key to the Loki exploit is actually at the step where the kernel is loaded into the memory. The flaw in the bootloader is that it relies upon the boot image header to determine the location at which to load the kernel and the ramdisk in the memory. The signature verification occurs after this. The exploit works by using an address in the boot image header that actually overwrites the part of the bootloader in the memory that does the signature verification. Shellcode added by the user is loaded to where the ramdisk is expected to reside and patches up boot image header and loads the kernel and ramdisk into the memory at the correct location, and then returns a value that would indicate that signature verification was successful, and thus the bootloader proceeds with the boot process with the custom kernel.
All in all it's pretty simple, and quite brilliant.
If you are installing a custom ROM or kernel, all of boot images have this exploit written into them, otherwise they will not boot. As an end user, all you need to really worry about is things like checking integrity, as if you flash a damaged image it will not run the exploit as it is supposed to and fail to boot, you'll get a security error, and basically have no option other than to flash completely back to stock (or if you end up in fastboot, flash a good boot image and recovery that properly exploit the bootloader and can boot the ROM you have installed or recovery). It's not much different from an actual bootloader unlock to the user, as if you get a bad download and flash it you're going to have problems no matter what. Check your md5s always!
Perhaps worth noting is that this exploit has been patched in the official kit-kat releases. I do not know too much about the new bootloader, but I am told that it includes steps that verify it's own integrity so it will not boot if it is overwritten. Since the old bootloader won't boot official 4.4.2, there is currently no way to get both official 4.4.2 and a custom recovery.
Sent from my Nexus 7 using Tapatalk
Thanks
Thanks, but I'm still confused about the practical ramifications.
When I choose a rom to install does it need to specifically be built on the 12b ota? when I'm on a particular ota can I restore a backup that was had a different base? both of those things were things I couldn't do with safestrap, but I could on my bootloader-unlocked phones
Edited my first post with a little more info. Loki had to be updated for 12B. Most ROMs and kernels have been updated but some won't work. I would read the ROMs thread to make sure. I am on 12B currently and I have not run into any problems with it yet, but it never hurts to read the thread for the things you are flashing and seeing if others are having a problem. This is not like safestrap where you are limited to the stock kernel (or one specific kernel if you have kexec). Any kernel that is properly Loki'd will be bootable as long as you don't do something like try to boot an AOSP ROM on a stock kernel. There are a few incompatibilities between ROMs and kernels that arise from various ROMs moving away from AOSP but this has nothing to do with this specific exploit and would happen regardless of bootloader unlocking/hacking methods
Sent from my Nexus 7 using Tapatalk
I am getting into development more and have a new load of questions. And yes, I searched first.
Do all Roms include firmware(OS), kernal, baseband, and boot loader?
Do over-the-air updates include the baseband and boot loader, or only the kernal and firmware/(OS).
I once used the Wugfreth toolkit to reinstall the stock ROM. It flashed the baseband with the same version and then attempted to flash the boot loader with the same version, but failed. How can I JUST flash the kernal and firmware/os.
This may be dumb question, but what language is the boot loader and baseband written in? Is it encrypted, or can anyone edit it and flash?
What happens if the boot loader, baseband, kernal, and firmware versions do not match?
I did not know the ROM included the bootloader, and I almost purposely flash the ROM of another device to see what would happen, figuring I could have restored using fastboot. But that probably would have hard-bricked it, right? I thought flashing a ROM was completely safe because it did not touch the boot loader, and could always be undone with fastboot?
How do you developers test out modified bootloaders without making a simple coding mistake and ruining your device?
How can you flash a bootloader using itself (fastboot)?
I saw a post for a different device for changing the boot loader logo. Not the firmware's boot animation. I don't want mine to say "Google" with an unlock icon. Can this be done on the Nexus 7?
I read the partition sizes are determined by the boot loader, and not adjustable. Is this correct? I am running stock 4.4.3 and only have 11MB free on the system partition. How do custom Roms fit within this limit? I am worried this will prevent a custom ROM based in 5.0 Lollipop, and the Nexus 7 2012 will be stuck on Kitkat. Maybe the firmware could be loaded on the data partition with a symbolic link to the system partition?
Thank you
I'm not a developer, but can answer some of your questions (at least as they relate specifically to the Nexus 7).
Custom ROMS typically just include the firmware/kernel (and i believe the radio/baseband if it's for a 3g/mobile device, though these can also be flashed separately, and i could be wrong on this part.) Bootloader is typically untouched, but this might differ on other devices.
As for OTA updates and what all they include, well that depends on the device, manufacturer, carrier, and even the specific OTA. It could potentially include everything (firmware/kernel updates, bootloader, radio/baseband, etc.), but may be any combination of the different components.
Available free space on the system partition doesn't really matter if you're flashing a new ROM, because you'll be wiping the partition as part of the flashing process. ROMs typically don't include GAPPS either (unless it's just a modified version of stock), so will actually take up much less room than the stock ROM on their own. Then you can decide which GAPPS to flash separately, there are various packages available in different sizes; some just include the basic google play services needed to have the play store and related basic functionality, others will mirror the stock pre-installed apps.
If you're using a custom recovery to flash a ROM, they typically contain a script to first verify the device matches, if not, it won't even flash. If you do manage to flash an incompatible ROM (via fastboot maybe, or if it doesn't include a verification script), with a Nexus this typically is not a big deal, you just won't ever actually boot into the ROM, but should still be able to boot into recovery or bootloader and then flash a compatible ROM.
If you flash an incompatible kernel on top of a ROM, you'll likely get a bootloop/softbricked device.
Flashing an incompatible bootloader may brick the device. Any tinkering with the bootloader is always risky.
Hope that helps a little, I'll take another look when I'm not at work
flyoffacliff said:
I am getting into development more and have a new load of questions. And yes, I searched first.
Do all Roms include firmware(OS), kernal, baseband, and boot loader?
Do over-the-air updates include the baseband and boot loader, or only the kernal and firmware/(OS).
I once used the Wugfreth toolkit to reinstall the stock ROM. It flashed the baseband with the same version and then attempted to flash the boot loader with the same version, but failed. How can I JUST flash the kernal and firmware/os.
This may be dumb question, but what language is the boot loader and baseband written in? Is it encrypted, or can anyone edit it and flash?
What happens if the boot loader, baseband, kernal, and firmware versions do not match?
I did not know the ROM included the bootloader, and I almost purposely flash the ROM of another device to see what would happen, figuring I could have restored using fastboot. But that probably would have hard-bricked it, right? I thought flashing a ROM was completely safe because it did not touch the boot loader, and could always be undone with fastboot?
How do you developers test out modified bootloaders without making a simple coding mistake and ruining your device?
How can you flash a bootloader using itself (fastboot)?
I saw a post for a different device for changing the boot loader logo. Not the firmware's boot animation. I don't want mine to say "Google" with an unlock icon. Can this be done on the Nexus 7?
I read the partition sizes are determined by the boot loader, and not adjustable. Is this correct? I am running stock 4.4.3 and only have 11MB free on the system partition. How do custom Roms fit within this limit? I am worried this will prevent a custom ROM based in 5.0 Lollipop, and the Nexus 7 2012 will be stuck on Kitkat. Maybe the firmware could be loaded on the data partition with a symbolic link to the system partition?
Thank you
Click to expand...
Click to collapse
1. roms dont include a bootloader.
2. no
3. easily in a custom recovery.
4. i have no idea, and its the most secure part of the device.
5. nothing.
6. roms DO NOT EVER include bootloaders.
7. developers on nexus devices never modify the bootloader. first off, its extremely tedious and difficult. secondly, there is no need, as our bootloaders are unlockable and lockable.
8. it overwrites itself, but you are on your computer using fastboot, phone is just plugged into it.
9. no.
10. each partition has its own size. roms go into a partition that also holds your storage, and is separated from the storage. another reason why you dont have 16gb storage when you buy a 16gb device, because some of it gets allocated to the system.
from this thread/post by Hashcode, to install KK "4.4.2 Stock Root Odex/DeOdex [04/23/14]" by BeansTown106 on dev edition note 3:
I have a dev edition VZW Note 3 still with the 4.3 (JellyBean) bootloader / aboot. Obviously I can't just flash the 4.4 aboot without locking it and turning it into a retail version.
I'm aware of the bootloader unlock using the CID exploit to convert any VZ Note 3 into a dev edition version, however, I'd like to avoid modifying my CID and want to keep it as is.
Apparently, there is this kernel that will let the "older" dev edition to run a 4.4-based rom. The links in the post seem to have expired, or are no longer working now;
"(Goo.im)"
"(Crackflashers)"
I also did a search for that file on google, and nothing useful came up.
With a regular 4.4.2 kernel, my phone just gets stuck at the "Note 3" screen after running the kernel, it won't get to /system, if I use the de-odex rom's kernel from Hashcode, the 4.3 bootloader won't even run the kernel and just freezes. I'd really appreciate it if someone could re-post it with a link here, if they still happen to have that modified 4.4.2 kernel for the dev edition, it is called
flash-vzw-de-4.4-kernel-v1.0.zip
supposedly it also needs this file, but I'm sure it'll still work without it:
flash-tw44-sys-files-fixes-v1.0.zip
If anyone still happens to have these files, I would really appreciate it they could post a link for download.
There is a link for the kernel source in that post, but I'm not really good at compiling my own kernels.
Thanks for any assistance
newuser134 said:
from this thread/post by Hashcode, to install KK "4.4.2 Stock Root Odex/DeOdex [04/23/14]" by BeansTown106 on dev edition note 3:
I have a dev edition VZW Note 3 still with the 4.3 (JellyBean) bootloader / aboot. Obviously I can't just flash the 4.4 aboot without locking it and turning it into a retail version.
I'm aware of the bootloader unlock using the CID exploit to convert any VZ Note 3 into a dev edition version, however, I'd like to avoid modifying my CID and want to keep it as is.
Apparently, there is this kernel that will let the "older" dev edition to run a 4.4-based rom. The links in the post seem to have expired, or are no longer working now;
"(Goo.im)"
"(Crackflashers)"
I also did a search for that file on google, and nothing useful came up.
With a regular 4.4.2 kernel, my phone just gets stuck at the "Note 3" screen after running the kernel, it won't get to /system, if I use the de-odex rom's kernel from Hashcode, the 4.3 bootloader won't even run the kernel and just freezes. I'd really appreciate it if someone could re-post it with a link here, if they still happen to have that modified 4.4.2 kernel for the dev edition, it is called
flash-vzw-de-4.4-kernel-v1.0.zip
supposedly it also needs this file, but I'm sure it'll still work without it:
flash-tw44-sys-files-fixes-v1.0.zip
If anyone still happens to have these files, I would really appreciate it they could post a link for download.
There is a link for the kernel source in that post, but I'm not really good at compiling my own kernels.
Thanks for any assistance
Click to expand...
Click to collapse
Suggest you try to PM hashcode if you haven't already.
For what it's worth... I am running Jasmine 6.1 (based on lollipop OF1) witb the lean kernal and NC4 bootloader. I am not seeing any issues with that combination.
I do have a TWRP backup of the bootloader if that would do you any good.
Sent from my SM-N900V using Tapatalk
donc113 said:
Suggest you try to PM hashcode if you haven't already.
For what it's worth... I am running Jasmine 6.1 (based on lollipop OF1) witb the lean kernal and NC4 bootloader. I am not seeing any issues with that combination.
I do have a TWRP backup of the bootloader if that would do you any good.
Sent from my SM-N900V using Tapatalk
Click to expand...
Click to collapse
Hi,
Thanks for your offer to help. I wish that would work. I'm assuming you have a retail version Note 3 that was bootloader unlocked with the CID conversion method, right?
I can always do it that way, but then I will have to change my phone's CID, which is a unique number to the device. That's what converts any retail Note 3 into a dev edition Note 3.
The phone I have came as a dev edition (unlocked bootloader) from the manufacturer. That means it has a bootloader from factory with a signature in it matching my original CID. Obviously that makes it impossible for me to use anybody else's bootloader other than my own, unless I also change my CID to theirs (which defeats the purpose because my phone already has an unlocked bootloader).
My problem is that my bootloader is Android 4.3-based (JellyBean), not 4.4 (KitKat). Any Android version above 4.3 WILL run on the 4.4 bootloader. That's why your Lollipop-based (Android 5.x-based) rom will run on a 4.4 (KitKat)-based bootloader. The bootloader I have is older than KitKat, it's from Android JellyBean (4.3). The version of the bootloader that you have is exactly what I need, but not just from any phone, it would have to be "signed" with the CID from my phone.
You CANNOT backup the bootloader (aboot) with twrp, what you have backed up, is the BOOT partition, boot.img, which is the kernel image or backup. Bootlader is even at a lower level on your phone than kernel, it's the very first thing that runs when you power up your phone, which shows the "Note 3 - Custom" screen while it's booting up. It's what you overwrote when you unlocked your bootloader, if that's what you did. Be very careful that you NEVER overwrite it from what you have now, otherwise you will either lock your phone back, or you will hard brick it.
You can backup your bootloader (or aboot) using either ADB from a pc, or from Terminal Emulator app (if your phone is rooted) with this set of commands:
su <enter>
dd if=dev/block/platform/msm_sdcc.1/by-name/aboot of=/mnt/extSdCard/aboot.mbn <enter>
Don't type <enter>, that just means you hit enter after typing the command(s).
That set of commands will produce a backup file called "aboot.mbn", which is exactly 2.0 Mb, on the main directory of you external sd card if you need to keep it for later. DO NOT ever try to write to the aboot partition unless you know what you're doing, and DO NOT enter the commands above incorrectly, it could easily hard-brick your phone, it cannot be recovered from that if it gets hard-bricked.
Anyway, what you have backed up with twrp, is boot.img, a backup of the lean kernel you use. It should be stored in your TWRP "BACKUP" folder, along with an MD5 file, they are called boot.emmc.win and boot.emmc.win.md5 depending on your version of twrp, the first file should be between 10 to 12 Mb, the md5 file is under 1Kb, like maybe 48 bytes. Could you get those two files and share them with me, I might be able to use the lean kernel to fix my issue. If you are unable to post a link to share those with me, or link them on this thread to share, could you point me to where you downloaded the lean kernel you use from? You should be able to share those files with dropbox or google drive or something similar.
Thank you again
newuser134 said:
Hi,
Thanks for your offer to help. I wish that would work. I'm assuming you have a retail version Note 3 that was bootloader unlocked with the CID conversion method, right?
I can always do it that way, but then I will have to change my phone's CID, which is a unique number to the device. That's what converts any retail Note 3 into a dev edition Note 3.
The phone I have came as a dev edition (unlocked bootloader) from the manufacturer. That means it has a bootloader from factory with a signature in it matching my original CID. Obviously that makes it impossible for me to use anybody else's bootloader other than my own, unless I also change my CID to theirs (which defeats the purpose because my phone already has an unlocked bootloader).
My problem is that my bootloader is Android 4.3-based (JellyBean), not 4.4 (KitKat). Any Android version above 4.3 WILL run on the 4.4 bootloader. That's why your Lollipop-based (Android 5.x-based) rom will run on a 4.4 (KitKat)-based bootloader. The bootloader I have is older than KitKat, it's from Android JellyBean (4.3). The version of the bootloader that you have is exactly what I need, but not just from any phone, it would have to be "signed" with the CID from my phone.
You CANNOT backup the bootloader (aboot) with twrp, what you have backed up, is the BOOT partition, boot.img, which is the kernel image or backup. Bootlader is even at a lower level on your phone than kernel, it's the very first thing that runs when you power up your phone, which shows the "Note 3 - Custom" screen while it's booting up. It's what you overwrote when you unlocked your bootloader, if that's what you did. Be very careful that you NEVER overwrite it from what you have now, otherwise you will either lock your phone back, or you will hard brick it.
You can backup your bootloader (or aboot) using either ADB from a pc, or from Terminal Emulator app (if your phone is rooted) with this set of commands:
su
dd if=dev/block/platform/msm_sdcc.1/by-name/aboot of=/mnt/extSdCard/aboot.mbn
Don't type , that just means you hit enter after typing the command(s).
That set of commands will produce a backup file called "aboot.mbn", which is exactly 2.0 Mb, on the main directory of you external sd card if you need to keep it for later. DO NOT ever try to write to the aboot partition unless you know what you're doing, and DO NOT enter the commands above incorrectly, it could easily hard-brick your phone, it cannot be recovered from that if it gets hard-bricked.
Anyway, what you have backed up with twrp, is boot.img, a backup of the lean kernel you use. It should be stored in your TWRP "BACKUP" folder, along with an MD5 file, they are called boot.emmc.win and boot.emmc.win.md5 depending on your version of twrp, the first file should be between 10 to 12 Mb, the md5 file is under 1Kb, like maybe 48 bytes. Could you get those two files and share them with me, I might be able to use the lean kernel to fix my issue. If you are unable to post a link to share those with me, or link them on this thread to share, could you point me to where you downloaded the lean kernel you use from? You should be able to share those files with dropbox or google drive or something similar.
Thank you again
Click to expand...
Click to collapse
Towards the bottom of this post is a link to the lean kernel under dev edition options (part of the Jasmine 6.1 announcement.
http://forum.xda-developers.com/showthread.php?p=62769340
Yes.. On aboot... The code for the exploit is on github under beaups and if you read YOUR cid and then use that and YOUR aboot signature you can redo YOUR cid and signature to re unlock your dev edition.
Read these 2 threads
http://forum.xda-developers.com/showthread.php?t=3359370
http://forum.xda-developers.com/showthread.php?p=66068899
Sent from my SM-N900V using Tapatalk
donc113 said:
Towards the bottom of this post is a link to the lean kernel under dev edition options (part of the Jasmine 6.1 announcement.
http://forum.xda-developers.com/showthread.php?p=62769340
Yes.. On aboot... The code for the exploit is on github under beaups and if you read YOUR cid and then use that and YOUR aboot signature you can redo YOUR cid and signature to re unlock your dev edition.
Read these 2 threads
http://forum.xda-developers.com/showthread.php?t=3359370
http://forum.xda-developers.com/showthread.php?p=66068899
Sent from my SM-N900V using Tapatalk
Click to expand...
Click to collapse
I'm very grateful that you let me know about the exploit code on how to use your own original CID and maybe sign the new 4.4 bootloader with my own CID. That was very nice to point me in that direction. Looks like I need to do a little research and figure out how to do that.
Now I wonder though that if I upgrade my bootloader to the next version, even if I am able to unlock my dev edition again, if I'll be able to use use JellyBean android with the newer aboot if KitKat or Lollipop don't work out for me?! I am under the impression that once you upgrade your bootloader, you CANNOT roll it back, it blacklists all the older aboot versions. Looks like I also need to figure out if older kernels will run on the newer bootloader, the reverse of what I am having trouble with now, with a newer kernel and older bootloader problem.
newuser134 said:
I'm very grateful that you let me know about the exploit code on how to use your own original CID and maybe sign the new 4.4 bootloader with my own CID. That was very nice to point me in that direction. Looks like I need to do a little research and figure out how to do that.
Now I wonder though that if I upgrade my bootloader to the next version, even if I am able to unlock my dev edition again, if I'll be able to use use JellyBean android with the newer aboot if KitKat or Lollipop don't work out for me?! I am under the impression that once you upgrade your bootloader, you CANNOT roll it back, it blacklists all the older aboot versions. Looks like I also need to figure out if older kernels will run on the newer bootloader, the reverse of what I am having trouble with now, with a newer kernel and older bootloader problem.
Click to expand...
Click to collapse
The original code for an S5 us here:
https://github.com/beaups/SamsungCID?files=1
There's also a Sam_Dunk pdf that explains the exploit.
My SLIGHTLY modified version of beaups code is in the zip located here
http://forum.xda-developers.com/showthread.php?p=66529761
Hopefully you can read and modify C code, I compiled it right on my Note 3 using C4DROID app and its GCC module.
@beaups can probably tell you if the exploit can be used to go backwards on ABOOT
Sent from my SM-N900V using Tapatalk
donc113 said:
The original code for an S5 us here:
https://github.com/beaups/SamsungCID?files=1
There's also a Sam_Dunk pdf that explains the exploit.
My SLIGHTLY modified version of beaups code is in the zip located here
http://forum.xda-developers.com/showthread.php?p=66529761
Hopefully you can read and modify C code, I compiled it right on my Note 3 using C4DROID app and its GCC module.
@beaups can probably tell you if the exploit can be used to go backwards on ABOOT
Sent from my SM-N900V using Tapatalk
Click to expand...
Click to collapse
Thank you
I know enough C to probably figure it out. I'm glad to hear that it is possible to compile code on the phone with an app, I haven't used a PC for years to compile any kind of computer code, it's a lot easier to setup an android phone for that. I will give it a try.
I wasn't able to get stock (or de-odexed) KitKat 4.4.2 to work on the older aboot even with Lean Kernel. I was, however, able to get get the latest version of Jasmine Rom (to which you provided the link to get Lean Kernel from its post ), even though it's even newer than KitKat 4.4.2! As you said, Jasmine Rom 6.1 is Lollipop-based, KitKat 4.4.2 is a lot closer to my own JellyBean aboot (4.3), so if Android 5.0 or 5.1 is working on the old aboot, I don't see why Android 4.4.2 should be able to work?! I know for sure it has something to do with the kernel, I know if I flash the right kernel, it will work. Stupid somewhat-locked bootloader! On older phones with truly unlocked, unsigned bootloaders, once the bootloader handed the chain to the kernel, it would care less if they were "compatible", the kernel would then run and boot into /system. These signed/encrypted bootloaders, along with secure boot being on on the phone, aren't really unlocked even when unlocked, they just enforce slightly less when checking for boot.img or recovery.img signature, they still check for version and compatibility. I've never had an issue with a bootloader version not being compatible with kernel version, the bootloader's purpose is just to load the operating system or kernel. Ever heard of a PC's bios not being compatible with a version of Windows or Linux?!
I confirmed with someone else's dev edition phone that the new aboot (version 4.4) will NOT boot into old Android 4.3 JellyBean, so since downgrading aboot may not be possible, I will hold on upgrading my aboot for now till I figure out more. If Lollipop will work with the older aboot, then KitKat must be able to as well, it's just a question of figuring it out eventually, and getting the right kernel. Maybe I'll have to start learning on how to modify kernels and turn on/off kernel modules.
Thank you for all your help again. I'll get your code and look at it a little later once I figure it out a little more.
Hi! A couple of days ago I found FlashFire from chainfire and saw G4 users used to flash roms with it while they didn't have their bootloader unlocked, so I was wondering if it is possible to install roms using it.
According to their website it isn't recommended for unlocked bootloaders but since I have a spare h440 board I've been trying to flash a stock MM rom using rooted LP for preserve root at upgrading, I think it might be possible but unfortunately while flashing the system.img I made using our poland MM kdz use 2.76gb and my system partition stand about 2.4gb so when it hits 2.4 an error alert is prompt and the phone stays unusable till I flash a new kdz using lg flash tool.
I think I'm missing something while making my system.img, I used WindowsLGFirmwareExtract to obtain the dz file and DZFileTools too obtain BINS files and then WindowsLGFirmwareExtract to merge them again into a .img file. Any suggestions?
not yet
spirytusek said:
not yet
Click to expand...
Click to collapse
no suggestion? I mean thing was flashing my system.img, it's just bigger than the available space so I think it's possible but I just don't know how to create correctly a system.img from a stock rom kdz file if we manage to create a smaller we might be able to inject supersu while flashing using flashfire
bootloader unlock must first
I'm not very keen to this kind of things, unlocking and making custom roms, but I think that some guy try to do the same thing and ended up with a hard brick.
This is the link to what he tried http://forum.xda-developers.com/showpost.php?p=67408204&postcount=1407
Wish I could help you more but I'm just an ignorant u.u
Hello. On Lollipop, the ROOT is being written on the system partition. If you upgrade to Marshmallow with any way, you replace th LP system with the MM one. It is being overwritten. So, ROOT is lost, together with the LP system. There is a way to write ROOT on the MM system partition, but STILL, it is not working, because the bootloader of MM checks if there has been a modification, like ROOT (dm_verity). So, the only way to root MM for now is to have an unlocked bootloader.