Root i'll help find a root method if...

[stayboogy]

So as Bugmenot_Rules said, I did, and can, get very, very temporary root access:

As you can see, it does look like true root. However, it is not even close, even to temp root. Heres the latest why.

After accepting root access once (ex. Titanium Backup) you can use root privileges in that app. If you close and reopen it, or try to use another app, you cannot use root privileges again until you reboot, and run cmds again. The superuser app also recognizes it incorrectly after that, as shown by jjfriede (see this page). It seemes that the firmware is constantly scanning the FS for any sort of SU, as this happens without a reboot. cguru:

The other thing is that when I deleted LiveWallpapers.apk and Email.apk, I thought they hadnt returned for some reason, and thats what I told Bugmenot_Rules. However, I was wrong. I investigated it more recently and yes, they did return:

So that means that there IS something replacing the apps on reboot. Whether it is another partition or what, I dont know.

For those that would like to try the method, go here https://github.com/benjimt/RootMyValet/blob/master/Install.txt and follow method 2.

Follow the latest progress here: https://github.com/Unkn0wn0ne/RootMyValet/issues?state=open

thanks for this.

so again, simply and technically, temp root has not really been gained then, as far as system rw access is concerned--just hasn't happened.

i'd like to know what exactly is happening. it's nothing embedded in the ramdisk as far as i can tell. i've been up and down the .rc files and can't find anything of interest to help with these matters.

if we could ever figure out what verifies the boot partition's hash/size, and then modify to accept the new boot with ro.secure=0 then we'd be in business because the boot.img unpacks and packs quite easily and is easily flashed through the telnet exploit

 

[scary alien]

Hey guys, I've moved you all over to the all-things-root sub-forum for the Valet.

Seems like you've got enough traction now for this thread to be there.

Cheers and best of luck!

:thumbup:

 

[xVxMatthewxVx]

I'm not sure if anyone has posted this, but have any of you tried the Z4Root.apk?
I would try it myself, but I'm scared of bricking my phone!
Heres a link: http://forum.xda-developers.com/attachment.php?attachmentid=446145&d=1290341328
Do this a your own risk, as i don't know if this will brick the device.

 

[jjfriede]

I'm not sure if anyone has posted this, but have any of you tried the Z4Root.apk?
I would try it myself, but I'm scared of bricking my phone!
Heres a link: http://forum.xda-developers.com/attachment.php?attachmentid=446145&d=1290341328
Do this a your own risk, as i don't know if this will brick the device.

I gave it a try and the app crashed when it was reporting that it was acquiring root shell. Also, I tried restarting the app but nothing happened when i tapped its icon, which is strange. I even tried reinstalling it but when i tried to install it again, It said 'app not installed'. After a reboot, everything worked normally so I installed it and ran it a second time and got the same result for both the temporary and permanent root options.

So looks to me like it's a no go. I wonder what exploit it uses though, the thread gives no information on that.

 

[werewolfboy]

I have tried the instructions plus the app and both failed to work.

 

[xVxMatthewxVx]

Here, Give this one a try: http://forum.xda-developers.com/attachment.php?attachmentid=2784451&d=1402084843

And has anyone tried SuperOneClick?
@jjfriede, I'm no expert, but couldn't you just extract the .apk, and grap the exploit from there?

 

[jjfriede]

Here, Give this one a try: http://forum.xda-developers.com/attachment.php?attachmentid=2784451&d=1402084843

And has anyone tried SuperOneClick?
@jjfriede, I'm no expert, but couldn't you just extract the .apk, and grap the exploit from there?

Framaroot and SuperOneClick don't work either. We've tried just about everything out there and have had no luck due to the anti-root mechanism built into the valet along with some sort of backup partition that everything is checked against and restored from upon reboot.

Also I read somewhere that the exploit used by zroot has been patched since 2012 so it wouldn't be any use. We're better off waiting for the RootMyValet to be completed or see if we can disable the system partition restoring mechanism.

 

[xVxMatthewxVx]

Framaroot and SuperOneClick don't work either. We've tried just about everything out there and have had no luck due to the anti-root mechanism built into the valet along with some sort of backup partition that everything is checked against and restored from upon reboot.



Also I read somewhere that the exploit used by zroot has been patched since 2012 so it wouldn't be any use. We're better off waiting for the RootMyValet to be completed or see if we can disable the system partition restoring mechanism.

Will RootMyValet require any additional steps, or will it be as simple as Z4Root, and just require one click?

 

[jjfriede]

Will RootMyValet require any additional steps, or will it be as simple as Z4Root, and just require one click?

According to the instructions on github, You are either going to have to copy some files to your device first or run a script from your computer that will do that for you before the app will work.

 

[xVxMatthewxVx]

