I have completed my Tattoo M7 root however applications say it is not rooted.
basically if i do ADB SHELL and then SU i get the root console but can not write to /system folder via adb push since i get permisison denied which means i always have to adb shell and su.
I believe this is somehow creating problems also to applications (i am testing Titanium Backup) which require root permissions and say i am not.
Anyone can help understanding why i can su only in console or terminal emultor but cannot use apps requiring root permissions.
Dude, you have to remount EVERY TIME /system and /data if you reboot, otherwise it says permission denied because system is read only...
Get RootExplorer, there is a little button which lets you remount partitions with one tap...
pardol said:
I have completed my Tattoo M7 root however applications say it is not rooted.
basically if i do ADB SHELL and then SU i get the root console but can not write to /system folder via adb push since i get permisison denied which means i always have to adb shell and su.
I believe this is somehow creating problems also to applications (i am testing Titanium Backup) which require root permissions and say i am not.
Anyone can help understanding why i can su only in console or terminal emultor but cannot use apps requiring root permissions.
Click to expand...
Click to collapse
hi
as ur question in the related thread
see link : http://forum.xda-developers.com/showthread.php?t=637927
CLOSED
Another S-Off script that was sent to me by coremark. Successfully s-off my device and supercid.
http://firewater-soff.com/
Thanks to @coremark.
After gaining S-off on a fully stock device using Firewater + temproot, what is the easiest method for permanent rooting?
Since due to S-off full access is granted to all partitions, is it possible to install the su binary and superuser / superSu apk to the /system partition without flashing a custom recovery? For example by using "adb push" or a root file manager?
Where can I get a su binary? Should I extract it from superSu / superuser recovery ZIP package?
Could anyone walk me through the steps?
edorner said:
After gaining S-off on a fully stock device using Firewater + temproot, what is the easiest method for permanent rooting?
Since due to S-off full access is granted to all partitions, is it possible to install the su binary and superuser / superSu apk to the /system partition without flashing a custom recovery? For example by using "adb push" or a root file manager?
Where can I get a su binary? Should I extract it from superSu / superuser recovery ZIP package?
Could anyone walk me through the steps?
Click to expand...
Click to collapse
I'm afraid you'll need a custom recovery for this. The /system write protection is implemented in kernel (the kernel doesn't sync changes to the actual block device and keeps them in RAM) and S-OFF is completely orthogonal to this. To work around it, you'd need a custom kernel (which is not feasible at the moment since HTC haven't released the full source tree yet, unfortunately) or the wp-mod hack (which I would be afraid of using, to be honest).
Also, why avoid custom recovery when you're already S-OFF and you can flash the stock recovey anytime?
koniiiik said:
The /system write protection is implemented in kernel (the kernel doesn't sync changes to the actual block device and keeps them in RAM) and S-OFF is completely orthogonal to this.
Click to expand...
Click to collapse
You are right, that makes sense.
But then how is this possible (if it is at all)? -> http://forum.xda-developers.com/showthread.php?t=2339056
(Pls check out the 2nd post from member "Indirect".)
AFAIK the One has the exact same kind of /system write protection as the 901s. Doesn't it?
Just out of curiosity, why would you be afraid to use wp-mod? Unknown / unpublished source? Bad feedback from users?
edorner said:
You are right, that makes sense.
But then how is this possible (if it is at all)? -> http://forum.xda-developers.com/showthread.php?t=2339056
(Pls check out the 2nd post from member "Indirect".)
AFAIK the One has the exact same kind of /system write protection as the 901s. Doesn't it?
Click to expand...
Click to collapse
To be honest, no idea. All I do know is that on my phone the write protection works the way it does and I don't really see a feasible way around it. Also, I haven't tried these exact steps. It's possible that adb remount does some extra work or something. Moreover, I'm not sure about the adb shell chmod ... command – that would require root, wouldn't it? But since I haven't tried it, I can only guess.
If you don't mind trying it, I'd be interested in the results.
edorner said:
Just out of curiosity, why would you be afraid to use wp-mod? Unknown / unpublished source? Bad feedback from users?
Click to expand...
Click to collapse
The way I understand wp_mod works is that it monkey-patches the running kernel's filesystem driver to skip the check for the /system partition. In other words, it rewrites the code of the running kernel in-memory. This by itself is reason enough to be extremely careful around such code as it has potential for a major disaster. Missing the right memory location by any nonzero number of bytes can result in the kernel doing practically anything (most likely a crash).
Now, to make matters worse, these seem to be only a few binary versions of the kernel module and people seem to just take a binary compiled for one kernel, modify the version information within the file to make it match other kernels and load it on a completely different kernel. This, to me, is borderline insane, considering that the kernel binaries depend on the version of the kernel, used compiler and even compiler flags used when building.
Again, though, I haven't actually looked at the module's source code; can't say I'm suffering from a surplus of free time and I'm also not *that* interested in it. Most likely it's written in a robust enough way to have a high chance of success. (This seems to be backed up by anecdotal evidence – the thing appears to work for people, which is a small wonder for me.) All of the above is actually just my interpretation of stuff I read in some threads here on XDA-developers and I haven't even tried to confirm it myself.
Still, for me, using the recovery for any such changes is a sufficient and acceptable workaround, since I don't need to modify /system that often.
Wow! Thanks for the exhaustive expanation about WP-mod!
If you don't mind trying it, I'd be interested in the results.
Click to expand...
Click to collapse
Well I am also a bit skeptical about this solution. So I am not sure I will be brave enough to try it
But if I do decide to give it a try, I will post the results here, I promise.
edorner said:
Well I am also a bit skeptical about this solution. So I am not sure I will be brave enough to try it
But if I do decide to give it a try, I will post the results here, I promise.
Click to expand...
Click to collapse
As far as @Indirect's post goes, that should be risk-free – either it does work, or it doesn't do anything. I don't see how it could harm your phone. Worst case, you end up with a /system/xbin/su binary that doesn't work due to wrong privileges (or owner information), in which case you should be able to just remove it and start over.
koniiiik said:
As far as @Indirect's post goes, that should be risk-free – either it does work, or it doesn't do anything. I don't see how it could harm your phone. Worst case, you end up with a /system/xbin/su binary that doesn't work due to wrong privileges (or owner information), in which case you should be able to just remove it and start over.
Click to expand...
Click to collapse
Ah, I see. In that case I will definitely try it!
Truth is I am still an Android noob, I used ADB maybe on two occasions so far, and did not have the time yet to properly check out the documentation for these particular commands.
One more question:
If I understand correctly, Firewater (when used together with the temproot) will also unlock your bootloader. Do you think the apps in /data/preloadwill be deleted in this case too? (I.e. does it do a factory wipe like the unlock process via HTCDev?)
If so, how do I restore the apps? Do I simply copy the APK's back to /data/preload with a root file manager, and that's it?
IIRC Helium backup is not really perfect for the purpose, because it is unable to restore those apps to /data/preload, and puts them to the standard app path. Is this what you remember, too?
edorner said:
One more question:
If I understand correctly, Firewater (when used together with the temproot) will also unlock your bootloader. Do you think the apps in /data/preloadwill be deleted in this case too? (I.e. does it do a factory wipe like the unlock process via HTCDev?)
If so, how do I restore the apps? Do I simply copy the APK's back to /data/preload with a root file manager, and that's it?
IIRC Helium backup is not really perfect for the purpose, because it is unable to restore those apps to /data/preload, and puts them to the standard app path. Is this what you remember, too?
Click to expand...
Click to collapse
No idea, I haven't used firewater, but my guess would be that it won't wipe anything…
As for backing up /data/preload, you can for example use temproot to get access to the directory, copy it somewhere on your sdcard and adb pull it. In case it gets wiped, you can just push it back again and voilà. It's going to require some shell-fu, however.
Alternately, you can just download my ZIP of the latest stock ROM and extract it, it contains the latest /data/preload.
And yes, just copying the APK files into /data/preload should suffice *– Dalvik and its package manager is intelligent enough to detect something has changed in there and perform any installation steps necessary. If it doesn't work right away, a reboot should fix things.
Edorner. It won't wipe. I tried it already.
Sent from my GT-I9305 using XDA Premium 4 mobile app
koniiiik said:
As far as @Indirect's post goes, that should be risk-free – either it does work, or it doesn't do anything. I don't see how it could harm your phone. Worst case, you end up with a /system/xbin/su binary that doesn't work due to wrong privileges (or owner information), in which case you should be able to just remove it and start over.
Click to expand...
Click to collapse
So, as promised, I tried the "adb remount" command on my device and it did not work.
Code:
adb remount
remount failed: Operation not permitted
However "mount -o remount,rw -t ext4 /dev/block/mmcblk0p38 /system" in root shell (acquired by temproot) worked like a charm And the modifications to /system performed afterwards turned out to be permanent. So in the end I was able to gain root without using a custom recovery.
Based on my experiences, I created a guide which summarizes all the steps necessary to S-OFF and root a completely stock device without using HTCDev unlock and custom recoveries.
I investigated a bit as to why "adb remount" would not work, and found two interesting topics on XDA about the issue:
[2013.05.24][ROOT] adbd Insecure v1.30
Can't get ADB Root Access in certain ROMs?
In short, "adb remount" is only available if the ADB daemon is run in "insecure" mode in a particular ROM. And unfortunately our stock ROMs seem to use secure ADB.
edorner said:
So, as promised, I tried the "adb remount" command on my device and it did not work.
Code:
adb remount
remount failed: Operation not permitted
However "mount -o remount,rw -t ext4 /dev/block/mmcblk0p38 /system" in root shell (acquired by temproot) worked like a charm And the modifications to /system performed afterwards turned out to be permanent. So in the end I was able to gain root without using a custom recovery.
Based on my experiences, I created a guide which summarizes all the steps necessary to S-OFF and root a completely stock device without using HTCDev unlock and custom recoveries.
I investigated a bit as to why "adb remount" would not work, and found two interesting topics on XDA about the issue:
[2013.05.24][ROOT] adbd Insecure v1.30
Can't get ADB Root Access in certain ROMs?
In short, "adb remount" is only available if the ADB daemon is run in "insecure" mode in a particular ROM. And unfortunately our stock ROMs seem to use secure ADB.
Click to expand...
Click to collapse
Fantastic guide, I just read it and wow.
Also, good to know that particular procedure disables the write protection. I'll have to investigate this sometime, because just now I tried and found out that on my device, the changes to /system are rolled back as soon as I remount /system read-only again. Maybe if I left it read-write all the time, they would persist as well...? I'll have a closer look at this later.
koniiiik said:
Fantastic guide, I just read it and wow.
Also, good to know that particular procedure disables the write protection. I'll have to investigate this sometime, because just now I tried and found out that on my device, the changes to /system are rolled back as soon as I remount /system read-only again. Maybe if I left it read-write all the time, they would persist as well...? I'll have a closer look at this later.
Click to expand...
Click to collapse
Thanks
Hm... Strange...
Instead of manually remounting /system as "ro", I simply rebooted the device. (What can I say, I am hopelessly lazy ) After the reboot I checked the permissions of /system by issuing the "mount" command without any parameters. It showed that it was remounted using the original settings:
Code:
/dev/block/mmcblk0p38 /system ext4 ro,noatime,data=ordered 0 0
So in theory, rebooting instead of manually remounting as "ro" should not make any difference. But who knows
After the reboot, I checked the changes I made to /system previously, and fortunately they did not disappear. (su was still there, I could successfully copy it, and execute it.)
Since then, I've performed a couple more reboots and at least one full shutdown-startup cycle as well. And I still have not lost any changes.
Please let me know if you find something out! I am very interested.
AT&T XT1097 Absolutely Refuses To Mount /system Read-Write Under Any Circumstances
Yes, I'm rooted (specifically using KingRoot - it's not a permanent root, but at the moment it works)
Yes, I double checked, su works.
No, SELinux was not in Enforcing mode. (getenforce returned "Permissive")
No, I can't just flash a custom recovery, my bootloader's locked.
The problem is every time I try to run a mount command - any mount command - to mount /system read-write, I get the error "Read Only File System". This is reproducible in both adb shell and the terminal emulator on the Play Store. The main reason I want to root is to get rid of all of the reinventions of the wheel AT&T put in my system partition (for instance, I have the standard Contacts app and an "AT&T Address Book"), and install busybox. I want a solution to remount /system read-write, I don't give a damn about potential consequences at the moment.
I consider myself a relatively advanced user in theory, so you probably don't need to dumb down your answer. If I don't know something, I'll ask.
What is the exact syntax of the mount command you're running to attempt to remount /system in read/write mode?
Problem: I have an Aishon A19 tablet, which it is very hard to find information about. It is an RK3288 tablet running Android 5.1.1.
It is not really rooted in the normal sense. However, "adb root" works; I can get a root shell and mount /system as writeable, I can push any app I want to the device, etc.
Things that will not work:
-- I tried to put on a /system/xbin/su (from SuperSU 2.76), with mode 6755 (rwsr-sr-x) and it didn't work. I also made symbolic links to /system/bin/su and /system/xbin/daemonsu. Running it from a non-root shell in adb prints a 1 and doesn't give me root. Running it from a non-root shell on the tablet does the same thing. Running it from a root shell gives me no error, but that obviously isn't much use.
-- Running SuperSU as an app gives me the error message about "There is no SU binary installed, and SuperSU cannot install it. This is a problem! If you just upgraded to Android 5....." I have no idea if it actually can't see the ./system/xbin/su or if the error message just isn't that good.
-- Trying to use "adb reboot bootloader" or getting into the bootloader using buttons doesn't work. It reboots the tablet into a blank screen, with the same vendor ID and a new product ID; however, "fastboot devices" shows nothing. This happens both under Windows and Linux, and even when run as root under Linux (thus not having to worry about udev rules). This means that I cannot install TWRP unless someone can explain to me how to install TWRP without using the bootloader.
I *can* use "adb reboot recovery" and get into the recovery menu. And as I mentioned, I can get root access to the tablet and a root shell using "adb root", and push any file I want to it.
Is it possible to use this root shell and/or recovery to install SuperSU somehow, even if I have to just copy files one at a time?
Edit: Moderators., you can lock this. Someone had the same problem in http://forum.xda-developers.com/apps/supersu/how-to-manually-update-su-supersu-file-t3238991 and I was able to folloow that, manually running the commands in update-binary.
I'm hoping to pull an image of my decrypted /data partition in order to hopefully recover some deleted files via sophisticated recovery software on the PC side of things. I manage to pull an image just fine, but it ends up being encrypted when adb is done pulling it.
From what I can gather doing a lot of google searches when you decrypt in TWRP you're supposed to get a new apparent mount/partition visible under /dev/block or thereabouts. Called "dm-0" on a lot of other phones it seems, but I don't get one of those. Decrypting directly on the phone or via adb works just fine and I can access my /data partition via the shell w/o issues.
However this still ends up being encrypted after pulling it. Is there a way to actually create and pull a decrypted image of said partition this way or am I way off? I need help finding said decrypted and supposed mount point/partition. Can't see anything new under /dev/block or as far as those directories goes so I'm at a loss.
Using:
XZ1 Compact
Android 9
TWRP 3.6.1_9-0
Latest adb from android sdk platform tools as of this writing.
Hmm. Have you tried pulling it while the phone is in recovery? If you are rooted, before pulling have you tried giving root to adb?
adb shell
su
Yes that's what I'm trying to do in order to get a decrypted image. Did not try pulling the image as root. You think that could make a difference?
EDIT: Hold on though. From the shell you can't send adb commands? I.E. opening the terminal with adb shell you have no access to adb?
knerlington said:
Hold on though. From the shell you can't send adb commands? I.E. opening the terminal with adb shell you have no access to adb?
Click to expand...
Click to collapse
adb root
adb remount
Now you're back to adb. Not sure if it will make a difference in this case, but worth a shot.
Also, you could try making a copy of the patrition via TWRP > Advanced > File manager and transferring it to PC regularly from explorer.
I have no problems making an image of said partition in different ways, but the problem is that everything that I need access to from the image file is encrypted despite making the image from twrp after decrypting it.
I'm trying to restore and recover deleted files from this partition, but in order to do that I need an image that I can use in more sophisticated recovery programs.
So is this possible at all or is there a way to decrypt an encrypted image somehow?