There is a bug on some Samsung Android Phones causing USB-debugging to automatically be turned on if the USB is plugged in. This is obviously a security issue. I want to write a program which will disable USB debugging so that I can start it whenever usb-plug is inserted.
Any ideas on how to do this?
It seems to be impossible. I think I must use Settings.System with ADB_ENABLED, but ADB_ENABLED is a Secure-System-Setting which cannot be changed by a normal application. :-(
On the other hand, there is the permission android.permission.WRITE_SECURE_SETTINGS, so it looks like I can alter it. Can I get it on a rooted phone?
If someone has an idea on how to fix this security issue, it would be great.
I don't think it is a security issue.
First, it is the responsibility of a developer to only make debug messages available that do not compromise his application in the later.
Secondly, debug messages that are used for development should probably have another debug level than for production.
Third, if your application exposes data via adb that compromisses your application, maybe there's something wrong in the app design in the beginning?
Fourth: It is not recommended to toggle settings that the user should be able to configure. I would hate to see manything I configured go on and off by starting an app. Of course, you mentioned the Bug with Samsung. But I think they should be able to fix this.
Regards, Chris
To achieve this , you require android.permission.WRITE_SECURE_SETTINGS permission.
Without root : From ABD execute adb shell pm grant <package-name> android.permission.WRITE_SECURE_SETTINGS
With root : Root access means we can execute shell commands without adb, so workaround for that :
try {
Runtime.getRuntime().exec(new String[]{"su","-c",String.format("pm grant %s android.permission.WRITE_SECURE_SETTINGS",BuildConfig.APPLICATION_ID)});
} catch (IOException e) {
// handle IOException
}
Related
Background: I am developing for a signage device which is to be remotely operated. I need an application that can
Fetch and install new packages
Reboot the device (for troubleshooting)
I have an unrooted Android device. I also have files which I am told are the platform keys.
I have developed an application which attempts to kick off the su process.
Process p = Runtime.getRuntime().exec("su");
Before I signed the application with the platform keys this was throwing an IOException, with the message being Permission Denied.
I signed the application with these platform keys, and I am still getting the Permission Denied exception.
Here are three contradictory statements. Which one of these statements (if any) is correct?
Statment 1: This should work. The application, even though is is stored in /data/app, should be able to run su. Either I have the wrong keys, or there's some other entry I need to add to the manifest to get it to work.
Statement 2: This shouldn't work. Even though it is signed with the platform key, the application is in /data/app, so it's a data application, not a system application. Data applications cannot run su on an unrooted devices. If this application was installed into /system/app, then it would be able to run su. (And I can't get it into /system/app because it's unrooted, so I'm stuck).
Statment 3: This will never work. If the device is not rooted, then NOTHING can run su, even if it is a signed system app.
Android shouldn't even have a su binary if you didn't flash some sort of root method to the device, such as Magisk or SuperSU.
Even if it does have a su binary, I wouldn't expect it to work, for one of two reasons. Assuming that your device comes with a preinstalled su binary, who's managing it? If it's unmanaged, it should just deny all requests. If you flash a root method, then it's up to that manager to decide if your app gets access to su, regardless of whether you have signature-level permissions or nor (the root manager uses a different signature, after all).
And why would you even need access to su as a signature app? You have total access to the device anyway. If you need to run a command, you should have no problems no matter what you run, as long as it's done from your platform-signed package. But since you have full access, the native APIs should let you do everything you need.
As for the IOException returned when you try to execute su in a Process, that's just a weird Android quirk. If there's no su binary installed, it'll sometimes return command not found and other times permission denied, depending on the device.
The point I think I'm making is that, unless your app is the root manager, you could be part of the system_server and still have the same access to su as everyone else. For which statement I agree with, I think #3, although I don't fully agree with it, because chances are su just doesn't exist, or it's a dud binary.
I've explained why #1 shouldn't be true, but #2 is just incorrect. If you look at the platform manifest, every permission that requires a privileged app can also be granted to signature apps. So even if you did move your app to /system/priv-app/ (/system/app/ won't make it privileged), it wouldn't make a difference. Basically, if your app is signed by the platform signature, it doesn't matter where it's installed.
EDIT:
You can easily reboot by just running reboot as a command, since you have signature-level access to the system, but it's a little more elegant to use the proper API for this. If you use the API, you get the shutdown animation, but you also let the system shut down gracefully, stopping services and sending the ACTION_REBOOT broadcast to any apps that might be listening for that.
To use the API, first add the following permission to your AndroidManifest:
<uses-permission android:name="android.permission.STATUS_BAR_SERVICE" />
Now, where you need to call the reboot action, use the following code:
IStatusBarService bar = IStatusBarService.Stub.asInterface(ServiceManager.getService(Context.STATUS_BAR_SERVICE));
bar.reboot(false); //using true here will reboot to Safe Mode
This method is a hidden method, so if you're using Android Studio to edit and compile, it'll error out. You can use reflection, or use Android Hidden API to access it directly.
This is how System UI implements it in the power menu: https://github.com/aosp-mirror/platform_frameworks_base/blob/master/packages/SystemUI/src/com/android/systemui/globalactions/GlobalActionsComponent.java
This is the class that implements IStatusBar service: https://github.com/aosp-mirror/platform_frameworks_base/blob/master/services/core/java/com/android/server/statusbar/StatusBarManagerService.java#L969
I'd go with Statement 3. This will never work on an unrooted Android device. At least, not on recent Android OS versions (I have no idea if this might work on really old Android devices).
"su" is an application -- there has to be an "su" binary on disk in order to execute it, and Android does not by default provide an "su" binary for security purposes. When you use thirdparty rootkits, they install their own "su" binary to provide a mechanism for the user to elevate themselves to root privileges.
If your app is signed with a special key and granted elevated privileges from startup, why would you need to execute "su" anyway?
I want to create an app to turn on/turn off Android developer mode. This will be on a rooted device. What api's do need to call?
I know i am answering it very late but i will surely help other who are searching on this.
To enable developer options programatically :
Settings.Global.putString(this.getContentResolver(), Settings.Global.DEVELOPMENT_SETTINGS_ENABLED, "1");
To disable :
Settings.Global.putString(this.getContentResolver(), Settings.Global.DEVELOPMENT_SETTINGS_ENABLED, "0");
But to access this Settings.Global... , it requires a permission
android.permission.WRITE_SECURE_SETTINGS
But normally , This permission is only granted to system app
You can also grant this permission to user app using ADB
Since you said your app would be running on a rooted deice , so have access to the shell , so you can grant this permission to your app by running the below shell command
pm grant <your.package.name> android.permission.WRITE_SECURE_SETTINGS
I don't think it is possible. Since it is part of the Settings.Secure.
Secure system settings, containing system preferences that applications can read but are not allowed to write. These are for preferences that the user must explicitly modify through the system UI or specialized APIs for those values, not modified directly by applications.
I recently jumped into an android development tutorials and doing my own app for the sake of learning. I want to get root permissions within my code in a proper way. So not by calling /system/xbin/su but by using something like seteuid(0). Unfortunately seteuid method does not work for me.
I am testing app on a real device, which I rooted, enabled debugging mode and well I clearly see that when using a call to /system/xbin/su my app requests root permissions from system, which does not happen with seteuid and seteguid (setuid and setguid do not work either but I would not expect those to do it as they are capable only in lowering the permissions).
Please, advice on where to look for a proper code implementation for requesting root permissions like it would do a top notch developer. Maybe some native api call? Or does everyone just use a call to su to get the needed access?
The usual way in Linux of elevating privileges -- that is, to run an application with greater privileges than the logged-in user -- is to set the SUID flag on the executable (e.g., chmod ug+s ...). This will make the process take the identity of the binary's owner (usually root), rather than the logged-in user.
This is tricky to do effectively on Android, even on a rooted device. First, you won't be able to install an app using the usual (APK) mechanisms that includes binaries with SUID permissions. Second, an Android app is not an executable in the usual sense -- a single executable handles the launching of all apps.
Still, if you want to experiment on the command line, it should be possible to set the SUID flag on binaries, in at least some filesystem locations.
If you have a rooted Android, then very likely there is some infrastructure already in place to control privilege elevation. Most likely the "su" command will work (because there will be kernel mods to make it work), and it will be provided either with credentials or with some other way to control which apps can use it. I believe that, as you suggest, calling "su" is the usual way to do privilege elevation in apps on rooted Android. It is fraught with difficulties, however. There's a document https://su.chainfire.eu/ that explains how "su" is typically implemented in rooted Android devices, and gives some guidance on how to use it properly.
Just in case posting my solution to the problem which I did in Java (no native code is needed here):
protected void hideRoot() throws IOException, InterruptedException {
Process p = Runtime.getRuntime().exec("su");
DataOutputStream dos = new DataOutputStream(p.getOutputStream());
dos.writeBytes("mount -o remount,rw /system\n");
dos.writeBytes("mv /system/xbin/su /system/xbin/suhidden\n");
dos.writeBytes("exit\n");
dos.flush();
p.waitFor();
}
I made an Android app that internally calls su -c "pm ...". However, I get Permission denied when my app tries to execute this.
My app appears as Deny in the SuperUser log section, but CYM does not ask me via a Toast what I want to do, nor it appears in the Allow/Deny list...
Clues?
Thanks!
L.
I upgraded to CYM 11 M10, and now su works fine. No doubt it was a bug. So now I can mount/umount encrypted stuff as I was always able to do.
It seems the problem is solved in the M10 build.
Several questions about shutting down a rooted android device have answers saying you should run "reboot -p" within an "su" shell. However, this answer says that reboot is quite low-and-dirty and doesn't do sufficient tidying up before pulling the plug. Instead it recommends using android.internal.app.ShutdownThread.shutdown(). Looking at the code I can see that this does a whole bunch of housekeeping stuff that I'd like to have, and it also has a handy "confirm" parameter that appears to let you shut down without asking for confirmation, which is nice.
My question is this - what properties does an app have to have in order to call ShutdownThread.shutdown()? Does is require a particular permission that can be set if the device is rooted, or does it have to be signed using the firmware key, or something else entirely?
Shutting down the device requires you to hold android.permission.SHUTDOWN which is only available to system applications, or applications signed with the platform certificate.