Database Info

[Q] Conceptual Rooting question

Hi all,
First post here, be gentle.
I am a linux user (pretty noob but learning) and I'm a bit confused about what I've been reading on rooting android. I'm looking at getting a Droid X and I'm just trying to understand things before I dive in (already running 1.6 as a VM to play with it).
As far as I can tell--my bash skills not being quite good enough to completely understand everything in the rooting wikis--the methods employed to gain root access to a phone (from: wiki link) use an external OS to push image files onto the phone, then remove the native rights management files (mid.txt?) and replace them with something else in the pushed files. (Please correct me if I'm wrong, cause I probably am)
When completed, this presumably allows you to run su and changes the root password or removes it (though I have no idea how that would work). If this is the case, and I root my phone does this mean that my default login to new sessions will be as root, or will I have to run su to gain privileges? And if I have to run su, what's the password?
One of the first things I learned when getting into linux was that root can be dangerous--you can kill your computer etc.--so, what does this mean for my phone? Can I just login as an admin and then sudo for the apps that need it? (Yes, I realize that I would have to install sudo and edit the list of sudoers etc.) Is it not dangerous to run as root or it it dangerous but easily ignored?
I'm just curious about this because it seems funny to me that a lot of joe shmos who have no idea what they're unleashing by running as root might suddenly hear that it's a great idea to go into a terminal and run
Code:
#rm -rf /
and I have this desperate hope that it's not as simple as that and there is some kind of rights management still in effect once a phone is "rooted." If not, and rooting a phone really does log you in as root for every session then it's much more dangerous than I had thought.
Thanks,
Bob

Is there really no one here who can answer this?
My phone is coming on Wednesday and I'd love some help with this and I can't believe that one of the brilliant people here can't answer this.

Sorry nobody replied yet. When you root there is usually a one click root app that does everything for you. After you are rooted you can install superuser from the market and it lets you choose what apps are allowed to have root access. You can search the droid forums for more info since I have an epic. If this helped please hit the thanks button below
Sent from my Epic that craves frozen yogurt

Temporary root shell for developers on locked bootloaders.

Hello All! I am me2151.
I am here to tell you some kind of good news.
We have achieved a temporary root shell using a modified recowvery script. Originally Recowvery installed a custom "recovery" but I have modified it to instead create a temporary root shell using the System_Server SELinux context and disable the flashing portion of the script. Yes we are still limited until we can get Kernel or Init context but I am working on that as well.
This exploit will be useful down the line because of one major thing. WE CAN INSERT KERNEL MODULES!!! But they need to be signed. So I am releasing this out here so we can take the next step into our full root! We also have rw to the /data partition and changes save over a reboot.
If we can get someone to sign a kernel module that the system accepts we can set SELinux to permissive.
This exploit SHOULD work for all variants.
NOTE: This should only be used by devs who know what they are doing.
Instructions(this should work on MacOS and Linux only!):
Download linked file below.
Extract to either adb directory OR a directory you have adb access in.
Give execute permissions to temp.sh.
Run temp.sh.
When you are all done with your exploring and stuff type "Reboot" to reboot normally.
https://drive.google.com/open?id=0B8CP3g3AqMuHcmNJUUJWLUJUelE
Credit:
 @jcadduono - For recowvery, and pointing me in the right direction on IRC.
 @brenns10 - Wrote the lsh used in the exploit to spawn the shell.
The group over here for ideas and solutions.

Very cool work! Glad to see people putting my shell (such as it is) to good use. Wish I had a V20 to try it out

I don't think you'll ever be able to sign a kernel module (SHA512 hash). You'd probably have better luck signing your own boot image.
Here's a theory to toy with:
I think the way to do it would be to gain read access to /init binary allowing you to dirtycow /init with the same init binary but change a very specific (but not vital to system integrity) set of instructions to point back to the setenforce code with a value of 0 without disturbing the rest of the binary/instructions. This way, init should continue running without crashing and taking down the whole system, and you can do something that might trigger that specific instruction set - which would then result in selinux becoming permissive.
This is beyond me, unfortunately. This method would also be very device specific until someone also finds an intelligent way to read init, modify instructions, then dirtycow it back.
I think system server context might be able to read init?
Once you get your permissive selinux, you'll also have to deal with Unix capabilities limitations (find a way around them).

jcadduono said:
I don't think you'll ever be able to sign a kernel module (SHA512 hash). You'd probably have better luck signing your own boot image.
Here's a theory to toy with:
I think the way to do it would be to gain read access to /init binary allowing you to dirtycow /init with the same init binary but change a very specific (but not vital to system integrity) set of instructions to point back to the setenforce code with a value of 0 without disturbing the rest of the binary/instructions. This way, init should continue running without crashing and taking down the whole system, and you can do something that might trigger that specific instruction set - which would then result in selinux becoming permissive.
This is beyond me, unfortunately. This method would also be very device specific until someone also finds an intelligent way to read init, modify instructions, then dirtycow it back.
I think system server context might be able to read init?
Once you get your permissive selinux, you'll also have to deal with Unix capabilities limitations (find a way around them).
Click to expand...
Click to collapse
if system_server can read init then thats a serious flaw.... Question for you. you said it would be very device specific. does that mean its unique for each individual phone or each model?
EDIT:Unfortunately we only have access to the init.rc not the binary it self.

@jcadduono I appreciate your input and direction in this matter another idea we have been toying with is
We have the aboot boot recovery and system dump. From the tmob variant would it be possible to make a tot from that for our devices changing the props to match our device, build, and carrier info? We can also pull apks from /system/apps and /privapps to our ext sdcard

@me2151, @jcadduono, @brenns10: Great work guys, keep it up. Good to see some people are trying for root. What model/s are being tested, or should this theoretically work on all models? Whilst you probably aren't doing it for the cash, there is a bounty I hope someone can claim soon, for a functonal root alone (not boot unlock) posted on this board.
RoOSTA

roosta said:
@me2151, @jcadduono, @brenns10: Great work guys, keep it up. Good to see some people are trying for root. What model/s are being tested, or should this theoretically work on all models? Whilst you probably aren't doing it for the cash, there is a bounty I hope someone can claim soon, for a functonal root alone (not boot unlock) posted on this board.
RoOSTA
Click to expand...
Click to collapse
It should work on all models. I personally use a sprint model(LS997). I think it MAY have been tested on VZW as well.

I can confirm that work on H990DS
Sent from my MI PAD using XDA-Developers mobile app

We know from earlier LG phone releases that the laf partition when bypassed in some way (corrupted, etc) aboot will boot to fastboot when going into download mode. It was my thought that the bootloader could be unlocked from there. However corrupting laf eliminates device recovery. Catch-22.
I think the best way to proceed is to get a working .TOT first which is just a waiting game. That would ensure device recovery and replacing the bootloader in the .TOT and signing it with something unlockable.
This is a great way to explore the locked phones in the meantime, thanks.

ATT Pretty Please

me2151 said:
Hello All! I am me2151.
I am here to tell you some kind of good news.
We have achieved a temporary root shell using a modified recowvery script. Originally Recowvery installed a custom "recovery" but I have modified it to instead create a temporary root shell using the System_Server SELinux context and disable the flashing portion of the script. Yes we are still limited until we can get Kernel or Init context but I am working on that as well.
This exploit will be useful down the line because of one major thing. WE CAN INSERT KERNEL MODULES!!! But they need to be signed. So I am releasing this out here so we can take the next step into our full root! We also have rw to the /data partition and changes save over a reboot.
If we can get someone to sign a kernel module that the system accepts we can set SELinux to permissive.
This exploit SHOULD work for all variants.
NOTE: This should only be used by devs who know what they are doing.
Instructions(this should work on MacOS and Linux only!):
Download linked file below.
Extract to either adb directory OR a directory you have adb access in.
Give execute permissions to temp.sh.
Run temp.sh.
When you are all done with your exploring and stuff type "Reboot" to reboot normally.
https://drive.google.com/open?id=0B8CP3g3AqMuHcmNJUUJWLUJUelE
Credit:
@jcadduono - For recowvery, and pointing me in the right direction on IRC.
@brenns10 - Wrote the lsh used in the exploit to spawn the shell.
The group over here for ideas and solutions.
Click to expand...
Click to collapse
At the moment all I am using root for is to add a line within my build.prop to disable Tethering checks, so I can tether at full 4G speed and not get throttled. Would this be possible using the method above, or would build.prop immediately get replaced at the reboot?
Thanks, and keep up the good work!

NRadonich said:
At the moment all I am using root for is to add a line within my build.prop to disable Tethering checks, so I can tether at full 4G speed and not get throttled. Would this be possible using the method above, or would build.prop immediately get replaced at the reboot?
Thanks, and keep up the good work!
Click to expand...
Click to collapse
no. it is a tcp root shell that can only do a few things such as kernel modules.. only section we were able to write to and have it stick was the /data partition which wont help you in this scenario

elliwigy said:
no. it is a tcp root shell that can only do a few things such as kernel modules.. only section we were able to write to and have it stick was the /data partition which wont help you in this scenario
Click to expand...
Click to collapse
So if we can write to data partition then in theory can we adb push to it using this? I ask because I'd like to install some tbo apps that normally would require flashing. But if we could push them we would be solid

markbencze said:
So if we can write to data partition then in theory can we adb push to it using this? I ask because I'd like to install some tbo apps that normally would require flashing. But if we could push them we would be solid
Click to expand...
Click to collapse
Unfortunately its a tcp shell. not a pure adb shell. so we cannot push or pull to those directories

Wow great progress keep up the good work. You guys are helping those assholes from LG sell more phones. Obviously some people have not made the switch because the lack of root. Root users are very influential leaders to get others to try out a new device.
Sent from my LG-LS997 using XDA-Developers mobile app

Works on the LG G5 also...

Hey guys, with the expectation of many that 'root is coming' to the other v20 models...are we likely to see the same type of root format that applied to the LG G4, where you have to (either) download or rip your own image to a PC. Use commands to insert root, then reflash to the device?
Any root is better than nothing, I know...but I ask because with the amount of software updates for the G4 (v10c software through to v10k before MM came out), meant the sheer amount of times you'd have to go through this process to keep your phone up to date whilst maintaining root was extremely frustrating - as it also meant xposed and related settings/apps needed to be reinstalled each time you performed an OTA update and re-flashed root.
Is this going to be a side effect of dealing with a locked bootloader? PS: If I sound dumb, it's probably because I am.
RoOSTA

roosta said:
Hey guys, with the expectation of many that 'root is coming' to the other v20 models...are we likely to see the same type of root format that applied to the LG G4, where you have to (either) download or rip your own image to a PC. Use commands to insert root, then reflash to the device?
Any root is better than nothing, I know...but I ask because with the amount of software updates for the G4 (v10c software through to v10k before MM came out), meant the sheer amount of times you'd have to go through this process to keep your phone up to date whilst maintaining root was extremely frustrating - as it also meant xposed and related settings/apps needed to be reinstalled each time you performed an OTA update and re-flashed root.
Is this going to be a side effect of dealing with a locked bootloader? PS: If I sound dumb, it's probably because I am.
RoOSTA
Click to expand...
Click to collapse
it shouldnt be an expectation as weve made it clear we do not have root and are hitting hurdles.. we have been advised we need to atack selinux and or the bl but at this point were wanting to try to use debug firmware which hoprfully would allow a bl unlock..
unfortunately nobody can creat a .tot with the debug firmware at al and theres no way at all to flash the images..
we need to somehow leverage an exploit to gain a temp adb root shell before we could even attempt anything and this has not been done in a way thats useful to us..
unfortunately we need more experienced devs at this point.

LG Australia (and as such, Taiwan) have effectively confirmed their H990DS v20 mobile phone's bootloader is confirmed as being unlockable. However (and for no apparent reason) they will not confirm why one region have released a variant of the phone with the bootloader unlock and why they are refusing this to others phones/regions. Because of course, they have zero training and information about anything related to their company expect for goods released in a specific region. That comes from a 'product expert'

Titanium Backup
Howdy,
Just reading through the thread, I understand that it's not quite a "full" root, but would it be enough to run Titanium Backup? I'm hoping to move away from root access with my V20 but it would be really helpful if I could do it temporarily, restore some application and data backups, reboot and uninstall Titanium.
Tim

True? Unlocked phone + su == rooted?

Hi,
I have successfully unlocked my motorola phone using the motolora support
page.
Unfortunately, the motorola device does not have su(1) on it.
If I were to get an su binary from somewhere (like, compile it myself),
and store it on the sd-card or in some download directory, would I
effectively have rooted my device?
Without having to load some unknown binary from some hackers somewhere
(like superSu) in order to do it?

tmellman said:
Hi,
I have successfully unlocked my motorola phone using the motolora support
page.
Unfortunately, the motorola device does not have su(1) on it.
If I were to get an su binary from somewhere (like, compile it myself),
and store it on the sd-card or in some download directory, would I
effectively have rooted my device?
Without having to load some unknown binary from some hackers somewhere
(like superSu) in order to do it?
Click to expand...
Click to collapse
That is not how root works, the su binaries have to be in the /system partition, placing su binaries in user partition does absolutely nothing. What's wrong with using SuperSU?
I DO NOT PROVIDE HELP IN PM, KEEP IT IN THE THREADS WHERE EVERYONE CAN SHARE

Droidriven said:
That is not how root works, the su binaries have to be in the /system partition, placing su binaries in user partition does absolutely nothing. What's wrong with using SuperSU?
Click to expand...
Click to collapse
If it's provided by Google or from the android source tree, then I would feel secure in using it. Other than that, I avoid solutions where I have to take binaries from unverifiable sources.
And in general, everybody offers some (binary) tool to do your rooting for you, but - once the manufacturer lock is removed - I don't understand why linux isn't linux.

tmellman said:
If it's provided by Google or from the android source tree, then I would feel secure in using it. Other than that, I avoid solutions where I have to take binaries from unverifiable sources.
And in general, everybody offers some (binary) tool to do your rooting for you, but - once the manufacturer lock is removed - I don't understand why linux isn't linux.
Click to expand...
Click to collapse
The developer that created the SuperSU app along with many other apps that you might be familiar with is called Chainfire and he's known worldwide, you might have heard of him.
Without him, alot of the custom software and a lot of the tools/apps we use to customize our devices wouldn't exist. He has been pretty much the most influential developer in the entire android rooting and customizing community. If that isn't verifiable enough for you then something is wrong with you. In fact, I'm pretty sure that you have or will require something he developed when you customize your device.
Everyone in this community uses at leat one of his apps.
Android operating system isn't linux, it's based on a Linux kernel but the operating system is very different. The linux kernel is about all that they have in common with a couple of exceptions.
Su binaries aren't something that would ever come from Google or android source tree. It will ALWAYS come from somewhere else other than Google or android source tree, even if you write the su binaries yourself, yours would be just as questionable because they also would not be coming from Google or android source. How would your own su binaries be any different than the ones that already exist?
I DO NOT PROVIDE HELP IN PM, KEEP IT IN THE THREADS WHERE EVERYONE CAN SHARE

Droidriven said:
Su binaries aren't something that would ever come from Google or android source tree. It will ALWAYS come from somewhere else other than Google or android source tree, even if you write the su binaries yourself, yours would be just as questionable because they also would not be coming from Google or android source. How would your own su binaries be any different than the ones that already exist?
Click to expand...
Click to collapse
I've already gotten this URL from Usenet:
(googlesources) /platform/system/extras/+/master/su/
(unfortunately had to obfuscate the URL due to a limitation of the forum)
and have fetched arm-linux-gnueabi-gcc.
As to running from /system, I've seen mention of this:
mount -o remount,rw /system
Now perhaps I understand what that's needed for.
I'm collecting the information bit-for-bit, but am not 100% sure I'll be able to run with my image and without third-party code...

tmellman said:
I've already gotten this URL from Usenet:
(googlesources) /platform/system/extras/+/master/su/
(unfortunately had to obfuscate the URL due to a limitation of the forum)
and have fetched arm-linux-gnueabi-gcc.
As to running from /system, I've seen mention of this:
mount -o remount,rw /system
Now perhaps I understand what that's needed for.
I'm collecting the information bit-for-bit, but am not 100% sure I'll be able to run with my image and without third-party code...
Click to expand...
Click to collapse
If you want root, it will be third party code, regardless of what method, software or tools you use. Root is not a stock android or Google product so third party is the only source.
If you're on lollipop, Marshmallow or nougat then pretty much your only option to root your device is to use one of the universal rooting apps and hope one of them works. Otherwise, you probably won't get root.
I DO NOT PROVIDE HELP IN PM, KEEP IT IN THE THREADS WHERE EVERYONE CAN SHARE

Disable ability of installing/removing apps on android smartphone

Is there an elegant way to disable the ability of a smartphone user to install and uninstall applications?
We have the following situation. Our company purchased smartphones for employees so that they communicate with customers on corporate phones, rather than by personal ones. All they need is a telephone connection, the Viber and corporate mail. As a system administrator, I want to configure the devices for these sevices only. If I make a rooting of the smartphones, can I make some changes that disable ability to install and uninstall apps from files and Google Play? And will I be able to easily turn this ability back on in the future to install some application for user?
Smartphone's model Lenovo A Plus, Android version 5.1.

One way would be to remove package installer app from system partition. I am not sure though, just give it a try

naagdevta said:
One way would be to remove package installer app from system partition. I am not sure though, just give it a try
Click to expand...
Click to collapse
Thank you for answer! I must say, I'm new to android, although I have experience in administering FreeBSD (both systems are unix-like). Can you give me a resource from which I could learn about administering and tweaking android?

yurybx said:
Thank you for answer! I must say, I'm new to android, although I have experience in administering FreeBSD (both systems are unix-like). Can you give me a resource from which I could learn about administering and tweaking android?
Click to expand...
Click to collapse
https://forum.xda-developers.com/go...urce-guides-info-threads-linked-read-t2784527
These guides are mostly for nexus 5 but once you go through them you will get a fair idea about everything. Then you can search things for your specific device model.

naagdevta said:
https://forum.xda-developers.com/go...urce-guides-info-threads-linked-read-t2784527
These guides are mostly for nexus 5 but once you go through them you will get a fair idea about everything. Then you can search things for your specific device model.
Click to expand...
Click to collapse
Thank you very much!

I began to get acquainted with the process of obtaining root-access, and was surprised when I found out that there are no standard unix files "passwd" and "master.passwd" in the android. This means that I can not set a password for root-access, and the user will be free to use root-access. How to solve this problem? Maybe I need a custom firmware or a special app? But which one exactly?

yurybx said:
I began to get acquainted with the process of obtaining root-access, and was surprised when I found out that there are no standard unix files "passwd" and "master.passwd" in the android. This means that I can not set a password for root-access, and the user will be free to use root-access. How to solve this problem? Maybe I need a custom firmware or a special app? But which one exactly?
Click to expand...
Click to collapse
Supersu or magisk, they get automatically installed when you flash their zip file from custom recovery to root the phone. But not all phones have custom recovery or firmware. Mostly it depends on popularity of device, if your phone is popular many developers would be working on it.

naagdevta said:
Supersu or magisk, they get automatically installed when you flash their zip file from custom recovery to root the phone. But not all phones have custom recovery or firmware. Mostly it depends on popularity of device, if your phone is popular many developers would be working on it.
Click to expand...
Click to collapse
I managed to block the ability to install and uninstall programs by disabling the packageinstaller and daemon installd. Thank you for suggestion!

Options other than Titanium Backup for backing up/restoring all Android apps?

Currently running a OnePlus 8T + 5G with unlocked/TWRP bootloader which is not rooted, since neither of the two methods want to work on my specific version (KB2007; unlocked former T-Mobile).
Anyway, I'm trying to switch to another ROM but I'm wondering how best to backup/restore all of my apps. Loved using Titanium Backup way back in the day, but am I still correct in assuming that it doesn't work correctly without root access? If so, are there any non-root methods of backing up all or most of my apps along with their current configurations/etc to restore into the new ROM once it's installed? Obviously, most ROMs will support doing it through Google Play, but then it takes forever to log back in to each app, set it all back up, etc. If I've been missing some basic way of restoring all the apps with their configurations intact, please feel free to smack me upside the head with the answer =)
And my apologies in advance if I'm misusing any of the terminology. Before this phone, it has been at least five years since I even tried rooting/unlocking/etc, so I'm a bit rusty.

In the world of computers an app belongs to person who installed it, app's data are owned by the app itself.
Hence it should be obvious that only an user with elevated rights ( AKA Superuser or Root ) can perform a backup and/or restore.
Take note that a temporary root is enough to do the jobs.

Got it. So, in other words, figure out how to root the phone despite the troubles I've been having trying to do so. Unless there's some sort of temporary root privs available that I've never heard of?

To get a temporary root all you have to do is to add to Android OS the binary called SU
Example
Code:
adb push <LOCATION-OF-SU-BINARY-ON-COMPUTER> /data/local/tmp/
adb shell "chmod +x /data/local/tmp/su"
what then allows you to run Android shell commands when elevated rights are needed
Example
Code:
adb devices
adb shell "/data/local/tmp/su -c '<SHELL-COMMAND-HERE>'"

Am I correct in assuming that SU is the same as "switch/substitute user" in *nix? Does that mean I can run TB from the ADB shell, assuming I include the correct command line arguments? Something along the lines of doing a SUDO in *nix before running something that requires admin access or whatever.

I know this might be quite different from what you're looking for maybe?
In the future if you get a rooted rom, I use something called Migrate from the play store, it requires root and just copies all your data into a bunch of twrp flashable zip files.
Play Store

silentrawr said:
Am I correct in assuming that SU is the same as "switch/substitute user" in *nix? Does that mean I can run TB from the ADB shell, assuming I include the correct command line arguments? Something along the lines of doing a SUDO in *nix before running something that requires admin access or whatever.
Click to expand...
Click to collapse
SU in root context usually means super user, as a user with all privileges, but it's the same thing as super user, so yes.

Hello Everyone,
I too am interested in a backup solution for my Android smartphone.
I would happily root or temporarily root, but despite having a computer background that dates back to Unix, I am an Android novice and do not know how to perform these operations which to most people here seem elementary.
Could someone please point me to an easy to understand primer on either temporary root or permanent root.
I would be very appreciative and I am sure that there are other readers of this post who would benefit as well.
Thank you.

AndroidNewbie9000 said:
Could someone please point me to an easy to understand primer on either temporary root or permanent root.
I would be very appreciative and I am sure that there are other readers of this post who would benefit as well.
Thank you.
Click to expand...
Click to collapse
The thing is, that the "official" way to root a device nowadays usually includes a wipe of all user data. You basically have to decide that you want to do full backups before you use an app. This is a security measure so that an attacker cannot use the official way to e.g. access app-internal data on a stolen phone, like secret tokens of 2FA-apps. In order to backup existing app-internal data you either need to use the per-app-backup that the creators of that app did hopefully include or hope that the allowed to do adb backup. That can be used without root, but depending on your Android, apps either need to allow this explicitly or at least not explicitly disallow that in their manifest file.
In principle you can use exploits for non-official rooting to backup existing data that is blocked from adb backup - but this is only an option if you do not have the latest security updates in place and an exploit is publicly available.