yashsingh1/xdaforums huggingface dataset:
[G1 Android Development] Koush:
You don't need to request Superuser anymore from any application. I need to remove that menu item from Shell. Just type/use su and it should work.

Make sure you start the Superuser application at least once so it can set up properly.
[G1 Android Development] grickson:
i did re-install the newest one from the market :P..i just reflashed it back to modified RC30..im going to test it again tomorrow.. :)
[G1 Android Development] uta8111:
After installation of the superuser program, I did not see any visible change in behavior. The superuser whitelist entry point showed up in the app list, but nothing else. Nothing I did caused any program to pop up a permissions request or become whitelisted. I didn't start up telnetd to test with terminal emulator, but nothing else seemed to have any effect. Can you suggest an explicit test sequence I can use to verify that the installation of superuser is correct and functional? Thanks.
[G1 Android Development] jashsu:
Open Terminal Emulator and type su. If it didn't pop up a permission request then you need to start over and install Superuser 1.0.3. I suggest just reflashing and starting from scratch.
[G1 Android Development] Fnorder:
Hmmm. I finally skimmed the auto-rotate app thread...just as I was

thinking...why not make this sudo, instead of not-quite-sudo? There is a

trust issue with giving apps root access:

"I wouldn't trust my mom's binary if it asks me for a root password."

This isn't regarding the filename of the your 'su', but for example:

/etc/sudoers:

defaults noexec

Cmnd_Alias PROCESSES = /system/xbin/kill, /system/xbin/killall, /system/xbin/ps

Cmnd_Desc PROCESSES = List and kill processes.

Cmnd_Alias DRIVERS = /system/bin/insmod, /system/bin/rmmod

Cmnd_Desc DRIVERS = Insert or remove drivers.

