Related
Hi all, i've just picked up a G2 today to replace my ageing N95, loving it so far. I've a few questions for you experts if thats ok -
Is the G2 the same as the Hero or can I flash the firmware to get rid of the Tmob stuff?
Can someone tell me in a nut shell what 'rooting' is?
Is the web'n'walk browser on G2 the same as the original HTC on? I thought it was meant to support full flash but i can't get some things to work?
Can you set individual ringtones and ring volume for each scene?
Thanks in advance!
Flash apps build targeting the newest flash technology aren't supported. Apparently this will be rectified in October (although when HTC will push this update on to us is unknown, at least it should be available in custom ROMs)
In a nutshell, rooting allows you full control over your phone. Linux systems are built around strict access control policies and the Android is locked to only allow you default user permissions. "Root" is the name of a profile common to all linux distributions, with the highest permissions possible - a super user that can do anything. Rooting your phone allows you access to step your permissions up to root level.
This is useful for doing things that you are normally locked out of - changing core parts of the OS. For now, there isn't much useful to do with it (app2sd is about it) and deleting packaged software from the firmware that you don't want. This will change as Android becomes more popular and there are more interesting things to do.
kiz said:
Flash apps build targeting the newest flash technology aren't supported. Apparently this will be rectified in October (although when HTC will push this update on to us is unknown, at least it should be available in custom ROMs)
In a nutshell, rooting allows you full control over your phone. Linux systems are built around strict access control policies and the Android is locked to only allow you default user permissions. "Root" is the name of a profile common to all linux distributions, with the highest permissions possible - a super user that can do anything. Rooting your phone allows you access to step your permissions up to root level.
This is useful for doing things that you are normally locked out of - changing core parts of the OS. For now, there isn't much useful to do with it (app2sd is about it) and deleting packaged software from the firmware that you don't want. This will change as Android becomes more popular and there are more interesting things to do.
Click to expand...
Click to collapse
Thanks mate.
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.
I'm pretty sure this is the latest version of SuperSU, but every time I reboot my phone I get a message that reads: "The SU binary needs to be updated!", and when I click on the prompt to update it, it always fails and asks me to reboot.
Has anyone else run into this issue, or know how to resolve it? Thanks.
SuperSU APK and the SU binary are two different things :
SU is a binary executable, it's used by Android and other *nix based systems to allow a process to change the user it is run by and therefore what the process has the rights to do (as it inherit the user permissions). In the rooting case, processes invoke SU to switch to the root user therefore acquiring root permissions.
SuperSU is an Android application (.apk is an Android application package), it works as a sort of "gatekeeper" to the SU binary. Applications which attempt to invoke SU will be forced to route through SuperSU, which will then prompt the user with the options of approving or denying the access to SU (and optionally having SuperSU remember their decision and automatically apply it for subsequent calls by that app).
So what happens to you is, every time you boot, SuperSU v2.78 (which is the latest version of the SuperSU APK) checks the SU binary version and tells you that there is a newer version of it and that you should update it.
Then for SuperSU failing to update the SU binary I can't help as for me it always worked till now. But maybe there is a way to manually do it (by finding the binary in a flashable zip that you can flash in recovery)?
bafforosso said:
SuperSU APK and the SU binary are two different things :
SU is a binary executable, it's used by Android and other *nix based systems to allow a process to change the user it is run by and therefore what the process has the rights to do (as it inherit the user permissions). In the rooting case, processes invoke SU to switch to the root user therefore acquiring root permissions.
SuperSU is an Android application (.apk is an Android application package), it works as a sort of "gatekeeper" to the SU binary. Applications which attempt to invoke SU will be forced to route through SuperSU, which will then prompt the user with the options of approving or denying the access to SU (and optionally having SuperSU remember their decision and automatically apply it for subsequent calls by that app).
So what happens to you is, every time you boot, SuperSU v2.78 (which is the latest version of the SuperSU APK) checks the SU binary version and tells you that there is a newer version of it and that you should update it.
Then for SuperSU failing to update the SU binary I can't help as for me it always worked till now. But maybe there is a way to manually do it (by finding the binary in a flashable zip that you can flash in recovery)?
Click to expand...
Click to collapse
Thank you for explaining the difference for me. I went ahead and downloaded the .zip from here: http://forum.xda-developers.com/apps/supersu/stable-2016-09-01supersu-v2-78-release-t3452703/page8
And then used the installation instruction found here: http://androiding.how/how-to-flash-supersu-using-twrp-recovery-and-root-any-android-device/
And I don't seem to be getting the prompt that SuperSU needs to be updated anymore.
Huh. Never mind. Seemed to work for about 12 hours, but now it's asking me to update again, and I can't. Looks like I need step-by-step instructions on how to clear this message, cause whatever I'm doing isn't doing the trick.
Did you disable Sony RIC and dm-verity when you modified the kernel? I'm not sure if it has anything to do with or whether it will solve your problem, but one time I patched my kernel leaving one of the options enabled and ran into all sorts of problems with apps that required root, so after that horrible experience I decided to just disable everything. During that horrid experience, I think I also had SuperSU (or was it busybox?) complain about not being able to update binaries.
"It has been claimed that the Privacy Guard implementation of ‘su’ has security vulnerabilities even when disabled. In other words, the mere presence of the su binary is enough to compromise the device.
Unfortunately, the person who reported this vulnerabilty refuses to disclose its exact nature, nor could we make sure to properly fix this exact issue. The next best solution is to ensure that su is only accessible when enabled in the Settings app and keep su disabled when it’s not in use.
We’ve created a kernel patch that hides the existence of su from all processes except root and system when the su daemon is not running (root needs access so that init can start the su daemon, and system needs access in order to populate the root access settings appropriately).
This effectively makes it impossible for unprivileged processes to exploit su when it is disabled in settings. Indeed, it makes it impossible to even see that the su binary exists. It cannot be seen either directly (via stat /system/xbin/su) or indirectly (via ls /system/xbin). A side effect of this, is that Play Services can’t detect su binary when root is disabled either, allowing some (older) devices to pass SafetyNet when root is installed but disabled.
This fix cannot be applied globally but must be merged to each device’s kernel. If your device hasn’t been patched yet, or you’re maintaining a device, take the proper patch and apply it as soon as possible (kernel 3.18, 3.10 and 3.4).
This is a precautionary measure. We are not aware of any active exploits targeting this issue....."
Ref: https://www.lineageos.org/Changelog-9/
Any developers looking to resolve this vulnerability, I already had it merged in my kernel weeks ago
Here https://github.com/anupritaisno1/an...mmit/20796ec7f64678ef644cd8c1085bb01c9e951049
I can't believe I am still struggling with this.....
I've flashed an AOSP 7.1 build by @amaces from the Unlegacy Android site. Based on what has been said about rooting AOSP builds, I flashed addonsu-phh-arm-new.zip and then installed me.phh.superuser.1033.apk. After a reboot, I get the dreaded "su binary is out of date", the SU app does not respond to any changes and I don't have root.
I've gone round and round on this, first treating it like the AOSP 7.0 I am running on another Nook (which only required the apk installation) and then trying the double barrel assault.
I am stumped.
nmyshkin said:
Based on what has been said about rooting AOSP builds, I flashed addonsu-phh-arm-new.zip and then installed me.phh.superuser.1033.apk. After a reboot, I get the dreaded "su binary is out of date", the SU app does not respond to any changes and I don't have root.
Click to expand...
Click to collapse
Are you sure the control APK is equivalent to the Play Store version (i.e., looks for the same SU binary signatures)? It's possible PHH did update his SU backend; I'll investigate.
Something that I didn't really mention in the FAQ, with current AOSP builds, you can also install the CM backend (addonsu-14.1-arm-new.zip, or the official version at https://download.lineageos.org/extras), which doesn't need any extra UI APK. I had adapted some of the CM14 patches such that the CM/Lineage blurb applies to AOSP as well.
On another note, wouldn't it be more productive to post these questions in the respective threads? Visibility is probably much lower when creating these independent question threads...
Edit: I did look at PHH's SU packages, and they all have the exact same SU backend included in addonsu-phh-arm-new.zip, so I don't have any explanation other than incorrect APK.
amaces said:
Are you sure the control APK is equivalent to the Play Store version (i.e., looks for the same SU binary signatures)? It's possible PHH did update his SU backend; I'll investigate.
Something that I didn't really mention in the FAQ, with current AOSP builds, you can also install the CM backend (addonsu-14.1-arm-new.zip, or the official version at https://download.lineageos.org/extras), which doesn't need any extra UI APK. I had adapted some of the CM14 patches such that the CM/Lineage blurb applies to AOSP as well.
On another note, wouldn't it be more productive to post these questions in the respective threads? Visibility is probably much lower when creating these independent question threads...
Edit: I did look at PHH's SU packages, and they all have the exact same SU backend included in addonsu-phh-arm-new.zip, so I don't have any explanation other than incorrect APK.
Click to expand...
Click to collapse
Mmm....I'll keep plugging away at it. Must be missing something.
Sorry for the new post, but I wasn't sure it would be appreciated to insert questions about the Nook Tablet into the HD/HD+ thread. In retrospect I guess the issue is more general than tablet-specific since it refers to ROMs which have similar rooting issues.
nmyshkin said:
I wasn't sure it would be appreciated to insert questions about the Nook Tablet into the HD/HD+ thread. In retrospect I guess the issue is more general than tablet-specific since it refers to ROMs which have similar rooting issues.
Click to expand...
Click to collapse
Sorry, I think I misread the initial question; you were asking about UA acclaim builds, whereas I referred to my personal builds. While I maintain both, only my personal repositories are patched in such a way to utilize CM14.1 SU. The goals of the UA project are different (more about purity), but I can experiment with various things in my own builds. About PHH root, I suspect the builds you installed are missing the persist.sys.root_access property, so the SU backend never starts up. You might be able to get PHH root going on the UA builds by adding
Code:
persist.sys.root_access=3
to your build.prop (remount system, or in recovery).
amaces said:
Sorry, I think I misread the initial question; you were asking about UA acclaim builds, whereas I referred to my personal builds. While I maintain both, only my personal repositories are patched in such a way to utilize CM14.1 SU. The goals of the UA project are different (more about purity), but I can experiment with various things in my own builds. About PHH root, I suspect the builds you installed are missing the persist.sys.root_access property, so the SU backend never starts up. You might be able to get PHH root going on the UA builds by adding
Code:
persist.sys.root_access=3
to your build.prop (remount system, or in recovery).
Click to expand...
Click to collapse
Thanks for the lead. I learned something new in the editing of the build.prop file from recovery
Unfortunately, it did not give the desired result. After a little more work with the ROM it appears it is not quite ready for "prime time". It can't remember my WiFi password and does not have a browser. I guess I could always adb push the AOSP browser (which I like), but the WiFi issue is beyond my pay grade. On the plus side, it does shut down properly (and......"restart" reboots into recovery....not quite what I expected)
I'll just keep an eye on future releases.
Edit: Ha! One more reboot and this time it actually connected to WiFi by itself! Maybe worth a fifth look.....
nmyshkin said:
It can't remember my WiFi password and does not have a browser.
Click to expand...
Click to collapse
The deprecated AOSP browser had become a security risk lately, and it was removed in the UA builds. My own builds contain a different browser, albeit from CM/Lineage. Either way, there are many good options that you can sideload (e.g., Lightning) or install from Play Store.
nmyshkin said:
On the plus side, it does shut down properly (and......"restart" reboots into recovery....not quite what I expected)
Click to expand...
Click to collapse
I built things on the CM/Lineage kernel, and the bug was introduced there sometimes last year. After a few bisection attempts, the root cause hasn't been found yet.
The solution is a patched version of Magisk, courtesy of @fddm. See https://forum.xda-developers.com/nook-tablet/help/acclaim-patched-magisk-tester-t3752775