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
Related
Hi,
I hope this isnt a stupid question. I tried searching first but can't seem to find this exact question. From my understanding, by Rooting a device, I provide myself with Root access to modify system files and scripts.
My question is, in theory, just like in any other linux, if I was to get root access (SU) and modify system files (for example the wpa_supplicant fix) and then unroot, shouldnt it keep my rooted changes when I am out of the superuser?
So, what I am asking is, "Is it possible to Root my xoom, make a few quick fixes like the WPA_supplicant and the SD card driver, and then unroot, keeping the changes persistent, but not the rooting? Or, am I misunderstanding a fundamental principal?
I'm not 100% sure why you would want to unroot. If there are other changes that need to be made in the future to the device, you would need to run root scripts again and it adds steps to the process - Adding greater complexity, greater complexity = greater risk.
In theory your changes should stay, because you only need to root permissions when actually writing to that part of the filesystem and as long as it is not something that needs to be reapplied on boot - it should be able to so what it needs to do.
the reason is because, in theory, it wouldnt look "rooted" so if I need service, it should pass the test...
also, I thought that it would allow the updates to still come in...
would these things not be affected?
ethanpil said:
the reason is because, in theory, it wouldnt look "rooted" so if I need service, it should pass the test...
also, I thought that it would allow the updates to still come in...
would these things not be affected?
Click to expand...
Click to collapse
Updates definetly won't. Happen if the file structure has bee modified. Regardless of root. Also, before you send it in for service, any tech you talk to will have you factory reset it fist. So it wouldt matter.
Sent from my SPH-D700 using XDA Premium App
Hey guys,
I couldn't find it anywhere and I don't really know if this is the right place to ask, but I'll give it a try...
I wonder how does the CF-Auto-Root for the nexus 5 works?
I can see in the windows batch file that it unlocks the bootloader (that's the easy part) and than boot with some image file.
It seems that this tool is not installing any custom recovery which I always saw is a necessary tool for rooting.
What exactly is this image file? what does it do? Where does it come from? What it contains?
Why it's device related (different image files for different nexus devices running the same stock version).
Thanks,
Casteel.
Casteel said:
Hey guys,
I couldn't find it anywhere and I don't really know if this is the right place to ask, but I'll give it a try...
I wonder how does the CF-Auto-Root for the nexus 5 works?
I can see in the windows batch file that it unlocks the bootloader (that's the easy part) and than boot with some image file.
It seems that this tool is not installing any custom recovery which I always saw is a necessary tool for rooting.
What exactly is this image file? what does it do? Where does it come from? What it contains?
Why it's device related (different image files for different nexus devices running the same stock version).
Thanks,
Casteel.
Click to expand...
Click to collapse
Unlocking and rooting is a piece of cake with CF Auto Root for the N5, i never xperienced issues with it. Download CF Root for the Nexus 5, unzip it with 7-zip. Enable usb debugging in developer options, then go into bootloader/fastboot mode, open the uznipped CF Root folder and press Root_windows.bat and follow instructions. Takes 30 seconds - 1 minute all in all.
Thanks, but...
gee2012 said:
Unlocking and rooting is a piece of cake with CF Auto Root for the N5, i never xperienced issues with it. Download CF Root for the Nexus 5, unzip it with 7-zip. Enable usb debugging in developer options, then go into bootloader/fastboot mode, open the uznipped CF Root folder and press Root_windows,bat and follow instructions. Takes 30 seconds - 1 munute all in all.
Click to expand...
Click to collapse
First, thanks for your response.
I don't have a problem with making it work.
As you said, it is super simple and no question it's a great tool.
My question is about how it works? What exactly does it do behind the scene?
Casteel said:
First, thanks for your response.
I don't have a problem with making it work.
As you said, it is super simple and no question it's a great tool.
My question is about how it works? What exactly does it do behind the scene?
Click to expand...
Click to collapse
It unlocks the BL and injects superSU in one go without having to flash a seperate superSU.zip with a custom recovery. Thats all.
gee2012 said:
It unlocks the BL and injects superSU in one go without having to flash a seperate superSU.zip with a custom recovery. Thats all.
Click to expand...
Click to collapse
What do you mean by "injects SuperSU" ?
It sounds very simple from the way you say it. Why can't I do this myself?
I believe it doesn't just mean copy it to the right place.
Does it also include putting the su binary in the right system path with the right permissions?
How does the root privilage is gained?
Does only unlocking the BL let me write to the system partition?
I would really appreciate some technical details to understand this rooting process and what this image file contains.
Thanks again!
Read this http://forum.xda-developers.com/showthread.php?t=2507211 and this http://forum.xda-developers.com/showthread.php?t=1980683. You can also do the root yourself manualy if that more comfortable for you.
gee2012 said:
Read this http://forum.xda-developers.com/showthread.php?t=2507211 and this http://forum.xda-developers.com/showthread.php?t=1980683. You can also do the root yourself manualy if that more comfortable for you.
Click to expand...
Click to collapse
gee2012, I really appreciate your help.
I've already read (most of) these two threads before posted here, and couldn't find an answer to my questions,
only general explanations about how to make it work and how to solve problems,
nothing about HOW it works and what it actually does.
I have already rooted my device with this tool, I don't have any discomfort with is,
just pure technological curiosity about how it works.
Sure, I can also root myself manually, but all the guides I read about it mentioned installing custom recovery, and that tool does it with out it.
Casteel said:
gee2012, I really appreciate your help.
I've already read (most of) these two threads before posted here, and couldn't find an answer to my questions,
only general explanations about how to make it work and how to solve problems,
nothing about HOW it works and what it actually does.
I have already rooted my device with this tool, I don't have any discomfort with is,
just pure technological curiosity about how it works.
Sure, I can also root myself manually, but all the guides I read about it mentioned installing custom recovery, and that tool does it with out it.
Click to expand...
Click to collapse
Look here https://www.google.com/search?q=how+root+works&ie=utf-8&oe=utf-8&aq=t and other sites how root works http://stackoverflow.com/questions/...hat-are-the-pre-requisites-for-it-to-work-wha.
With Google you can find anything
Actually, I read this also...
It only talks about gaining root privilage using some system exploit.
So, you're telling that CF-Auto-Root is running some script in its bootable image file that is using some kind of exploit to gain root access?
Shouldn't it be less "hacky" thing in nexus devices?
And how can it be that the image file is related to specific devices and not to specific stock versions?
What prevents from other apps to use this so called "exploit"?
This is probably what you are looking for...
Embedded in the boot image a folder cfroot with the SuperSU apk file, the su binary and the necessary init scripts and there is a binary under sbin does the remaining steps of copying the files to the respective places. It is not an exploit, it merely uses the boot image and the boot process to "install" SuperSU. You do not need a custom recovery to root your phone, merely the capability to copy the superuser files to the /system partition.
In more detail:
1. Embedded in the ramdisk is a folder "cfroot" with "99SuperSUDaemon, install-recovery.sh, su and Superuser.apk".
2. In the sbin folder in the ramdisk is a binary "cfautoroot" which does stuff like copy the above files to the correct locations and set the appropriate permissions, etc.
3. This file is called through the "recovery" script/binary in the sbin folder
4. The "recovery" script/binary is executed as a startup server via the init system in "init.rc" within the ramdisk
The result:
When you boot up, the superuser files are copied to the respective locations with the right permission, thereby rooting the system
OK! Now we're getting closer
Thank you very much.
But I still have some confusions...
You said:
craigacgomez said:
there is a binary under sbin does the remaining steps of copying the files to the respective places.
You do not need a custom recovery to root your phone, merely the capability to copy the superuser files to the /system partition.
Click to expand...
Click to collapse
How did the "cfautoroot" got to my phone sbin folder?
How do I get the capability to copy the superuser files to the system partition?
Putting things in these folders and set their appropriate permissions doesn't require root from the first place?
How is the init.rc calling the recovery script to run the cfautoroot? shouldn't I need root access to modify init.rc?
[Is the CF-Auto-Root source code available somewhere to see all these files you're talking about?]
It sounds like only unlocking the bootloader is giving me some sort of "root" capabilities to do all these stuff. is it true?
Will this method work in non Nexus devices either?
And what are all those "exploits" that so many rooting guides are talking about?
I'm guessing it desn't have anything with rooting Nexus devices since rooting them is kind of part of their existence, isn't it?
Thanks again! :good:
Casteel said:
OK! Now we're getting closer
Thank you very much.
But I still have some confusions...
You said:
How did the "cfautoroot" got to my phone sbin folder?
How do I get the capability to copy the superuser files to the system partition?
Putting things in these folders and set their appropriate permissions doesn't require root from the first place?
How is the init.rc calling the recovery script to run the cfautoroot? shouldn't I need root access to modify init.rc?
[Is the CF-Auto-Root source code available somewhere to see all these files you're talking about?]
It sounds like only unlocking the bootloader is giving me some sort of "root" capabilities to do all these stuff. is it true?
Will this method work in non Nexus devices either?
And what are all those "exploits" that so many rooting guides are talking about?
I'm guessing it desn't have anything with rooting Nexus devices since rooting them is kind of part of their existence, isn't it?
Thanks again! :good:
Click to expand...
Click to collapse
"cfautoroot" is a binary created by Chainfire which is embedded in the sbin folder in the kernel ramdisk. It's in the CF Auto Root boot image. Android kernels are essentially Linux kernels and have an init process which is basically a bootstrap/startup process. init.rc is part of this process. It is run when the kernel boots up. Anything within the init process is low-level and essentially run as "root". It kick-starts various other processes like zygote which is the Android process management system. This will help you understand the init process a bit better (http://www.mekya.com/blog/2012/03/android-initialization-from-init-rc-to-third-party-code/). In the init.rc file is a line which "executes" the file /sbin/recovery (which is embedded in the ramdisk along with cfautoroot). This in turn "executes" cfautoroot which takes care of copying the superuser files to the correct locations and setting the correct permission. All this is done within the init process and has elevated (root) permission.
Unlocking the bootloader does not root your phone. It simply allows you to flash "unsigned" (custom) boot images.
Any phone with the ability to flash a custom boot image can make use of this process.
Exploits make use of holes or workarounds to either flash a custom boot image or inject files into the system partition without unlocking the bootloader and are only needed if you cannot unlock the phone bootloader.
Hope this helps!
Casteel said:
Hey guys,
I couldn't find it anywhere and I don't really know if this is the right place to ask, but I'll give it a try...
I wonder how does the CF-Auto-Root for the nexus 5 works?
I can see in the windows batch file that it unlocks the bootloader (that's the easy part) and than boot with some image file.
It seems that this tool is not installing any custom recovery which I always saw is a necessary tool for rooting.
What exactly is this image file? what does it do? Where does it come from? What it contains?
Why it's device related (different image files for different nexus devices running the same stock version).
Thanks,
Casteel.
Click to expand...
Click to collapse
Thank you for asking the question and being polite yet persistent about getting your answer. I have been trying to get to this answer myself for some time now.
Sent from my Nexus 5 using Tapatalk
Great! now we're even closer :victory:
So in the boot process I have elevated privilages, that basically what I was missing.
But this bootable image file is not an image of the OS, isn't it?
It is an image of the kernel?
It is some sort of pre-handled file system that the device is booted into and than startup the OS?
Or something like that...?
Thanks for your patient and the very quiqc responses!
We're almost there...
Casteel said:
Great! now we're even closer :victory:
So in the boot process I have elevated privilages, that basically what I was missing.
But this bootable image file is not an image of the OS, isn't it?
It is an image of the kernel?
It is some sort of pre-handled file system that the device is booted into and than startup the OS?
Or something like that...?
Thanks for your patient and the very quiqc responses!
We're almost there...
Click to expand...
Click to collapse
The boot image is not the OS image. It contains the kernel and the ramdisk. The ramdisk is the basically the root filesystem (/) which the kernel mounts, after which the init process begins and init.rc is called. Nothing is ever persisted or modified in the root filesystem unless it is done during the init process or it is embedded in the ramdisk
craigacgomez said:
The boot image is not the OS image. It contains the kernel and the ramdisk. The ramdisk is the basically the root filesystem (/) which the kernel mounts, after which the init process begins and init.rc is called. Nothing is ever persisted or modified in the root filesystem unless it is done during the init process or it is embedded in the ramdisk
Click to expand...
Click to collapse
Nice.
I thought the root file system is part of the OS image.
So basically, I can have the same OS installed on my devices with different file systems according to what is defined in boot?
One last question and I will stop bother you
Why is the image file device related?
Meaning, why nexus 4, 5 and 7 have different CF-Auto-Root?
(Nexus 7 even got several).
Thanks again!
Casteel said:
Nice.
I thought the root file system is part of the OS image.
So basically, I can have the same OS installed on my devices with different file systems according to what is defined in boot?
One last question and I will stop bother you
Why is the image file device related?
Meaning, why nexus 4, 5 and 7 have different CF-Auto-Root?
(Nexus 7 even got several).
Thanks again!
Click to expand...
Click to collapse
Yes, you could theoretically change the way your filesystem is defined via the boot image, but Android as an OS expects some things.
And each device has different autoroot files because they have different kernels and some differences in some init scripts specific to the hardware. Some devices like the Nexus 7 have multiple version (LTE & non-LTE for example) and there are hardware differences and different kernels.
craigacgomez said:
Yes, you could theoretically change the way your filesystem is defined via the boot image, but Android as an OS expects some things.
And each device has different autoroot files because they have different kernels and some differences in some init scripts specific to the hardware. Some devices like the Nexus 7 have multiple version (LTE & non-LTE for example) and there are hardware differences and different kernels.
Click to expand...
Click to collapse
A thousand thanks, Craig Gomez!
You really helped.
I truely appreciate the patient and the kindful responses.
It was a nice first experience in this forum.
Thank you very much!
Casteel said:
A thousand thanks, Craig Gomez!
You really helped.
I truely appreciate the patient and the kindful responses.
It was a nice first experience in this forum.
Thank you very much!
Click to expand...
Click to collapse
Glad I could help you... It's what communities are all about... Sharing knowledge and experiences.
Sent from my Nexus 5
Excellent thread. Thanks to OP and members who responded.
Hello everyone,
I would really like to achieve a temporary root on my device. I am running the stock version, recently it updated to 20N for the Android 6.0 MM update.
I am very comfortable with adb and other command line interfaces (I primarily work on Linux servers remotely for my day job).
Are there any good resources for achieving a manual temporary root from adb on this device (or any Android device in general?). I find my Google-Fu searching has been lacking, I haven't found any reliable information on this in general for Android. Ideally, I would like to achieve a temporary root without having to wipe my device or install a new ROM. Am I correct in thinking that some sort of temporary root must be achieved before installing a custom ROM? I am wary of most "One Click" packages out there.... I prefer to do the grunt work and understand why/how something works.
In short, I yearn to see a '#' instead of '$' over an abd connection, specifically for an LG G4 H810 20N, but any general Android process is welcomed! Even being able to mount the filesystem as root (possibly from a bootloader or recovery mode) and access the internal filesystem as root via command line would be considered a success. I primarily want to be able to read/write files that are normally blocked from the standard user.
Thanks in advance!
MisterMagicFingers said:
Hello everyone,
I would really like to achieve a temporary root on my device. I am running the stock version, recently it updated to 20N for the Android 6.0 MM update.
I am very comfortable with adb and other command line interfaces (I primarily work on Linux servers remotely for my day job).
Are there any good resources for achieving a manual temporary root from adb on this device (or any Android device in general?). I find my Google-Fu searching has been lacking, I haven't found any reliable information on this in general for Android. Ideally, I would like to achieve a temporary root without having to wipe my device or install a new ROM. Am I correct in thinking that some sort of temporary root must be achieved before installing a custom ROM? I am wary of most "One Click" packages out there.... I prefer to do the grunt work and understand why/how something works.
In short, I yearn to see a '#' instead of '$' over an abd connection, specifically for an LG G4 H810 20N, but any general Android process is welcomed! Even being able to mount the filesystem as root (possibly from a bootloader or recovery mode) and access the internal filesystem as root via command line would be considered a success. I primarily want to be able to read/write files that are normally blocked from the standard user.
Thanks in advance!
Click to expand...
Click to collapse
Bad news: at this point it's not going to happen. With 6.x you have to have a modified kernel to get root and the locked bootloader on your phone will not allow that kernel to boot. In short: don't expect to see root on Marshmallow on this phone anytime soon and it will probably never happen.
I'm not saying that it's impossible, but it's almost certainly not going to happen.
http://www.xda-developers.com/a-look-at-marshmallow-root-verity-complications/
fatbas202 said:
http://www.xda-developers.com/a-look-at-marshmallow-root-verity-complications/
Click to expand...
Click to collapse
Thanks for the information! I have several 4.x and 5.x devices around and am still hoping to find some general information on manually achieving temp root access of the filesystems.
MisterMagicFingers said:
Thanks for the information! I have several 4.x and 5.x devices around and am still hoping to find some general information on manually achieving temp root access of the filesystems.
Click to expand...
Click to collapse
We are all hoping that you find something that someone else has overlooked! Good luck!
Hey guys... I've seen various methods to get Google Pay working and simply put, none of them worked for me. All that I could find left was advanced stuff involving SQLite editors and that's just not for everyone. So I started trying other known working methods from different devices, and this is what I did to get it going without issue.
1. Open Magisk, Magisk Hide, and tick the check box next to Google Pay. Proceed normally through the following steps after doing so.
2. Force stop Google Pay, clear app data/storage.
3. Open a root file manager
4. Using root file manager, find /data/data/com.google.android.gms/databases directory
5. Select a file called db.dg and chmod the permissions to 440, save and make sure it in fact saves
6. Reboot and set up Google Pay.
This should get you set up in no time without a need for modules or advanced user techniques. Hope it helps!
Edit: People seem to really dislike this method for some reason, so just throwing out there it seems everyone else recommends the SQL editing. This method worked for me, but YMMV and everyone else hates it
wrongway213 said:
Hey guys... I've seen various methods to get Google Pay working and simply put, none of them worked for me. All that I could find left was advanced stuff involving SQLite editors and that's just not for everyone. So I started trying other known working methods from different devices, and this is what I did to get it going without issue.
Unlocked users start at Step 1 below. Rooted users - First open Magisk, Magisk Hide, and tick the check box next to Google Pay. Proceed normally through the following steps after doing so.
1. Force stop Google Pay, clear app data/storage.
2. Open a root file manager OR reboot to TWRP if you don't have one
3. Using root file manager OR TWRP file manager, find /data/data/com.google.android.gms/databases directory
4. Select a file called db.dg and chmod the permissions to 440, confirm if in TWRP, save and make sure it in fact saves if using a file manager.
5. Whether in TWRP or using a root file manager. reboot and set up Google Pay.
This should get you set up in no time without a need for modules or advanced user techniques. Hope it helps!
Click to expand...
Click to collapse
That will only work if the attestation values in the dg.db file haven't been changed to flag root/unlocked bootloader already.
If your values have already been changed, you will need to manually edit the dg.db file or use the Magisk modules from this post: https://forum.xda-developers.com/apps/magisk/magisk-google-pay-gms-17-1-22-pie-t3929950/post79643248
ilal2ielli said:
That will only work if the attestation values in the dg.db file haven't been changed to flag root/unlocked bootloader already.
If your values have already been changed, you will need to manually edit the dg.db file or use the Magisk modules from this post: https://forum.xda-developers.com/apps/magisk/magisk-google-pay-gms-17-1-22-pie-t3929950/post79643248
Click to expand...
Click to collapse
Yeah... I'm not sold on making those kinds of edits or loading modules that do so without a working TWRP for this device anywhere in sight. That's precisely why I posted this thread - a working solution that doesn't involve editing things at that level - even if it doesn't work for everyone, I think it'll be more comfortale for those apprehensive to make certain changes without recovery :good:
wrongway213 said:
Yeah... I'm not sold on making those kinds of edits or loading modules that do so without a working TWRP for this device anywhere in sight. That's precisely why I posted this thread - a working solution that doesn't involve editing things at that level - even if it doesn't work for everyone, I think it'll be more comfortale for those apprehensive to make certain changes without recovery :good:
Click to expand...
Click to collapse
Having TWRP or not changes nothing for anyone that makes a mistake with those edits or Magisk. Editing the dg.db and messing that up doesn't require TWRP to fix it and there's already a boot image with Magisk core only mode posted by Tulsdiver that will save you in case a Magisk module screws things up (the Google Pay fix module is working perfectly, BTW).
People probably shouldn't be messing with any of this until they understand everything that entails getting Google Pay working on a modified device. I'd argue that changing permissions of the dg.db file is just as difficult for anyone who doesn't understand what they're doing as it is going all the way and modifying the actual values in the dg.db file. It's all a slippery slope for the overzealous people anyway.
wrongway213 said:
Yeah... I'm not sold on making those kinds of edits or loading modules that do so without a working TWRP for this device anywhere in sight. That's precisely why I posted this thread - a working solution that doesn't involve editing things at that level - even if it doesn't work for everyone, I think it'll be more comfortale for those apprehensive to make certain changes without recovery :good:
Click to expand...
Click to collapse
Grab the modified kernel in the themes area that forces modules to be deactivated. That way you can just temp boot it to fix your issues if it goes south on you. I've used it several times so far when needing around with different combos of mods, etc...
https://forum.xda-developers.com/pixel-4-xl/themes/magisk-modules-disabler-booting-magisk-t3990557
While I appreciate your efforts this is a halfbaked hack and like the previous poster said it's will do nothing if those values have been tripped. I have always been a believer of figuring out things and going the long route that way you know why and how it was done it's very convenient for somebody else to do it and you just flash it but if you do it yourself you'll find out the intricacies of how Android and how rooting and modding works....
CyberpodS2 said:
Grab the modified kernel in the themes area that forces modules to be deactivated. That way you can just temp boot it to fix your issues if it goes south on you. I've used it several times so far when needing around with different combos of mods, etc...
https://forum.xda-developers.com/pixel-4-xl/themes/magisk-modules-disabler-booting-magisk-t3990557
Click to expand...
Click to collapse
That's kind of my reason for not wanting to use mods on this device yet - being tied to Fastboot at any given time isn't practical for me. Being unable to buy gas because my phone isn't set up isn't practical for me. My goal is to use my device just like I did when I had working TWRP on other devices without losing functionality OR having to rush to a PC for fastboot. Neither are practical solutions for me - making simple modifications that are easily overwritten gives me much less anxiety than messing with things at a deeper level.
wrongway213 said:
Yeah... I'm not sold on making those kinds of edits or loading modules that do so without a working TWRP for this device anywhere in sight. That's precisely why I posted this thread - a working solution that doesn't involve editing things at that level - even if it doesn't work for everyone, I think it'll be more comfortale for those apprehensive to make certain changes without recovery :good:
Click to expand...
Click to collapse
No disrespect, it looks like you're active here and helpful, but I don't think editing some values some values in a SQL editor that is tested and proven in a thread that has 55+ pages is going to hurt anything.
vanydotk said:
No disrespect, it looks like you're active here and helpful, but I don't think editing some values some values in a SQL editor that is tested and proven in a thread that has 55+ pages is going to hurt anything.
Click to expand...
Click to collapse
I'm apprehensive because of what SQL changes under the hood typically mean. I know most people haven't built ROMs, built kernels, maintained for a ROM Team, done platform development, etc. etc . - I have done all those things. One thing I learned is that there are TWO scenarios that will ALWAYS necessitate a clean flash no matter what - SQL changes and Android version changes. Given we don't know as much as we typically do about the state of Coral without TWRP due to Android 10 changes makes me unwilling to assume things proven to work on other devices will work when we get an OTA on this one. Chmod perms will be overwritten but SQLite changes can cause things to go south in my experience - none of which relating to this module. It's about SQL vs chmod for me. I'm doing what I trust and understand until recovery exists to fix things without needing a PC. If no one else finds use for it, I'm OK with that. For my use case - it makes perfect sense. :good:
Fair enough, I figured you knew what you were talking about, everyone needs to make their own decisions. Nonetheless, thanks for contributing!
Here's a simple way to get gpay to work on stock with root after you hide gms and gpay with magisk.
1. Install Termux app and open the app
2. Type pkg install sqlite hit enter and let it install.
3. Type su hit enter
4. Copy and paste this then hit enter
am force-stop /data/data/com.google.android.apps.walletnfcrel && chmod 777 /data/data/com.google.android.gms/databases/dg.db && /data/data/com.termux/files/usr/bin/sqlite3 /data/data/com.google.android.gms/databases/dg.db "update main set c='0' where a like '%attest%';" && chmod 444 /data/data/com.google.android.gms/databases/dg.db
5. Reboot
The Magisk modules are honestly easier.
Busybox module, SQLite module, reboot, the fix module, and reboot once more.
LLStarks said:
The Magisk modules are honestly easier.
Busybox module, SQLite module, reboot, the fix module, and reboot once more.
Click to expand...
Click to collapse
How hard is it to enter a few lines in terminal? Lol
People should learn how to fix things without always relying on a module or a zip they can flash.
The manual fix isn't persistent.
LLStarks said:
The manual fix isn't persistent.
Click to expand...
Click to collapse
What I posted is.
It's weird that google pay to registry my credit cards is so unstable after flashing Gpay Sqlite fixer 1.7. When flashing Gpay sqlite fixer 1.7 at first time, I could registry my 1st credit card but it failed in next credit card. It showed up an error message and said that my phone has been rooted and .... ", So I returned commend mode to key-in few words to make me registry rest 3-credit-card successfully.
You could just delete the GMS folder while rooted and it also works
This is something myself and another user found on the p3 when Google started tripping the values on unlock
Rolling back to a previous version also works but we found that deleting that folder from /data/data along with gsf folder fixed it
Of course after clearing gpay cache.
This is working on my p4xl too
wrongway213 said:
I'm apprehensive because of what SQL changes under the hood typically mean. I know most people haven't built ROMs, built kernels, maintained for a ROM Team, done platform development, etc. etc . - I have done all those things. One thing I learned is that there are TWO scenarios that will ALWAYS necessitate a clean flash no matter what - SQL changes and Android version changes. Given we don't know as much as we typically do about the state of Coral without TWRP due to Android 10 changes makes me unwilling to assume things proven to work on other devices will work when we get an OTA on this one. Chmod perms will be overwritten but SQLite changes can cause things to go south in my experience - none of which relating to this module. It's about SQL vs chmod for me. I'm doing what I trust and understand until recovery exists to fix things without needing a PC. If no one else finds use for it, I'm OK with that. For my use case - it makes perfect sense. :good:
Click to expand...
Click to collapse
It might work for you but like it's been said multiple times, if the values are already tripped then your method is useless. Then it would REQUIRE SQL editing.
Posting an incomplete or half baked method can cause issues with newer people on these forums no matter how "simple" it may be.
spaceman860 said:
How hard is it to enter a few lines in terminal? Lol
People should learn how to fix things without always relying on a module or a zip they can flash.
Click to expand...
Click to collapse
This 100%
Sent from my Pixel 4 XL using Tapatalk
Hi there. Just a question. With this mod google pay works flawlessly all the time? No need to redo the procedure all few days when there are updates to play service? Because i need a real stable google pay when i am out only with my mobile to pay.
Just delete the folder...GMS will recreate the folder withthe right values because magisk is already setup to hide GMS
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.