Hello,
let's assume I have a super-secure Android phone that's known for not being rootable. Let's also assume, I've successfully tried the Janus vulnerability and was able to replace the classes.dex of a system app with a slightly modified one.
As far as I understand it, using the Janus vulnerability, you can only replace the classes.dex but no resources. So whatever is in the classes.dex can only work with the resources already there.
Now the big question: Is there any classes.dex that doesn't depend on specific resources and that I could use to get e.g. a root shell?
I'll try to change a System app to gain higher rights, but i doubt this will be enough to write to system.
github.com/wegeneredv-de/CVE-2017-13156
Use Janus vulnerability to get root access ?
No, I think you can't really. It is maybe possible to root using this exploit by editing a system app because system apps have more rights than "normal" apps which are installed in /data partition. If you really want to use janus exploit to root your phone, try to find a privilege escalation exploit and edit an app to make it execute the exploit. But I think "normal" rooting methods are more efficients. You can install any app on your phone or update any apps, so you don't need Janus. Executing privilege escalation exploit is the only way to root your phone with no (not at 100% true, you can root your phone using recovery, but it is not the subject)
I hope I have helped you,
Have a n1ce day,
Luca
PS : Don't hesitate to thanks me
Yes, you can. You can edit the system upgrade app to make it install a special package (that should be signed by recovery) to root your phone I think.
lucahack said:
Yes, you can. You can edit the system upgrade app to make it install a special package (that should be signed by recovery) to root your phone I think.
Click to expand...
Click to collapse
There's no easier way? Something like copying a "su" binary to somewhere and setting a few filesystem permissions?
mbirth said:
There's no easier way? Something like copying a "su" binary to somewhere and setting a few filesystem permissions?
Click to expand...
Click to collapse
The easiest way is to flash supersu in a custom recovery to root. (link to supersu flashable : https://s3-us-west-2.amazonaws.com/supersu/download/zip/SuperSU-v2.82-201705271822.zip )
lucahack said:
Yes, you can. You can edit the system upgrade app to make it install a special package (that should be signed by recovery) to root your phone I think.
Click to expand...
Click to collapse
I've been looking into that for awhile. I thought it was possible using dirtycow also maybe.
How would a special package still be usable and signed by the recovery?
Wouldn't modification break the recovery signing?
Delgoth said:
I've been looking into that for awhile. I thought it was possible using dirtycow also maybe.
How would a special package still be usable and signed by the recovery?
Wouldn't modification break the recovery signing?
Click to expand...
Click to collapse
If you extract your ota certs from a valid OTA and sign the injected update.zip with those valid signatures it may be possible. That's the latest I've been looking into but the updater binaries are so complicated I don't know how it will work. I think the best option is smali edit within an app like testmode.apk on the K1 that can manipulate system properties and shared preferences. Once you can allow the properties to allow insecure adb or debuggable = true or secure = false you can do the rest of the work in adb. But BB probably has protections that will nullify on reboot.
jcrutchvt10 said:
If you extract your ota certs from a valid OTA and sign the injected update.zip with those valid signatures it may be possible. That's the latest I've been looking into but the updater binaries are so complicated I don't know how it will work. I think the best option is smali edit within an app like testmode.apk on the K1 that can manipulate system properties and shared preferences. Once you can allow the properties to allow insecure adb or debuggable = true or secure = false you can do the rest of the work in adb. But BB probably has protections that will nullify on reboot.
Click to expand...
Click to collapse
I have the Verizon test keys for the G925V 4CPI2 6.0.1, but my s6 edge is currently out of commission until I can find the signed bootloader binaries to upload to the device over the serial port. SDB and SDC are completely gone. I need to inject the data, but don't know the map of the sboot.bin
I had the same idea though. I'm glad I wasn't the only one. It got lost in the cracks because of other projects going on. I saw some malware one time that would install itself by piggybacking on the ota system update process, when you scheduled the update to occur five minutes from the current time. And that process I do believe relied on using a modified CSC or Cache once the process started.
Related
NOTE: DO NOT DO THIS UNLESS YOU KNOW WHAT YOU ARE DOING, YOU CAN EASILY SCREW UP YOUR SYSTEM, AND THIS WON'T HELP YOU.
BACKUP FIRST, AND MAKE SURE YOU HAVE A SETUID SH AS ROOT SO YOU CAN RECOVER FROM BACKUPS IF NECESSARY.
First you have to re-sign framework-res.apk using testkeys. This will allow you to use testkeys for system uid packages.
Next step is to re-sign all other apks that use shared uid system.
That is: bootinfo, Fota, GoogleCheckin, GoogleSubscribedFeedsProvider, NetworkLocation, ServiceMenu, Settings, SettingsProvider, VpnServices
Next you have to re-sign all apks that use the platform key, which turns out to be the shared uid phone - these require implicit permissions from the platform like DEVICE_POWER:
TelephonyProvider, Stk, semc-backup-rachael, Phone
Finally, I think GoogleEnhancedSearch also needs it or something otherwise a settings menu will fc.
The nice part about re-signing is that you don't actually need to deodex the files.
One important thing is that in the new versions, the fota.action.DEBUG_ENTRY is actually disabled, and moreover, requires special permissions that aren't granted. This is where re-signing comes in.
Now, you need to deodex fota.apk, modify the manifest to remove permissions required for DEBUG_ENTRY, and finally, force enable the debug menu:
In com/sonyericsson/android/fota/common/fotaview/FotaDebugEntry.smali,
find "debug UI is not available!"
a few lines above, there is if-nez v0 :cond_0
change it to if-eqz v0 :cond_0
This forces it to enable the debug menu.
Now we re-smali the Fota.apk, re-sign, then push it on to the phone along with the rest of the modified packages.
Repush all the files to the phone and it's done
problem !
baksmali gives an error at fota.apk
can you post your deodex scrypt
Why is this required?
TechGuru_x10 said:
Why is this required?
Click to expand...
Click to collapse
So that you won't have to keep re-flashing the older firmware to root (and keep re-installing stuff afterwards), and it should save time in repairing your firmware if you mess system files up.
It should also allow us to upgrade to newer firmwares from the current one, so we don't have to lose all of our apps/settings when rooting our phones again with a newer firmware.
Is this right guys? Anyway, thanks and good luck!
jerpelea said:
problem !
baksmali gives an error at fota.apk
can you post your deodex scrypt
Click to expand...
Click to collapse
You need to add the classpath by deodexing everything in the framework folder and including it.
zephyrix said:
You need to add the classpath by deodexing everything in the framework folder and including it.
Click to expand...
Click to collapse
oki
will try
thanks
found my error
i was using smali1.2.2 tested with 1.2.3 and is working
jerpelea said:
oki
will try
thanks
found my error
i was using smali1.2.2 tested with 1.2.3 and is working
Click to expand...
Click to collapse
Could these steps be made into a script, to run everything at once? Or at least in sections?
Daneshm90's autodeodexer 2.3 modified by me for X10
http://hotfile.com/dl/53736770/16a1bc8/Deodexer_2_3_SE.rar.html
So eventually (with this) we can take a newer build and run this script thus allowing us to then run the files necessary for root?
what do you mean by newer builds like R2BA020
Sorry if Im being a noob but lets say I mess up a framework file and get stuck at the bootscreen. When I try to use adb to push my backup it says permission denied. Will this allow me to make the changes?
Well what I've done is use a modified adb which runs as root and replaces on boot. However, I believe you could use a setuid sh and achieve the same result.
i.e. cp /system/bin/sh /system/bin/rootsh
chmod 6755 /system/bin/rootsh
then you can push to a folder where you can normally write, and use rootsh and move it.
Great thanks, I'm going to wait until I have to try it...
This is not a question about how to root the Atrix. I've already done that.
My question is about what actually is changed in the phone by following the root procedure. (I searched the forum but didn't find elsewhere the answers I look for).
Why do I ask?
1) Because I'd like to have a better understanding of the android OS.
2) Because I'd like to understand and know what do I need to do in case I want to unroot and return to plain stock.
My case:
(I've just rooted my Atrix. I didn't unlock it)
I've followed the "manual" procedure proposed by BriefMobile.
I can essentially understand (more or less) the commands listed (mount, remount, cp, install, chmod 6755, flash...)
What I'd like to understand better is what changes does the command
Code:
fastboot flash preinstall root.img
Does it just copy new files? Or does it copy (and replace) files on the phone?
(In the second case I'm afraid I made a mistake in not backing them up before running that command...)
Thanks in advance for your help.
Putting it in Windows terms (because Android is Linux), root is like having administrator privileges on your computer. It allows you to modify any system files that would normally be kept locked down. It also allows you to run applications, such as SetCPU, which can directly control hardware (in this case CPU frequency/speed and voltage) and low-level system files. Root in Android is comprised of two main files: the "su" binary (which is the command that applications use to invoke a request to do something with root privileges) and the SuperUser.apk (SuperUser app that's in the app drawer). The SuperUser app exists to prompt you whenever an application asks for root permission. So if you go into the terminal and type a low-level command, you'll see something like, "You do not have permission to do this". But if you type "su" before the command, it will run if you hit "Allow" on the SuperUser request.
Get it?
Product F(RED) said:
....
Get it?
Click to expand...
Click to collapse
Thanks Product F(RED) .
Yes I got it.
I already knew what rooting means in general terms.
What I really asked (sorry if I wasn't clear enough) is what does the root "physically" change on the phone.
According to your answer I assume it just adds the "su" binary and the "SuperUser" app (apart from changing some permission on some system folders) and that it doesn't replace any "stock" system file.
I also assume that these new files are extracted from the "root.img" (or "preinstall.img") files flashed by the fastboot command.
Is it so?
I was a little confused because I saw in some other forum a reference to some "stock" files wiped out in the /preinstall/app/ folder by the root process, mining the reversibility of the procedure (in case of no previous full system backup).
sphere314 said:
Thanks Product F(RED) .
Yes I got it.
I already knew what rooting means in general terms.
What I really asked (sorry if I wasn't clear enough) is what does the root "physically" change on the phone.
According to your answer I assume it just adds the "su" binary and the "SuperUser" app (apart from changing some permission on some system folders) and that it doesn't replace any "stock" system file.
I also assume that these new files are extracted from the "root.img" (or "preinstall.img") files flashed by the fastboot command.
Is it so?
I was a little confused because I saw in some other forum a reference to some "stock" files wiped out in the /preinstall/app/ folder by the root process.
Click to expand...
Click to collapse
Pretty much, yes, you're adding those two files (as well as another called BusyBox that allows other files to run, but this you can install after you root). The scenario I'm describing is that you're on a stock ROM and you just rooted your phone for the first time.
Though fastboot is present on every phone, using it to flash those two files seems to be unique to your phone because rooting methods vary from phone to phone. But basically the two most common methods are:
1. You flash a custom recovery from your computer if your phone's bootloader is not locked, and then you can flash the root files (su/SuperUser.apk) to the ROM from there or just flash a custom ROM that includes them.
or
2. You use fastboot/adb/some third-party method to root the stock ROM on your phone from your computer, then you install a custom recovery, and then you can flash custom ROMs/kernels/etc.
That /preinstall/app folder seems to be unique to your phone, but if I had to guess, it has something to do with deleting preloaded bloatware that comes with the phone. Because out of the box you can't, but once you have root permissions, you can go to that folder with a file manager to delete the APKs or use something like Titanium Backup to do it.
Product F(RED) said:
Pretty much, yes, you're adding those two files (as well as another called BusyBox that allows other files to run, but this you can install after you root). The scenario I'm describing is that you're on a stock ROM and you just rooted your phone for the first time.
Though fastboot is present on every phone, using it to flash those two files seems to be unique to your phone because rooting methods vary from phone to phone. But basically the two most common methods are:
1. You flash a custom recovery from your computer if your phone's bootloader is not locked, and then you can flash the root files (su/SuperUser.apk) to the ROM from there or just flash a custom ROM that includes them.
or
2. You use fastboot/adb/some third-party method to root the stock ROM on your phone from your computer, then you install a custom recovery, and then you can flash custom ROMs/kernels/etc.
That /preinstall/app folder seems to be unique to your phone, but if I had to guess, it has something to do with deleting preloaded bloatware that comes with the phone. Because out of the box you can't, but once you have root permissions, you can go to that folder with a file manager to delete the APKs or use something like Titanium Backup to do it.
Click to expand...
Click to collapse
Thanks again Product F(RED).
Things are clearer now.
I wasn't aware of the installation of "BusyBox" (I found it in my phone in the folder /osh/bin/)
I think the root method I used (BriefMobile) is the type 2. I didn't install a custom recovery as I'm not interested yet in flashing custom ROMs/kernels/etc.
So, to summarize...
The basic root methods (no unlock) consists in
1) install the "su" binary
2) install the "busybox" binary
3) install the "superuser.apk" app
4) change some r-w permissions
In my case (probably) the root method also wiped out some preloaded bloatware file in the /preinstall/app folder but that's not essential (unless Moto makes a check for the presence of those files before an OTA update).
They usually do check (and will fail) because OTA's are like patches; not really replacements for the whole /system/ partition. Never take an OTA when you're rooted, especially because they can do things like update and lock your bootloader, among other things. It's safer to wait until rooted versions pop up in the development section for your phone.
I am running stock DNA, rooted, and with CWM touch recovery. For myself, being root is not merely a luxury, it is a need. Most importantly, I cannot stand having a crippled unix terminal without busybox, which of course, requires root.
I know not what the imminent OTA will bring, but root is too precious to risk losing. I would therefore like to engage in a DNA-specifc discussion about disabling the OTA update.
From what I can tell so far, the two methods include:
1) renaming the otacerts.zip file in /etc/security to a .bak file. This will not work in the present case, since /etc is mounted at /system/etc, and /system can only temporarily be mounted rw due to us being stuck with "S-ON" for now.
2) installing "FOTAkill.apk", or, flashing its corresponding zip (attached below) in custom recovery. Again, in the present case, this file was written for the EVO, and will most certainly not work. The updater-script in the zip can be modified to reflect the correct mount points, but there is a corresponding binary which I have no clue contains what, and would certainly need some expert opinion about.
Any ideas ye fine fellers?
You could always do load ota root keeper from the market back your root up temp un root via app update ota and then re root using the app, I have done this on other devices and I never lost root. Worked well. Might be worth a shot.
Sent from my HTC6435LVW using xda app-developers app
manzdagratiano said:
I am running stock DNA, rooted, and with CWM touch recovery. For myself, being root is not merely a luxury, it is a need. Most importantly, I cannot stand having a crippled unix terminal without busybox, which of course, requires root.
I know not what the imminent OTA will bring, but root is too precious to risk losing. I would therefore like to engage in a DNA-specifc discussion about disabling the OTA update.
From what I can tell so far, the two methods include:
1) renaming the otacerts.zip file in /etc/security to a .bak file. This will not work in the present case, since /etc is mounted at /system/etc, and /system can only temporarily be mounted rw due to us being stuck with "S-ON" for now.
2) installing "FOTAkill.apk", or, flashing its corresponding zip (attached below) in custom recovery. Again, in the present case, this file was written for the EVO, and will most certainly not work. The updater-script in the zip can be modified to reflect the correct mount points, but there is a corresponding binary which I have no clue contains what, and would certainly need some expert opinion about.
Any ideas ye fine fellers?
Click to expand...
Click to collapse
There are system writable kernels out there, and you can always rename your files in recovery. S-Off is not an issue in this scenario.
delete checkinprovider.apk, cotaclient.apk, and updater.apk from /system/app
Jaggar345 said:
You could always do load ota root keeper from the market back your root up temp un root via app update ota and then re root using the app, I have done this on other devices and I never lost root. Worked well. Might be worth a shot.
Click to expand...
Click to collapse
I have indeed heard this alternative thrown around but I am not willing to chance it; I have seen an equal amount of horror stories about people having their systems fried with this method (the Droid X for instance, which I had and where the last update broke root).
SolusCado said:
There are system writable kernels out there, and you can always rename your files in recovery. S-Off is not an issue in this scenario.
Click to expand...
Click to collapse
I will look at what's out there and if it is stable enough to be flashed. How does one rename files in recovery though? I rebooted into CWM (touch) and I see no such option - unless you can remount a partition and rename files in it somehow.
nitsuj17 said:
delete checkinprovider.apk, cotaclient.apk, and updater.apk from /system/app
Click to expand...
Click to collapse
This avenue seems promising. Has anyone tried this before? Also, how does one delete these in the S-ON situation? (I'm assuming recovery is the answer). I feel if I remounted rw, deleted and then rebooted, they will be right back where they are.
manzdagratiano said:
This avenue seems promising. Has anyone tried this before? Also, how does one delete these in the S-ON situation? (I'm assuming recovery is the answer). I feel if I remounted rw, deleted and then rebooted, they will be right back where they are.
Click to expand...
Click to collapse
If you install a kernel with /system writing enabled you can just delete them normally.
Sent from my HTC6435LVW using xda app-developers app
Bigandrewgold said:
If you install a kernel with /system writing enabled you can just delete them normally.
Click to expand...
Click to collapse
Great... thanks! I am looking into custom kernels. By the way, if custom kernels that do allow write to /system can be concocted, why is S-ON an issue at all? I was under the impression that this has to do with NAND memory being inaccessible, which seems to be a lower level issue than the kernel.
manzdagratiano said:
Great... thanks! I am looking into custom kernels. By the way, if custom kernels that do allow write to /system can be concocted, why is S-ON an issue at all? I was under the impression that this has to do with NAND memory being inaccessible, which seems to be a lower level issue than the kernel.
Click to expand...
Click to collapse
With s on we can not.
Flash radios
Flash kernels in recovery.
Change the splash screen
Go back to a locked bootloader
And a few other things I'm probably forgetting.
Sent from my HTC6435LVW using xda app-developers app
Before you read this trough : This is not a question about how to root my phone or add root access to an app. This is about how I can add root acess to my phone. I mean like ading root acess to a phone where no root is yet released. If anyone knows a github repo with the commits of adding root to the phone, please tell me. Thanks!
CTXz said:
Before you read this trough : This is not a question about how to root my phone or add root access to an app. This is about how I can add root acess to my phone. I mean like ading root acess to a phone where no root is yet released. If anyone knows a github repo with the commits of adding root to the phone, please tell me. Thanks!
Click to expand...
Click to collapse
you don't want to root device (for example: kingo root, Iroot, etc) u want to compile su file or what??
Paget96 said:
you don't want to root device (for example: kingo root, Iroot, etc) u want to compile su file or what??
Click to expand...
Click to collapse
I currently don't look to compile for a specific device but I want it as basic knowledge when it comes to the case of a new device that has no root yet.
CTXz said:
Before you read this trough : This is not a question about how to root my phone or add root access to an app. This is about how I can add root acess to my phone. I mean like ading root acess to a phone where no root is yet released. If anyone knows a github repo with the commits of adding root to the phone, please tell me. Thanks!
Click to expand...
Click to collapse
"How I can add root access to my phone" = root your phone? There's not much difference between the two sentences. Unless you mean adding the root path to the device without installing SuperSU or any other SU app?
popthosegaskets said:
"How I can add root access to my phone" = root your phone? There's not much difference between the two sentences. Unless you mean adding the root path to the device without installing SuperSU or any other SU app?
Click to expand...
Click to collapse
Look. You have a phone that doesn't have root access. So what I would do is go to xda, find a root IMG to flash on my phone and then flash it. That would give me root access to the phone. The thing is, if there is no flashable IMG I would develop one by myself. Now I can't find any tutorials or sources of how to build a image like that.
Sent from my SM-G800F using XDA Free mobile app
1. Such methods would depend on your phone, not all phones go through .img file flash.
2. Usually I would associate .img files as kernel. So I assume you want to flash a custom kernel?
3. If you indeed want to flash a custom kernel, you still need root on the ROM before the custom kernel can have root access.
CTXz said:
Look. You have a phone that doesn't have root access. So what I would do is go to xda, find a root IMG to flash on my phone and then flash it. That would give me root access to the phone. The thing is, if there is no flashable IMG I would develop one by myself. Now I can't find any tutorials or sources of how to build a image like that.
Sent from my SM-G800F using XDA Free mobile app
Click to expand...
Click to collapse
There are several steps to go about to developing a rooting procedure for a device when none has been released yet. The first key step would be to identify whether the device has a looked bootloader. If it does then you will need to resort to an exploit to gain root access rather then flashing a pre-rooted boot.img for example unless you can figure you a way of bypassing the img signature check which in many cases using an exploit is easier. A good basic place to start looking for exploits is here. You will then have to do research on how to exploit the security flaw which involves knowledge of Assembly, C, and Linux. If the bootloader is unlocked you can attempt to make a superboot or autoroot type boot.img which I would suggest taking an existing .img of those types and disasembling them to learn how they were created. Let me know if you still have any questions.
Hi everyone. I'm trying to root my Alcatel 1T 7 8067, by using TWRP 3.2.1 and zip SuperSu images, but rooting was unsuccessful.
The last successful root that I got with that method, was on a marshmallow android device (a CATS60), with no issues; but on my recent device (with oreo go), when I try to install supersu by TWRP option "install", it begins to install, and the process log shows apparently an error: "Patching Sepolicy -----Failure, aborting", and when I reboot to system, there is no root access.
As result of those failed attempts, I have tried by installing old versions of supersu with apparent success, but then, when I try to boot the device, it enters into a bootloop.
So I think, that unsuccessful rooting is related to that Sepolicy error ¿Am I right?
I've noticed that there's no SU folder inside /system folder, so, as I understand, it means supersu wasn't installed (I can see that by using the TWRP's file explorer).
So ¿What can I do with that issue?
I've read that Magisk can solve this problem. Following tutorials about, I tried by flashing a magisk patched boot image, but supersu installation issue still continues.
I must say, that I prefer supersu over magisk, because is more familiar to me, but in general what I need, is a system root, a real root access; not a systemless root; and based on my experience, I only can get that with supersu.
@Camilo Gil I don't really understand your point "real root access".
On my Magisk rooted devices I can access any system file and even change it externally and write it back into system.
I used SU previously but as further development has stopped I had to switch anyway.
superSU? do you live in 2010? get rid of that old stuff and use magisk, SupeSu is totally useless in android 7+
bmwdroid said:
@Camilo Gil I don't really understand your point "real root access".
On my Magisk rooted devices I can access any system file and even change it externally and write it back into system.
I used SU previously but as further development has stopped I had to switch anyway.
Click to expand...
Click to collapse
By real root access, I want to mean, that SU binaries are installed on /system folder. As I understand, if that requirement is given, all apps that need root access, can fully work, without any limitations. Recently, I tested magisk, supposedly my device already had root access. Then I installed ES file explorer to give it root access, and it was granted on magisk but root access couldn't be activated in the app. That never happened me before.
As I understand, that's because ES file explorer couldn't find SU binaries, because magisk root method is systemless root.
I hope I would explain myself right.
tutibreaker said:
superSU? do you live in 2010? get rid of that old stuff and use magisk, SupeSu is totally useless in android 7+
Click to expand...
Click to collapse
¡More o less! I live in 2018, or at least that was the last date when I rooted a device (CAT S60, android 6.0). I don't trust on Magisk, just because I couldn't give root access to ES file explorer. That never happened me before. And I know there are many more file explorers; I know that Es file explorer is kinda deprecated, and root explorer works fine; but I want a root access on which any app that needs root access, and that I want to install obviously, can work without any limitation. My firsts impressions of magisk root is that it cannot provide that service.
Now, what you say that supersu is useless, it's worrying to me, because I can't see any other alternative for root access.
¿Why do you say it's useless?
Camilo Gil said:
¡.... I want a root access on which any app that needs root access, and that I want to install obviously, can work without any limitation. My firsts impressions of magisk root is that it cannot provide that service......
Click to expand...
Click to collapse
Yes it can but in a different way.
You're asked once to grant root privileges for each app that needs it and if you let it have root that's it.
Or you grant root temporarily and will be asked every time for this app.
Apps that don't need it don't get it.
You can change your decision afterwards as well.
Btw I use Total Commander with LAN plugin to access my NAS.
bmwdroid said:
Yes it can but in a different way.
You're asked once to grant root privileges for each app that needs it and if you let it have root that's it.
Or you grant root temporarily and will be asked every time for this app.
Apps that don't need it don't get it.
You can change your decision afterwards as well.
Btw I use Total Commander with LAN plugin to access my NAS.
Click to expand...
Click to collapse
With magisk, I grant root access to ES file explorer, but I can't enable it on the app. As I read, that's because ES File Explorer can't find SU folder in system folder (which actually happens on system root), and because of that, some apps like es file explorer, won't detect systemless root or better, to them, systemless root is detected as non root access.
I read that even supersu must be installed as systemless root, because if installed as system root (or what I refer as "real root") on android 7+, causes bootloops. On my particular case, system root causes an endless boot. As I understand, that happens because supersu can't set /system folder to R/W, on android 7+.
On the other hand, I know there are several alternatives to ES file explorer, for instance Root Explorer, Total Commander, etc. But it's just I'm accustomed to it. But also I read that systemless root not only can cause issues with ES File explorer, but also with Viper4android and some other Xposed modules.
PS 1: We should suggest to google, that release an official rooted android version, specially addressed for us, the medium skilled and advanced android users (that normally we like to root android and get the most of it).
PS 2: So finally ¿is there any way to have a working system root access in oreo, or systemless root is the only option?
Camilo Gil said:
... because if installed as system root (or what I refer as "real root") on android 7+, causes bootloops.
Click to expand...
Click to collapse
I can't remember on which LOS version or when I used it the last time before switching to Magisk.
Camilo Gil said:
On my particular case, system root causes an endless boot. As I understand, that happens because supersu can't set /system folder to R/W, on android 7+.
Click to expand...
Click to collapse
Idk
Camilo Gil said:
On the other hand, I know there are several alternatives to ES file explorer,
Click to expand...
Click to collapse
There seem to be several with that name so just tell me it's full correct name and I will install it on my Magisk rooted LOS14.1=Nougat tablet and see if I get problems with it.
Camilo Gil said:
... Viper4android and some other Xposed modules.
Click to expand...
Click to collapse
don't use them so can't tell
Camilo Gil said:
PS 1: We should suggest to google, that release an official rooted android version, specially addressed for us, the medium skilled and advanced android users (that normally we like to root android and get the most of it).....
Click to expand...
Click to collapse
afaik the pure Vanilla is the base from which most custom ROMs are built by the devs and imo most ROMs you can get are not rooted as it's of course a safety hazard.
bmwdroid said:
afaik the pure Vanilla is the base from which most custom ROMs are built by the devs and imo most ROMs you can get are not rooted as it's of course a safety hazard.
Click to expand...
Click to collapse
I know a rooted android is a security and stability hazard of the device. But evidently who wants to root his/her device, is fully warned about its potential consequences. So google could publish a prerooted version, previously warning about its use, warning that its use is exclusively under user responsability, and maybe disclaiming liability for damages. I guess there's no problem if users of that (at the current moment) imaginary OS , are aware of the risk that they are taking by using it. At least, I would use it if could (and as it doesn't exist, it's because I'm trying to root my current one).