Looking through AndroidCentral, I ran across this and knowing our phones use Qualcomm's chipset (Snapdragon) is it possible someone could write up a app to root our phones?
http://www.androidcentral.com/quadrooter-5-things-know-about-latest-android-security-scare
Yes, is posible, i consider GmsCore, and Gapps, the primary crappy apps that haves ocult root activities.
Someday i found an activity in googlplayservices.apk named as RootActivity on the 365 activities inside the GMSCore.apk
After this i confirmed, the crappy google is the creator of root services without superuser/su
This is why i consider "if my phone or device haves no root, the phone or device is not mine, and someday, will die".
But root a device, requires long years working with Linux or CentOs in a computer. Because all is the same on android.
The simplest way i do "sometimes", is install dr web and scan my app list for confirm thus crappy event.
We download apks sometimes, we need to know what these apk do.
WidgetWindow.apk or sugarmintcandy.widgetwindow.apk
Was an app found by dr web scanner that reported that this app access internet, without permission declared in Manifest.xml
Of course, i decompiled the apk, writed the INTERNET.permission tag and recompiled again.
If some app access internet without permission, why not some another will not gain root without permission too?
This is an android error , not the apk's creators.
:thumbup:
Sent from my XT687 using xda premium
Which means?
Dethfull said:
Yes, is posible, i consider GmsCore, and Gapps, the primary crappy apps that haves ocult root activities.
Someday i found an activity in googlplayservices.apk named as RootActivity on the 365 activities inside the GMSCore.apk
After this i confirmed, the crappy google is the creator of root services without superuser/su
This is why i consider "if my phone or device haves no root, the phone or device is not mine, and someday, will die".
But root a device, requires long years working with Linux or CentOs in a computer. Because all is the same on android.
The simplest way i do "sometimes", is install dr web and scan my app list for confirm thus crappy event.
We download apks sometimes, we need to know what these apk do.
WidgetWindow.apk or sugarmintcandy.widgetwindow.apk
Was an app found by dr web scanner that reported that this app access internet, without permission declared in Manifest.xml
Of course, i decompiled the apk, writed the INTERNET.permission tag and recompiled again.
If some app access internet without permission, why not some another will not gain root without permission too?
This is an android error , not the apk's creators.
:thumbup:
Sent from my XT687 using xda premium
Click to expand...
Click to collapse
The "patches" are applied only by recompiling the rom and updating to the new by the manufacturer
I installed the app
I foud 4 CVE errors in my Gpu
But i still cannot clarify the risk level of this.
I believe, this risk, comes installing an affected apk ONLY
Dr. Web light antivirus inspects and detects dangerous apks after installing.
I may update my rom only if Motorola send the patches and ONLY IF is a high level risk and strictly necessary
Sent from my XT687 using xda premium
They are saying these CVE errors are new, and the menaces may be initiated in 4 months, and we need to contact the Manufacturer "imploring new rom"
Hm imploring, haha, lamenatable.
I am on a semi custom stock rom, if they fixes my rom, i will need begin again
But xt687 is out of the list.
Hahaha, i will "implore".
Sent from my XT687 using xda premium
---------- Post added at 08:02 PM ---------- Previous post was at 07:54 PM ----------
The checkpoint site that "discovered"
This CVE error, is promotting "download apps from goglebley site", well...
I downloaded the widgetWindow from there, still are there and EVERYWHERE is the same.
I say against them:
Stay donloading all apks that you want from where you want because java and linux is not their property!
Be aware after installing apks CHECKING WITH CISecurity or Dr web antivirus...
:thumbup:
Sent from my XT687 using xda premium
Using this exploit would be a temp root situation I believe. We would still have to unlock the bootloader to have root after we reboot.
I haven't looked into these enough. Plus the fact I'll be switching to the note 7 soon means I'll still be looking to see if these will work or not to try and gain root.
I understand the bootloader issue. However with us obtaining root it might help us get closer to finding what is needed to get the bootloader unlocked correct?
This could be interesting to hear more about. I'd love to upgrade to MM. But I'm not jumping off of 5.1.1 until that happens.
Kickin' it on my VS990
This screenshot is from my xt687 android 4.0.4 is not only the new devices, is more than these.
We have not affraid with this, even only, if we install UNCHECKED apks.
Nobody can install apps remotely, they can execute remotely only.
Sent from my XT687 using xda premium
Did this ever get any traction? I was just reading about QuadRooter and figured I'd give my device a scan. It says that I am vulnerable to CVE-2016-2059 and CVE-2016-2504. According to ZoneAlarm who put out the scanner, two vulnerabilities were fixed by a patch but two were not. I guess these are the two? So, CVE-2016-2059 is the Linux IPC router kernel, and CVE-2016-2504 which is the KGSL (Kernel Graphics Support Layer) according to codeaurora.org
Would be cool if we could root this bad boy afterall... (I'm on Android 6.0 with security patch level 2016-06-01, and build MRA58K -- VS99023A
Related
installed tnt lite on my g tab...first step running z4root....tab is up and running..
ran security check on toshiba computer and had the following virus warning..
z4root...exploit:wnix/lotoor....listed as severe threat..my security program deleted the apk..i know there can be a false positive, but i am concerned if this threat is now on my gtab? your thoughts?
thanks...steve n
Most likely a false positive, but either way windows viruses can't infect your tablet. Android malware is a completely different beast.
Sent from my T-Mobile G2 using XDA App
Nospin said:
Most likely a false positive, but either way windows viruses can't infect your tablet. Android malware is a completely different beast.
Sent from my T-Mobile G2 using XDA App
Click to expand...
Click to collapse
+1 Definately a false positive
Windows malware can't affect Android and visa versa.
Also, though z4Root is an exploit script it is not Android Malware.
thanks for quick reply..both of them
thanks very much ... that was the answer i was looking for...
again..thanks for helping to nospin and tekrhino
steve n
Is spam/viruses protection necessary?
So this brings up something I've been wondering about. Do we need to protect the G-Tab against spam and viruses? Is there a vulnerability? If so, what is recommended?
Thanks!
Terry
I suppose someone could cross compile clamav
tmacrae said:
So this brings up something I've been wondering about. Do we need to protect the G-Tab against spam and viruses? Is there a vulnerability? If so, what is recommended?
Thanks!
Terry
Click to expand...
Click to collapse
There is a patch currently available to correct this exploit for all pre Gingerbread ROMs (TnT, VEGA, etc...)
http://forum.xda-developers.com/showthread.php?t=977756&highlight=[Patch]
Also, I installed Lookout Mobile Security to scan all new apps that I install because I do a lot of sideloading and get many apps via newsgroups.
So I need to be extra careful considering where I go to get apps.
Another method I tend to use before installing sideloaded apps is a batch conversion to zip "ren *.apk *.zip" then scan the zip files with anitvirus on my pc.
If they come out clean I will batch convert them back to apk "ren *.zip *.apk" then proceed to install at will.
I know that Windows & Android Malware are two different types but you NEVER KNOW with those that have malicious intent hence having Lookout Mobile Security installed on my GTAB. I'm just trying to cover all sides.
VirusTotal
I sent the apk downloaded from the link on the closed thread http://forum.xda-developers.com/showthread.php?t=833953 to VirusTotal:
VirusTotal: Detection ratio: 31/46:
https://www.virustotal.com/file/d49...13ec1a86092a58da2faf81736cb17326d0d/analysis/
Since, I've found that it has successfully rooted my i5800, which I confirmed with BusyBox > su
Hi everybody,
Good evening!
I recently came across a post about almost 50% android devices being vulnerable. Duo securities has made this finding using an app 'X-Ray'. They mention following 8 types of vulnerabilities: 1. Ashmem 2. Exploid 3. Gingerbreak 4. Levitator 5. Mempodroid 6. Wunderbar 7. Zergrush, and 8. Zimperlich. Please see this link for details: http://www.xray.io/#vulnerabilitieshttp://www.xray.io/#vulnerabilities
I downloaded the app 'X-Ray' and did a X-ray of my Desire Z. It came out clean for all but one vulnerability, Mempodroid. I've a rooted and S-off desire z and am using Jelly Bean rom (andromadus Test Build, .85). The website gives following details for the Mempodroid:
"Inherited from the upstream Linux kernel, a vulnerability in the /proc/pid/mem interface allows for writing arbitrary memory in the address space of a setuid process. It's about as complicated as it sounds, but attackers are smart like that."
I cross checked the same X-ray with a different rom, this time GenY (Sense 4 based ICS Rom). The results were similar. I don't know much about these vulnerabilities so thought of putting this question in this learned forum. Please clear my following doubts:
1. Is this Mempodroid is a serious problem?
2. Since this is surfacing in different roms, it should not be a ROM-specific issue but a device-specific one. Is there anything that I can do to remove this vulnerability.
3. What possible harm can it do to me?
Thanks,
dcpathak
HTC Desire Z (Rooted & S-Off)
Those sound like root methods, or at least the few I recognize. Basically it would be possible for a malicious app to have a root exploit built it so that it could get su permissions and potentially do some real damage. Even if your device was already rooted with Superuser installed the root exploit would bypass the superuser prompt since it doesn't need root to get su. As long as you download apps straight from Google Play and check the reviews first to make sure its legit, you'll be fine. These malicious apps are turning up on sites that distribute pirated software.
If you've used one of the root methods listed to root your device, don't worry. Any root method is technically a security vulnerability.
Thanks, I also remembered that some of these vulnerabilities are names of root methods, for instance, Gingerbreak, Zergrush etc. Further, I think Mempodroid may have something to do with the processor speed management (just a wild guess).
dcpathak
Just don't install apps from dubious sources and your fine.
While those loop holes could be exploited, you will need to have downloaded an app that does this in the first place.
[FIX][XPOSED][4.0+] Universal fix for the several "Master Key" vulnerabilities
You may be aware of recent news about several different security vulnerabilities that allow replacing code on a signed APK without invalidating the signature:
Master Key (Bug 8219321)
An issue related with duplicate entries on the ZIP / APK files.
It was patched by Google back in February 2013 and shared with OEMs, and some of the newer devices might have already received the fix in a recent stock update. At least both Xperia Z 4.2.2 and Galaxy S2 4.1.2 contain the fix; CM has also recently patched it, on this commit.
More info can be found on @Adam77Root's thread here: http://forum.xda-developers.com/showthread.php?t=2359943
Bug 9695860
This also originates in the ZIP file parsing routines, and was disclosed just a few days ago immediately after the previous one was made public. The correction has already been applied by Google to the code (this commit), but it's very likely that its rollout on stock ROMs will take a long time especially on non-Nexus devices.
You can read more about it here.
To know if you're vulnerable, use SRT AppScanner mentioned above.
Unless you're running CM 10.1.2, there's a fairly big chance that you have this issue, at least as of this moment.
Bug 9950697
It's yet another inconsistency in ZIP parsing that could be abused in very a similar way to the previous one.
This one is a bit special to me, since I was fortunate enough to be the first one to report it on Google's bugtracker
It was discovered around the time that the previous bug was acknowledged and Android 4.3 was a few days from being released, but despite the prompt report it was unfortunately too late to include the fix in time for the release; Therefore it wasn't disclosed till Android 4.4 sources came out and I had also decided not including a fix for in on this module, since it would be an easy way to learn about the extra attack vector.
Kudos to Jeff Forristal at Bluebox Security, who I learned was also working on that exact problem and helped me report it properly to Google, and also to Saurik who already released a Substrate-based fix and has written a very interesting article about it here.
Checking if you're vulnerable
You can use some 3rd party apps to test your system, such as:
- SRT AppScanner
- Bluebox Security Scanner
On Android 4.4 all these bugs should be fixed, and therefore this mod is not needed. But you can run one of these scanners to make sure you're not vulnerable.
While technically different, these vulnerabilities permit that legitimate APKs can be manipulated to replace the original code with arbitrary one without breaking the signature. This allows someone to take an update from a well known publisher (e.g. Google Maps), change the APK, and a device receiving it will happily apply the update as if it was indeed from that publisher. Depending on the apps being updated in this way, priviledge escalation can be achieved.
Google has already mentioned that all apps published on the Play Store are checked for this kind of manipulation, but those of us installing APKs from other sources aren't safe.
The universal fix
Since decompiling, fixing and recompiling the code for every possible ROM version is way beyond anyone's capability, the awesome Xposed framework by @rovo89 proves itself once again as an invaluable tool.
By creating hooks around the vulnerable methods and replacing the buggy implementation with a safe one, it's possible to patch the 2 issues on the fly without ever changing the original files. Applying the fix is as easy as installing and enabling an Xposed module.
Installation steps
1. Make sure the Xposed Framework is installed.
Follow the instructions on the thread. Root is required only during installation, it is no longer required afterwards. Only ICS or above is supported.
2. Install the Master Key multi-fix module.
3. Follow the Xposed notification about a new module being available, and on the list of modules activate Master Key multi-fix
4. Reboot
You should now see an image similar to the attached one when opening the app. The green text shows that the module is active and the vulnerabilities have been patched in memory.
Download
Grab it from Google Play (recommended, as you'll get updates) or use the attached APK. The files are the same.
Version history
2.0 - Fix bug 9950697; additional corrections taken from Android 4.4 (also supports GB, provided you have a working version of Xposed Framework for your ROM)
1.3 - Fixed problems with parsing some zips depending on the rom original code
1.2 - Added 2 additional zip entry integrity checks that were missing
1.1 - Support for additional devices with modified core libraries (e.g. MTK6589)
1.0 - Initial version
Sources
Available on GitHub
If you appreciated this fix, consider donating with Paypal.
Thanks!
FAQ
Fequently asked questions
[ 1 ]
Q: Bluebox Security Scanner still says my phone is unpatched after installing this... Any ideas why?
A: Make sure to click the Refresh entry on the app's menu and it should change to green once the mod is active.
[ 2 ]
Q: Bluebox Security Scanner says that the 2nd bug is not patched even after refreshing but SRT AppScanner says it's patched. Which one is right?
A: The scanner was mis-detecting the 2nd bug and it got fixed in version 1.5. Make sure you update Bluebox from the Play store.
[ 3 ]
Q: Does the module permanently patch the vulnerability or is it only when the module is active? If for example, I activate the module and reboot, then after verifying that the exploit is patched, deactivate the module. Would I still be patched? I guess what I'm asking is if I need to have this module active at all times to be patched? Permanent fix, or Just while the module is installed?
A: The fix is not permanent. It's applied only whenever the module is installed and active. If you remove it, after the next boot you're back with the original code from your ROM (which might have the bug or not).
Thank you, this would help a lot
Sent from my GT-I9500 using Tapatalk 4 Beta
Thank you but I don't see any link to the xposed patch app
Envoyé depuis mon LT28h en utilisant Tapatalk 4 Beta
Marsou77 said:
Thank you but I don't see any link to the xposed patch app
Click to expand...
Click to collapse
Have a look now
I needed to create the thread first in order to include the link on the app itself.
Thanks! I was just googling to see if someone had already done this before writing it myself!
XPosed is amazing sauce for Android.
The 4.1.2 update for the T-Mobile galaxy s3 is already patched.
Thanks for the info OP.
Maxamillion said:
The 4.1.2 update for the T-Mobile galaxy s3 is already patched.
Thanks for the info OP.
Click to expand...
Click to collapse
The second bug as well? Check java.util.zip.ZipEntry on /system/framework/core.jar and see if the readShort() values are properly converted to unsigned.
.....
Bluebox security still says my phone is unpatched after installing this... Any ideas why?
Sent from my HTC Sensation Z710e using xda app-developers app
Shredz98 said:
Bluebox security still says my phone is unpatched after installing this... Any ideas why?
Click to expand...
Click to collapse
No idea why it doesn't refresh automatically each time you execute the app, but access the Refresh option from the menu and it should change to green once the mod is active.
Tungstwenty said:
No idea why it doesn't refresh automatically each time you execute the app, but access the Refresh option from the menu and it should change to green once the mod is active.
Click to expand...
Click to collapse
Yeah you're correct mate, says patched when I rescanned so all good the patch does exactly what it says, brilliant work! Was beginning to think I would have to live with this security hole active on my device!
Sent from my HTC Sensation Z710e using xda app-developers app
Shredz98 said:
Yeah you're correct mate, says patched when I rescanned so all good the patch does exactly what it says, brilliant work! Was beginning to think I would have to live with this security hole active on my device!
Click to expand...
Click to collapse
Added to the FAQ (post #2)
Hey Everyone,
I've found an alternative for the blueboox app. It's called the SRT AppScanner and seems to work better than the BlueBox Scanner and it provides more functionality, too.
Since I'am a new user, i can't post links. Simply query SRT AppScanner in the PlayStore.
Best regards
Boradin
Thanks for great patch.
I've tested with SRT AppScanner and found I'm still vulnerable to bug 9695860.
How do I make sure bug 9695860 was fixed?
mnirun said:
Thanks for great patch.
I've tested with SRT AppScanner and found I'm still vulnerable to bug 9695860.
How do I make sure bug 9695860 was fixed?
Click to expand...
Click to collapse
When I initially installed SRT it was always giving me 2 greens even with the mod disabled, even though I checked the code for my ROM and the 2nd bug is there.
Now, after a very recent update, it always gives me a red on the second bug even with the mod active. I'll need to double check how they are doing the detection because it doesn't seem to be correct.
Bluebox Security, on the other hand, does reflect the change although it only detects the first bug. Running it on an emulator with a vulnerable ROM correctly said so, and after applying the mod and forcing a rescan it will change to no longer vulnerable.
SRT AppScanner has just received an additional update from Play and now appears to correctly detect the status of bug 9695860 depending on whether the mod is active or not and if your base ROM is vulnerable.
The sources are now available on GitHub (check 1st post).
Tungstwenty said:
SRT AppScanner has just received an additional update from Play and now appears to correctly detect the status of bug 9695860 depending on whether the mod is active or not and if your base ROM is vulnerable.
Click to expand...
Click to collapse
Confirmed, you patch is now detected by SRT AppScanner.
Thank you.
Tungstwenty said:
You may be aware of recent news about 2 different security vulnerabilities that allow replacing code on a signed APK without invalidating the signature:
Master Key (Bug 8219321)
An issue related with duplicate entries on the ZIP / APK files.
It was patched by Google back in February 2013 and shared with OEMs, and some of the newer devices might have already received the fix in a recent stock update. At least both Xperia Z 4.2.2 and Galaxy S2 4.1.2 contain the fix; CM has also recently patched it, on this commit.
An easy way to know if you're vulnerable is installing this app by Bluebox Security. Update: An ever better one is SRT AppScanner, which can detect both bugs.
More info can be found on @Adam77Root's thread here: http://forum.xda-developers.com/showthread.php?t=2359943
Bug 9695860
This also originates in the ZIP file parsing routines, and was disclosed just a few days ago immediately after the previous one was made public. The correction has already been applied by Google to the code (this commit), but it's very likely that its rollout on stock ROMs will take a long time especially on non-Nexus devices.
You can read more about it here.
To know if you're vulnerable, use SRT AppScanner mentioned above.
Unless you're running CM 10.1.2, there's a fairly big chance that you have this issue, at least as of this moment.
While technically different, both of these vulnerabilities permit that legitimate APKs can be manipulated to replace the original code with arbitrary one without breaking the signature. This allows someone to take an update from a well known publisher (e.g. Google Maps), change the APK, and a device receiving it will happily apply the update as if it was indeed from that publisher. Depending on the apps being updated in this way, priviledge escalation can be achieved.
Google has already mentioned that all apps published on the Play Store are checked for this kind of manipulation, but those of us installing APKs from other sources aren't safe.
The universal patch
Since decompiling, fixing and recompiling the code for every possible ROM version is way beyond anyone's capability, the awesome Xposed framework by @rovo89 proves itself once again as an invaluable tool.
By creating hooks around the vulnerable methods and replacing the buggy implementation with a safe one, it's possible to patch the 2 issues on the fly without ever changing the original files. Applying the fix is as easy as installing and enabling an Xposed module.
Installation steps
1. Make sure the Xposed Framework is installed.
Follow the instructions on the thread. Root is required only during installation, it is no longer required afterwards. Only ICS or above is supported.
2. Install the Master Key dual fix module.
3. Follow the Xposed notification about a new module being available, and on the list of modules activate Master Key dual fix
4. Reboot the device (a Soft reboot is sufficient)
You should now see an image similar to the attached one. The green text shows that the module is active and the 2 vulnerabilities have been patched.
Download
Grab it from Google Play or use the attached APK.
Sources
Available on GitHub
If you appreciated this fix, consider donating with Paypal.
Thanks!
Click to expand...
Click to collapse
Thank you for this patch, but can we install this mod over "REKEY" patch or remove rekey and enable this patch instead ??
Hi everyone,
I'm new on xda and I come here because I struggle to install this app on my rooted Galaxy S4 with CyanogenMod 11: "Paiement mobile (pour Orange)" (sorry, I'm new, so I cannot post urls).
In fact, this app has not been declared by the devs (on the Google Play) to be compatible with my phone, despite the fact that I have the specs to run it (NFC payment).
I asked a friend who was able to download the app to upload it on Aptoide, giving me the opportunity to download the apk on my phone (this apk is available in this thread). I tried to install it, but I get the following the error: "app not installed".
I would like to force the installation of the app. I tried many ways, like using apps that use root access on the phone, without success (for example, I tried with "System Apps Installer" on the Google Play, but I get a problem with mounting /system). I also tried to install it with the command line tool, but I get the error "[install_failed_invalid_uri]". I tried to change the permission of the /data/local directory and /data/local/tmp with ES file explorer, but it did not change anything.
In addition to this, I'm not able to enable usb debugging in the developper options (to install the apk with adb), because every time I activate the option, it becomes disabled in the following seconds.
It seems to be a little bit complicated, because I seem to have different problems, but I hope that someone here will be able to help me !
Thanks for your help,
Aquignis.
The issue is most likely Cm. They alter things so some that normally work no longer work
I suceeded to solve the "[install_failed_invalid_uri]" error in the command line tool by also changing the permissions of /data.
After that, I got another error (yes, one more, but the last) that made me discovering what's the real problem in this situation: "install_failed_missing_shared_library". By doing some researches on the web and exploring the apk, I understood that the app use a library called "org.simalliance.openmobileapi" that corresponds to the work of SIMalliance, who developped an API called "Open Mobile API", which notably enables communication with NFC sim cards and must be integrated to the build of the ROM. This system is used by many banks in Europe and has been integrated in the stock ROM of many NFC devices by the important manufacturers, but not by Cyanogenmod devs in the last stable release of CM 11 for the Galaxy S4.
Like you said it, the problem was CM
I asked them if it has been integrated in CM 12, because that is why the app is said to be incompatible with my device by Google Play which automatically checks which libraries are installed on your device (I'm waiting for their answer). The other solution would be to add the library to the CM build by myself, because it seems not to be very complicated, but I'm not qualified enough to do this !
If it is not part of aosp I wouldn't count on it being added to be honest. Not to mention most banking apps refuse to work if the Rom has root as it can cause security issues.
Yes, the root seems to be a problem with some apps according to the work of this man.
On the other hand, I think that this API is important enough to make CM devs pay attention to it, because it is used in many countries (except the USA which use only HCE, I believe). If only I was able to build it myself !
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.