Related
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.
Not sure my question in subject is clear, so here's the thing...
I have dual-boot tablet with Android 5.0.1 and Windows 10 installed, and the model is Onda V80 Plus (32GB), if that matters at all.
I'm really having hard time rooting this device using standard methods (even with much of background knowledge and experience), so I was about to take a different route.
I installed Paragon ExtFS windows app which gives me read/write access to /system and /data android partitions (which have ext4 filesystem).
I was wondering if anyone knows if it's possible to gain root access in Android just by copying some files and changing some permissions or whatever from within Windows OS?
Basically, for those not familiar with ExtFS app, I can assign a drive letter to /system and /data partitions, and do whatever I want with them just like with any other drive or volume.
I'm aware that modifying ext4 partitions can render my Android OS unbootable, but I have a backup and would like to try it anyway as this is my last option.
When I look into SuperSU.zip file (which I always flashed through CWM/TWRP recovery to gain root access), I see many files which some lengthy script is copying all around, so I stopped after analyzing about hundred lines of code lol.
I really didn't find any method like this on the internet, so I wonder if that's even possible, and if it is, how would I go about it?
Thanks everyone.
Burs said:
Not sure my question in subject is clear, so here's the thing...
I have dual-boot tablet with Android 5.0.1 and Windows 10 installed, and the model is Onda V80 Plus (32GB), if that matters at all.
I'm really having hard time rooting this device using standard methods (even with much of background knowledge and experience), so I was about to take a different route.
I installed Paragon ExtFS windows app which gives me read/write access to /system and /data android partitions (which have ext4 filesystem).
I was wondering if anyone knows if it's possible to gain root access in Android just by copying some files and changing some permissions or whatever from within Windows OS?
Basically, for those not familiar with ExtFS app, I can assign a drive letter to /system and /data partitions, and do whatever I want with them just like with any other drive or volume.
I'm aware that modifying ext4 partitions can render my Android OS unbootable, but I have a backup and would like to try it anyway as this is my last option.
When I look into SuperSU.zip file (which I always flashed through CWM/TWRP recovery to gain root access), I see many files which some lengthy script is copying all around, so I stopped after analyzing about hundred lines of code lol.
I really didn't find any method like this on the internet, so I wonder if that's even possible, and if it is, how would I go about it?
Thanks everyone.
Click to expand...
Click to collapse
Root needs a custom kernel. Not something you are gonna do with a Windows setup the way you have it. Also you will most likely not find anything as that is most likely not an official version of Android as Google doesn't allow dual booting.
Thanks for a reply. But I don't see what does custom kernel have to do with what I try to achieve? If I could, in my Windows environment, replicate the modifications that script inside SuperSU zip does to /system partition, I should gain root access, right? In theory that is, since I'm aware lots of things can go wrong. I was hoping someone could explain a bit what SuperSU script is doing when run inside custom recovery, so I try to do the same thing. Again, if it's possible, and if it's worth the time spent. But I have time, and I'm always willing to learn something new.
Burs said:
Thanks for a reply. But I don't see what does custom kernel have to do with what I try to achieve? If I could, in my Windows environment, replicate the modifications that script inside SuperSU zip does to /system partition, I should gain root access, right? In theory that is, since I'm aware lots of things can go wrong. I was hoping someone could explain a bit what SuperSU script is doing when run inside custom recovery, so I try to do the same thing. Again, if it's possible, and if it's worth the time spent. But I have time, and I'm always willing to learn something new.
Click to expand...
Click to collapse
what su is doing is pulls the kernel and patches it. root access is defined in the kernel. what itnis doing in system is flashimg just the apk
Ok, I see. So if I ask someone who rooted the same model successfully to send me patched kernel, I could easily flash it in fastboot mode (my bootloader is unlocked). So only thing left to do would be to copy apk inside /system/app, and cross my fingers? I'll post my findings if I manage to do something worth writing about. Thanks.
I have same problem with you. I can't root my Onda V80 plus. I unlock bootloader, flash recovery for my device. Then, i put it into recovery mode and install supersu.zip over recovery. When i reboot this onda, it has stopped in onda logo.
bahuy2003 said:
I have same problem with you. I can't root my Onda V80 plus. I unlock bootloader, flash recovery for my device. Then, i put it into recovery mode and install supersu.zip over recovery. When i reboot this onda, it has stopped in onda logo.
Click to expand...
Click to collapse
I managed to root my Onda few days after my last post, but forgot to post my findings, sorry. I didn't used any of my hacker's skills lol, but I researched a bit more and found out what I was missing. The same issue is with you, so you have to disable verity before flashing recovery by typing in these commands:
Code:
adb root
adb remount
adb disable-verity
adb reboot
After rebooting install supersu.zip, and the next boot won't hang on Onda logo anymore. Hope this helps you.
btw, note that not just any adb version has verity command line switch. You have to download newer adb version!
Thank you! I trie a lots times, but i can't make successfully!
Basic root procedure would be: unlock BL -> disable verity -> flash (temp) recovery -> install SuperSU
Here are the links containing all the files neccessary for rooting Onda V80 Plus: Mega | MediaFire
Note the ReadMe.txt inside archive. It contains list of adb/fastboot commands needed to be executed in order to successfully root the device.
Thank you very much! I download your file and root successfully my Onda V80 plus! It works well for me.
Ok, I get that boot-debug has been around for years... since android 10 for me, before that, it was variant=user, or variant=eng(ineer).
Strange how after I show boot-debug.img, magisk chooses this very path, but only after. Keeping in mind many people come here asking questions, and all those that know sit back and say nothing. Until they dont like what they see.
If you know better, and cant help, please keep your comments to yourself. This thread is intended to HELP, and is targetted toward those who CHOOSE to HELP because they CAN.
How I got su to work. Is this root? Now this is a good question. I dont want ANY overlaid system in my fone. I want to write to system like many others want to.
Not some google way of forcing us to use their mirrored online version of a locked filesystem already on my f'n.
Priority 1: I want to root my f'n without internet. Period. I do NOT want magisk using my credit. This proves we pay for magisk. I sometimes live so far from the world wide web, that offline is the only way to work. So I need to be able to root without google or THEIR employees offerings.
Priority 2: RW-able system.
So, I discover boot-debug.img for my f'n. Had it for a year, before I discovered it. Yeah, I discovered it after a year here asking, and getting NO replies that worked. Only after I'm vindicated to the naysayers 'thats been around forever...' yeah, try helping instead of useless comments.
In the end, I learned so much in such a short time. Constructive critiscism is NOT insulting. Magisk kills root in MY f'n. PERIOD. Camera does not work, location does not work, and I cant make/receive calls. But hey, it's an overlaid file system, of course it wont ALL work, I mean, I'd expect to lose a lil functionality, but disabling the GSI ability in dev options? I dont think so.. Worse, lack of adb or fastboot is produced in my f'n when using magisk, so tata magisk.
My logs actually explain all, so no more crappy adb logs. Yeah, I like simple adb, it works, or I'll MAKE it work.
Like this:
Attempt every possible method of flashing magisk according to tut's, nada. 3 different paths lead me to...?
1: The note9 recovery I found, that lopstom was kind enough to twrp for me (well appreciated) is the KEY to gaining root on my ulefone armor x5 mt6765. It turns out that the note9 recovery is actually an android 9 os, with a 'super' .img - and being android 9, the bootloader I used is an OLD bootloader, in particular, the variant=eng type. Note this, this is key.
2: With the note9 flashed to recovery I can RW system in android 10 properly, but only in twrp.
3: Discover boot-debug.img - yup, it's not quite a variant=eng build, but it does work for the following:
Flash boot-debug.img. By doing so, you get the adb root command, and the disable-verity options, way better than wiping vbmeta, which contains the 'is it rw, or ro' of every file in every partition to be mounted in their own partitions, but what most dont know, is each file mounted in it's own mountpoint also has the information contained by vbmeta, but for each seperate file. So unless you add the /null (one for system, the other for vendor) after the disable-verity...
Nah, wipe most of your directory structure, then wonder why in a RW-able system, it still dont work. Because each file in it's own mountpoint knows if the system directory SHOULD be ro or rw. That's EACH and EVERY stock file in it's OWN mountpoint, has the RW or RO inf for the system & vendor directory, ie, is system RW?
Example: Camera wont work, get it?
In the end, this is how I went about installing su.
Flashed boot-debug.img did NOT flash recovery. Flashed meefik busybox-arm64 to f'n, but did NOT install it, instead, I opened it to install it, top left, saved the busybox-arm64 and then flashed twrp, and while there, flashed the system_rw, to defeat the system_RW saying not enough space, I chose 1024, did the copy over of super_fixed, then rebooted, enabled system, THEN flashed the busybox-arm64 from twrp, and rebooted.
Results: I copied the busybox-arm64 su, from xbin to system. In order to defeat the system_RW saying not enough space, I chose 1024. Round numbers matter with system_RW, same senario as memory, so use sizes equal to how memory works. ie, 32, 64, 128, and multiples of.
Look at the adb posts in my closed thread.
With Su installed, I have to type exit TWICE to exit. without su in system, exit only needs typed once.
Now here is why I continue. I found root, but dont have the experience, but it's like this:
See all those lovely new file that end in .cel? Mine says platinum. That means I AM ROOT. By swapping out .cel files, I have all the access magisk denies me. .cel files... get on it devs... swap them out, try try try... find what I found.
I dont actually need su, but i need it for some apps. What I have proven, is that SU does NOT kill android 10_Q.
variant=user or variant=eng, is NOW dependant on .cel files, like, say, boot-debug.cel.
Have a nice discovery... I hacked googles latest offering my-cel-f
Edit: Cel files are found in the bootloader, a zero byte file, the file NAME decides what the loader can or cant do, PERIOD.
New root tools only require swapping these out, as well as a few system edits when done.
Ok, slight mistake in spelling so I'll add the following for you to 'see'..
userdebug_plat_sepolicy.cil
So it's not cel as I wrote in the first post, my point being just as valid.
Platinum clearly states there are more who's names I have yet to obtain...
Theoretically in my mind, if I swap the .cil file in the bootloader for say hypothetically:
engdebug_plat_sepolicy.cil... with the few edits seen in the android 10 notes I posted from china, the one where people say 'too much hassle' - I say, for them. Those notes show the rest of the cil files, so yeah, I got root OPTIONS to play with
Stay tuned for more scottish inventor style NOTES.
Edit: for the record: https://source.android.com/compatibility/vts/vts-on-gsi
hello ...
back for more question about pixel 6 : how do we mount system partition to r/w using any file explorer apps ? i have root access.
thank you !
I think you can't. Make a Magisk module and replace/edit things you want to
mailistman said:
hello ...
back for more question about pixel 6 : how do we mount system partition to r/w using any file explorer apps ? i have root access.
thank you !
Click to expand...
Click to collapse
As mentioned already, you can't and haven't been able to since Android 10. System partitions have the RO_COMPAT_SHARED_BLOCKS flag set. This is nicknamed the "dedup" flag, and the flag's behavior only works if the partition is read only. Not only that, the flag cannot be disabled due to insufficient space remaining in the partition. The lack of space has the side effect of making it impossible to ever set the partition as r/w.
thank you for the answers. i came from android Pie. so much learning curve & surprises with the 12.
Also wanted this. Thanks to community.
some system directory's can be mounted r/w if you have a root enabled file explorer. like root explorer. im not sure exactly which ones.
Rooting didn't harm the devices?
xikal12 said:
Rooting didn't harm the devices?
Click to expand...
Click to collapse
define harm?
AFAIK the pixel can always be put back to complete stock by flashing the factory rom back and re-locking the bootloader
Harm means the capability of the device. But got the point. Thanks.
So, did you got the point about harm?
physically no. as for software wise you will need to research.
i don't use my phone to pay for things or banking apps so i have never had any loss of use i find valuable.
security wise if you don't have your phone you don't have any security left anyways.
as for what damage you can do once you mount a system partition or other partitions, everything should be fixable with a fresh flash.
but then you take your chances with anything you do.
If you wanna listen all bulshitt about harm and so on - listen .If you wanna enjoy real root and debloat your phone I can drop to you all files (system,system_ext,product) with rw enable form may 5. Drop request in conversation.
Drop all of the files.
The best forum for information and sharing knowledge.
XDA forum is best.
cori12 said:
Drop all of the files.
Click to expand...
Click to collapse
Right now I'm on GrapheneOS Android 13 and have only stock Android 13 September update files with rw, no more android 12.
Hello masters,
I am here with a simple question, since Pixel 2 XL I have been unlocking boot loader, rooting with Magisk, and then editing the System/Build.prop file in order to enable Wifi Hotspot Native tethering. I got a new Pixel 6 and am wondering if I can edit the System/Build.prop file without unlocking boot loader or rooting the pixel 6 currently running android 13 with the latest patch as of Sep 2022.
Thank you in advance for your suggestions.
Sincerely,
Nope, no read/write access without root.
Cheers
@tom1807 ,
I actually don't agree with that, I believe it might be possible to write to the Build.prop without rooting. Especially if you can install a custom recovery image such as TWRP, because it will allow me to mount the system/Build.prop file and that way make the changes on the file save it and then unmount the system/Build.prop file?
Has anyone else experienced this scenario?
I tested it before I wrote my comment.
Filemanager without root access, saw the build.prop, but opening stated "Unable to read file." Access the build.prop with the same filemanager with root access was able to open the build.prop and show the content incl. editing.
There is no TWRP (yet) available for the Pixel 6-series, but installing that would require to unlock the bootloader.
Cheers
@tom1807 ,
Noted, if I am not able to install a custom recovery on the Pixel 6 with Android 13 then I am definitely out of luck, I wanted to avoid unlocking the bootloader because it will wipe/erase all the current data apps, etc on the Pixel 6 and I really want to avoid that.
Thank you very much for the information.
Sincerely,
Lol os13 even not possible with root access
Its depends on brands too
Like in oneplus os12 not even possible with root access twrp and also many other things to get rw
I'll pay to you or any other person if you or he can get rw in os12
So don't even think about without root edit build or modifications
@Mr Hassan,
OS 12 and OS 13 I am guessing you mean Android 12 and Android 13, in any device, not just the Pixel 6 (which is the device I am working on at the moment)?
Thank you,
Mr Hassan said:
Lol os13 even not possible with root access
Its depends on brands too
Like in oneplus os12 not even possible with root access twrp and also many other things to get rw
I'll pay to you or any other person if you or he can get rw in os12
So don't even think about without root edit build or modifications
Click to expand...
Click to collapse
No idea about OS12 on OnePlus, but I can assure you, that I was able to edit my build.prop with root access.
Maybe you use the wrong filemanager (I use FX) or don't have root access.
FX is able to switch to R/W access.
Cheers
jairunet said:
@Mr Hassan,
OS 12 and OS 13 I am guessing you mean Android 12 and Android 13, in any device, not just the Pixel 6 (which is the device I am working on at the moment)?
Thank you,
Click to expand...
Click to collapse
Op have very bad partitions table its on RO its blocks not sys parts to edits
The matter is not about editor
I can also try with pull then edit via pc notepad++ and try push but error not enough space
Or su not found or not accessible etc
tom1807 said:
No idea about OS12 on OnePlus, but I can assure you, that I was able to edit my build.prop with root access.
Maybe you use the wrong filemanager (I use FX) or don't have root access.
FX is able to switch to R/W access.
Cheers
Click to expand...
Click to collapse
Build prop edits still work ?
JazonX said:
Build prop edits still work ?
Click to expand...
Click to collapse
The system partition is read only and not even Root Explorer was able to fix that. With Magisk however I believe some files can be copied into a particular folder and run from there in place of the originals. Build.prop is almost certainly one of them.
I am rooted and I can't freaking access the damn thing either.
I'm thinking of downgrading the os to twelve. Won't give me read write access even with root.
dragonsouce said:
I am rooted and I can't freaking access the damn thing either.
I'm thinking of downgrading the os to twelve. Won't give me read write access even with root.
Click to expand...
Click to collapse
I haven't tried it, but there's this...
GitHub - HuskyDG/magic_overlayfs: Make system partition become read-write (it is also possible without Magisk)
Make system partition become read-write (it is also possible without Magisk) - GitHub - HuskyDG/magic_overlayfs: Make system partition become read-write (it is also possible without Magisk)
github.com