According to the instructions on github, You are either going to have to copy some files to your device first or run a script from your computer that will do that for you before the app will work.

Ahh, I see. That doesn't sound to hard!

 

[benjimt]

thanks for this.

so again, simply and technically, temp root has not really been gained then, as far as system rw access is concerned--just hasn't happened.

i'd like to know what exactly is happening. it's nothing embedded in the ramdisk as far as i can tell. i've been up and down the .rc files and can't find anything of interest to help with these matters.

if we could ever figure out what verifies the boot partition's hash/size, and then modify to accept the new boot with ro.secure=0 then we'd be in business because the boot.img unpacks and packs quite easily and is easily flashed through the telnet exploit

Yes true, although system rw IS possible, its just nothing persists reboots.

What happens is this. If you are able to success fully run temp root commands, you have the su binary in the xbin, and symlinked in the bin. You can open up, for example, es file manager and get root privileges, and mount any partition as rw. You can do as many changes as you'd like, delete bloat ware etc. If you were then to go to Titainium backup for example, root privileges would not work. If you were to then go into the superuser app to see whats going on, you would see what jjfriede posted awhile back. You then have to reboot and rerun commands to get root privileges in any other app again.

I agree, I think it is our next option if we cant get the RootMyValet system to work soon.

 

[benjimt]

Ahh, I see. That doesn't sound to hard!

Unfortunately, it is a bit harder, as the app or the script is currently not working. I've updated the wiki to include the latest method for temp rooting, that partially, and only sometimes works.

 

[werewolfboy]

Yes true, although system rw IS possible, its just nothing persists reboots.

What happens is this. If you are able to success fully run temp root commands, you have the su binary in the xbin, and symlinked in the bin. You can open up, for example, es file manager and get root privileges, and mount any partition as rw. You can do as many changes as you'd like, delete bloat ware etc. If you were then to go to Titainium backup for example, root privileges would not work. If you were to then go into the superuser app to see whats going on, you would see what jjfriede posted awhile back. You then have to reboot and rerun commands to get root privileges in any other app again.

I agree, I think it is our next option if we cant get the RootMyValet system to work soon.

I saw another post that someone tried to remove them and the bloatware was readded back upon reboot. So it looks like it is not possible for apps to be removed. Or am I wrong?

 

[benjimt]

I saw another post that someone tried to remove them and the bloatware was readded back upon reboot. So it looks like it is not possible for apps to be removed. Or am I wrong?

That someone was me. No, that is not currently possible. I am trying modding the verify.zip to allow certain file changes, but I dont know if that will work yet because I currently cant get temp root to re-mount the / partition. Ill keep trying!

 

[jjfriede]

That someone was me. No, that is not currently possible. I am trying modding the verify.zip to allow certain file changes, but I dont know if that will work yet because I currently cant get temp root to re-mount the / partition. Ill keep trying!

I gained temp root and got rid of the stock browser system app and removed its md5 values in verify.zip but after a reboot, both the stock browser apk and the verify.zip files were back to normal.

If not even the verify.zip file will remain intact after changing, /system must just be a temporary copy of the real filesystem created everytime the device boots? If I'm right, how would we find the "real" /system on the hard drive?

Also, I've been poking around the filesystem and I found something interesting that might help. Look at the fstab file in the root directory:

