• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

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

Once I get settled in for the evening I may try to replicate Unkn0wn0ne's method.

I also want to see if I can get QPST to backup the phone, as it has a potential to be able recover from brick.
 
For what it is worth, I was able to replicate Unkn0wn0ne's method... And I was able to use root explorer no problem.

/system is mounted r/w

345ndl5.png


/root explorer says it has r/w access to /system... gives an option to mount it r/o...

2lncytv.png


I also found something else interesting... My /stystem/etc folder has a lot more files and folders in it when "rooted" this way, then the one posted before... Here is a copy of that... In order to get them all to zip once I dumped them to the SDCARD, I had to use my chmod to change their permissions. Otherwise zipping gave me an error and skipped several of the files...

Here is my FULL /system/etc dump.. Have at it to see what else we can learn...
 
mainefungi said:
For what it is worth, I was able to replicate Unkn0wn0ne's method... And I was able to use root explorer no problem.

/system is mounted r/w

345ndl5.png


/root explorer says it has r/w access to /system... gives an option to mount it r/o...

2lncytv.png


I also found something else interesting... My /stystem/etc folder has a lot more files and folders in it when "rooted" this way, then the one posted before... Here is a copy of that... In order to get them all to zip once I dumped them to the SDCARD, I had to use my chmod to change their permissions. Otherwise zipping gave me an error and skipped several of the files...

Here is my FULL /system/etc dump.. Have at it to see what else we can learn...
Click to expand...


have you tried pushing an su file to the /system/xbin folder??? then remounting /system and checking if it's still there?
 
stayboogy said:
have you tried pushing an su file to the /system/xbin folder??? then remounting /system and checking if it's still there?
Click to expand...

Yes, I just did that and it does show there... but does still does not survive reboot.

Either something is removing it during the reboot process, or it is only in the ramdisk which would need to have been somehow mapped to look like it is linked to /system/xbin.

I wonder if I should try copying some other file to that location and seeing if is survives. If it does, then some process is specifically looking for 'su' and removing it. If it does not, then there are only 2 possibilities left... Something is looking for ANY change to /system, or the file was never really there to begin with...

Thoughts?
 
i guess the real test would be to push su,

then, without rebooting the phone, exit the telnet session and try to gain root by adb,

adb shell
su

and see if the su gets activated
 
improper su binary being used as well, me thinks.

that's the tegra cpu binary i think. you're going to need one for some sort of msm device. the 22kb is prob the most reliable.

when i used the wrong one on my xoom jb tablet, i would get weird root and no-root type of access to files and the system. but, i highly doubt that is responsible for what's going on here.

i didn't find anything of interest in those folders.

i'm stumped for now.
 
stayboogy said:
improper su binary being used as well, me thinks.

that's the tegra cpu binary i think. you're going to need one for some sort of msm device. the 22kb is prob the most reliable.

when i used the wrong one on my xoom jb tablet, i would get weird root and no-root type of access to files and the system. but, i highly doubt that is responsible for what's going on here.

i didn't find anything of interest in those folders.

i'm stumped for now.
Click to expand...

That su was pulled directly from Superuser-3.1.3-arm-signed.zip, found at Superuser
 
lightmaster said:
Anything new on this in the last few days? Wife just got a Valet from a friend and I'm very interested in rooting it.
Click to expand...

Nothing permanent at this time. We have been able to gain temporary root, which is lost when the phone is rebooted...

Have made a couple of observations over the past couple of days though...

Android wifi tether not only does not start correctly (gives errors), it also causes the su binary to be deleted from /system/xbin

And, when following Unkn0wn0ne's directions in post #163, if I press any buttons on the phone while running through the process, it will fail to mount /system as r/w...

I also cannot get this phone into Field Test Mode, or into the bootloader. I am able to enter revovery, of course... Using power + volume up... I can get into Safe Mode, using power + volume down. But no FTM, and no bootloader/fastboot access.

Last but not least, if I plug the phone into usb while powered off nothing happens... but if I press the power button just long enough to show the battery charge progress it does show up in Device Manager as a ADB device. However, ADB is not able to talk to it.

Will update if I learn anything more.
 
mainefungi said:
Last but not least, if I plug the phone into usb while powered off nothing happens... but if I press the power button just long enough to show the battery charge progress it does show up in Device Manager as a ADB device. However, ADB is not able to talk to it.

Will update if I learn anything more.
Click to expand...

What's the significance of being able to use adb while the device is powered off?
 
echristopherson said:
What's the significance of being able to use adb while the device is powered off?
Click to expand...

Nothing really... Just that it is showing up as a ADB device, and not a Fastboot device. Fastboot would be more helpful, because it would give is a chance to unlock the bootloader and begin to make more progress.

