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.
Related
Hi,
I am new to the Atrix, but have a background in software development and was a sys admin on unix for a number of years.
I would like to know if, after a phone is rooted, do all apps run as root? or does routing simple install a setuid "su", and root apps call that when they need root access?
The webtop2sd post looks very complete and also something I will try soon. Do I need to unlock the bootloader to run a modified webtop from my sd card?
I would like to keep my phone as stock as possible, but enable a hacked webtop on the sd card.
Also there are 1000's of root threads, what is the safest canonical method (that can easily be undone)?
Many thanks and sorry for asking for your time. I have not found these answers around, but then again, there is a great amount of mis-information out there.
thx,
Scott.
Don't take this as "authoritative" but I don't believe they do, for 2 reasons.
1) If all the apps were running as root, we wouldn't run into permissions problems and have to run "Fix Permissions" to fix the resulting FC's. But we do.
2) If all the apps were running as root, none of them would need "su" to gain superuser permission but I still get that for certain root apps (Samba, Titanium Back, Rom Manager, etc, etc, etc).
Hello xda, I have a bit of a problem:
I have a Samsung Exhibit which I rooted using the zergRush method found here on the forums. At first everything worked fine. But recently I was trying to push a modified system app to my phone using adb and it told me the action wasn't permitted. Checking the shell, and terminal emulator on my phone to see if I had superuser permissions failed. So I went about trying to root my phone again, which according to the zergRush script said was successfull, but checking the shell once again showed that I still did not have superuser permissions. I did a factory wipe of my phone in hopes of trying to get it to root again with no success. But here's the weird part, although it doesn't appear I have root access all my apps that require root access (titanium backup, my screenshot app, and some of widgetlocker's features) still fully function.....
Does anyone have any idea what's going on here? I would love my system folder access back
Thanks in advance.
Dumb question, but your H-Boot shows S-Off? Just covering the bases... Also, do you have Super User installed and functional?
To be honest... I don't know what H-Boot or S-Off means. Pretty new to all of this. Mind giving me a walkthrough? I have superuser installed yes. It's granting programs superuser permissions. But I can't access su in terminal emulator or in the shell.
Well, I'm not the top tier technical person here, so I'm not exactly sure on how to get your problem resumed, since I've not heard of that. On the other hand, there might be a different way to accomplish what you are trying to do.
What are you trying to achieve, pushing a modified system app to do what and where? My suggestion, might be to just put it on your phone through USB to the root folder and then move it in ES File manager, or w/e you use. If all you are doing is pushing.
Obviously ADB shell detects your device, but I'm not sure why it is saying it doesn't have SU access. My other suggestion is to redo the ADB/Android SDK installs. I had a problem where I installed them wrong, by installing too much and ADB did not work properly. So, there might be a chance your phone is fine, but the ADB/SDK are not proper, somehow.
Let me know.
If that were the case, and my phone was fine, wouldn't I be able to access super user through terminal emulator on my phone? Right now when typing su in terminal emulator, the pop up to grant superuser permissions appears but when you allow it to have su permission the # doesn't turn to a $ like it should. The more I think about it the more I think it's a problem with superuser. I've seen people talking about an update to superuser that can break your root? Mehhhh.
Seems like other have had this problem too... Not sure if a nandroid recovery will fix this, otherwise you might have to try to unroot, and then reroot.
Sorry, just might have to do a little more digging than I was able to. Good luck
I know how to root devices but whenever someone ask me what is rooting i am not able to explain it :-\ anyone got idea about how to explain rooting
Sent from my GT-I9100 using xda premium
ankur.co.in said:
I know how to root devices but whenever someone ask me what is rooting i am not able to explain it :-\ anyone got idea about how to explain rooting
Sent from my GT-I9100 using xda premium
Click to expand...
Click to collapse
Rooting is opening the operating system to be alerted.
Sent from my Rooted Gameboy
Rooting allows you to run special applications like SuperUser, SetCPU. Allows you to flash custom kernels and ROMs like cyanogen mod. Also you free up memory that extra apps use.. In easy language, you get full access to everything..
Sent from my GT-I9300 using xda premium
If you want the most complete, hands-on way to control what your phone is capable of...it's best to root it. Rooting gives you access to manipulate your phone in a way that carriers try to keep you from doing.
Sent from my SGSIII running some "Goodness" 4.0 (Team Nocturnal) using xda app-developers app
Allow you to backup & access apps/info/data etc that no root phone cant.
ankur.co.in said:
I know how to root devices but whenever someone ask me what is rooting i am not able to explain it :-\ anyone got idea about how to explain rooting
Sent from my GT-I9100 using xda premium
Click to expand...
Click to collapse
Rooting is the act of gaining superuser access(root permissions) to the root(main files) of the device's operating systems, letting apps run at kernel level. Rooting allows for overclocking, however, in Jelly Bean, root is not required to overclock. Overclocking is the most frequently used root application. Root also lets you change system files.
Here is rooting for all you noobs
Basically every linux system has an administrator capable of making changes to the computer and access all the files that make the system up. On Mobile phones however, this is locked down for security/warranty reasons etc.
This is a great start, we know that the admin (root) access is there, we are just locked down from using it. So the point of rooting is not to install Super User, it is to trick the system into giving us adb shell as root and therefore allowing us to mount the /system partition as Read/Write (instead of read only).
That is what allows us to change the value of ro.secure in the kernel, which sets the flag that allows us a root shell, instead of a regular (non-privileged) shell. Then we push the SU binary and SU app to the system, which gives us choice as to what apps are allowed su rights and what is not. In other words, we don't need the SU app to obtain root access. It is just for data protection.
It sounds so simple, but it is not. Since the /system partitions cannot be mounted as read/write by default, and ro.secure=1, we cannot have a root shell and therefore not able to change ro.secure=0. Therefore, it is secure.
In order to gain the root shell we have to find an exploit that will trick the system. We use an exploit (hack, vulnerability) to trick the android OS into giving us a root shell in adb. For example on of them (in simple terms is...)
1. We kill adbd ***(this is the parent) It spawns a shell (adb) based on its rights*** keep this in mind.
2. When it adbd starts up, it must run as root. When its done, it will set its id back to a non root user
3. The program (SuperOneClick for ex) races adbd by spawning a process that tries to change its id at the same time (slightly first).
4. Since we are busy changing the id of our fake process, the kernel wont be able to change adbd since it is busy and therefore adbd continues to run as root.
5. Now we can spawn a root shell, because the root rights are passed from adbd to the shell, which is now root.
6. Sucess! Now lets set everything up!
This has been answered about as well as it can. For future reference, please try searching before posting as extremely basic questions like this do not warrant creating a thread. Closed.
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
Hello, is there a way to root the phone where everything works now (Bluetooth, Face ID, etc.)?
I would very much like to see this answered. I've seen some application-specific instructions such as this reddit thread for enabling Samsung Health, and I've read about hiding the fact that the phone is rooted from apps by using MagiskHide, but it's not clear whether this works for all apps and features or just some. There's also this recently updated guide to rooting that claims:
Magisk is a highly advanced way of rooting android systemless-ly. This means that Magisk root android without changing or modifying the system partition. Hence you can receive OTA updates, run apps that require to pass Google’s SafetyNet tests.
Click to expand...
Click to collapse
However, many hacks that sound good when you read about them in advance run into snags and gotchas once you actually get into implementing them, and I'm hesitant to just give it a try and see how it works out when tripping Knox is irreversible and if things stop working you can't get them back by flashing the stock ROM.
I'd be grateful if anyone who has actual experience on this subject could vouch for being able to re-enable all lost functionality after rooting or to not lose it in the first place, or whether even some lost functionality can be enabled (and if so, what have you been able to get working and what haven't you? I don't know about OP, but to me the most important ones are Secure Folder and Samsung Health).
Also, does anyone have experience with retaining Knox-sensitive functionality on rooted S9 Exynos with Android 11 (either rooting after upgrading to 11, or rooting first and retaining root when upgrading)?
@bis225
IMO noone needs Magisk to root a device's Android. Rooting Android means having the SU-binary present on Android - a ~100KB file - nothing else. Copying SU-binary onto Android allows you to temporariy give you root access when needed.
jwoegerbauer said:
@bis225
IMO noone needs Magisk to root a device's Android. Rooting Android means having the SU-binary present on Android - a ~100KB file - nothing else. Copying SU-binary onto Android allows you to temporariy give you root access when needed.
Click to expand...
Click to collapse
I'm not sure I understand what you're saying. Are you telling me that you can simply copy the file onto an unrooted phone, and voila, you can gain root access?? Can you point to information about what to do and how this works? It runs contrary to everything I've ever read on the subject.
To the best of my understanding, in order to install su binary unto an unrooted phone you need to install a custom recovery, and use that to flash the su binary onto the phone. I thought the idea of Magisk was to provide root access without modifying system files so that SafetyNet can't detect that the system has been modified. Unless I'm missing something there's no disadvantage to rooting with Magisk, only advantages, but regardless, I don't see how it makes a difference with respect to this topic. Installing a custom recovery is what trips Knox and prevents some features and apps from working, so it doesn't really matter what root method you use if you have to use a custom recovery to install it.
If you know of a way to root a Galaxy S9 without using a custom recovery or tripping Knox and that can't be detected by SafetyNet, please elaborate.
Rooting Android simply means to add a ( hidden ) user called root ( AKA super-user ) who has ALL rights to Android's file system.
For example from within ADB you activate this user and let run him any command what requires to have ALL rights - assumed the SU-binary is located in /sdcard
Code:
adb shell "/sdcard/su -c '<command-here>'"
AFAIK Magisk installs the SU-binary in /data/adb/magisk/busybox, but I may err.
@jwoegerbauer
But I didn't ask what rooting means. Unfortunately, this doesn't answer any of my questions.
I think I clearly expressed that neither a Custom Revovery nor Magisk itself is needed to have root, that simply copying SU-binary to Android's user-space is enough.
If you want to root via Magisk then do it.
Personally never would do it this way.
jwoegerbauer said:
I think I clearly expressed that neither a Custom Revovery nor Magisk itself is needed to have root, that simply copying SU-binary to Android's user-space is enough.
If you want to root via Magisk then do it.
Personally never would do it this way.
Click to expand...
Click to collapse
This really seems contrary to everything I've read, and this Stack Exchange thread specifically explains why that wouldn't work, but if you say you have experience with this and it works for you, I'm certainly willing to give it a try and see how far it gets me. Do you know where a copy of the su binary can be obtained? All my searches for su binary lead to the supersu APK and instructions for installing it by flashing, or something along those lines. I can't find an su executable that can just be copied to internal storage as-is anywhere.