yashsingh1/xdaforums huggingface dataset:
[LG G8X ThinQ Guides, News, & Discussion] Stavinair Bluewing:
So I updated to 12, (model number is LM-G850QM, Software version is G850QM40b) from 11, and now when I try to use capture plus for some reason it doesn't show the overlay after hitting the edit icon. Backing out of it throws a "discarded" toast popup. I think it might be something to do with drawing over app permissions? I looked into it I couldn't see anything there that was causing the issue. Some help in this matter would be GREATLY appreciated.
[LG G8X ThinQ Guides, News, & Discussion] Stavinair Bluewing:
Also for some unknown reason I can't find wireless debug in the dev options
[LG G8X ThinQ Guides, News, & Discussion] Stavinair Bluewing:
Having the exact same problem on my v50s dualscreen but I hadnt updated anything. And its been two years without any response? No offense but some help you all are. Tch.
[LG G8X ThinQ Guides, News, & Discussion] Stavinair Bluewing:
For some goddamn reason Qmemo is reliant on animation duration. Setting that to 0 breaks some Qmemo functionality. Wtf
[Galaxy Note II Q&A, Help & Troubleshooting] skullnailer:
There were sc02e specific ROMs made by ma34s. Does anyone still have copies? CM11 is preferred as I prefer faster response and startup, and the games I want to install still supports KK.
[G1 Android Development] Koush:
Summary:

There have been a few threads about the root setuid su being a potential security hole on modified RC30 phones. We all want to have root on our phones, but we don't want malicious programs/people to take advantage of it.

To that end, I came up with the following program that fixes the security hole, and also allows you or any application to get root when authorized.

This program works with any application that may use su: no special code or support needs to be written. Just use su like normal from within both Java applications or a terminal.

To install, simply install the Superuser application on top of modified RC30 V1.2.

If Superuser does not install properly automatically, do the following to install it manually:

Make sure you have the adb tool from the SDK.

Unzip the ZIP file (it will create a folder called Superuser).

Run install.bat (or install.sh if you are on Linux) from the Superuser directory.

Here's the script that the install runs:

adb push bin/su /system/bin
adb shell chmod 4755 /system/bin/su
adb uninstall koushikdutta.superuser
adb install bin/Superuser.apk

How it works:

The modified su command looks in a whitelist database for uids that is allowed root access. That database is only accessible by the Superuser application and root.

If a database entry is found, it decrements the white list counter by one (so, an application can access su 10 times, 1 time, etc, depending on the count).

If no database entry is found, it will show the Superuser confirmation activity and wait for 10 seconds for the user to respond. If the user presses yes or always, it adds the user id to the white list. (If yes is pressed, the white list counter is just 1).

If access was granted, su will setgid/setuid and call /system/bin/sh.

Implementation:

The Superuser Java application was written by me.

su was based on the su implementation built by Google for the Android platform. http://android.git.kernel.org/?p=pl...eb00e56211962786ff89d0e7940f73d7e914e;hb=HEAD

Source code and binaries are attached to this post.
[G1 Android Development] jashsu:
v1.2 and up only, correct? Not the setuid sh of v1.1.
[G1 Android Development] Koush:
Edit: Yeah, you need a setuid su in /system/bin. Having a setuid sh won't work.
[G1 Android Development] cookzitall:
?

Can't root just be blocked from the handset..? So the only root access would b from adb..doesn't that make the phone safe? Or is this the only real answer to the security issue?
[G1 Android Development] Koush:
Yup, of course you can delete the su command from the handset so you can only adb shell for root.

However, then legitimate uses of having root on your handset would not be possible:

For example, I am currently working integrating the G1 WiFi router instructions sticked in this forum into the Android WiFi settings application.
[G1 Android Development] persiansown:
I did this and now everything is working fine, however I was wondering how another application can have root access other than the shell program you created.

Great work by the way!
[G1 Android Development] Koush:
They can use the Intent that is exposed by Superuser, that Shell uses to get root:

