I read somewhere that Shizuku can provide some elevated privileges (like for SwiftBackup). Does anyone know if it can trip Knox?
GitHub - RikkaApps/Shizuku: Using system APIs directly with adb/root privileges from normal apps through a Java process started with app_process.
Using system APIs directly with adb/root privileges from normal apps through a Java process started with app_process. - GitHub - RikkaApps/Shizuku: Using system APIs directly with adb/root privileg...
github.com
It's not root. No Knox trip. I use it plus LSPatch with it too for some xposed modules to work without root
Related
Hello XDA-Forum users,
I ask you a question: How does Android Root works ?
I mean, for example, How does it works in Nexus One ?
This would be an understanding question to know more about how I get root from my Phone (Nexus One, for example) from scratch, from sources.
upupupupupup
Rooting basics:
http://lifehacker.com/5342237/five-great-reasons-to-root-your-android-phone
For details on how to do it on your device, Google or use the forum search. Lots of rooting information that is device dependent out there.
It basically gives your phone permission to do almost anything. It is similar to giving a user in Windows Administrator rights. It is called super user. You can do many things such as removing unwanted apps and overclocking.
This is not what I mean, I asks for an explaining in which the question is "How the root is possible? What active the root ?" Probably a kernel exploit, or stuff like that, to understand the underground passage to take it, from an hack view.
So, How works a root utility (such SuperOneClick) to set gid to 0 ?
Valid question, I am also interested in learning this.
In other words, if I were to perform the rooting manually, where can I find such info?
And some of the question is why su must be in some diredctories, and can't be run from /data/local/tmp for example?
Someone can enlighten us?
diego.stamigni said:
Someone can enlighten us?
Click to expand...
Click to collapse
The general approach is taking advantage of bugs in the android OS
The process works something like this
User crafts some special data that contains a "payload" (the script/executable that we want to run)
User runs a system process that has root privileges and gets it to open the special data
The bug causes the system process to get confused by the data, and ends up running the embedded script
The embedded script runs with the same privileges as the system process, and thus can stuff that normal users aren't allowed to do (e.g. installs the SU app)
Commonly, things such as buffer overflows are used
So after gaining root access, which apps can run as root?
Or the user becomes root(as in desktop), and can run all types of apps?
Can root app(run as root) access everything?? Or app permission still applies?
Is it that system exploit is always used to run root apps?
can someone explain in technical details? not how to root.
are rooting programs open source??
What is the root procedure
Bayint Naung said:
So after gaining root access, which apps can run as root?
Or the user becomes root(as in desktop), and can run all types of apps?
Can root app(run as root) access everything?? Or app permission still applies?
Is it that system exploit is always used to run root apps?
can someone explain in technical details? not how to root.
are rooting programs open source??
Click to expand...
Click to collapse
Hi guys!
I have the same question and after searching and asking find this!
it is good!!
hope it works!
http://stackoverflow.com/questions/...hat-are-the-pre-requisites-for-it-to-work-wha
also look at the suggestedpages at the right of this page!
I'm sure the answer to this question is somewhere there, but I cannot find it. There is plenty of information on how to root your phone or tablet, but not on how the root works on Android.
When I work on my Linux box I usually use a "normal", limited user. Only when I need to install something, I switch to superuser, or root, using "su" or "sudo".What happens on a rooted Android? Do all apps run with root privileges all the time? Or rather some sort of "su" command is unlocked, and an app can access it when required. Can I give and revoke superuser powers to an app?
It is always safer to run all programs or apps with limited privileges, so when they misbehave, the risk to system integrity is minimal. If everything runs in root mode, it might just spectacularly crash one day.
In this context, how does adaway work? Does it start with the system, sitting in the background and using its root privileges to intercept and filter incoming HTTP packages? If I understand this correctly, it should then work with any browser?
Sorry for asking several questions in one topic, but I'd appreciate if someone could briefly explain the whole thing.
There is a superuser app, which seems to be doing the same job as gksu does on a linux desktop. Apps can request root, you can allow/deny. If you use the shell, su works as normal (just no password) - but connectbot needs to be given root privileges in order for this to succeed.
Starting with Android 4.4 SELinux's MAC is enforced. Does this mean that if an app somehow can get installed and exploit the kernel to get root privileges, that MAC will still prevent that app with root privileges from accessing private app data?
Android Documentation says: "SELinux can be used to label these devices so the process assigned the root privilege can write to only those specified in the associated policy. In this way, the process cannot overwrite data and system settings outside of the specific raw block device." source - http://source.android.com/devices/tech/security/se-linux.html#use-cases
As a reference I am implementing a Mobile Device Management system and in the process I have to determine how secure Android OS is itself. That is why I need to know how secure corporate data stored on a device is to root-kits, spyware, and other malware.
p.s. This has been posted on the "Unix and Linux" StackExchange site with no one being able to answer yet. I'm hoping XDA's hands on experience with the Kernel will be able to help get this answered, Thank You .
milleraj66 said:
Starting with Android 4.4 SELinux's MAC is enforced. Does this mean that if an app somehow can get installed and exploit the kernel to get root privileges, that MAC will still prevent that app with root privileges from accessing private app data?
Click to expand...
Click to collapse
The answer is: "It depends."
Mandatory access controls systems like SELinux are very good at constraining application behavior to what is allowed by the security policy. In many cases, it can eliminate huge chunks of security vulnerabilities by sandboxing privileged applications so that exploitation of those applications is ineffective.
You may want to take a look at http://selinuxproject.org/~jmorris/lss2011_slides/caseforseandroid.pdf, specifically slides 7-9. This will give you an idea for what SELinux can and can't defend against.
Has a write-up ever been released on exactly how SuperSu works? After searching around for a while I found mostly guides on who to use the app, no the implementation details.
I did, however, find this official resource that is mostly directed at explaining how to use the root privileges programmatically, but explained things fairly well. The article gives information about SELinux, but not so much how its enforcement is circumvented.
There appears to be a lot of context switching to allow execution of certain events (from the point of view of those using SuperSu) otherwise denied under SELinux, but how did SuperSu get to the point at which it was able to "legally", as far as SELinux is concerned, patch SELpolicies?
It seems that the objective is to force the init process to spawn a new shell that runs the su daemon, but there does not appear to be any patching of the init process, but from the article linked:
On firmwares that use SELinux, su is generally implemented as a proxy to a daemon started from init
Click to expand...
Click to collapse
and
You might wonder why - if we're already running as the init context, as the root user ..
Click to expand...
Click to collapse
-------------------------------------------
tl;dr; How does SuperSu execute in the context of the init process?
Given as:
u:r:init:s0 - Highest init context
u:r:init_shell:s0 - Shell started from init
Click to expand...
Click to collapse
SuperSU does not provide root privilege. Root privilege exists or it doesn't. Someone more knowledgeable can explain it better than I can, but either you have access to the system partition (root), or you don't. What SuperSU and similar apps do is act as a gatekeeper for other apps that utilize root access. Primarily to allow or disallow apps, or certain functions within apps, to do whatever it is they do. And of course, it's also a safety precaution against malware, because malware with root access can cause serious damage.
As for the other questions, I'm not the one to reply; that stuff is beyond me.
OEMs use root/admin and then lock it away like on Linux so Its SuperSU tht is the admin and grants root*admin permission
Planterz said:
SuperSU does not provide root privilege. Root privilege exists or it doesn't. Someone more knowledgeable can explain it better than I can, but either you have access to the system partition (root), or you don't. What SuperSU and similar apps do is act as a gatekeeper for other apps that utilize root access.
Click to expand...
Click to collapse
This is likely misunderstood by many. You are thinking of the SuperSU app that can be downloaded from the app-store. In this regard, you are correct in that it manages root access. However, the application portion of SuperSU is only the front-end; there is an entire back-end solution to SuperSU that patches the system to achieve elevated permissions to be managed by the front-end in the first place. Check out the write-up linked in the OP.
arshad145 said:
OEMs use root/admin and then lock it away like on Linux so Its SuperSU tht is the admin and grants root*admin permission
Click to expand...
Click to collapse
This sounds like a plausible method, but I did not see any mention of this in the article linked in the OP. Could you provide further details or sources for your thought?
Android uses *linux* based kernel
So I know the root part is true but for the OEM just a guess ;p
---------- Post added at 19:07 ---------- Previous post was at 19:01 ----------
If you want to learn more about root just use a linux and go explore its deepest secret
Can be tricky to learn about the function of linux kernel but android is more or less the same
*Simplified description*
arshad145 said:
Android uses *linux* based kernel
So I know the root part is true but for the OEM just a guess ;p
---------- Post added at 19:07 ---------- Previous post was at 19:01 ----------
If you want to learn more about root just use a linux and go explore its deepest secret
Can be tricky to learn about the function of linux kernel but android is more or less the same
*Simplified description*
Click to expand...
Click to collapse
I have used Linux for some time now. It is not the architecture of Linux that I am curious about, though.
You are correct in that root access is locked away in most production phones. This is done simply by allowing the user of the phone to execute as a separate user with lower permissions. SuperSU somehow patches the system to execute a daemon in the same context as the init process, which presumably has the most privileged access from the set of contexts. I am wondering of the architecture of SuperSU such that it is able to achieve this execution.
Oh my sorry for misunderstanding :/
but no idea for SuperSU privilege accesses or loop
but if you debug it on pc u can find something?
*Hopefully*
:fingers-crossed:
---------- Post added at 19:29 ---------- Previous post was at 19:23 ----------
One thing am curious too
Why can't superSU gain permanent root unless bootloader is unlocked???
Like if there is OTA update root is gone unless bootloader unlocked ...
WHY?!
**Curious**
arshad145 said:
One thing am curious too
Why can't superSU gain permanent root unless bootloader is unlocked???
Like if there is OTA update root is gone unless bootloader unlocked ...
WHY?!
**Curious**
Click to expand...
Click to collapse
As far as I know, when a bootloader is "locked" is prevents any sort of reflash of the device unless you otherwise provide some kind of proprietary key (.e.g. to authenticate genuine OEM updates). So, you first need to unlock the bootloader in order to flash a custom recovery, which then gives you support for patching the system with the necessary SuperSU files.
Presumably, just as an educated guess, when you receive a genuine OTA the core patched files for SuperSU are overwritten, thus disabling your prior rootkit.
SuperSU is closed source. Just curious to see if anyone has any background knowledge of its implementation.
It seems not. Although this is disappointing, it was somewhat expected.
Is it possible to build a rom that allows access to the CA trust store? We're deploying android devices in a corporate environment and discovered that after android 7.0 any self installed CA's aren't trusted by apps by default. We would like to eliminate untrusted cert popups in certain apps and the only way to do it is get our internal CA in the cert store but we cannot permanently root the device due to mobile device management software. The manufacturer enables use to a custom rom without rooting but I wasn't sure if you could modify the core OS to allow access to the CA store without rooting to get SU access.