I do think that the locked bootloader may what caused it to brick when we tried to DD a modified boot image back to the phone. In another thread the same thing happened to the ZTE Whirl when they tried to DD a modified recovery image... The bootloader may also be what is deleting the su binay on reboot...

Another possibility is that the kernel is responsible for both deleting the su binary on reboot, and the recovery and boot image verification failures that resulted in bricked devices. I am not yet skilled enough to pull the kernel and decompile it to study it.

Any takers on that?
 
mainefungi said:
Nothing really... Just that it is showing up as a ADB device, and not a Fastboot device. Fastboot would be more helpful, because it would give is a chance to unlock the bootloader and begin to make more progress.

I do think that the locked bootloader may what caused it to brick when we tried to DD a modified boot image back to the phone. In another thread the same thing happened to the ZTE Whirl when they tried to DD a modified recovery image... The bootloader may also be what is deleting the su binay on reboot...

Another possibility is that the kernel is responsible for both deleting the su binary on reboot, and the recovery and boot image verification failures that resulted in bricked devices. I am not yet skilled enough to pull the kernel and decompile it to study it.

Any takers on that?
Click to expand...

the kernel has long been decompiled. that was done when you gave me the copy of it.

and no, there is absolutely nothing in the kernel responsible for verification of the image(s) or the deleting of su