final int SUPERUSER_REQUEST = 2323; // arbitrary number of your choosing
Intent intent = new Intent("android.intent.action.superuser"); // superuser request
intent.putExtra("name", "Shell"); // tell Superuser the name of the requesting app
intent.putExtra("packagename", "koushikdutta.shell"); // tel Superuser the name of the requesting package
startActivityForResult(intent, SUPERUSER_REQUEST); // make the request!

Then, if the user presses Yes or Always, that Java application can call su just like normal:

Runtime.getRuntime().exec("su -c <your privileged command here>");

Otherwise, that command will fail.
[G1 Android Development] persiansown:
Sounds good. Great job. Hopefully apps that require root in the future use this method rather than trying to force it.
[G1 Android Development] hbguy:
Hi Koush,

I have Jf's modified RC30 but I am not that tech savy. Before I could access su in terminal emulator but now i am locked out. I downloaded both your apps off the mark but when I request superuser I get an error. Also terminal emulator now doesn't work when i enter in su. I think that was the point though.

However the error message on shell when i request superuser says;

error: permission denied: starting intent {action= android... and so on....

What should i do to get root back?

PLease advise.

Thank you,

hbguy
[G1 Android Development] cookzitall:
question

i change the "su" to a different word...thinking it wouold help with security a little while back..does that effect your program?
[G1 Android Development] mack:
hey can anyone tell me what empty whitelist means?
[G1 Android Development] d0nkey:
I am having the same issue. I cannot execute su from terminal, permission denied. and when i try to get su access with the new shell program i get and error with "android.permission.ACCESS_SUPERUSER.

now my root job is all for nothing and im wondering how to get it back to normal.

Do i have to reflash from the backup image?
[G1 Android Development] Leeah:
Check to make sure you have the latest version of the RC30 mod (1.2). If not. copy the update to your SD and install the new update. Then superuser and shell will work just fine and you will have root.
[G1 Android Development] Koush:
Yes, don't worry: it is not possible to "lose" root with Superuser. You can always adb shell in for root; and if worst comes to worst (and it shouldn't), you can reflash.
[G1 Android Development] hbguy:
I am updated to Jesusfreke's newest modified version 1.2 but I still get the same error when i request superuser off of shell ( i also remembered to run superuser before requesting access in shell too). I just re-flashed ( i think that's what its called) JF's modified and now I can run root on terminal emulator again if DONKEY still trying to figure out how to get it back.

I'd like to use superuser and shell but I think I'm missing something lol.

Sorry, clearly a noob here.
[G1 Android Development] JesusFreke:
I think what we need is a combination of fnord's and koush's approach :).

I'm thinking something along the lines of a sudo type program. Let's call it asudo (android sudo). Basically, there would be a sqlite database that contains a "white list" of user ids (java applications) that are allowed root access. This could potentially be time limited, or even "use" limited (i.e. a single use permission).

So when asudo is executed, it checks the database for the calling user id, and if it is allowed access to root, it would automatically run the specified command with root access. Otherwise, if the calling user id doesn't have explicit permission, it would prompt for a global password (which only the real person using the phone should know). The password would also be stored in the same sqlite database.

The same type of java based permissions scheme as Koush's could be implemented. When an application requests root access, it would pop up a notification screen similiar to what it shows now, with options something like - "allow access once", "allow access for 10 min", or "always allow access". And "don't allow access" of course. It would write a corresponding "allow" entry into the database based on what the user selected, and then the requesting application could execute asudo.

Thoughts?

Anyone wanna take this on? If not, I may have to do it myself :)
[G1 Android Development] Koush:
IMO, su should act like normal su in every respect from a scripting perspective. IE, it never prompts for password on stdin. Piping in passwords from Runtime.exec is sort of kludgy. Also, if you start start prompting for passwords on su, you open a whole can of worms moving forward: some su's on people's phones will require passwords on stdin, while others won't.

That is my primary aversion to fnord's implementation; it makes development a pain, and future compatibility scary.

I think one way to do what you are suggesting is to implement a su.jar, and have a /system/bin/su script that launches that jar file. That su.jar can then redirect the stdin/stout to /system/bin/realsu (which is the vanilla RC30 v1.2 su). su.jar can interact with the Android application layer (which realsu can not do) and prompt for a password, ask for confirmation, or check the whitelist in the Android UI.

