Develop Bugs

[Q] Root available for ASUS MeMO Pad 10 (ME103K)?

Greetings!
First of all, I am sorry if this is on the wrong section of the forum. Nevertheless i've tried few rooting applications which are stated to be compatible with this ME103K model, but with no results.. Also many fake sites trying to lure you to purchase something.
Is there anyone who could provide me information on how to root my ASUS ME103K tablet? Should I also try every rooting application available out there or is this useless? Can I verify if they are compatible without all the way installing and running them on the device? (Sorry don't know much about this stuff =)! )
Thank you very much in advance

I rooted ME103K on my own - by compiling a custom kernel
Executive summary: Go to youtube and watch video with ID "gqubgQjqfHw" (I can't post links yet, sorry! ) - or search Youtube for "Rooting MemoPAD10 (ME103K) with my custom compiled kernel"
Analysis:
I hated the fact that my recently purchased MemoPAD10 (ME103K) tablet had no open process to allow me to become root. I don't trust the closed-source one-click root apps that use various exploits, and require communicating with servers in.... China. Why would they need to do that? I wonder...
I therefore decided this was a good opportunity for me to study the relevant documentation and follow the steps necessary to build an Android kernel for my tablet. I then packaged my custom-compiled kernel into my custom boot image, and the video shows how I boot from it and become root in the process.
Note that I didn't burn anything in my tablet - it's a 'tethered' root, it has no side-effects.
If you are a developer, you can read in detail about the steps I had to take to modify the kernel (and su.c) and become root - by reading the questions (and answers!) that I posted in the Android StackExchange forum ( can't post links yet, see the video description in Youtube ).
If you are not a developer, you can download my custom boot image from the link below - but note that this means you are trusting me to not do evil things to your tablet as my kernel boots and my /sbin/su is run
Honestly, I haven't done anything weird - I just wanted to run a debootstrapped Debian in my tablet, and succeeded in doing so. But I am also worried about the cavalier attitude I see on the web about rooting your devices - if you want to be truly safe, you must either do what I did (and recompile the kernel yourself) or absolutely trust the person that gives it to you. I do wish Google had forced a UI-accessible "become root" option in Android, just as Cyanogen does (sigh).
The image I created and used in the video to boot in rooted mode, is available from the link show in the Youtube video details.
Enjoy!

ttsiodras said:
Executive summary: Go to youtube and watch video with ID "gqubgQjqfHw" (I can't post links yet, sorry! ) - or search Youtube for "Rooting MemoPAD10 (ME103K) with my custom compiled kernel"
Analysis:
I hated the fact that my recently purchased MemoPAD10 (ME103K) tablet had no open process to allow me to become root. I don't trust the closed-source one-click root apps that use various exploits, and require communicating with servers in.... China. Why would they need to do that? I wonder...
I therefore decided this was a good opportunity for me to study the relevant documentation and follow the steps necessary to build an Android kernel for my tablet. I then packaged my custom-compiled kernel into my custom boot image, and the video shows how I boot from it and become root in the process.
Note that I didn't burn anything in my tablet - it's a 'tethered' root, it has no side-effects.
If you are a developer, you can read in detail about the steps I had to take to modify the kernel (and su.c) and become root - by reading the questions (and answers!) that I posted in the Android StackExchange forum ( can't post links yet, see the video description in Youtube ).
If you are not a developer, you can download my custom boot image from the link below - but note that this means you are trusting me to not do evil things to your tablet as my kernel boots and my /sbin/su is run
Honestly, I haven't done anything - I just wanted to run a deboot-strapped Debian in my tablet. But I am also worried about the cavalier attitude I see on the web about rooting your devices - if you want to be truly safe, you must either do what I did (and recompile the kernel yourself) or absolutely trust the person that gives it to you. I do wish Google had forced a UI-accessible "become root" option in Android, just as Cyanogen does (sigh).
The image I created and used in the video to boot in rooted mode, is available from the link show in the Youtube video details.
Enjoy!
Click to expand...
Click to collapse
Hello ttsiodras,
I had the same problem as OP and didn't want to go the "chinese route" either, especially since there seem to be conflicting reports on whether it works on the ME103k or not so I tried your solution - with mixed results...
Disclaimer: I'm totally new to Android (colour me unpleasantly surprised) and have little experience in Linux, so for further reference I would consider myself an advanced noob. Please keep this in mind when evaluating my claims or judging what I have done so far or am capable of doing by myself in the future.
What I did:
- become developer in the ME103k by tapping the system build repeatedly, then allowing debugging via USB
- use ADB to boot into the bootloader
- use fastboot to boot your boot.rooted.img
What happened:
- I did get root access
- the tab now always boots into the bootloader, even when told via ADB or fastboot to boot normally or into recovery. Pushing buttons etc doesn't seem to work either
- my attempts to do a recovery via the vanilla Asus method has failed due to the same fact that boot never gets past fastboot
Since you claimed in your description that there would be no side-effects since it is a tethered root I am somewhat puzzled as to what exactly happened. From what I understand - which admittedly isn't a lot - what should have happened is that your boot image is loaded, giving me root access until the next reboot without changing anything about the default boot process or image. I read somewhere else that this is how people test out different kernels with fastboot before deciding on which one they want to use on their devices. The whole boot process being changed and corrupted in a way that makes the tablet non-rebootable without having the cable and an adb- and fastboot-capable machine nearby is not really what I would have expected going by your description.
Of course it is entirely possible (and probably even rather likely) that I got something wrong along the way or there is a simple fix to my problem I am not aware of.
As for possible steps maybe you or someone else in the forum could point me to a way to return my tablet to factory settings before risking damaging it beyond repair. I'm assuming that it should be possible and rather straightforward to recover the original setup with the firmware provided by Asus (downloaded the newest version from the homepage) but to be honest I'm a bit scared to go ahead with it before knowing for sure how to do this safely.
One thing seems certain: I won't be able to do it the way Asus says I should unless I can somehow get into normal or recovery boot modes again. I do however still have root access and am able to run fastboot and ADB including shell on the tablet, so it should be possible.
I would certainly appreciate any help very much
Thanks

drsiegberterne said:
. . . From what I understand - which admittedly isn't a lot - what should have happened is that your boot image is loaded, giving me root access until the next reboot without changing anything about the default boot process or image. I read somewhere else that this is how people test out different kernels with fastboot before deciding on which one they want to use on their devices.
Click to expand...
Click to collapse
Your understanding is correct - that's exactly what should have happened.
I can assure you that the kernel I compiled is formed from the Asus sources with the 2 patches I made that have *nothing* to do with the bootloader - they patch the way that the kernel allows dropping privileges and thus allowing root level access.
Something else must have happened - did you by any chance "burn" the image? i.e. `(DONT DO THIS) fastboot flash boot boot.rooted.img` instead of `fastboot boot boot.rooted.img`?
I did not advocate for burning precisely because it is unpredictable - manufactures sometimes require signing images with their private keys before allowing a boot image to boot (AKA "locked bootloaders") which means that any attempt to burn may lead to weird configurations. . .
If you did burn it, maybe you can try burning the original "boot.img" from the Asus OTA (Over the Air) update .zip file (avaible as a big download at the ASUS site - "UL-K01E-WW-12.16.1.12-user.zip" )
I know of no way to help you with the current state of your tablet, except to "ease the pain" by saying that rebooting to fastboot is always "recoverable" - you can always boot into my own (rooted) kernel or the original (from the ASUS .zip file) with `fastboot boot <whatever_image>`. No "harm" can happen from this - as you correctly said, it's the way to try new kernels and images.
UPDATE - after more reverse engineering:
I had a look into the contents of the boot loader running inside the ME103K, and I am pretty sure that if you execute this at fastboot...
# fastboot oem reset-dev_info
# fastboot reboot
... you will get back to normal, un-tethered bootings of your ME103K.
Thanassis.

ttsiodras said:
Your understanding is correct - that's exactly what should have happened.
I can assure you that the kernel I compiled is formed from the Asus sources with the 2 patches I made that have *nothing* to do with the bootloader - they patch the way that the kernel allows dropping privileges and thus allowing root level access.
Something else must have happened - did you by any chance "burn" the image? i.e. `(DONT DO THIS) fastboot flash boot boot.rooted.img` instead of `fastboot boot boot.rooted.img`?
I did not advocate for burning precisely because it is unpredictable - manufactures sometimes require signing images with their private keys before allowing a boot image to boot (AKA "locked bootloaders") which means that any attempt to burn may lead to weird configurations. . .
If you did burn it, maybe you can try burning the original "boot.img" from the Asus OTA (Over the Air) update .zip file (avaible as a big download at the ASUS site - "UL-K01E-WW-12.16.1.12-user.zip" )
I know of no way to help you with the current state of your tablet, except to "ease the pain" by saying that rebooting to fastboot is always "recoverable" - you can always boot into my own (rooted) kernel or the original (from the ASUS .zip file) with `fastboot boot <whatever_image>`. No "harm" can happen from this - as you correctly said, it's the way to try new kernels and images.
Thanassis.
Click to expand...
Click to collapse
Hi Thanassis,
thanks for your quick reply and your efforts. I'm actually around 85% sure I did not flash the image but since I had no Linux on my computer at the time (I know shame on me) I used a Mac and the command line was a bit different. Since I had never used ADB or fastboot I relied on some guide that explained how to even get into the bootloader and might have gotten something wrong.
On the other hand I later read out the commands I used in the Mac shell and couldn't find anything other than the things I should have done and described earlier, so as far as I can tell this all should never have happened. It may be interesting to point out here that the "stuck in fastboot" mode happened immediately after the first time I loaded your kernel and I most definitely just wrote fastboot boot boot.rooted.img at that point.
As for fixing the problem now it's not only about the inconvenience of the whole thing. I also later (after I was already stuck in fastboot mode) installed some apps for helping me manage privileges of different apps (xposed framework and xprivacy) which turned out to not be compatible in some way or another. So now not only is my tablet not booteable in a normal way but its also cluttered with even more useless stuff than before and I would really like to just reset it before thinking about any other possibilities.
If I flash boot the original ASUS boot image found in the file you described and which i dowloaded already, shouldn't that fix the problem if I accidentally did flash your boot image? Or will there be even more trouble?
Alternatively isn't there a manual way to flash the whole zipped recovery image or am I misunderstanding what this ASUS file actually contains?
And which of the two options is safer to try first or in other words - which one might break the tablet once and for all?
Thanks again and sorry for my incompetence

drsiegberterne said:
Hi Thanassis,
If I flash boot the original ASUS boot image found in the file you described and which i dowloaded already, shouldn't that fix the problem if I accidentally did flash your boot image? Or will there be even more trouble?
. . .
Alternatively isn't there a manual way to flash the whole zipped recovery image or am I misunderstanding what this ASUS file actually contains?
. . .
Thanks again and sorry for my incompetence
Click to expand...
Click to collapse
No, don't be sorry We are all either choosing to learn in this world (i.e. make mistakes and learn from them), or choose to remain stuck in ignorance. I applaud your efforts in properly rooting the tablet. . .
To the point - remember, you are root now ; whatever apps you installed, you can definitely uninstall them. You don't necessarily need to wipe it.
If you do want to, I'd suggest booting in recovery and doing it the normal way that Asus recommends. Since you said "buttons don't work", you may want to try using the original recovery .img - i.e. "fastboot boot recovery.img". I'd love to suggest a link from ASUS, but they don't host it (which is bad - they really should) - so instead go to "goo" dot "gl" slash "noegkY" - this will point you to a discussion where a kind soul is sharing his ME103K recovery.img.
Booting from the recovery will allow you to install the ASUS OTA update - and probably try cleaning cache partition, etc
Good luck!

ttsiodras said:
No, don't be sorry We are all either choosing to learn in this world (i.e. make mistakes and learn from them), or choose to remain stuck in ignorance. I applaud your efforts in properly rooting the tablet. . .
To the point - remember, you are root now ; whatever apps you installed, you can definitely uninstall them. You don't necessarily need to wipe it.
If you do want to, I'd suggest booting in recovery and doing it the normal way that Asus recommends. Since you said "buttons don't work", you may want to try using the original recovery .img - i.e. "fastboot boot recovery.img". I'd love to suggest a link from ASUS, but they don't host it (which is bad - they really should) - so instead go to "goo" dot "gl" slash "noegkY" - this will point you to a discussion where a kind soul is sharing his ME103K recovery.img.
Booting from the recovery will allow you to install the ASUS OTA update - and probably try cleaning cache partition, etc
Good luck!
Click to expand...
Click to collapse
The problem here is that he doesn't seem to have the same version as on my tablet. I have the newest version with Lollipop while this seems to be at least a couple of patches earlier with a completely different version of Android. Won't I risk breaking things even more if I try to apply this - as in trying to recover a recovery that is not on my tablet since certainly the recovery.img doesn't contain all the information needed since it's only 10 MB.
As you can probably guess the whole discussion in your link about what part of the system is broken and how to fix it goes right over my head. It also seems like they did not find a satisfactory solution in the end (short of sending the tablet to ASUS). As you can imagine I'm at quite a loss what to try and what not out of fear to make things worse. At least for now I can still use the tablet to do the things I need it to do.
Thanks for your help anyway, I will try to read up more on the topic and decide what to do next.

drsiegberterne said:
The problem here is that he doesn't seem to have the same version as on my tablet. I have the newest version with Lollipop while this seems to be at least a couple of patches earlier with a completely different version of Android. Won't I risk breaking things even more if I try to apply this - as in trying to recover a recovery that is not on my tablet since certainly the recovery.img doesn't contain all the information needed since it's only 10 MB.
Thanks for your help anyway, I will try to read up more on the topic and decide what to do next.
Click to expand...
Click to collapse
I understand how you feel - your tablet is operational now (OK, with the annoyance that you need to boot it in "tethered mode") - so you rightfully fear that you may mess things up with further steps.
Just to clarify something - the recovery img is something that works on its own ; it has no dependency on what kind of Android image is installed in the /system partition.
If you do decide to do it, "fastboot boot recovery.img" will bring you to a spartan menu, showing options that allow you to apply an update (i.e. the ASUS update you downloaded!), clean the /cache partition, etc.
Choose "install update from SD card" (use volume up/down to choose, power btn to select), and navigate to your SD card, where you will have placed the big .zip file from ASUS.
The recovery process will begin, and your tablet will be "wiped" with the image from ASUS. Reboot, and be patient while the tablet boots up - it will be just like the first time you started it (i.e. install from scratch).
Whatever you decide - good luck!

ttsiodras said:
I understand how you feel - your tablet is operational now (OK, with the annoyance that you need to boot it in "tethered mode") - so you rightfully fear that you may mess things up with further steps.
Just to clarify something - the recovery img is something that works on its own ; it has no dependency on what kind of Android image is installed in the /system partition.
If you do decide to do it, "fastboot boot recovery.img" will bring you to a spartan menu, showing options that allow you to apply an update (i.e. the ASUS update you downloaded!), clean the /cache partition, etc.
Choose "install update from SD card" (use volume up/down to choose, power btn to select), and navigate to your SD card, where you will have placed the big .zip file from ASUS.
The recovery process will begin, and your tablet will be "wiped" with the image from ASUS. Reboot, and be patient while the tablet boots up - it will be just like the first time you started it (i.e. install from scratch).
Whatever you decide - good luck!
Click to expand...
Click to collapse
Okay, a little update from the battlefront:
I tried the recovery image and did get into the menu, however the recovery failed with the same two error messages as in your earlier link ("footer is wrong" and "signature verification failed"). My output from fastboot getvar all is also very similar to the one from that guy except I have a different bootloader version than him (3.03).
Another thing I noticed is that if I boot the standard boot.img found in the ASUS zip it will recognize the internal sdcard normally, however when I boot your rooted image the internal memory doesn't seem to be recognized, at least not through the pre-installed file manager. Downloading a file to the internal storage also failed while rooted but all the apps and the OS itself so far seem totally unaffected otherwise.
My last resort at the moment is the fastboot flash boot boot.img but I have little hope it would change anything since in the thread you linked they proposed just that and if it had worked they probably would have mentioned it.
Can it theoretically break the tablet even more? I would hate to have to send it in because I completely bricked it...

drsiegberterne said:
Okay, a little update from the battlefront:
Another thing I noticed is that if I boot the standard boot.img found in the ASUS zip it will recognize the internal sdcard normally, however when I boot your rooted image the internal memory doesn't seem to be recognized.
Click to expand...
Click to collapse
Not the case for me - everything works fine (including internal and external sdcard), so it's definitely not my kernel causing this.
drsiegberterne said:
My last resort at the moment is the fastboot flash boot boot.img but I have little hope it would change anything since in the thread you linked they proposed just that and if it had worked they probably would have mentioned it.
Can it theoretically break the tablet even more? I would hate to have to send it in because I completely bricked it...
Click to expand...
Click to collapse
Flashing is always dangerous (from what you've said, I actually theorize that you did, actually, flash already...)
I doubt this will solve the boot issue, to be honest - if I were you, I'd continue to boot tethered (with my image when you need root access, and (maybe) the Asus image when you don't). Myself, I always boot my own bootimage, since I have zero problems with it, and it allows me to run a complete Debian distro in a chroot (thus making my tablet a full-blown UNIX server - e.g. I run privoxy on it to filter all stupid ads in all apps on the tablet, etc).
No matter what you decide, good luck!
Thanassis.

ttsiodras said:
Not the case for me - everything works fine (including internal and external sdcard), so it's definitely not my kernel causing this.
Flashing is always dangerous (from what you've said, I actually theorize that you did, actually, flash already...)
I doubt this will solve the boot issue, to be honest - if I were you, I'd continue to boot tethered (with my image when I need root access, and (maybe) the Asus image when I don't). Myself, I always boot my own bootimage, since I have zero problems with it, and it allows me to run a complete Debian distro in a chroot (thus making my tablet a full-blown UNIX server - e.g. I run privoxy on it to filter all stupid ads in all apps on the tablet, etc).
No matter what you decide, good luck!
Thanassis.
Click to expand...
Click to collapse
I already tried to flash the original boot.img yesterday but it didn't change anything as you correctly assumed so I guess for now there is nothing more to do. I might write to the Asus support and maybe send the tablet in if it is free of charge for me (which I doubt). The only other option is to spend the next months to get sufficiently versed in Android to actually fix the problems myself but even for that I would probably need some files or source code from Asus. I find it rather disappointing the way these "closed" systems work nowadays, with the advancement of Linux and Open Source I really would have expected the opposite to be true but apparently people care more about convenience than actually being able to use the tools they buy in the way they want to.
Getting these Android devices like buying a hammer that can't hammer things in on Sundays.

drsiegberterne said:
I find it rather disappointing the way these "closed" systems work nowadays, with the advancement of Linux and Open Source I really would have expected the opposite to be true but apparently people care more about convenience than actually being able to use the tools they buy in the way they want to
Click to expand...
Click to collapse
I share the sentiment - it's really sad.

Undoing the tethered root
drsiegberterne said:
I already tried to flash the original boot.img yesterday but it didn't change anything as you correctly assumed so I guess for now there is nothing more to do. I might write to the Asus support and maybe send the tablet in if it is free of charge for me (which I doubt). The only other option is to spend the next months to get sufficiently versed in Android to actually fix the problems myself but even for that I would probably need some files or source code from Asus. I find it rather disappointing the way these "closed" systems work nowadays, with the advancement of Linux and Open Source I really would have expected the opposite to be true but apparently people care more about convenience than actually being able to use the tools they buy in the way they want to.
Getting these Android devices like buying a hammer that can't hammer things in on Sundays.
Click to expand...
Click to collapse
Hi drsiegberterne - I had a look into the contents of the boot loader running inside the ME103K, and I am pretty sure that if you execute this at fastboot...
# fastboot oem reset-dev_info
# fastboot reboot
... you will get back to normal, un-tethered bootings of your ME103K.
Hope this solves your problem!
Kind regards,
Thanassis.

touching files in recovery mode results in factory reset

A week ago I flashed the current (lineage-14.1-20170504-nightly-oneplus3-signed.zip) lineage os nightly to my phone. I did not pay that much attention til I realize the impact, so no guarantee for the temporal order. I am pretty shure, that in the first place, I tried to flash the image via the update menu (is this called OTA update?). The previous update two weeks ago already results in partial data los. By this I mean some (maybe all) apps disappears after the update, but after installing them again, all of them provided the pre-update data - only exception was signal. This time the phone was like in factory state. But when I try to reinstall the telegram app - the app store refuses to install the app because of the presence of a identical named app.
Using adb shell shows me, that all apps and data where still present in the /data subdirectories. Even those I didn't had reinstalled til that time . So I took advantage of momentum and backed up some files and decided to perform a full pre factory reset formatting everything twrp let me format. After flashing the lineage update, another full format because things seems still weird, second lineage nightly flash, realizing I have to first flash OOS-x.y.z and a final third lineage flash, I thought I finally obtain a running system. After initial configuration I decided to only copy my previous wpa_supplicant.conf file back to the system. Since overwriting this file while running android didn't led to anything, I tried to replace this file in recovery mode. Instead of remembering my password, goatish oneplus 3 desides to perform factory reset.
After what seems to be a lower six digit number of flashing attemps I came to the conclusion that performing any modification to the file system while the native kernel is not running results in factory reseting the device. In the mean time I also figured out what dm-verity means - an error message I got used to and maybe a nice feature as long as you don't try to take your old config files to a new system. And I know I am the millionth person facing that problem in a dedicated thread, but I found nothing which links this annoying boot loader message to my reset problem.
I made my previous recovery attemps between the toilet and my bed, so I hadn't any strategy at all. But thank god its friday! I read: dm-verity is a feature of the device mapper which guarantees data integrity. When I alter the data using any other than the native system, the device mapper notices the integrity violation and reports to the system. I am only guessing that this makes the system to reset itself - Am I right? Even if I appreciate this concept, I think this might be a little too ambitious. Can I alter androids behaviour in this point? In the best case I want to temporary disable this feature, do some root stuff and turn it on again. Is this possible?
I could follow one of that numerous tutorials to remove that dm-verity message, but I am not confortable with flashing zip files from dubious file hosters as well as copy-pasting commands without any idea of what I am doing. So maybe someone could provide a little more information than the seven step recipe of getting rid of that error message blog posts.
I really appreciate material which explains my problem. I am quite new to android and I didn't figured out how to maneuver around all these google results which tells me to install a specific app which may will hide my problem. So thank you in advance.

hinerk0815 said:
A week ago I flashed the current (lineage-14.1-20170504-nightly-oneplus3-signed.zip) lineage os nightly to my phone. I did not pay that much attention til I realize the impact, so no guarantee for the temporal order. I am pretty shure, that in the first place, I tried to flash the image via the update menu (is this called OTA update?). The previous update two weeks ago already results in partial data los. By this I mean some (maybe all) apps disappears after the update, but after installing them again, all of them provided the pre-update data - only exception was signal. This time the phone was like in factory state. But when I try to reinstall the telegram app - the app store refuses to install the app because of the presence of a identical named app.
Using adb shell shows me, that all apps and data where still present in the /data subdirectories. Even those I didn't had reinstalled til that time . So I took advantage of momentum and backed up some files and decided to perform a full pre factory reset formatting everything twrp let me format. After flashing the lineage update, another full format because things seems still weird, second lineage nightly flash, realizing I have to first flash OOS-x.y.z and a final third lineage flash, I thought I finally obtain a running system. After initial configuration I decided to only copy my previous wpa_supplicant.conf file back to the system. Since overwriting this file while running android didn't led to anything, I tried to replace this file in recovery mode. Instead of remembering my password, goatish oneplus 3 desides to perform factory reset.
After what seems to be a lower six digit number of flashing attemps I came to the conclusion that performing any modification to the file system while the native kernel is not running results in factory reseting the device. In the mean time I also figured out what dm-verity means - an error message I got used to and maybe a nice feature as long as you don't try to take your old config files to a new system. And I know I am the millionth person facing that problem in a dedicated thread, but I found nothing which links this annoying boot loader message to my reset problem.
I made my previous recovery attemps between the toilet and my bed, so I hadn't any strategy at all. But thank god its friday! I read: dm-verity is a feature of the device mapper which guarantees data integrity. When I alter the data using any other than the native system, the device mapper notices the integrity violation and reports to the system. I am only guessing that this makes the system to reset itself - Am I right? Even if I appreciate this concept, I think this might be a little too ambitious. Can I alter androids behaviour in this point? In the best case I want to temporary disable this feature, do some root stuff and turn it on again. Is this possible?
I could follow one of that numerous tutorials to remove that dm-verity message, but I am not confortable with flashing zip files from dubious file hosters as well as copy-pasting commands without any idea of what I am doing. So maybe someone could provide a little more information than the seven step recipe of getting rid of that error message blog posts.
I really appreciate material which explains my problem. I am quite new to android and I didn't figured out how to maneuver around all these google results which tells me to install a specific app which may will hide my problem. So thank you in advance.
Click to expand...
Click to collapse
Your story is too long to go through. But most likely your issue will be solved if you install blue sparks twrp. Check his thread in the unified section

{Help} Adding Dual boot patcher support

Being an avid user of Multirom with TWRP on my now dead LG Optimus G, I couldn't deal with the fact there is no multi boot option for my Honor 8 pro. So, I did some research and came to know that "Dual boot patcher" is the preferred solution to boot multiple roms at the moment. Thankfully, the project turned out to be open source and the developer has a well documented Git with information required to add support for new devices. I tried following the dev's guide found here https://github.com/chenxiaolong/DualBootPatcher/wiki/How-to-add-new-Devices-to-DualBootPatcher%3F by flashing the provided zip file. But it did not create any log files in the internal storage. So, if any of you happen to be in stock rom and are willing to help, kindly flash the file found in the above URL and upload the results. I'll proceed with the further steps. Thanks.

Will be glad to help. Can you explain in step-wise format on what to do. Any prerequisites other than a twrp recovery.

NIKHIL JOHN said:
Will be glad to help. Can you explain in step-wise format on what to do. Any prerequisites other than a twrp recovery.
Click to expand...
Click to collapse
Thanks for taking interest in this. To test it out, you will need a device with unlocked bootloader with twrp recovery installed. Also, I believe (not sure though) that file encryption needs to be disabled for this to work. To check file encryption state, go to
Settings → Security & Location → Encryption & Credentials & it shows phone encrypted
or
Use adb command
Code:
adb shell getprop ro.crypto.state
( works on unrooted devices also) returns encrypted or unencrypted
As far as flashing is concerned, it is pretty straight forward. Just download the zip file mentioned in the above post and transfer it to either internal storage or SD card. Boot into TWRP recovery and flash the zip file. If you need any help during the process, feel free to ask.

Andromann said:
Thanks for taking interest in this. To test it out, you will need a device with unlocked bootloader with twrp recovery installed. Also, I believe (not sure though) that file encryption needs to be disabled for this to work. To check file encryption state, go to
Settings → Security & Location → Encryption & Credentials & it shows phone encrypted
or
Use adb command
Code:
adb shell getprop ro.crypto.state
( works on unrooted devices also) returns encrypted or unencrypted
As far as flashing is concerned, it is pretty straight forward. Just download the zip file mentioned in the above post and transfer it to either internal storage or SD card. Boot into TWRP recovery and flash the zip file. If you need any help during the process, feel free to ask.
Click to expand...
Click to collapse
Hey buddy sorry for the late reply. My phone was bricked so had to get it fixed. Now my phone is updated to Andriod Oreo. Will try to root again and Follow the procedure. It would be helpful if you can give me your whatsapp number because i kind of mess things up and it takes a long time for me to get my phone back up and going. It would be helpful if you can assist on the way.

Need a little help, please ....

I rebooted in to recovery (B partition) from custom ROM , ran Migrator Magisk module twice (as directions say-second run does FDR), booted into A partition of my Pixel XLto flash new ROM and for some reason EVERYTHING is encrpyted (do not have screen lock or pin applied) ..... I remember seeing something like this when I first got the device but cant recall how to deal with it.
Every attempt to adb sideload, adb push , etc not working ....

C.Hatfield said:
I rebooted in to recovery (B partition) from custom ROM , ran Migrator Magisk module twice (as directions say-second run does FDR), booted into A partition of my Pixel XLto flash new ROM and for some reason EVERYTHING is encrpyted (do not have screen lock or pin applied) ..... I remember seeing something like this when I first got the device but cant recall how to deal with it.
Every attempt to adb sideload, adb push , etc not working ....
Click to expand...
Click to collapse
So, I take it you were trying to 'migrate' to another ROM?
My suggestion is this, use this guide: https://forum.xda-developers.com/pixel-xl/how-to/guide-pixel-xl-android-9-0-pie-unlock-t3825866/
- Start fresh
- Do #4 'wipe data'

was just using the magisk migrator module - it backed up all my files on 1st run, then 2nd run it did FDR .... I would REALLY prefer not wiping my internal/sdcard ..... everything is still there but encrypted, unusable for the moment - hoping there is a workaround bc Ihave sooo much data that I havent backed up externally/cloud for a month or 3 .... got nothing I can boot from as well as no access to ALL the tons of stuff stored on my phone to flash .... was thinking to use Factory image but removing the [-w] from the bat file ..... would that work to keep my data integrity ?

Honestly, im wondering how things got encrypted when the process (xc for what im unsure the mod did extra besides FDR) is practically, if not identical, to the normal protocol for wiping>flashing for PIXEL XL

C.Hatfield said:
was just using the magisk migrator module - it backed up all my files on 1st run, then 2nd run it did FDR .... I would REALLY prefer not wiping my internal/sdcard ..... everything is still there but encrypted, unusable for the moment - hoping there is a workaround bc Ihave sooo much data that I havent backed up externally/cloud for a month or 3 .... got nothing I can boot from as well as no access to ALL the tons of stuff stored on my phone to flash .... was thinking to use Factory image but removing the [-w] from the bat file ..... would that work to keep my data integrity ?
Click to expand...
Click to collapse
...would that work to keep my data integrity ? Yes

will the modded flash-all.bat actually work with all the contents of the internal drive being encrypted?
I only ask bc of all the research Ive been doing for the last 4 hours, I had no idea that the current TWRP [3.2.3.1] made decryption on PIe possible .... I not ref to the PIN/lockscreen/Fingerprint decrypt either > more like decrypting the System partition like with Shamu/N6
**Also** found this during my harried research:
Encrypting does not completely delete the files, but the factory reset process gets rid of the encryption key. As a result, the device has no way it can decrypt the files and, therefore, makes data recovery extremely difficult.

C.Hatfield said:
will the modded flash-all.bat actually work with all the contents of the internal drive being encrypted?
I only ask bc of all the research Ive been doing for the last 4 hours, I had no idea that the current TWRP [3.2.3.1] made decryption on PIe possible .... I not ref to the PIN/lockscreen/Fingerprint decrypt either > more like decrypting the System partition like with Shamu/N6
**Also** found this during my harried research:
Encrypting does not completely delete the files, but the factory reset process gets rid of the encryption key. As a result, the device has no way it can decrypt the files and, therefore, makes data recovery extremely difficult.
Click to expand...
Click to collapse
Yes!
Yes, twrp-3.2.3-1 decrypts.
"**Also** found this during my harried research:
Encrypting does not completely delete the files, but the factory reset process gets rid of the encryption key. As a result, the device has no way it can decrypt the files and, therefore, makes data recovery extremely difficult."
Where did you find that? Link please.

Homeboy76 -
Very much appreciate the feedback !! This is the longest downtime I've experienced, likely-ever but I just couldn't make another move until I was certain it was the correct one.
Here is the link where I found the above info you asked about:
https://android.stackexchange.com/questions/149219/android-decrypt-sd-card-after-factory-reset?rq=1

C.Hatfield said:
Homeboy76 -
Very much appreciate the feedback !! This is the longest downtime I've experienced, likely-ever but I just couldn't make another move until I was certain it was the correct one.
Here is the link where I found the above info you asked about:
https://android.stackexchange.com/questions/149219/android-decrypt-sd-card-after-factory-reset?rq=1
Click to expand...
Click to collapse
Edit: Wrong link, it happens.

this is what it shows me:
It is in the default factory reset state ( like a new device ). You can't decrypt the device even if you wish to as the encryption password (generated from a combination of user lock screen PIN and encryption algorithm ) is lost
From Android's Factory Reset Does Not Wipe Your Data: Here's The Solution
Encrypting does not completely delete the files, but the factory reset process gets rid of the encryption key. As a result, the device has no way it can decrypt the files and, therefore, makes data recovery extremely difficult.

C.Hatfield said:
this is what it shows me:
It is in the default factory reset state ( like a new device ). You can't decrypt the device even if you wish to as the encryption password (generated from a combination of user lock screen PIN and encryption algorithm ) is lost
From Android's Factory Reset Does Not Wipe Your Data: Here's The Solution
Encrypting does not completely delete the files, but the factory reset process gets rid of the encryption key. As a result, the device has no way it can decrypt the files and, therefore, makes data recovery extremely difficult.
Click to expand...
Click to collapse
Yes, if you use this url: https://www.techtimes.com/amp/artic...oes-not-wipe-your-data-heres-the-solution.htm but that is not the url that was in your previous post. This is, https://android.stackexchange.com/questions/149219/android-decrypt-sd-card-after-factory-reset?rq=1
I think it is out dated: Android's Factory Reset Does Not Wipe Your Data: Here's The Solution By Anu Passary | May 27, 2015 11:07 PM EDT

hey homeboy76 tried the flash-all bat [-w removed] and the process went through w/o any issues but it immediately rebooted itself and within 30 seconds landed on the stock recovery & it said file may be corrrupt, TRY AGAIN or FDR ....
Do I have any other recourse to save my 100 GBs of data ??? or do I onlly have the unmoddded flash-all -w to do at this point ?

C.Hatfield said:
hey homeboy76 tried the flash-all bat [-w removed] and the process went through w/o any issues but it immediately rebooted itself and within 30 seconds landed on the stock recovery & it said file may be corrrupt, TRY AGAIN or FDR ....
Do I have any other recourse to save my 100 GBs of data ??? or do I onlly have the unmoddded flash-all -w to do at this point ?
Click to expand...
Click to collapse
Did you check the SHA256 of the March 2019 factory image?
I don't think it would hurt to try again. If it doesn't work you can try FDR or flash-all with [ -w] both will erase your internal storage.

Homeboy76 said:
Did you check the SHA256 of the March 2019 factory image?
I don't think it would hurt to try again. If it doesn't work you can try FDR or flash-all with [ -w] both will erase your internal storage.
Click to expand...
Click to collapse
Soooo, check this out .... I finally got a flash-all {no -w] to work and my phone booted - buuuuut it is STILL ENCRYPTED .... opening the root//file explorer I was horrified to see that everything is still encrypted .... it's soooo bizarre. apps from PS are restoring but I cannot get screenshots to save nor can I move any files from my laptop to my Pixel Xl. I wanted screeenshots so bad to show/post this bizarreness but -no- ....
I havent tried to boot into recovery yet or anything else .... so I dont even have root to look any deeper into the partitions. I was wondering if Titanium Backup would run and populate with proper app names, etc
Any more ideas from this unprecedented point bro >? BTW, the SHA256 was good/clean/proper.
BTW, when you flash a factory image, which facking partition (A or B) -should it- be flashed to or flashed "from" - I've let myself get quite confused >???? I have researched & read sooo much, my brain hurts (& is literally fried) .... I figured I would ask you so I could possibly get some firsthand clarification.

C.Hatfield said:
Soooo, check this out .... I finally got a flash-all {no -w] to work and my phone booted - buuuuut it is STILL ENCRYPTED .... opening the root//file explorer I was horrified to see that everything is still encrypted .... it's soooo bizarre. apps from PS are restoring but I cannot get screenshots to save nor can I move any files from my laptop to my Pixel Xl. I wanted screeenshots so bad to show/post this bizarreness but -no- ....
I havent tried to boot into recovery yet or anything else .... so I dont even have root to look any deeper into the partitions. I was wondering if Titanium Backup would run and populate with proper app names, etc
Any more ideas from this unprecedented point bro >? BTW, the SHA256 was good/clean/proper.
BTW, when you flash a factory image, which facking partition (A or B) -should it- be flashed to or flashed "from" - I've let myself get quite confused >???? I have researched & read sooo much, my brain hurts (& is literally fried) .... I figured I would ask you so I could possibly get some firsthand clarification.
Click to expand...
Click to collapse
I can't help you with the file encrypted problem. I've never read about anything like the problem you're having with encryption. TB might work. If your files are backed up on your computer, FDR.

https://forum.xda-developers.com/showpost.php?p=79273902&postcount=481
@C.Hatfield, continuing the discussion...
Topics
1) Forced encryption
2) Output of ls /data/misc/vold/*
3) Advanced approach

VR25-
First, I'll start with a sincere Thank You - I know you're busy with school & life, so I appreciate that you take the time to create such beneficial tools like Migrator. Having used Android OS since it's inception, I've learned a whole lot & seen a whole lot buuut not this craziness. I was unable to get any actionable help within the 2 weeks that I held out doing a full FDR ....
alas, I finally relented & did a full FDR with a full on flash-all.bat & ironically, it was only a couple hours before your response. I didn't read the response until now because I was afraid you'd posted an A, B, C unencryption method for me - in a small way, I'm glad it isn't that lol ....
As for the "did you..." questions you asked in Migrator thread, I followed my usual protocol & did not vary at all, except running the Migrator script 2x's before trying to install new ROM.

Encryption unsuccessful

I wake up today and saw my phone screen showing multiple horizontal lines scrolling up to down (something like that picture but horizontal not vertical lines : https://i.ibb.co/fv31J1J/gg.png). Immediately thought that my screen was broken and removed battery, restarted phone to verify. And then I was shocked with that message "encryption unsuccessful" (https://www.androiddata-recovery.com/blog/wp-content/uploads/2017/10/hqdefault.jpg). To my knowledge, I know that phone encryption had triggered and was somehow aborted, thus cannot access my phone data again. But, my big question how phone encryption had triggered automatically ??
Hint : the internet was OFF during night. My phone is rooted, and I use Lineage OS (Android 7), my device is Samsung galaxy j3 2016 I'm pretty sure it's not malware.
So I've searched and find that https://android.stackexchange.com/q...nsuccessful-and-bootloop-issue-on-andriod-8-1
It increased my confidence that it's not malware and something like hardware.
And, I noticed When I try to make a backup using TWRP that I got "could not mount /data and unable to find crypto footer". Also, /data partition became 0Mb in size (checked with twrp)
So, please do you have any ideas for what happened ?

kolisani7 said:
I wake up today and saw my phone screen showing multiple horizontal lines scrolling up to down (something like that picture but horizontal not vertical lines : https://i.ibb.co/fv31J1J/gg.png). Immediately thought that my screen was broken and removed battery, restarted phone to verify. And then I was shocked with that message "encryption unsuccessful" (https://www.androiddata-recovery.com/blog/wp-content/uploads/2017/10/hqdefault.jpg). To my knowledge, I know that phone encryption had triggered and was somehow aborted, thus cannot access my phone data again. But, my big question how phone encryption had triggered automatically ??
Hint : the internet was OFF during night. My phone is rooted, and I use Lineage OS (Android 7), my device is Samsung galaxy j3 2016 I'm pretty sure it's not malware.
So I've searched and find that https://android.stackexchange.com/q...nsuccessful-and-bootloop-issue-on-andriod-8-1
It increased my confidence that it's not malware and something like hardware.
And, I noticed When I try to make a backup using TWRP that I got "could not mount /data and unable to find crypto footer". Also, /data partition became 0Mb in size (checked with twrp)
So, please do you have any ideas for what happened ?
Click to expand...
Click to collapse
I'm not sure, what happened. But in your case I would format data and install a fresh lineageOS. I would not set a lock screen password or code. So I avoid unwanted encryption.

kurtn said:
I'm not sure, what happened. But in your case I would format data and install a fresh lineageOS. I would not set a lock screen password or code. So I avoid unwanted encryption.
Click to expand...
Click to collapse
Isn't the phone always encrypted if it's in the keylock state?
The user doesn't have to enter a password and the encrpytion should be weak, but still it should be encrypted (unless encryption hasn't been (automatically) applied. If the phone is working, you can check that in the settings).

User699 said:
Isn't the phone always encrypted if it's in the keylock state?
The user doesn't have to enter a password and the encrpytion should be weak, but still it should be encrypted (unless encryption hasn't been (automatically) applied. If the phone is working, you can check that in the settings).
Click to expand...
Click to collapse
charter/device-support-requirements.md at master · LineageOS/charter
Contribute to LineageOS/charter development by creating an account on GitHub.
github.com

kurtn said:
charter/device-support-requirements.md at master · LineageOS/charter
Contribute to LineageOS/charter development by creating an account on GitHub.
github.com
Click to expand...
Click to collapse
All devices that supported hardware-backed encryption on their stock OS MUST support hardware-backed encryption.
All devices that shipped stock as forceencrypt SHOULD default to forceencrypt enabled.
All devices MUST support software encryption.
Click to expand...
Click to collapse
Okay but that doesn't answer my question, does it?
Would you please elaborate a bit on this one?

User699 said:
Okay but that doesn't answer my question, does it?
Would you please elaborate a bit on this one?
Click to expand...
Click to collapse
Answer is: it's device dependent. Try yourself.

kurtn said:
Answer is: it's device dependent. Try yourself.
Click to expand...
Click to collapse
Well, but how would I try to check its encryption without actually unlocking the keylock?
On Android 11 as well as 11 I can easily access every data via adb if I decrypted my device for the first time (first password after reboot) even tough it is encrypted.

User699 said:
Well, but how would I try to check its encryption without actually unlocking the keylock?
On Android 11 as well as 11 I can easily access every data via adb if I decrypted my device for the first time (first password after reboot) even tough it is encrypted.
Click to expand...
Click to collapse
Can you boot recovery without entering unlock code?

kurtn said:
Can you boot recovery without entering unlock code?
Click to expand...
Click to collapse
Yes, I can (password is set set, device is encrypted).
Code:
adb reboot recovery
OR
Code:
adb shell
reboot recovery

User699 said:
Yes, I can (password is set set, device is encrypted).
Code:
adb reboot recovery
OR
Code:
adb shell
reboot recovery
Click to expand...
Click to collapse
So in recovery you see either clear name or encrypted filenames.

kurtn said:
So in recovery you see either clear name or encrypted filenames.
Click to expand...
Click to collapse
Yes I know.
It's encrypted until I insert my password.