verification is either responsible by some file on /system (which has pretty much been eliminated since all the scripts that are run on boot do not contain code to do this--from what i've seen anyway)

or

(the most likely) img verification is done by code in the bootloader.

in my opinion, this expression "barrier=1" is what is responsible for /system never truly being mounted as r/w, and that nothing is deleting the su file. it's never there to begin with. it might "appear" to be there, but it's not.
 
Finally got the Valet to connect with QPST...

1. Dial *983*673636#; enables Emode (Engineering mode)

11iir6x.jpg


2. Dial *983*87274#; Opens "USB switch Test" (will not work until after step 1)

2eqb9fl.jpg


3. Select the "diag" option on the screen, which puts the phone "diagnostics mode"
and installs the device in Windows Device Manager as "Handset Diagnostic Interface (COM 5)", your COM # may be different.

2re3wnd.jpg


QPST is then able to see the device.

2a7wye8.jpg



This is as far as I have come with this, so far... I have not attempted to make a backup of my phone using QPST yet.

Note: To disable Emode, either reboot the phone, or just dial *983*2567336#



Do with this what you wish, I assume no responsibility for any damages you do to your phone...
 
I'm still having problems being able to copy su to /system/xbin. I'll have to mess with it some more but there seems to be something different with my phone perhaps because of the apps that are installed. I did find that "df" showed my /system to have insufficient space for su and I was hoping that moving some apps to sdcard would solve the problem but it didn't. So anyway, I'm still not having luck with copying to /system. For some of you who got it to work, perhaps you could give me more details or suggestions. I'm still working exclusively on Linux so maybe that is the difference.

But I do have a suggestion. I had toyed with the idea of putting su somewhere else and changing the $PATH environmental variable to include the location. While looking for info on QPST today (thanks for the interesting info mainefungi), I ran across an xda-developer thread that has some similarity to our dilemma with the a related solution. The solution was to put su under /system/vendor instead of /system/xbin to avoid it from being deleted. The thread is below.

(TOOL) Perma-Temp Root with *R/W* & Stable! - xda-developers

mainefungi - have you tried this? I'd try it if I could. I realize it is a kludge if it works but maybe it could extend the usefulness of temporary root until a better solution is found. Of course it won't work for root apps that use an absolute path to /system/xbin/su.
 
karmmisht said:
mainefungi - have you tried this? I'd try it if I could. I realize it is a kludge if it works but maybe it could extend the usefulness of temporary root until a better solution is found. Of course it won't work for root apps that use an absolute path to /system/xbin/su.
Click to expand...

I have not tried this... I do not download anything hosted on multiupload.com because the "iLivid download manager" they force you to use installs many things I do not want on my PC.

Looks like this is still temporary...
 
karmmisht said:
I'm still having problems being able to copy su to /system/xbin. I'll have to mess with it some more but there seems to be something different with my phone perhaps because of the apps that are installed. I did find that "df" showed my /system to have insufficient space for su and I was hoping that moving some apps to sdcard would solve the problem but it didn't. So anyway, I'm still not having luck with copying to /system. For some of you who got it to work, perhaps you could give me more details or suggestions. I'm still working exclusively on Linux so maybe that is the difference.
Click to expand...

So, you have been able to successfully remount system as r/w, but it is not allowing you to copy su because you haven't got enough free space???? I know I have run the remount and it did not show any errors, but running the mount command showed it was still r/o. But free space is not a issue I have ever seen...

104eqvt.jpg


There is my current status, if you want to compare... I have 65M free... more than enough for the tiny su binary... Also, moving apps to SD should not affect the available space... reason being, none of the user installed apps installed to /system/app, they go to /data/app (not visible without root privs).

I cannot imagine it is the problem, but if you want to rule out your Linux box as the issue, simply run 'df' in a terminal emulator app from the phone itself...

Also, I have found that if anything goes wrong with unknownone's method, you need to start over from the beginning... Usually with a fresh reboot on my Valet.

Let me know what you find out...
 
My post was not clear. I was also immediately turned off by that same download manager and did not download the software. Later in the xda thread, someone else put out a Linux version (shell script) which I did download. There's nothing much to the script other than running the exploit (not for the valet) and then installing root. The part I was interested in was the idea of installing root under /system/vendor. Here's an excerpt from the perma-temp script:

Code: 
,,,
adb shell mount -o rw,remount rootfs /
adb shell mount -oremount,suid /dev/block/mmcblk0p23 /data
adb shell mkdir /vendor/bin
adb shell chown root.shell /vendor/bin
adb shell chmod 755 /vendor/bin
adb push ./sqlite3 /vendor/bin
adb push ./su /vendor/bin
adb push ./busybox /vendor/bin
adb shell chown root.shell /vendor/bin/su
adb shell chown root.shell /vendor/bin/busybox
adb shell chown root.shell /vendor/bin/sqlite3
adb shell chmod 6555 /vendor/bin/su
adb shell chmod 4555 /vendor/bin/busybox
adb shell chmod 755 /vendor/bin/sqlite3
adb shell busybox --install -s /vendor/bin
adb shell sync
adb shell chmod 6555 /vendor/bin
read -p "Finished! Press any key to continue..."

So instead of doing what was discussed before about installing su in the usual place, if you install root under /system/vendor and then set $PATH to:

export PATH=/system/bin:/system/xbin:/sbin:/system/vendor

root won't survive the reboot but maybe su will not be deleted whenever you press some keys, etc. and hopefully remain in effect until a reboot(?). Seems worth a try and it doesn't appear to be dangerous compared to what you have already done - no guarantee of course.

Back to my phone - when I found out I had ~60k of space left under /system, I thought that was the problem because the su binary was about 110k. After deleting a few apps and moving some over to the sdcard (not as root but by using the app settings), my space went up to 65m. Still no luck with copying to /system. Given your explanation of where the apps are stored, I am not understanding why the apparent /system file space increased after "moving" them to sdcard. Point is I still don't have the right karma to write to /system.

Correction: Not sure if this would work anyway. Maybe the ".profile" (or whatever) would need to be revised to supplement the $PATH so any new shell would get the right path.
 
Found a much shorter way to gain temp root...

First, some assumptions...
1. USB Debugging enabled
2. Stay Awake checked
3. Wifi enabled and connected (need IP of phone)
4. Proper su binary is saved on the root of your sdcard

Okay, lets get root!

1. Run "# start telnetd as root on port 22" from Cydia Impactor
2. Telnet into phone's wifi ip on port 22
3. At ~ # prompt, type "su", then enter (gives FIX ME! error)
4. Type "exit", then enter. (brings you back to ~ #)
5. Type "mount -o rw,remount /system", then enter.
6. Type "cp /sdcard/su /system/xbin/su", then enter.
7. Type "cd system/xbin", then enter.
8. Type "chmod 06755 su", then enter.
9. Type "ln -s /system/xbin/su /system/bin/su", then enter.

That's it!

At this point you can exit back to the C:\ prompt...

From there, if you want to test it you can open an adb shell, then type su and enter... You should get "shell@android:/ #"

If you have not already... install supersu or superuser on phone and make sure it sees the su binary.

This is still only temp root, but it eliminates having to start telnetd as 'system', telnet in as 'system', running some some commands, then exiting that and running Cydia Impactor again... the telneting back in as 'root'... It also allows you to use 'cp' and 'chmod' commands without busybox. As such, for me it seems less fool proof.

I have not had this method fail yet, after several phone reboots for a sanity check... Let me know how it goes for you... Here is a screenshot of everything from step 2 to step 9; and proof of a privileged shell using this method. Enjoy!

106cz74.jpg


2egg1lc.png



EDIT: What shall I call this method? LOL
 
From a long time ago:

That su was pulled directly from Superuser-3.1.3-arm-signed.zip, found at Superuser
Click to expand...

Is this still the su you use? I notice Impactor specifies it as "# drop SuperSU su to /system/xbin/su"; so I wonder if a Superuser su works as well.
 
You must log in or register to reply here.
Back
Top Bottom