This way, su behaves exactly as it should from an implementation standpoint, inside a console. Thoughts?

Edit:

Or conversely, you can modify a normal su to block on a call to an Android Activity that asks for user confirmation. That's actually probably the better way to do it: avoid the Java code unless absolutely necessary.
[G1 Android Development] jashsu:
Having a su script launch the jar file is more or less just the same as the requesting application launch the jar directly, I think. In any case, the difference would only be relevant for Android apps that use su. Given the relatively small number of apps that will fall into that category, it begs the question whether it is really necessary to implement Android su so perfectly transparent. I also wonder if the fully open Android implementations (e.g. Android on Freerunner) will have a su command and if so what their security implementation will be like.

Coming together and getting a de facto standard solution in place (and possibly pre-installed in JF's update packages) can't hurt.
[G1 Android Development] Koush:
Yeah, I admit the su script isn't ideal. Which is why I edited my post and suggested that su block on an Android Activity (the other way around) when necessary. :)

Off the top of my head, there are several applications that I am working on or have planned that will require su:

Fully configurable WiFi Router UI (that basically automates the instructions found in the sticky in this forum)

Screenshot Application

Auto Screen Rotation

And there will be even more applications that will require su as we move forward: and they won't just be reduxes of a console/shell, where it is reasonable to prompt for a password on stdin. So for that reason, I want the su implementation to be as transparent as possible, so future usage from Java applications isn't a pain in the ass.
[G1 Android Development] hbguy:
Jf, you are the man! and yes i am making sure that this message is over the required character and it is indeed a message with a profound meaning... :)

hbguy
[G1 Android Development] JesusFreke:
Maybe we just need 2 separate commands. One command for java apps that need root access, and one that a "real" user could run in a normal terminal session that would prompt for a password.

In fact, I think we could pretty much do that now. You could just install both Fnord's and Koush's su, and just rename one of the sus to something different. I think it would be easier to rename Fnord's su.. Koush's would probably require a re-compilation to change
[G1 Android Development] d0nkey:
i just wanted your program to work. now i have to do more work to get it back to the way it was. i was under the impression that your security fix would prompt the term emu to ask for su permissions. it fails and now i cant use the terminal to get root. and now i want it back.
[G1 Android Development] d0nkey:
but on a side note, you guys are doing great work on the development of this platform. I guess the whole point of my posts is to say hey, wtf. why did mine not work right? neither of you guys have proposed a reason for the errors that im getting using your su fix.

any ideas would be great, because i would like to still be able to root from the terminal and have it be secure asking for my permission for su.
[G1 Android Development] Koush:
Donkey: make sure you have V1.2. If you do, try reinstalling Shell and Superuser. Once inside shell, go to the menu and choose "Request Superuser", then type su.

I'm working on a better way to implement this, per Jesus' suggestions. You won't need to Request Superuser anymore. It will automatically show the dialog if you access su. I'll also be including a "sudo" command that will be similar to fnord's implementation, which will prompt for a password on the terminal. Basically it will be a mixed between my current application and fnord's.

Sorry about the bug.
[G1 Android Development] d0nkey:
dont apologize. im a software developer by trade, i know bugs will be there.

but, my phone was working just fine before the superuser program reset permissions on my su and now i would like it back to the way it was. i like the idea of having your program making sure i know what programs are trying to access root, but i would also like to use it myself. without having to jump through hoops to do so.

thanks for the reply
[G1 Android Development] d0nkey:
and yes, im using v1.2 of modded rc30. i will reinstall everything but its not going to fix my problem. i have to chmod my su file again and i dont have access to adb from work.
[G1 Android Development] d0nkey:
again, i get the same error message:

Error: Permission denial: starting intent {action=andriod.intent.action.superuser comp={koushikdutta.superuser/koushikdutta.superuser.SuperuserRequestActivity} (has extras) } from ProcessRecord{431d9b98607:koushikdutta.shell/10030} (pid=607,uid=10030) requires andriod.permission.ACCESS_SUPERUSER
[G1 Android Development] NYCdroid:
I installed Superuser and Shell a few days ago. It looks like I was on the 1.1 RC30 mod. How do I reflash to regain su?
[G1 Android Development] Koush:
Are you downloading from the market or my post? What order are you installing?

