Hello!
I've been looking for a way to achieve the topic title for a very long time but without result...
So what i'd like to accomplish is to give my application the ability to execute root/su -c commands without the device being actually rooted.
If this has to be done at the compiling of system.img / rom-cooking thats oke..
From what gathered through searching the source is that the init executable in the root of the device starts zygote, and zygote in turn is responsible of starting up each application.
This Zygote also manages what uid each application gets? If so shouldn't it be possible to change that uid to "system" or even "root"?
When you look at running processes on a device the "phone" app has as user radio..once again indicates it's very well possible to change under what user an app is being executed?
Also looking through the source the way an application gets a different uid seems to be because of sharing the same certificate on build, and in the androidmanifest.xml having
Code:
android:sharedUserId="android.uid.phone"
Am i have not yet find out where android.uid.* comes from but should the uid: system and root be there as well?
If anyone could enlighten me whether i am on the completely wrong track or if this makes any sense i'd be greatly appreciated!
Richard
Monday morning bump!
Isn't there any way to have an application start up as system/root user? is another way to do it perhaps via a service? and have that start up as another user?
Related
Just out of curiosity does anyone know if any android devices can be affected by a fork bomb sent via text or email?
It is Linux so I'm guessing it will be affected. Maybe it won't be like OMG but it will be some what affected.
If a text or email could execute a custom script on being received, there is probably a lot worse that it could do than a fork bomb... Might be possible to get two views to keep calling each other, in which case the bundle for that program will expand until it runs out of memory and android will kill the app. This is very much an app specific bug though, and isn't related to the "fork bomb" of a program making a new instance of itself.
I thought Android runs on the sandbox environment for applications, which means the app can't execute much permissions as compared to Windows.
Just my $0.02
Yes, the apps are sandboxed for the most part.
Now that I think on it, there is a launch flag to open a new instance of a program leaving any currently running ones alone, which could be used to make a forkbomb. In this case, it would not be stopped by memory as the earlier instances will shut down but the exponentially increasing new instances will keep going, probably making the phone unusable until a reboot.
This can only be done by compiling and launching a signed app though, no email client can do this unless it has a backdoor to trigger this code from itself or from a trojan-esque feature to download, install, and launch apps on its own. The user would be promted to ok the new app's permissions anyway, unless it uses and gets permission for root access.
Basically, forkbombs are possible, but not by email or text with stock or nonmalacious programs.
Task Management
If the script gained root access, it'd be just the same as on a Linux machine. But I believe the DalvikVM simply kills any apps/processes it needs to in order to keep the system running smoothly (in theory).
well it works...
https://github.com/nicandris/com.example.forkbomb
Hi everyone,
I'm trying to write an android program which will allow users to connect to an HID device. The device captures external pen strokes and I would like to retrieve this data and make a basic whiteboard app.
I've made some progress so far: if I use adb push to put the "hidd" daemon on a rooted phone and use hidd --connect, then I can open up hcidump and see the raw data appearing when the pen is used, so I know such a connection is possible.
I'm still a beginner at Android development, but I've learned that app communication with the bluetooth facilities is done via the dbus API. So, I wrote a simple test program using the NDK that tries to make a connection to the system dbus, based on some bluetooth-related code in mydroid/bin/frameworks/base/core/jni:
DBusConnection *conn = dbus_bus_get(DBUS_BUS_SYSTEM, &err);
On my non-rooted phone, this results in the error "VERBOSE/JNI1Activity_DEBUG(3226): Result: Could not get onto the system bus: Failed to connect to socket /dev/socket/dbus: Permission denied."
If I go ahead and do chmod 666 on /dev/socket/dbus on my rooted phone, then the connection can be made without error.
So, my question is this--first of all, am I going about this the right way? If so, is there some way that an application can get permission to talk to dbus on a non-rooted phone?
(If I can get this working, I think the next step would be to try and package/build in the needed parts of hidd to include with my app...)
Many thanks for any help,
Tom
Hi pyro777,
I was wondering if you received any replies on your query?
I also have a similar problem -- my android app accesses Dbus via a JNI, but I am getting the same permissions problem. I can use your workaround of explicitly setting the permissions on /dev/socket/dbus, but that solution can't be used for production code.
My Android java app as BLUETOOTH permissions, but this doesn't appear to be applied across the JNI boundary (as my experience indicates) into the JNI c++ library (*.so).
Does anyone have more info on this issue?
Thanks in advance,
robin
Hi evodevo,
No, no such luck so far if you figure it out I'd be happy to hear.
Strange, if this fails how does the normal Bluetooth java API it?
Perhaps certain permissions need to be set on your app? BLUETOOTH_ADMIN or so?
question 4 u: which libraries do you include when doing dbus stuff I get undefined references the whole time?
So, Im trying to address a battery readout issue with the Droid X. The system defaults the owner and group of /pds/public/battd to "mot_accy" (as well as /data/battd). This is causing the daemon to not be able to access the offset data and such, resulting in incorrect battery readouts across the scale.
I wanted to try manually adding the owner and group "mot_accy" to my build and setting root privileges to them, but after much searching, I have not been able to find out how.
Anyone have any suggestions?
Thanks in advance.
~Spz0
A Chairde
I am wondering if anyone can help me. I have heard there are Rooting methods on Android devices not involving third party software on the device, could you tell me what they are, and what phones support them. I have read the XDA Developers book, and the closest I have come is the Google Nexus phone on Chapter 8, Unlockable device, but still needs to load Busybox APK, and SuperUser binaries.
This question revolves around sound forensic techniques, I believe XRY load tools into RAM when using physical extraction.
Any help / pointers would be greatly appreciated
crumdub12 said:
A Chairde
I am wondering if anyone can help me. I have heard there are Rooting methods on Android devices not involving third party software on the device, could you tell me what they are, and what phones support them. I have read the XDA Developers book, and the closest I have come is the Google Nexus phone on Chapter 8, Unlockable device, but still needs to load Busybox APK, and SuperUser binaries.
This question revolves around sound forensic techniques, I believe XRY load tools into RAM when using physical extraction.
Any help / pointers would be greatly appreciated
Click to expand...
Click to collapse
By default, Android doesn't have the ability to substitute the current user for the root user, which is why the 'su' binary has to be installed. By adding a particular line to '/data/local.prop', you can trick the ADB into thinking it's communicating with an emulator, which would temporarily give the ADB elevated permissions, but most of the techniques needed to do so require other binaries that Android doesn't have by default, hence the need for Busybox.
XRY physical extraction, on the other hand, doesn't communicate with Android at all, so there are no "root" permissions to be gained. It relies more on very low level communication with the hardware itself and extracting raw data (i.e. ones and zeros). Highly specialized software would then be needed to translate that data into a more human readable format.
So, to answer your question...
As far as I'm aware, there is no way to achieve permanent "root" permissions on Android without (at the very minimum) installing the 'su' binary.
soupmagnet said:
By default, Android doesn't have the ability to substitute the current user for the root user, which is why the 'su' binary has to be installed. By adding a particular line to '/data/local.prop', you can trick the ADB into thinking it's communicating with an emulator, which would temporarily give the ADB elevated permissions, but most of the techniques needed to do so require other binaries that Android doesn't have by default, hence the need for Busybox.
XRY physical extraction, on the other hand, doesn't communicate with Android at all, so there are no "root" permissions to be gained. It relies more on very low level communication with the hardware itself and extracting raw data (i.e. ones and zeros). Highly specialized software would then be needed to translate that data into a more human readable format.
So, to answer your question...
As far as I'm aware, there is no way to achieve permanent "root" permissions on Android without (at the very minimum) installing the 'su' binary.
Click to expand...
Click to collapse
SoupMagnet,
You answered my question fully, you are a legend !!
Hello XDA Developers, I have a Debian subsystem of sorts on my phone which is created by an application called Lil' Debi. For those of you unfamiliar with it, it essentially creates a Debian install on an .iso that can be mounted onto the disk. Once mounted, a user can access a shell to interact with this Debian subsystem by running /debian/shell as root, which will chroot to its own directory system separate system accessible from the Android Terminal.
Within this Debian subsystem I have created a non-root user account for the purpose of running a few networking applications that if compromised for some reason, won't give the attacker root privileges to break everything on my phone. There's only one small problem with this setup: I can't access the internet from a non-root account.
Both my terminal emulator and Lil' Debi have full network access, even when not run as root. I am curious then, why a non-root user account should have an incapability of accessing the network. A sample of wget on my phone using Google's IP address (I use the IP address because it cannot do DNS lookup obviously) gives a Permission Denied error. At the current moment I am not sure whether this problem lies with Android or with Debian. Does the user need to be explicitly granted permissions to use the network through Debian, or is the application somehow only able to access the network if it's root?
Additional information: The ROM used is PAC ROM, so you can assume any settings changes that could be made from Cyanogenmod or Paranoid Android can be made if necessary. The phone itself is a Oneplus One. No I don't have invites, so don't bother asking.
Opinions on the matter?
Also, on an unrelated note, g++ will only run under root. If I launch it as a non-root user, it will tell me that execvp failed because cc1plus doesn't exist. Why?
Thread's fallen onto the third page, so I'm going to bump.
One day has passed, and no help offered. Bump again.
Another bump. I thought XDA was supposed to be the most knowledgeable forum on Android.
Daily bump until this problem is solved...
Still bumping...
I hope people aren't just looking at the number of replies and assuming it's resolved...
Bumping again. At least 100 people have seen this thread, and not a single one has anything to say.
Bump again. It's now been a week since I asked this question.
Bump.