Cmnd_Alias NETWORK = /system/*bin/ifconfig, /system/*bin/route, /system/*bin/iptables

Cmnd_Desc NETWORK = Alter your networking configuration.

Cmnd_Alias SHELL = EXEC: /system/bin/sh

Cmnd_Desc SHELL = Do ANYTHING to your system or data. Make sure that you trust this application!

backupapp ALL = /system/xbin/rsync -av /data/data/[^ ].db

user@hostname:/backup

vpngui ALL = DRIVERS, NETWORK, /system/xbin/openvpn, EDIT:/etc/openvpn.config

tetherapp ALL = NETWORK, DRIVERS, SCRIPT:/path/to/script.sh

that-autorotate-app-that-caused-drama ALL = mount -oremount\,r? /dev/mtd/mtdblock3 /system, \

chmod 6?? /system/framework/framework.odex

Basically - like in the gui - an app would need to request -specifics- on

what it needs to do, instead of requesting blanket permission to everything.

This is partially reinventing the wheel, and should really be a part of the

java API, but hey. Ideally an app should try to perform it's access requests

before the actual attempts, so as to generate one big scrollable popup,

instead of multiple small ones. Do allow this there could be a sudo

--request, which would read from stdin (for example):

DRIVERS

NETWORK

/system/xbin/openvpn

EDIT:/etc/openvpn.config

The example above is loosely based on /etc/sudoers on a normal linux system,

with some additions: Cmnd_Desc would replace the commands in the permission

request, so instead of 'this app is requesting the following type of access:

/system/bin/insmod, /system/bin/rmmod' it would be 'this app is requesting

the following type of access: To insert and remove drivers.'. EDIT: would

enable sudo --write /etc/openvpn.config, which would read from stdin, and

sudo --read /etc/openvpn.config, which would print out the contents. SCRIPT:

is probably asking for too much; it would require a built-in interpreter to

parse the script and call execs (That need to be in the allow list) so that

they couldn't exec. This is probably not very secure.

It should be noted that granting sudo access is a dangerous thing; you have

to make sure that the app you grant cannot in any way break out of the sudo

restrictions. This is not usually granted automatically by approving requests.

Still, with a large descriptive set of _Alias presets it may work, and it

would force apps to state what they want to do with root.

Also, NOEXEC depends on preloading a shared library, so granting statically

linked apps and ones that use a different libc would open a hole or cause the

app to not run.
[G1 Android Development] godcomplex:
Great work, but based on wrong approach?

So I just found this thread.. sorry if I'm getting into things a bit late..

This system is a great piece of work, a good solution to the initial security hole issue, and a great start to thinking about this whole root-access issue in a larger context, which I think is critical. I applaud Koush for coming up with this!

..but I have to say that personally I think it's based on a slightly wrong premise regarding how apps should be getting root access.

In my opinion, applications should not be obtaining root access by exec'ing a subprocess, running su (or sudo, or whatever), and piping shell commands to it at all. su was intended for (human) shell users, not applications, and using it in this way is really a hack, and it's completely contrary to the Android application model. What we actually should have is an Android service which runs with root access, and can accept, validate, and process requests from applications to perform root operations on their behalf, without any shell involved (similar to many of the other system-level Android services).

Initially, such a service might just present an interface that (after checking for appropriate permissions) allows executing an arbitrary command string passed to it by the app, and feeds it back the stout/stderr (which would allow apps to do roughly the equivalent of the su pipe, but without having to exec su to do it), and then over time more specific APIs (such as directly reading/writing files, making iptables changes, etc) and/or more fine-grained access controls could be established to allow more flexibility in what individual apps are allowed or prohibited from doing.

Ultimately, with this mechanism it would be possible for apps to declare up front what root privileges they need in their manifests, the same as any other android app permissions, and allow the user to allow or deny them at installation time. As a side-benefit, it also wouldn't matter what users did or didn't do with their su binary (or whether they had one at all), because apps wouldn't need to care about such details.

Mind you, I haven't looked at this idea in detail (I'm gonna go off and take a look now), but I think it should be doable without too much work, and would make for a much cleaner approach to the whole app-root-access issue, IMHO.
[G1 Android Development] jashsu:
That kind of advanced granular permissions approach has been touched upon I believe. Check out Fnord's comments about sudo-like permission model.

Is it a hack? Yes. No one should have any illusion that the current implementation is the best possible approach. What is available now is a stopgap measure to get some basic security in place.

Once you're talking about declaring root level permissions in the manifest and having a service that runs in the background handling this kind of stuff, you're talking about a project an order of magnitude more complex than what Superuser is/does. You should also consider: given the relatively small number of rooted G1s, is it worth the investment in time to bother creating such a nuanced and rich framework?

Edit: welcome to the forums ;-)
[G1 Android Development] godcomplex:
Oh, I understand that we need a stopgap, and this is definitely great work in that regard.. it's actually far more sophisticated than I was expecting in those terms, though, and looked like Koush was basically developing a general-purpose framework out of this whole thing (and he was talking about developing several other apps which need this sort of root access), which is why I brought up these larger issues.

I don't think it'd be that hard to set up a root service for this sort of access, though.. it seems like only a bit more work than what's already been done.. I may give it a try myself if I have some free time (which is kinda scarce at the moment, unfortunately, so no promises..). In any case, basically my point was that if people are planning on doing much more work in this direction, I wanted to suggest considering that approach.

As for the small number of rooted G1s, I'm still holding out hope that that's only a temporary thing.. sooner or later there will be a new exploit somewhere and we'll get a bunch more open handsets floating around. Ultimately, I'm looking at this from the perspective of beginning to develop an alternate community-supported firmware for the G1. Even if we never get another exploit, having a real, professional-quality alternative OS available with enhanced features would substantially strengthen the argument in favor of opening things up in general, so I think it's a good thing to work toward.

Sorry if my response seemed at all critical, it really wasn't intended to be. I was just proposing some thoughts on future development, should there be any..

(and thanks for the welcome :) )
[G1 Android Development] Koush:
Yep, this solution is not ideal. Obviously the best way to do it is to integrate with Android's security model and run a set of commands with root permissions. That's an approach I initially considered, but for a "root service" to really be successful, it must be adopted and used by all applications that need access. I didn't see that happening. So the best way to maintain application compatibility/functionality and protect your su was to just intercept the exec on su.

Also, regarding piping in passwords: The reason I implemented it the way it is, is because I'm worried more about user experience than how it is "supposed to work". If an application requests root access, an in your face dialog letting you know is nice to have. (BTW, the real su and sudo command don't accept piped passwords either.)

Also, developers shouldn't have to worry about what version of su is running on the phone and piping in passwords. Also This implementation works with unmodified su as well as a Superuser protected su.

And Jashu is correct, doing something to the level of sophistication you are suggesting is probably not worth the time. :)
[G1 Android Development] godcomplex:
Frankly, I don't see how that's any less likely than all applications adopting and using the approach you've done. We now have several different semi-official solutions to the su issue (not to mention several other variations I can think of which some people may have done on their own setups, such as my personal quick hack to fix this issue (make su only executable by the one app ID I use it with)), some of which will work with apps which use your model and some won't, and there's no good way for an app to know which one it's dealing with.

I'm saying take the su issue out of the equation for applications and publish a recommended API for apps to use instead. Then you avoid the whole issue of what form of su somebody chooses to set up. And I really don't understand why everybody thinks it would be so difficult. Sigh.. I guess now I'm gonna have to go do it just to prove it's not that hard.

Please note I never advocated piping in passwords. I actually think your approach is much better than that. I was actually advocating something entirely different (don't use a utility that might or might not require piping in passwords in the first place). However, for the sake of accuracy I should point out that the real su does always prompt for a root password. That's what every form of su on any real (Unix/Linux/etc) system does, and it's what's in the POSIX spec. The version of "su" that was provided for Android is a drastically oversimplified "su-like program" which isn't a real su at all (and in my opinion should never be used on a real phone.. arguably, it shouldn't have been included in JesusFreke's RC30 to begin with, but I can't really fault him too much for that as most people were already using setuid-sh, which is just as bad).

I don't have a problem with Android "su" doing something different than real su, but you can't really argue that asking for a password is a fundamentally wrong approach either, because, arguably, to be a correct implementation of the real, standard su, it actually should do that.

Anyway, sounds like I'm the only one who thinks a real API would be a good idea, so I guess I'm on my own.. Sigh.
[G1 Android Development] Koush:
Hmm? You must have misunderstood: other applications don't need to adopt and use my implementation: it has an "it just works" design regarding protecting su access. Ie, your application that needs su access just works whether or not the su is unprotected or protected by Superuser.

Incidentally my first implementation *did* have a service based superuser type functionality.

Basically the way it worked was you included a:

<uses permission android:name="android.permissions.SUPERUSER"/> in your manifest.

That gave you the rights to call into a Superuser service (which showed a dialog just like the current one) and ran whatever you wanted it to run.

You might actually be able to see some old posts towards the beginning of this thread that describe how to use the service. After some feedback from JF and Fnord, I scrapped that in favor of just retaining compatibility with other applications, such as Terminal Emulator and DroidSans Tweak Tools. I didn't want to ask the authors of those to rebuild/reimplement their programs with support for some third party root service API AND also have them retain compatibility with people that don't have that root service installed.

If you want to do it right, which is what I think you are suggesting, you'll have to modify the Android source extensively. Basically the Java layer will need access to all the things you must currently do via a command line through a set of legitimate APIs (iptables, installing native binaries, rebooting, remounting, modifying dex files, running a process as another user, etc). Then you protect access to the various API calls via the permission model native to Android. Each application will have to have a corresponding uses-permission in their manifest to be able to use that API. Because realistically, even a root service application where you pass in a bunch of commands is still just a bandaid, and not an elegant or proper solution.

Edit: Check out Fnord's comment in post #60 where he suggests something similar regarding granularity in access, rather than blanket root access.
[G1 Android Development] jashsu:
I'm not saying it's a bad idea, far from it. It would be pretty neat from a grey-hat hacking perspective. No project or endeavor is ever really perfectly complete, especially when it's only a layer or a module in a larger context. The problem this thread set to tackle was security, and to some extent that problem has been satisfied (Atleast to Koush and JF's satisfaction). Given that the amount of time available to work on side projects is a limited quantity, one has to kind of perform triage on the problems at hand. Meaning, at what point are you ready to say "okay, this is enough work, lets move on to the next job."

Of course if you decide to embark on some serious hacking to get a fullblown api in place, you should also consider the very likely possibility that a future Android may 1) trivially or permanently break the superuser api or 2) expose official superuser api (Lot of third parties wanting to get their code running on Android below the VM like Flash, Silverlight, Mozilla).

:p
[G1 Android Development] godcomplex:
..which is why my suggestion was regarding a relatively small additional piece that I saw as particularly low-hanging fruit, but would be a step in the right direction should people want to work on it in the future. But everybody else seems to have gotten it into their heads somehow that what I proposed is some horribly tremendous task (which it really isn't), so whatever. Everybody's also apparently gotten it into their heads that I'm saying "you have to do this", and all I was trying to say was "if you're going to do more work in this direction, howabout another approach?", but apparently I'm a taskmaster now. I give up.

Both of those possibilities seem very unlikely to me, actually, but it really doesn't matter anyway.

FYI, just as a side-note, root access is not required to run native code under Android. Any app can do it, it's just discouraged (and requires using unofficial APIs). One of the first apps I wrote for my new phone actually demonstrated exactly this.
[G1 Android Development] jashsu:
Nah, no one's accusing you of anything like that. At this point Android is just a hobby/side project for a lot of us. If it's the same for you, then you should code what you want to code. :D

I'm guessing the meaty stuff like writing to the fb would be completely out of the question though =/
[G1 Android Development] Koush:
AFAIK there's two ways you can do that:

You can drop an embed an executable into your application and write it into the /data/data/com.myapplication directory and chmod it as executable.

Or, you you can create a library and invoke that from Java somehow? I know this is how the Browser does it for web plugins like Google Gears.

Is there another way?

But yes, as you said, root access is not required to run native code, but for something like reading from /dev/graphics/fb0, it is.
[G1 Android Development] jashsu:
Yeah, JNI.

This thread on the platform mailing list has some relevant discussion about it.

Edit: another relevant thread on android-platform.
[G1 Android Development] Koush:
Cool, I figured that was it.
[G1 Android Development] jashsu:
Getting rather off-topic here, but Jean-Baptiste Queru posted an interesting comment about native code inside apk, somewhat soliciting feedback from devs:
[G1 Android Development] LGSilva:
Hei Koush, did you remove this app from android market? I can't find it there anymore...
[G1 Android Development] Koush:
Yes, it has been unpublished. Superuser is now packaged with the various modified images, so the download is obsolete. In addition, I think JesusFreke is using a different signing key anyways, so upgrading from a modified image to what is on the web site would not work. You should upgrade to a modified 1.3+.

Superuser is also now hosted at http://code.google.com/p/superuser/
[G1 Android Development] xile6:
Hey i have modified 1.3.1 and i just did an aTrackDog and it says that there is a new version of superuser 1.0.3 (modified 1.3.1 only has 1.0.1) Is there anyway to download and install superuser 1.0.3 or will i have to wait till JesusFreke adds it to a new modded verison?
[G1 Android Development] jashsu:
JFv1.31 has the absolute latest version of Superuser. The version numbering is probably just set incorrectly.
[G1 Android Development] Koush:
JF actually started with the source for an older version of Superuser. It doesn't matter though; the changes were only cosmetic.

Regardless, we have a Google code project now so the changes (if any) will be completely up to date from here on out.
[G1 Android Development] maydaysos:
Im having trouble getting this to work in Harukos 5.0.1htc build. do i use fast boot for this.
[G1 Android Development] BRad Barnett:
Hi Koush,

I have just rooted my Rogers G1. As I understand it, there are no other images for me to flash. Even if there were, I really don't want to flash other images.

I think the Magic is in the same boat (no modified images yet).

Would you republish, or provide an up to date downloadable image? Or, is there one somewhere?

Much thanks for anything you can do...
[G1 Android Development] androidmonkey:
Is it possible that someone has found a way to get around SuperUser? I installed Advanced Task Manager and it does not prompt me for root access. Ive used "Task Manager for Root Users" in the past and it ask me for root access.

Now I am worried that other apps are using root without me knowing.
[G1 Android Development] firetech:
That's because it doesn't need root. It even says so in its Market description. Stuff was added to cupcake so that you don't need root for being a task manager anymore.

You can calm down.
[G1 Android Development] androidmonkey:
I didn’t know that. I was looking at the developers blog

http://arronla.com/

4) Terminate applications if **ROOT Access is enabled**

http://www.cyrket.com/package/com.arron.taskManager
[G1 Android Development] firetech:
Well, that post is dated "February 20, 2009", and therefore quite outdated. It's even pre-cupcake ;)
[G1 Android Development] bijixda:
Hi,

where can i download latest superuser? it don't seem to work on 2.1 (milestone)

or is there any tutorial how to compile su.c ?

thanks
[Redmi 7A Questions & Answers] lemonsqueeze:
Hi,

This is a continuation of my errands in magisk-support-2661and magisk-support-2662. I'm interested in the twrp aspect here, hopefully someone who knows twrp welll reads this.

Basically this is a Redmi 7A phone with stock MIUI 10.2.5 and twrp 3.3.1. Phone got messed after updating Magisk to latest version, and while trying to fix it i accidentally wiped data from within twrp. It says this preserves internal storage so I thought this would be ok, but internal storage is encrypted on this device and after doing this i can't access my files from twrp anymore (before it used to ask for my pattern). Files are still there encrypted, and looks like keys are still there in /data/misc so I guess all hope is not lost.

Any ideas on how twrp Wipe data functionality is supposed to work on encrypted storage devices, and how to get one's files back afterwards ?

Help appreciated before i mess things up further =)
[Redmi 7A Questions & Answers] J.Michael:
Before you wiped data, was TWRP able to decrypt? able to view what you call internal storage?
[Redmi 7A Questions & Answers] lemonsqueeze:
Yes, it asked for my pattern and was able to decrypt the files.
[Xiaomi 12S Ultra] boober78:
I wanted to change the superwallpaper to the Earth one, it doesn't apply. Anyone has this issue? Latest xiaomi.eu rom
[Xiaomi 12S Ultra] def-g:
Nope. All of mine work. Did you make sure it downloaded?
[Xiaomi 12S Ultra] boober78:
It looks like it did. Can I re download the APK or just this wallpaper? Can somebody link the APK here maybe?
[Xiaomi 12S Ultra] def-g:
Try applying like the Saturn SWP. Then try downloading and applying the Earth one. Alline work and I switch regularly.
[Xiaomi 12S Ultra] boober78:
I have all downloaded. When trying to apply the earth, it won't even show the preview, it's black. After application, there is old 2allpaper applied. I was hoping to re download it but i don't see that option
[Xiaomi 12S Ultra] boober78:
Now, I broke the superwallpapers. I uninstalled Earth and the icon to download shows up there, but I cannot download it, nothing happens. Anyone has an idea what to do now?
[Xiaomi 12S Ultra] boober78:
@def-g would you be able to extract apk's from your MIUI?
[OnePlus 9 Pro] jimbobha:
I can't flash/boot recovery, edl is completely inaccessible, I even disabled driver signature verification. Fastboot does work but I can't boot to edl through it
[OnePlus 9 Pro] TheGhost1951:
Try to run command fastboot boot twrp and then in twrp boot to edl from there
[OnePlus 9 Pro] TheGhost1951:
Do not use the Indian MSM Tool. Will give links.....stay tuned....
[OnePlus 9 Pro] TheGhost1951:
T-Mobile MSM Tool.....

OP9Pro - Repository of MSM Unbrick Tools (TMO, EU, GLO, IN)

By using these tools, you accept full responsibility for your actions. Your warranty is void should you run any of these utilities without OnePlus support present. I am not responsible for bricks, fires, nuclear war, etc. If you modified any...

xdaforums.com

TWRP for OP9P....

OnePlus 9 Pro (lemonadep)

Disclaimer:Team Win strives to provide a quality product. However, it is your decision to install our software on your device. Team Win takes no ...

twrp.me

Be sure to read all instructions...these links are for the OnePlus 9 Pro....
[OnePlus 9 Pro] jimbobha:
downloading 'boot.img'...

OKAY [ 5.504s]

booting...

FAILED (remote: Failed to load/authenticate boot image: Load Error)

finished. total time: 5.521s this is what happens