I'm working on a fixed version of su now. It will work completely transparently with any application that wants root access. That will fix the issues you are having. Sorry again.
[G1 Android Development] Koush:
Get JesusFreke's RC30 image sticked in this post and reflash.
[G1 Android Development] d0nkey:
installed superuser then shell and i got them from the app market.

I guess i will be reflashing tonight. or just adb shell and mount r/w and chmod su and remove superuser.. i suppose that will work too.
[G1 Android Development] Fnorder:
Admittedly a real su port (my implementation) doesn't allow for java apps with root permissions (unless the app knows to exec "su -c 'whatever'" from a tty, then enter a user-specified password), however as it's simple and operates as standard unix superuser security has traditionally operated, it's less likely to break and likely more secure. I agree with JF that there's room for -both- methods on a firmware release, with -both- disabled by default. The user must specify a root password / and/or grant app access before anything is allowed, lest something exec("/system/bin/su -c 'rm -rf /'").

As far as naming, I'd say mine would best be named 'su' while this one named something else (it's not quite sudo). Then again, a name doesn't matter - save for finalizing one. Koush's su should make sure to actually use setuid()/setgid() as alot of unix programs (bash and busybox with su support, for example) will drop be user back to what getuid()/getgid() returns. IE, a 4755 shell is not good enough.
[G1 Android Development] jashsu:
@Koush, Fnorder, JesusFreke:

After reading through the thread resulting from nuuneoi's auto rotate hack, I think we might want to have some kind of certificate-verification component in the su-fix. It would work like this: A developer signs his apks with his private key and publishes the file. User downloads and installs apk. When a su access attempt is intercepted, su-fix reads the .rsa cert from the apk and checks against a secure local pool of stored public keys. Now one of two things happens:

If the corresponding public key does not exist, su-fix informs the user that the app is unverified and queries whether to accept or reject the privilege escalation.

If the corresponding public key is found, su-fix can either inform the user that the app is verified and query for a yes/no or automatically escalate the privilege.

The benefits are two-fold. First, as long as the download of the public key is secure (I assume the developer would want to host this on their own server) then no matter what source the user gets the apk from, he can be assured that it hasn't been tampered with and resigned. Furthermore, any future apks released by the developer signed with the same private key will key against the same public key. As long as the user has kept the public key installed in the secure key pool, he will not have to take any further action.

The second benefit is that developers who are reluctant to open the source code to the entire world can share it with a select few people designated to verify that an apk contains no malware. These folks would be given access to the source code (in confidence of course) and after verifying the security of the code, sign it with a xda-dev-checker private key. The corresponding xda-dev-checker public key would come preinstalled with the su-fix.

Thoughts?
[G1 Android Development] Koush:
Yeah, the current version does use setuid/setgid (it is an unmodified version of the su packaged with RC30 1.2).

The version I'm working on right now will do a couple things:

It doesn't matter how su was invoked; if invoked, it will pop a UI asking for confirmation. This will make developer and user use painless, and will work on any app that needs su. Terminal, pTerminal, Shell, Autorotate, etc.
[G1 Android Development] JesusFreke:
Sweet. sounds like a good solution to me :)
[G1 Android Development] Koush:
Ok JF, Fnord, take a look at the newer implementation (attached to first post) and let me know if you want additional changes.

I've tested this modified su with AutoRotate, Shell, Terminal, and pTerminal and it works fine.
[G1 Android Development] JesusFreke:
Awesome! much better :)

One issue I just thought of is that people are going to be tempted to click "always" for /system/bin/sh, so they don't have to wait for the alert screen to pop up when they type su in terminal emulator. And if they do that, then anything could run "sh su".