[shell@android:/ # cat fstab.msm7627a
# Android fstab file.
# The filesystem that contains the filesystem checker binary (typically /system) cannot
# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK

#TODO: Add 'check' as fs_mgr_flags with data partition.
# Currently we dont have e2fsck compiled. So fs check would failed.

#<src>                                          <mnt_point>  <type>  <mnt_flags and options>                     <fs_mgr_flags>
#ZTE_MODIFY change for crypt function
#/dev/block/platform/msm_sdcc.3/by-num/p19         /system      ext4    ro,barrier=1                                wait
/dev/block/platform/msm_sdcc.3/by-num/p22         /data        ext4    nosuid,nodev,barrier=1,noauto_da_alloc      wait,encryptable=footer
shell@android:/ #

I wouldn't consider myself proficient in interpreting Linux system files or the filesystem structure, but it looks the the /system is somehow related to /dev/block/platform/msm_sdcc.3/by-num/p19. I have no idea what is is and it might not be helpful at all, but It kind of looks like it might have something to do with the strangely behaving system partition.

 

[werewolfboy]

That someone was me. No, that is not currently possible. I am trying modding the verify.zip to allow certain file changes, but I dont know if that will work yet because I currently cant get temp root to re-mount the / partition. Ill keep trying!

Oh It was? I was to lazy to look. I tried some other root all methods and it got the su file in the correct area (I could tell because I got all "success!" messages) but after reboot it disappers. Only problem is that the program auto reboots the phone. Also I was able to see some protected folders before the forced reboot.

I gained temp root and got rid of the stock browser system app and removed its md5 values in verify.zip but after a reboot, both the stock browser apk and the verify.zip files were back to normal.

If not even the verify.zip file will remain intact after changing, /system must just be a temporary copy of the real filesystem created everytime the device boots? If I'm right, how would we find the "real" /system on the hard drive?

Also, I've been poking around the filesystem and I found something interesting that might help. Look at the fstab file in the root directory:

[shell@android:/ # cat fstab.msm7627a
# Android fstab file.
# The filesystem that contains the filesystem checker binary (typically /system) cannot
# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK

#TODO: Add 'check' as fs_mgr_flags with data partition.
# Currently we dont have e2fsck compiled. So fs check would failed.

#                                                                   
#ZTE_MODIFY change for crypt function
#/dev/block/platform/msm_sdcc.3/by-num/p19         /system      ext4    ro,barrier=1                                wait
/dev/block/platform/msm_sdcc.3/by-num/p22         /data        ext4    nosuid,nodev,barrier=1,noauto_da_alloc      wait,encryptable=footer
shell@android:/ #

I wouldn't consider myself proficient in interpreting Linux system files or the filesystem structure, but it looks the the /system is somehow related to /dev/block/platform/msm_sdcc.3/by-num/p19. I have no idea what is is and it might not be helpful at all, but It kind of looks like it might have something to do with the strangely behaving system partition.

That does look intresting. Where did you get it from? (where in the phone?)

 

[jjfriede]

Oh It was? I was to lazy to look. I tried some other root all methods and it got the su file in the correct area (I could tell because I got all "success!" messages) but after reboot it disappers. Only problem is that the program auto reboots the phone. Also I was able to see some protected folders before the forced reboot.



That does look intresting. Where did you get it from?

There's just a file called fstab.msm7627a sitting in the root directory of my phone. I know fstab has something to do with mounting things on boot so I used the 'cat' command to print the contents of it into my terminal window and that's what i saw. I was actually able to copy that 'p19' file onto my desktop computer and it is about half a gigabyte! It could definitely contain a copy /system

 

[benjimt]

Oh It was? I was to lazy to look. I tried some other root all methods and it got the su file in the correct area (I could tell because I got all "success!" messages) but after reboot it disappers. Only problem is that the program auto reboots the phone. Also I was able to see some protected folders before the forced reboot.



That does look intresting. Where did you get it from? (where in the phone?)

What program(s) did you use?

There's just a file called fstab.msm7627a sitting in the root directory of my phone. I know fstab has something to do with mounting things on boot so I used the 'cat' command to print the contents of it into my terminal window and that's what i saw. I was actually able to copy that 'p19' file onto my desktop computer and it is about half a gigabyte! It could definitely contain a copy /system

Interesting......notice the "ro,barrier=1" on /system....ill have to take a closer look at this tomorrow.

 

[werewolfboy]

There's just a file called fstab.msm7627a sitting in the root directory of my phone. I know fstab has something to do with mounting things on boot so I used the 'cat' command to print the contents of it into my terminal window and that's what i saw. I was actually able to copy that 'p19' file onto my desktop computer and it is about half a gigabyte! It could definitely contain a copy /system

Did you try to see the contents of it at all using 7-Zip? You can see sometimes the inside of a file using "Open Inside"

 

[werewolfboy]

What program(s) did you use?



Interesting......notice the "ro,barrier=1" on /system....ill have to take a closer look at this tomorrow.

I can get them for you in a couple of days when I am back home and give you the links for them. Is that OK?

 

[jjfriede]

Did you try to see the contents of it at all using 7-Zip? You can see sometimes the inside of a file using "Open Inside"

I'm using ubuntu and I have just about every kind of archiving program installed, including 7zip, but my archive manager says that the archive type is not supported, which either means It must be some really obscure archive type or it isn't an archive at all.

 

[jjfriede]

What program(s) did you use?



Interesting......notice the "ro,barrier=1" on /system....ill have to take a closer look at this tomorrow.

ro is read only and the barrier=1 option means that the write caches will be constantly flushed

 

[werewolfboy]

I'm using ubuntu and I have just about every kind of archiving program installed, including 7zip, but my archive manager says that the archive type is not supported, which either means It must be some really obscure archive type or it isn't an archive at all.

It could have a weird encryption to it as well.

 

[jjfriede]

It could have a weird encryption to it as well.

That's true. I just realized that that line in the fstab is commented out anyways, so it might not be the file we're looking for.

It's getting pretty late I'll have to check it out more tomorrow

 

[benjimt]

I can get them for you in a couple of days when I am back home and give you the links for them. Is that OK?

Yes no problem when ever you can! Thanks!