Related
Seriously. Why don't we have sudo on Android? Is there some technical limitation I'm missing?
Well, the first thing I'm noticing, is we don't have su under /system/xbin.
So it seems step one would be to compile a compatible binary for the phone in question, and then a method to place su into /system/xbin.
You must be new. What phone you talking about
Sent from my HERO200 using XDA App
I'm a bit new here, but I'm pretty sure I used su. Did you root your phone? If you do, you'll have su. Rooting an evo 4g isn't hard; google it(can't post links; too new).
thatguythatdid said:
You must be new. What phone you talking about
Sent from my HERO200 using XDA App
Click to expand...
Click to collapse
You must be new (to Linux).
Evo 4G, rooted, swapped for Fresh, swapped to DC, swapped to CM6, swapped back to 100% unrooted stock (current status).
In a 'normal' Linux installation, you usually log in as a normal user. Su, ie 'Switch user' or more commonly old-school 'Super user' allows you to temporarily log in as another user (we're going for 'root' here) and utilize that user without logging out and in of the current shell.
Running as root all the time is bad for security, as any Linux user can tell you.
Clearly, I have no desire to run as root on my phone ALL the time.
Also, from a development standpoint, releasing apps that ONLY work on rooted phones is ridiculous - you cut out the vast majority of users.
Which brings me back to the original topic - why don't have we su / sudo on Android yet?
Here's what I've come to this morning:
Well, su and sudo have to be compiled and compatible with the kernel. I was mistaken, in that I thought of Android similar to a normal Linux distribution (aka distro) - usually, you'll have many distros that utilize the same exact kernel, and this runs over a very large number of systems. Thinking deeper, however, I realized that even though most desktops are different, at the end of the day they are all x86 compatible - in other words, low level communication is the same between all major PCs.
On smartphones, however, you've got multiple architectures - I'm most familiar with ARM (Qualcomm) and OMAP (Texas Instruments). The kernels for the two will not be the same, unless we (the community) build a super-kernel that would run on both architectures (unlikely just from an efficiency standpoint). Android is just the framework that sits on TOP of the Linux Kernel.
In my particular case, the Evo 4G, it appears 'su' is not even on the phone. A quick 'adb shell ls -l -R -a > file_permissions.txt' show me, however, there is a hidden directory named 'sbin' on the phone, that is only accessible as root.
So my next step is to re-root my phone, flash the rooted 1.47 OTA image, and see what the hell is in that sbin directory.
The following step, I'm going to compile an ARM compatible copy of sudo, insert it into a non-rooted (stock) image, along with a proper /etc/sudoers file and see if I can develop a way to have a non-rooted image, with the ability to take root at will, on command (whether via su or sudo)
The purpose of this post is to find out if anyone's already attempted this, and if so, where they got stuck.
I have a /system/bin/su on my phone (G1 w/ CM6RC2). Any 'rooted' ROM should have the same. I don't understand why you think otherwise.
I'm the developer of QuickSSHd, an app that runs a secure shell daemon, either as root or not-root. I've also submitted (small) patches (and had them accepted) to the Superuser.apk and su.c that is used on most of the newer rooted ROMs. I've been using Linux for > 10 years.
Which brings me back to the original topic - why don't have we su / sudo on Android yet?
Click to expand...
Click to collapse
We do have su on Android. And the su we have is done in a way that it's more like sudo as it prompts the user for allow/deny and remember. But no password is needed.
http://github.com/ChainsDD/android_packages_apps_Superuser
http://github.com/ChainsDD/android_packages_apps_Superuser/blob/eclair-froyo/su.c
If for some reason you want to compile sudo you'll run into issues that Android's libc doesn't include crypt for passwords as the user system is completely different on Android. I don't think anyone has tried as it would be rather pointless with the above Superuser.apk and su (usually /system/xbin/su or /system/bin/su)
[email protected] said:
I'm the developer of QuickSSHd, an app that runs a secure shell daemon, either as root or not-root. I've also submitted (small) patches (and had them accepted) to the Superuser.apk and su.c that is used on most of the newer rooted ROMs. I've been using Linux for > 10 years.
We do have su on Android. And the su we have is done in a way that it's more like sudo as it prompts the user for allow/deny and remember. But no password is needed.
http://github.com/ChainsDD/android_packages_apps_Superuser
http://github.com/ChainsDD/android_packages_apps_Superuser/blob/eclair-froyo/su.c
If for some reason you want to compile sudo you'll run into issues that Android's libc doesn't include crypt for passwords as the user system is completely different on Android. I don't think anyone has tried as it would be rather pointless with the above Superuser.apk and su (usually /system/xbin/su or /system/bin/su)
Click to expand...
Click to collapse
Very nice, thank you for the information, Kevin. Believe it or not, I wasn't able to find anything searching here nor via Google.
Very informotive post guys, thanks.
I must ask, where can I find more on how Android is built?
Wouldn't be simple to add the possibility to ask a password while calling su binary? You can tell me it's useless, but some people may don't want anybody to access superuser powers on his phone. It would be safier if in Superuser's preferences we could add a password protection, IMHO. Of course this MUST be an option, not an imposition. But I would appreciate it veeery much.
mike.sw said:
Very informotive post guys, thanks.
I must ask, where can I find more on how Android is built?
Click to expand...
Click to collapse
There is a 2 part video which may help.
Part one is here:
http://m.youtube.com/#/watch?desktop_uri=/watch?v=1_H4AlQaNa0&v=1_H4AlQaNa0&gl=GB
Cheers
Please use the Q&A Forum for questions &
Read the Forum Rules Ref Posting
Moving to Q&A
HUGE BUMP
This was a very valid question. While the wording was.. oblique at best, it does raise a point.
Why are we not using sudo instead of su? Or at least, password protecting su. I realize SuperSu offers this feature if you.. pay for it. Seems backwards.. paying for a linux.. cough. Nevermind.....
In any event, I would think password protecting your su binary would very serious security concern for everyone... unless there's something the Android API does via some.. sandboxing that makes it a non-issue.. (please correct me.)
Side note, admins of this site..
You realize you have 6 trackers for social bullsh and allow passwords for logins to be transmitted in plain text? Better fix it.. before someone gets naughty and follows those spider webs....
Long story short because android OS is not open source like linux. They is how cell company's still make dollars
---------- Post added at 01:19 PM ---------- Previous post was at 01:10 PM ----------
Not
Doward said:
You must be new (to Linux).
Evo 4G, rooted, swapped for Fresh, swapped to DC, swapped to CM6, swapped back to 100% unrooted stock (current status).
In a 'normal' Linux installation, you usually log in as a normal user. Su, ie 'Switch user' or more commonly old-school 'Super user' allows you to temporarily log in as another user (we're going for 'root' here) and utilize that user without logging out and in of the current shell.
Running as root all the time is bad for security, as any Linux user can tell you.
Clearly, I have no desire to run as root on my phone ALL the time.
Also, from a development standpoint, releasing apps that ONLY work on rooted phones is ridiculous - you cut out the vast majority of users.
Which brings me back to the original topic - why don't have we su / sudo on Android yet?
Here's what I've come to this morning:
Well, su and sudo have to be compiled and compatible with the kernel. I was mistaken, in that I thought of Android similar to a normal Linux distribution (aka distro) - usually, you'll have many distros that utilize the same exact kernel, and this runs over a very large number of systems. Thinking deeper, however, I realized that even though most desktops are different, at the end of the day they are all x86 compatible - in other words, low level communication is the same between all major PCs.
On smartphones, however, you've got multiple architectures - I'm most familiar with ARM (Qualcomm) and OMAP (Texas Instruments). The kernels for the two will not be the same, unless we (the community) build a super-kernel that would run on both architectures (unlikely just from an efficiency standpoint). Android is just the framework that sits on TOP of the Linux Kernel.
In my particular case, the Evo 4G, it appears 'su' is not even on the phone. A quick 'adb shell ls -l -R -a > file_permissions.txt' show me, however, there is a hidden directory named 'sbin' on the phone, that is only accessible as root.
So my next step is to re-root my phone, flash the rooted 1.47 OTA image, and see what the hell is in that sbin directory.
The following step, I'm going to compile an ARM compatible copy of sudo, insert it into a non-rooted (stock) image, along with a proper /etc/sudoers file and see if I can develop a way to have a non-rooted image, with the ability to take root at will, on command (whether via su or sudo)
The purpose of this post is to find out if anyone's already attempted this, and if so, where they got stuck.
Click to expand...
Click to collapse
hi. i can't believe i'm the first person to ask this but i've searched as best i can through these forums, and on google, and cannot find a definitive answer. there are lots of pages giving high level descriptions of rooting a phone like "gives admin access", "allows access to the root filesystem", etc. but, when you root a phone, what actually happens ? does it simply make the "su" binary available so that apps can call it to access the root user ? eg. i've got a samsung galaxy s2, if i install an insecure kernel, then add su to /system/xbin, and then reinstall a stock kernel, is that technically a rooted phone ? this is actually what i did on my phone, although i installed superuser and busybox from the market after adding su. i am aware that there are various threads in the sgs2 forums on how to root, i'm just using my phone as an example, i'm just trying to understand generically what is meant when someone says a phone has been rooted. cheers.
Full control over your system
Ability to alter system files. You can replace many parts of the "Android Core" with this including:
Themes
Core apps (maps, calendar, clock etc)
Recovery image
Bootloader
Toolbox (linux binary that lets you execute simple linux commands like "ls") can be replaced with Busybox (slightly better option)
Boot images
Add linux binaries
Run special apps that need more control over the system
SuperUser (lets you approve or deny the use of root access to any program)
Task Manager For Root (Lets you kill apps that you otherwise could not kill)
Tether apps (like the one found at [android-wifi-tether.googlecode.com])
<there are more but I cannot think of any right now>
Backup your system
You can make a folder on your sdcard and backup all of your .apk files to your sdcard (helps if an author decides to "upgrade" you to a version that requires you to pay to use the version you just had)
Relocate your (browser/maps/market) cache to your /sdcard
Relocate your installed applications to your /sdcard
Reboot your phone from the terminal app easily (su <enter> reboot <enter>)
Copied and pasted from google... it is your friend.
thanks for the response however, i'm trying to understand what actually changes on the phone when you root it, rather than simply the benefits of rooting a phone.
Carrot Cruncher said:
thanks for the response however, i'm trying to understand what actually changes on the phone when you root it, rather than simply the benefits of rooting a phone.
Click to expand...
Click to collapse
Unrooted phone is like logging on as user in a computer. By rooting you have "administrative" rights, just like using sudo command in Ubuntu. Some binaries which are important in gaining administrative rights are installed in the phone.
sent from my nokia 3210
If you come from Windows, you're familiar with the Administrator account. A user that can do everything on the system, as opposed to other users than only have limited privileges. In Linux, that account is called "root". That's all there is to it. It's a user that can do everything on the system.
@Panos_dm: Actually, it's *not* like using sudo. Sudo gives elevated privileges to your existing user account, whereas "root" is a whole separate account.
Nope, sudo actually switches users
i'm a linux user and have been a linux admin in the past so understand the difference between su and sudo. sorry to sound pedantic but i'm still not clear on exactly what happens when you root a phone, i.e. what exactly happens during the rooting process ?
It opens your phone to a whole new array of possibilities.
Sent from my HTC Sensation 4G using xda premium
Carrot Cruncher said:
but i'm still not clear on exactly what happens when you root a phone, i.e. what exactly happens during the rooting process ?
Click to expand...
Click to collapse
In a gist? The "su" binary and the Superuser.apk app get installed. Sometimes doing so requires exploiting a vulnerability via a trigger. Rageagainstthecage is a common trigger. I once had a link that explained what exactly rageagainstthecage does, but I don't have it anymore.
If you really want to know all the details, here's the script I used to root my Defy: http://pastebin.com/G3m9v4FQ
Hmm, I see the script contains a link to the explanation of what rageagainstthecage does. Cool.
many thanks for confirming my understanding of the process.
I bought this nice minicomputer - MK812 Mini PC Dual-Core Android Camera Mic BT 4.2.1 and I relied on the fact that since there is Android 4.2 installed, I can use switching users, but unfortunately this function is disabled. I need to get it to work.
Of course, I googled. This is what I've already tried:
http://www.pocketables.com/2013/03/how-to-enable-multiple-user-mode-on-cyanogenmod-10-1-and-some-other-android-4-2-2-roms.html
The problem is that this command pm get-max-users returns Unknown command get-max-users.
Furthermore, when I enter SetProp fw.max_users 8, it has no effect, even after a reboot. The command pm usernameyouwanthere create-user is also without effect.
http://forum.xda-developers.com/showthread.php?t=2187934
App - 4.2 Multiple users feature enabler
This app can't be installed by Google Play (apparently MK812 is not a compatible device). Since I couldn't get APK anywhere to download, I downloaded the source code and compiled it and generated APK. Unfortunately, can't be installed either.
I studied the source code and found out that even if i was able to get it installed, it wouldn't have worked anyway, because this app runs similar commands (as those above) instead of the user.
https://play.google.com/store/apps/details?id=fahrbot.apps.switchme
This could be a solution even for Android 4.0 and 4.1. It works, but switching takes too long, because it requires a reboot and this switching is not integrated into the system. So I do not want it.
Do you know of any other solution or anything what I could try?
I googled again, found this - http://forum.xda-developers.com/showpost.php?p=34362377&postcount=8
But setting fw.max_users=8 in /system/build.prop haven't helped either.
Unfortunatelly they answer me, that MK812 mini pc does not support multiple user function. So I have to use SwitchMe Multiple Accounts
H0w4rd said:
Unfortunatelly they answer me, that MK812 mini pc does not support multiple user function. So I have to use SwitchMe Multiple Accounts
Click to expand...
Click to collapse
try
"setprop fw.max_users 8"
Lower-Case setprop without the quotes.
Edit: I see, can you and are you willing to get the source, modify it, build it and flash it? I'm going to have to enable it for my phone so when I figure out what needs modifying I'll let u know.
Hei there!
I just encountered some suspicious behavior on my phone, and I suspect some kind of malware / rootkit.
Background Information
After I accidentally deleted some pictures, I've installed EaseUS MobiSaver to try to recover those.
The scan for deleted files found some of my lost pictures, but also quite some more!
Turns out there are dozens of pictures, respectively screenshots of very random screens like, setting up my clock, browser pages, browsing files, watching YT or VLC, opened apps and so on.
I've attached some of those below.
At first I thought those images are just some kind of framebuffer leftovers or something like that. But then I found that "rootSU.png" image which is baffeling.
Kaspersky, Sophos and Malewarebytes do not find any hints of a infection.
As for my phone / environment
Pocophone F1
PixelExperience 10.0
NoGravityKernel 1.4
Magisk 20.4
So for now my phone is offline, and I would like to investigate what's going on there.
Is there any way to scan the system from external over adb or something?
.
The mentioned rootSU.png picture obviously is a screenshot, made by whomsoever. Yes, an innocent-looking image - sent either via the internet or text - could open your Android phone up to hacking.
Can it be you've run XIAOMI ROOT tool?
BTW, with regards to ADB: If your device is rooted, then install Termux: Termux is a free and open code app that simulates the command shell used in Linux. By doing so, you can introduce all the usual commands and work comfortably from your Android device - you don't need ADB.
jwoegerbauer said:
The mentioned rootSU.png picture obviously is a screenshot, made by whomsoever. Yes, an innocent-looking image - sent either via the internet or text - could open your Android phone up to hacking.
Can it be you've run XIAOMI ROOT tool?
BTW, with regards to ADB: If your device is rooted, then install Termux: Termux is a free and open code app that simulates the command shell used in Linux. By doing so, you can introduce all the usual commands and work comfortably from your Android device - you don't need ADB.
Click to expand...
Click to collapse
Thank you for answer.
No, did not use any XIAOMI Root-tool. Rooting was done via Magisk.
But termux could give me some insight. :good:
Well, despite those suspicious files, I was not able to identify any odd behaving processes.
I guess it's time to wipe and reinstall.
Ok lets first explain the situation
I've been dabbling with Tasker (Paid for version)- getting some automation depending on certain situations (mainly stuff like 'If I'm @ {location} get volumes set high' or ' If Unread msg then vibrate my Amazefit bip watch' - Nothing too complicated using variables / javascript etc)
One situation I want to attempt though is 'If Gpay app is started - turn on NFC, but when I leave the app - turn NFC off'
Now I already know there are 2 'main' ways I can turn on/off NFC in Tasker.. either use 'AutoInput plugin' or use 'Secure Settings'
- I've tried with Autoinput plugin but the problem is that with the free option, you need to watch an Ad every day to use it but of course I can pay for it (its only a couple of quid)
However you can't Install it & pay for it directly from within the plugin - you need to install yet another App (AutoApps) first - & although this one is free - I just don't like adding more bloat to my phone than necessary. Adding both the plugin & this additional App adds (although only a 'minor' amount) up to 20Mb
The other method is give Tasker 'Secure settings' permission
- So I read the 'What to do to give 'Write Secure Settings Permission' to Tasker' (enable Developer mode > Usb Debugging > Install ADB on PC etc etc) & it looks simple enough,
But (a loooong time ago) I tried other 'hacks' & it ended up disastrously (probably I did something wrong with missing a step or something) & I just want to make sure that it IS as simple as it seems and also ask how safe is it
for example
* If I type in the command in ADB - could something go wrong & could it crash/brick the phone ?
* Is this permanent - ie if I turn off/on phone or if I get an OTA update & phone restarts - will it stay, or will I have to repeat the ADB command each time ?
* Will this 'break' official OTA updates (whether security &/or Android firmware) - I once did a firmware update with a step that used ADB (IIRC) & it broke something that prevented any updates from happening
- official OR manual firmware updates
Any help/advice would be appreciated
Cannon_Foddr said:
* If I type in the command in ADB - could something go wrong & could it crash/brick the phone ?
* Is this permanent - ie if I turn off/on phone or if I get an OTA update & phone restarts - will it stay, or will I have to repeat the ADB command each time ?
* Will this 'break' official OTA updates (whether security &/or Android firmware) - I once did a firmware update with a step that used ADB (IIRC) & it broke something that prevented any updates from happening
- official OR manual firmware updates
Click to expand...
Click to collapse
ADB is the door to your phone's Android. It's a tool not meant to be used by John Doe. Wrongly used you can brick your phone. Hence it's by default disabled.
1. Yes, using ADB you can render your phone absolutely useless. If you e.g. enter
Code:
adb shell rm -rf /
then phone gets totally wiped ( really all gets destroyed, it gets naked ) - you can throw it into electric waste.
2. ADB commands aren't persistent, but their results may be.
3. ADB itself breaks nothing: it's a driver installed on your computer that let you access Android's files and launch Android executables.
Thanks for the reply
I doubt I'll use THAT command.
I forgot to mention what tasker's command is
adb shell pm grant net.dinglisch.android.taskerm android.permission.WRITE_SECURE_SETTINGS
Not 100% sure about your last comment though.
ADB allows access to android files so changing android files could break things, which I'm worried about especially with OTA updates etc. (my last phone stopped getting OTA updates when I rooted it despite using official firmware)
However IF I understand the above command all this does is tell the android operating system ('android') to only give the tasker app (which 'Real' name is 'net.dinglisch.android.taskerm') the rights ('permission') to access the required settings ('WRITE_SECURE_SETTINGS') which the NFC on/off toggle is part of (settings >connected devices > connection preferences> nfc) & 'shouldn' t' affect any other files such as OTA (unless OTA is also part of secure setting?)
@Cannon_Foddr
As I can see you until now haven't understood what ADB is, how it works.
Same probably your understanding of what an OTA is.
Personally never would allow 3rd-party apps ( like Tasker ) to modify sensible system settings: Tasker isn't an open-source app, so you can't control what it does in the last run.
It's simply on you to decide whether Tasker is given that right, or not ...
Can't see why 'open-source' has to do with this
IMHO if Open-source - anyone can release similar apps with added extra hidden code that could spy's on you/steal info etc, but a 'closed sourced' app from a long running developer (tasker been around for 10yrs with over 1mil downloads) must mean people seem to trust him/them & if he was 'dodgy' surely he would've been caught out by now
Anyway the Bottom line seems to be
Safe route: pay for plugin & live with extra bloatware
Or
Risky route: give access to secure system resources, see what happens & keep fingers cross nothing does
Thanks for your replies.. I think I may have to sit down & have a long hard think which route I feel more comfortable with
I have been using Automate for about 4 months now. I granted it WRITE_SECURE_SETTINGS and I have not noticed any modifications in my system. Granted I may have not looked specifically for them but as far as braking the system or disruption of OTAs no issues so far
DennisHarrows said:
I have been using Automate for about 4 months now. I granted it WRITE_SECURE_SETTINGS and I have not noticed any modifications in my system. Granted I may have not looked specifically for them but as far as braking the system or disruption of OTAs no issues so far
Click to expand...
Click to collapse
I assume you had to do something like Taskers command then to grant the secure settings
( "adb shell pm grant net.dinglisch.android.taskerm android.permission.WRITE_SECURE_SETTINGS" )
Cannon_Foddr said:
I assume you had to do something like Taskers command then to grant the secure settings
( "adb shell pm grant net.dinglisch.android.taskerm android.permission.WRITE_SECURE_SETTINGS" )
Click to expand...
Click to collapse
Automate is straight forward, there is a toggle for "modify system settings" needed for some tasks to run and one you run the ADB command, it's done