Hi,
I have successfully unlocked my motorola phone using the motolora support
page.
Unfortunately, the motorola device does not have su(1) on it.
If I were to get an su binary from somewhere (like, compile it myself),
and store it on the sd-card or in some download directory, would I
effectively have rooted my device?
Without having to load some unknown binary from some hackers somewhere
(like superSu) in order to do it?
tmellman said:
Hi,
I have successfully unlocked my motorola phone using the motolora support
page.
Unfortunately, the motorola device does not have su(1) on it.
If I were to get an su binary from somewhere (like, compile it myself),
and store it on the sd-card or in some download directory, would I
effectively have rooted my device?
Without having to load some unknown binary from some hackers somewhere
(like superSu) in order to do it?
Click to expand...
Click to collapse
That is not how root works, the su binaries have to be in the /system partition, placing su binaries in user partition does absolutely nothing. What's wrong with using SuperSU?
I DO NOT PROVIDE HELP IN PM, KEEP IT IN THE THREADS WHERE EVERYONE CAN SHARE
Droidriven said:
That is not how root works, the su binaries have to be in the /system partition, placing su binaries in user partition does absolutely nothing. What's wrong with using SuperSU?
Click to expand...
Click to collapse
If it's provided by Google or from the android source tree, then I would feel secure in using it. Other than that, I avoid solutions where I have to take binaries from unverifiable sources.
And in general, everybody offers some (binary) tool to do your rooting for you, but - once the manufacturer lock is removed - I don't understand why linux isn't linux.
tmellman said:
If it's provided by Google or from the android source tree, then I would feel secure in using it. Other than that, I avoid solutions where I have to take binaries from unverifiable sources.
And in general, everybody offers some (binary) tool to do your rooting for you, but - once the manufacturer lock is removed - I don't understand why linux isn't linux.
Click to expand...
Click to collapse
The developer that created the SuperSU app along with many other apps that you might be familiar with is called Chainfire and he's known worldwide, you might have heard of him.
Without him, alot of the custom software and a lot of the tools/apps we use to customize our devices wouldn't exist. He has been pretty much the most influential developer in the entire android rooting and customizing community. If that isn't verifiable enough for you then something is wrong with you. In fact, I'm pretty sure that you have or will require something he developed when you customize your device.
Everyone in this community uses at leat one of his apps.
Android operating system isn't linux, it's based on a Linux kernel but the operating system is very different. The linux kernel is about all that they have in common with a couple of exceptions.
Su binaries aren't something that would ever come from Google or android source tree. It will ALWAYS come from somewhere else other than Google or android source tree, even if you write the su binaries yourself, yours would be just as questionable because they also would not be coming from Google or android source. How would your own su binaries be any different than the ones that already exist?
I DO NOT PROVIDE HELP IN PM, KEEP IT IN THE THREADS WHERE EVERYONE CAN SHARE
Droidriven said:
Su binaries aren't something that would ever come from Google or android source tree. It will ALWAYS come from somewhere else other than Google or android source tree, even if you write the su binaries yourself, yours would be just as questionable because they also would not be coming from Google or android source. How would your own su binaries be any different than the ones that already exist?
Click to expand...
Click to collapse
I've already gotten this URL from Usenet:
(googlesources) /platform/system/extras/+/master/su/
(unfortunately had to obfuscate the URL due to a limitation of the forum)
and have fetched arm-linux-gnueabi-gcc.
As to running from /system, I've seen mention of this:
mount -o remount,rw /system
Now perhaps I understand what that's needed for.
I'm collecting the information bit-for-bit, but am not 100% sure I'll be able to run with my image and without third-party code...
tmellman said:
I've already gotten this URL from Usenet:
(googlesources) /platform/system/extras/+/master/su/
(unfortunately had to obfuscate the URL due to a limitation of the forum)
and have fetched arm-linux-gnueabi-gcc.
As to running from /system, I've seen mention of this:
mount -o remount,rw /system
Now perhaps I understand what that's needed for.
I'm collecting the information bit-for-bit, but am not 100% sure I'll be able to run with my image and without third-party code...
Click to expand...
Click to collapse
If you want root, it will be third party code, regardless of what method, software or tools you use. Root is not a stock android or Google product so third party is the only source.
If you're on lollipop, Marshmallow or nougat then pretty much your only option to root your device is to use one of the universal rooting apps and hope one of them works. Otherwise, you probably won't get root.
I DO NOT PROVIDE HELP IN PM, KEEP IT IN THE THREADS WHERE EVERYONE CAN SHARE
Related
Hello,
first of all, excuse me for my very bad english and if this has been asked before. The reason I'm posting this is because I was trying to add CIFS support to my Nexus 7: I compiled and sideloaded the cifs.ko module correctly and had no luck with mounting (Error: Invalidad argument, any help to fix that is welcome!). I assumed that it was a problem of Android's "mount" command and went to install BusyBox from Google Play, it created a lot of symlinks that I didn't wanted and had to restore original firmware to fix that.
I'm not interested in using apps from Google Play that need root, I just need root privilegies with a terminal in order to use small scripts/programs I make myself or have access to their source code, so I was wondering if there's some kind of "sandbox" mechanism (I've used chroot in Linux and jail in FreeBSD) so I can minimize the probability of screwing up Android filesystem.
Obviosuly, I'm not referring to Android sandbox for its apps.
Thanks!!
CarlosML said:
Hello,
first of all, excuse me for my very bad english and if this has been asked before. The reason I'm posting this is because I was trying to add CIFS support to my Nexus 7: I compiled and sideloaded the cifs.ko module correctly and had no luck with mounting (Error: Invalidad argument, any help to fix that is welcome!). I assumed that it was a problem of Android's "mount" command and went to install BusyBox from Google Play, it created a lot of symlinks that I didn't wanted and had to restore original firmware to fix that.
I'm not interested in using apps from Google Play that need root, I just need root privilegies with a terminal in order to use small scripts/programs I make myself or have access to their source code, so I was wondering if there's some kind of "sandbox" mechanism (I've used chroot in Linux and jail in FreeBSD) so I can minimize the probability of screwing up Android filesystem.
Obviosuly, I'm not referring to Android sandbox for its apps.
Thanks!!
Click to expand...
Click to collapse
If you root and install super user you can prevent any apps using root apart from the terminal app you wish to use, or just make sure you have a backup of your filesystem so if anything does break you can just reinstall via recovery
zacthespack said:
If you root and install super user you can prevent any apps using root apart from the terminal app you wish to use, or just make sure you have a backup of your filesystem so if anything does break you can just reinstall via recovery
Click to expand...
Click to collapse
Thanks for your answer! My idea is preventing myself from screwing up the main fs without the hassle of doing a backup everytime I want to test something.
I've done something like that using 'chroot' in Linux, so I'm curious if the same mechanism can be used in Android.
CarlosML said:
Thanks for your answer! My idea is preventing myself from screwing up the main fs without the hassle of doing a backup everytime I want to test something.
I've done something like that using 'chroot' in Linux, so I'm curious if the same mechanism can be used in Android.
Click to expand...
Click to collapse
chroot works under android however you can not create a chrooted android install (that i know of).
Theres no good way of preventing yourself damaging it apart from just making sure you test each command and do not delete or edit anything you shouldnt be.
Hello everyone,
I would really like to achieve a temporary root on my device. I am running the stock version, recently it updated to 20N for the Android 6.0 MM update.
I am very comfortable with adb and other command line interfaces (I primarily work on Linux servers remotely for my day job).
Are there any good resources for achieving a manual temporary root from adb on this device (or any Android device in general?). I find my Google-Fu searching has been lacking, I haven't found any reliable information on this in general for Android. Ideally, I would like to achieve a temporary root without having to wipe my device or install a new ROM. Am I correct in thinking that some sort of temporary root must be achieved before installing a custom ROM? I am wary of most "One Click" packages out there.... I prefer to do the grunt work and understand why/how something works.
In short, I yearn to see a '#' instead of '$' over an abd connection, specifically for an LG G4 H810 20N, but any general Android process is welcomed! Even being able to mount the filesystem as root (possibly from a bootloader or recovery mode) and access the internal filesystem as root via command line would be considered a success. I primarily want to be able to read/write files that are normally blocked from the standard user.
Thanks in advance!
MisterMagicFingers said:
Hello everyone,
I would really like to achieve a temporary root on my device. I am running the stock version, recently it updated to 20N for the Android 6.0 MM update.
I am very comfortable with adb and other command line interfaces (I primarily work on Linux servers remotely for my day job).
Are there any good resources for achieving a manual temporary root from adb on this device (or any Android device in general?). I find my Google-Fu searching has been lacking, I haven't found any reliable information on this in general for Android. Ideally, I would like to achieve a temporary root without having to wipe my device or install a new ROM. Am I correct in thinking that some sort of temporary root must be achieved before installing a custom ROM? I am wary of most "One Click" packages out there.... I prefer to do the grunt work and understand why/how something works.
In short, I yearn to see a '#' instead of '$' over an abd connection, specifically for an LG G4 H810 20N, but any general Android process is welcomed! Even being able to mount the filesystem as root (possibly from a bootloader or recovery mode) and access the internal filesystem as root via command line would be considered a success. I primarily want to be able to read/write files that are normally blocked from the standard user.
Thanks in advance!
Click to expand...
Click to collapse
Bad news: at this point it's not going to happen. With 6.x you have to have a modified kernel to get root and the locked bootloader on your phone will not allow that kernel to boot. In short: don't expect to see root on Marshmallow on this phone anytime soon and it will probably never happen.
I'm not saying that it's impossible, but it's almost certainly not going to happen.
http://www.xda-developers.com/a-look-at-marshmallow-root-verity-complications/
fatbas202 said:
http://www.xda-developers.com/a-look-at-marshmallow-root-verity-complications/
Click to expand...
Click to collapse
Thanks for the information! I have several 4.x and 5.x devices around and am still hoping to find some general information on manually achieving temp root access of the filesystems.
MisterMagicFingers said:
Thanks for the information! I have several 4.x and 5.x devices around and am still hoping to find some general information on manually achieving temp root access of the filesystems.
Click to expand...
Click to collapse
We are all hoping that you find something that someone else has overlooked! Good luck!
Ok so theres this security exploit or 4 actually that mainly involve sideloading a specially designed apk called quadroot, i assume that you already have an idea what this is if you're reading this if not then google it. I read that alot of the time root access exploits are found by finding apps that have root access and exploiting them to install su to the system partition. In this case you could potentially create your own. So my question is why isn't this being persued as a viable option? Pleas let the people who know what their talking about speak and if you have no legitimate knowledge of your own (im talking google cut paste) then just syfm please.
that-squirrel said:
Ok so theres this security exploit or 4 actually that mainly involve sideloading a specially designed apk called quadroot, i assume that you already have an idea what this is if you're reading this if not then google it. I read that alot of the time root access exploits are found by finding apps that have root access and exploiting them to install su to the system partition. In this case you could potentially create your own. So my question is why isn't this being persued as a viable option? Pleas let the people who know what their talking about speak and if you have no legitimate knowledge of your own (im talking google cut paste) then just syfm please.
Click to expand...
Click to collapse
Interesting. Will look into it. Will update if I find anything.
*UPDATE*
Checked it out. Useless because we still have locked bootloader. We need SYSTEMLESS root. Anything besides that is useless.
I was under the impression that the bootloader being locked only pertains to trying to install unsigned images, the method used for rooting mm in the same manner as lp would require a modified boot.img and no one has a working system image dump for mm being the reason no one can modify the boot.img. if a app was designed to escalate root access to install super su to the system partition and gain root access that way even temporary we could copy the entire system and make a permanent solution.
Hello All! I am me2151.
I am here to tell you some kind of good news.
We have achieved a temporary root shell using a modified recowvery script. Originally Recowvery installed a custom "recovery" but I have modified it to instead create a temporary root shell using the System_Server SELinux context and disable the flashing portion of the script. Yes we are still limited until we can get Kernel or Init context but I am working on that as well.
This exploit will be useful down the line because of one major thing. WE CAN INSERT KERNEL MODULES!!! But they need to be signed. So I am releasing this out here so we can take the next step into our full root! We also have rw to the /data partition and changes save over a reboot.
If we can get someone to sign a kernel module that the system accepts we can set SELinux to permissive.
This exploit SHOULD work for all variants.
NOTE: This should only be used by devs who know what they are doing.
Instructions(this should work on MacOS and Linux only!):
Download linked file below.
Extract to either adb directory OR a directory you have adb access in.
Give execute permissions to temp.sh.
Run temp.sh.
When you are all done with your exploring and stuff type "Reboot" to reboot normally.
https://drive.google.com/open?id=0B8CP3g3AqMuHcmNJUUJWLUJUelE
Credit:
@jcadduono - For recowvery, and pointing me in the right direction on IRC.
@brenns10 - Wrote the lsh used in the exploit to spawn the shell.
The group over here for ideas and solutions.
Very cool work! Glad to see people putting my shell (such as it is) to good use. Wish I had a V20 to try it out
I don't think you'll ever be able to sign a kernel module (SHA512 hash). You'd probably have better luck signing your own boot image.
Here's a theory to toy with:
I think the way to do it would be to gain read access to /init binary allowing you to dirtycow /init with the same init binary but change a very specific (but not vital to system integrity) set of instructions to point back to the setenforce code with a value of 0 without disturbing the rest of the binary/instructions. This way, init should continue running without crashing and taking down the whole system, and you can do something that might trigger that specific instruction set - which would then result in selinux becoming permissive.
This is beyond me, unfortunately. This method would also be very device specific until someone also finds an intelligent way to read init, modify instructions, then dirtycow it back.
I think system server context might be able to read init?
Once you get your permissive selinux, you'll also have to deal with Unix capabilities limitations (find a way around them).
jcadduono said:
I don't think you'll ever be able to sign a kernel module (SHA512 hash). You'd probably have better luck signing your own boot image.
Here's a theory to toy with:
I think the way to do it would be to gain read access to /init binary allowing you to dirtycow /init with the same init binary but change a very specific (but not vital to system integrity) set of instructions to point back to the setenforce code with a value of 0 without disturbing the rest of the binary/instructions. This way, init should continue running without crashing and taking down the whole system, and you can do something that might trigger that specific instruction set - which would then result in selinux becoming permissive.
This is beyond me, unfortunately. This method would also be very device specific until someone also finds an intelligent way to read init, modify instructions, then dirtycow it back.
I think system server context might be able to read init?
Once you get your permissive selinux, you'll also have to deal with Unix capabilities limitations (find a way around them).
Click to expand...
Click to collapse
if system_server can read init then thats a serious flaw.... Question for you. you said it would be very device specific. does that mean its unique for each individual phone or each model?
EDIT:Unfortunately we only have access to the init.rc not the binary it self.
@jcadduono I appreciate your input and direction in this matter another idea we have been toying with is
We have the aboot boot recovery and system dump. From the tmob variant would it be possible to make a tot from that for our devices changing the props to match our device, build, and carrier info? We can also pull apks from /system/apps and /privapps to our ext sdcard
@me2151, @jcadduono, @brenns10: Great work guys, keep it up. Good to see some people are trying for root. What model/s are being tested, or should this theoretically work on all models? Whilst you probably aren't doing it for the cash, there is a bounty I hope someone can claim soon, for a functonal root alone (not boot unlock) posted on this board.
RoOSTA
roosta said:
@me2151, @jcadduono, @brenns10: Great work guys, keep it up. Good to see some people are trying for root. What model/s are being tested, or should this theoretically work on all models? Whilst you probably aren't doing it for the cash, there is a bounty I hope someone can claim soon, for a functonal root alone (not boot unlock) posted on this board.
RoOSTA
Click to expand...
Click to collapse
It should work on all models. I personally use a sprint model(LS997). I think it MAY have been tested on VZW as well.
I can confirm that work on H990DS
Sent from my MI PAD using XDA-Developers mobile app
We know from earlier LG phone releases that the laf partition when bypassed in some way (corrupted, etc) aboot will boot to fastboot when going into download mode. It was my thought that the bootloader could be unlocked from there. However corrupting laf eliminates device recovery. Catch-22.
I think the best way to proceed is to get a working .TOT first which is just a waiting game. That would ensure device recovery and replacing the bootloader in the .TOT and signing it with something unlockable.
This is a great way to explore the locked phones in the meantime, thanks.
ATT Pretty Please
me2151 said:
Hello All! I am me2151.
I am here to tell you some kind of good news.
We have achieved a temporary root shell using a modified recowvery script. Originally Recowvery installed a custom "recovery" but I have modified it to instead create a temporary root shell using the System_Server SELinux context and disable the flashing portion of the script. Yes we are still limited until we can get Kernel or Init context but I am working on that as well.
This exploit will be useful down the line because of one major thing. WE CAN INSERT KERNEL MODULES!!! But they need to be signed. So I am releasing this out here so we can take the next step into our full root! We also have rw to the /data partition and changes save over a reboot.
If we can get someone to sign a kernel module that the system accepts we can set SELinux to permissive.
This exploit SHOULD work for all variants.
NOTE: This should only be used by devs who know what they are doing.
Instructions(this should work on MacOS and Linux only!):
Download linked file below.
Extract to either adb directory OR a directory you have adb access in.
Give execute permissions to temp.sh.
Run temp.sh.
When you are all done with your exploring and stuff type "Reboot" to reboot normally.
https://drive.google.com/open?id=0B8CP3g3AqMuHcmNJUUJWLUJUelE
Credit:
@jcadduono - For recowvery, and pointing me in the right direction on IRC.
@brenns10 - Wrote the lsh used in the exploit to spawn the shell.
The group over here for ideas and solutions.
Click to expand...
Click to collapse
At the moment all I am using root for is to add a line within my build.prop to disable Tethering checks, so I can tether at full 4G speed and not get throttled. Would this be possible using the method above, or would build.prop immediately get replaced at the reboot?
Thanks, and keep up the good work!
NRadonich said:
At the moment all I am using root for is to add a line within my build.prop to disable Tethering checks, so I can tether at full 4G speed and not get throttled. Would this be possible using the method above, or would build.prop immediately get replaced at the reboot?
Thanks, and keep up the good work!
Click to expand...
Click to collapse
no. it is a tcp root shell that can only do a few things such as kernel modules.. only section we were able to write to and have it stick was the /data partition which wont help you in this scenario
elliwigy said:
no. it is a tcp root shell that can only do a few things such as kernel modules.. only section we were able to write to and have it stick was the /data partition which wont help you in this scenario
Click to expand...
Click to collapse
So if we can write to data partition then in theory can we adb push to it using this? I ask because I'd like to install some tbo apps that normally would require flashing. But if we could push them we would be solid
markbencze said:
So if we can write to data partition then in theory can we adb push to it using this? I ask because I'd like to install some tbo apps that normally would require flashing. But if we could push them we would be solid
Click to expand...
Click to collapse
Unfortunately its a tcp shell. not a pure adb shell. so we cannot push or pull to those directories
Wow great progress keep up the good work. You guys are helping those assholes from LG sell more phones. Obviously some people have not made the switch because the lack of root. Root users are very influential leaders to get others to try out a new device.
Sent from my LG-LS997 using XDA-Developers mobile app
Works on the LG G5 also...
Hey guys, with the expectation of many that 'root is coming' to the other v20 models...are we likely to see the same type of root format that applied to the LG G4, where you have to (either) download or rip your own image to a PC. Use commands to insert root, then reflash to the device?
Any root is better than nothing, I know...but I ask because with the amount of software updates for the G4 (v10c software through to v10k before MM came out), meant the sheer amount of times you'd have to go through this process to keep your phone up to date whilst maintaining root was extremely frustrating - as it also meant xposed and related settings/apps needed to be reinstalled each time you performed an OTA update and re-flashed root.
Is this going to be a side effect of dealing with a locked bootloader? PS: If I sound dumb, it's probably because I am.
RoOSTA
roosta said:
Hey guys, with the expectation of many that 'root is coming' to the other v20 models...are we likely to see the same type of root format that applied to the LG G4, where you have to (either) download or rip your own image to a PC. Use commands to insert root, then reflash to the device?
Any root is better than nothing, I know...but I ask because with the amount of software updates for the G4 (v10c software through to v10k before MM came out), meant the sheer amount of times you'd have to go through this process to keep your phone up to date whilst maintaining root was extremely frustrating - as it also meant xposed and related settings/apps needed to be reinstalled each time you performed an OTA update and re-flashed root.
Is this going to be a side effect of dealing with a locked bootloader? PS: If I sound dumb, it's probably because I am.
RoOSTA
Click to expand...
Click to collapse
it shouldnt be an expectation as weve made it clear we do not have root and are hitting hurdles.. we have been advised we need to atack selinux and or the bl but at this point were wanting to try to use debug firmware which hoprfully would allow a bl unlock..
unfortunately nobody can creat a .tot with the debug firmware at al and theres no way at all to flash the images..
we need to somehow leverage an exploit to gain a temp adb root shell before we could even attempt anything and this has not been done in a way thats useful to us..
unfortunately we need more experienced devs at this point.
LG Australia (and as such, Taiwan) have effectively confirmed their H990DS v20 mobile phone's bootloader is confirmed as being unlockable. However (and for no apparent reason) they will not confirm why one region have released a variant of the phone with the bootloader unlock and why they are refusing this to others phones/regions. Because of course, they have zero training and information about anything related to their company expect for goods released in a specific region. That comes from a 'product expert'
Titanium Backup
Howdy,
Just reading through the thread, I understand that it's not quite a "full" root, but would it be enough to run Titanium Backup? I'm hoping to move away from root access with my V20 but it would be really helpful if I could do it temporarily, restore some application and data backups, reboot and uninstall Titanium.
Tim
Hello, is there a way to root the phone where everything works now (Bluetooth, Face ID, etc.)?
I would very much like to see this answered. I've seen some application-specific instructions such as this reddit thread for enabling Samsung Health, and I've read about hiding the fact that the phone is rooted from apps by using MagiskHide, but it's not clear whether this works for all apps and features or just some. There's also this recently updated guide to rooting that claims:
Magisk is a highly advanced way of rooting android systemless-ly. This means that Magisk root android without changing or modifying the system partition. Hence you can receive OTA updates, run apps that require to pass Google’s SafetyNet tests.
Click to expand...
Click to collapse
However, many hacks that sound good when you read about them in advance run into snags and gotchas once you actually get into implementing them, and I'm hesitant to just give it a try and see how it works out when tripping Knox is irreversible and if things stop working you can't get them back by flashing the stock ROM.
I'd be grateful if anyone who has actual experience on this subject could vouch for being able to re-enable all lost functionality after rooting or to not lose it in the first place, or whether even some lost functionality can be enabled (and if so, what have you been able to get working and what haven't you? I don't know about OP, but to me the most important ones are Secure Folder and Samsung Health).
Also, does anyone have experience with retaining Knox-sensitive functionality on rooted S9 Exynos with Android 11 (either rooting after upgrading to 11, or rooting first and retaining root when upgrading)?
@bis225
IMO noone needs Magisk to root a device's Android. Rooting Android means having the SU-binary present on Android - a ~100KB file - nothing else. Copying SU-binary onto Android allows you to temporariy give you root access when needed.
jwoegerbauer said:
@bis225
IMO noone needs Magisk to root a device's Android. Rooting Android means having the SU-binary present on Android - a ~100KB file - nothing else. Copying SU-binary onto Android allows you to temporariy give you root access when needed.
Click to expand...
Click to collapse
I'm not sure I understand what you're saying. Are you telling me that you can simply copy the file onto an unrooted phone, and voila, you can gain root access?? Can you point to information about what to do and how this works? It runs contrary to everything I've ever read on the subject.
To the best of my understanding, in order to install su binary unto an unrooted phone you need to install a custom recovery, and use that to flash the su binary onto the phone. I thought the idea of Magisk was to provide root access without modifying system files so that SafetyNet can't detect that the system has been modified. Unless I'm missing something there's no disadvantage to rooting with Magisk, only advantages, but regardless, I don't see how it makes a difference with respect to this topic. Installing a custom recovery is what trips Knox and prevents some features and apps from working, so it doesn't really matter what root method you use if you have to use a custom recovery to install it.
If you know of a way to root a Galaxy S9 without using a custom recovery or tripping Knox and that can't be detected by SafetyNet, please elaborate.
Rooting Android simply means to add a ( hidden ) user called root ( AKA super-user ) who has ALL rights to Android's file system.
For example from within ADB you activate this user and let run him any command what requires to have ALL rights - assumed the SU-binary is located in /sdcard
Code:
adb shell "/sdcard/su -c '<command-here>'"
AFAIK Magisk installs the SU-binary in /data/adb/magisk/busybox, but I may err.
@jwoegerbauer
But I didn't ask what rooting means. Unfortunately, this doesn't answer any of my questions.
I think I clearly expressed that neither a Custom Revovery nor Magisk itself is needed to have root, that simply copying SU-binary to Android's user-space is enough.
If you want to root via Magisk then do it.
Personally never would do it this way.
jwoegerbauer said:
I think I clearly expressed that neither a Custom Revovery nor Magisk itself is needed to have root, that simply copying SU-binary to Android's user-space is enough.
If you want to root via Magisk then do it.
Personally never would do it this way.
Click to expand...
Click to collapse
This really seems contrary to everything I've read, and this Stack Exchange thread specifically explains why that wouldn't work, but if you say you have experience with this and it works for you, I'm certainly willing to give it a try and see how far it gets me. Do you know where a copy of the su binary can be obtained? All my searches for su binary lead to the supersu APK and instructions for installing it by flashing, or something along those lines. I can't find an su executable that can just be copied to internal storage as-is anywhere.