But I can't really think of a good way around that... Unless maybe you keep going up the process tree until you find a java app and white list the java app (i.e. the terminal emulator app), instead of of the immediate process that actually executes su (sh in this case).
[G1 Android Development] Koush:
Superuser is whitelisting uids, not process names. So just because a user whitelists sh for terminal, it doesn't mean sh is whitelisted for shell: they have different uids, and each app has its own uid.
[G1 Android Development] widto08:
After installing the app's from the market, I too lost "root" and was getting the same message that d0nkey received above. No matter what I tried, it didn't work. So I thought I may be doing this wrong by d/l from the market so I d/l the "Superuser.zip" file found in the Koush's first post and unziped it to my desktop. I went to the command prompt on my computer (with phone attached via usb) and ran the "adb shell" to see if I could gain "root" as shown below.

GREAT!!! I was able to gain "root". I then navigated to the "Superuser" directory and ran the "install.bat" file exactly like the instructions stated in the quote above (highlighted in red) and it didn't work as shown below.

My first thought at this point was that I was going to have to re-flash my phone to get "root" back which I really did not want to do. So I thought about it some and figured maybe the unzipped "Superuser files" and the "adb" app needed to be in the same location/directory/folder. I moved them to the same dir as the adb and ran the "install" again and bingo bango it worked. :D

Thumbs up to Koush for taking the time to write all this for "us". Maybe you can edit your first post to state that after unzipping Superuser.zip file it's necessary to move them to the sdk/tools directory/folder.

p.s. can you explain why the line "adb uninstall koushikdutta.superuser" resulted in Failure?
[G1 Android Development] Koush:
The previous version needs to be uninstalled first is all
[G1 Android Development] JesusFreke:
Oh! duh. That makes sense. Thanks for clarifying :D
[G1 Android Development] d0nkey:
Koush, Fnorder, JesusFreke, jashsu:

Thanks for all the hard work. I will try this all again when i get a chance to adb shell from home.
[G1 Android Development] Koush:
Updated it on the Market and the zip file here: cleaned up some UI issues.
[G1 Android Development] jashsu:
Cool, will do a fresh flash and take a look. Maybe consider adding some version numbers to help with troubleshooting too?

On a side note, no thoughts on the certificate-based security idea? I'm concerned some hypothetical malicious actor could take some future well known community root-access-requiring app, modify it with malcode and redistribute it pretending to be a mirror of the original file. In the current superuser implementation, there isn't any way to tell a modified apk from the original.
[G1 Android Development] Koush:
All APKs are signed with a certificate. If you try to reinstall the same application with a different certificate, it would fail. The installer would let you know, and to install over it, you'd need to explicitly uninstall and reinstall.
[G1 Android Development] angel-78:
Seems a lot easier to use now thanks a lot.
[G1 Android Development] rdfry:
koush

What is the updated version number? Your work is greatly appreciated.
[G1 Android Development] grickson:
Well I can get root from 'Shell' but I cannot get root from Terminal Emulator, so my question is how do we get Terminal Emulator on your Superuser whitelist?
[G1 Android Development] JesusFreke:
Did you install his latest version? I'm guessing not. :p

The newest version works from terminal emulator.
[G1 Android Development] Koush:
Download the newer version. It fixes the problems with not being compatible with existing applications.
[G1 Android Development] Koush:
The current version number is 1.0.3.
[G1 Android Development] rdfry:
Koush

The new version will not install says file is not signed correctly. Do I need to uninstall the earlier version first?
[G1 Android Development] Koush:
Yes, I think my first version was using a Debug cert.
[G1 Android Development] rdfry:
Thanks Koush

that did it
[G1 Android Development] uta8111:
I'd like to make sure I'm clear on this sequence. I started with mod30 1.1 that had a setuid sh for local su access. Worked of course with terminal emul if telnetd running to answer.

Flashed to mod30 1.2. Shell was already installed, installed superuser program from K. Attempts to use "request superuser" from shell complain that the superuser program is not installed. Uninstalled and reinstalled shell on general principles, no change -- shell continues to ask that the superuser program be installed. Did I miss a step somewhere?

Side notes: I assume the old setuid sh named su must be manually deleted.

I haven't checked to see if the certs that were renamed to avoid OTA updates

"nothankyou" have been restored to their original state by the 1.2 flash.

Thanks.