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

[mrfeh]

I'm not comfortable trying to piece together the procedure from multiple posts...if you can give me step-by-step instructions and links to files that need to be installed, I'm willing to give it a try. I don't think my phone has the heartbleed fix.

Thanks.

Had some spare time, so started attempting this process...unless I'm mistaken, the first thing to do is get temporary root, correct?

I've been using the rootmyvalet process, without success. First question - where can I find the correct su binary for this device?

 

[jjfriede]

Had some spare time, so started attempting this process...unless I'm mistaken, the first thing to do is get temporary root, correct?

I've been using the rootmyvalet process, without success. First question - where can I find the correct su binary for this device?

The binary I'm using is from here:
http://download.clockworkmod.com/superuser/superuser.zip

You'll need to extract the zip file and the su binary should be in the folder labeled armeabi.

 

[mrfeh]

The binary I'm using is from here:
http://download.clockworkmod.com/superuser/superuser.zip

You'll need to extract the zip file and the su binary should be in the folder labeled armeabi.

Thanks.

Unfortunately, I'm still not able to get temp root. I'm following the instructions under "The Second way" on this page:

https://github.com/Unkn0wn-0nes/RootMyValet/wiki/Manual-installation-Instructions

and it's not working. My root checker app says I don't have root, and I don't see su binaries/links in the correct places.

 

[jjfriede]

Thanks.

Unfortunately, I'm still not able to get temp root. I'm following the instructions under "The Second way" on this page:

https://github.com/Unkn0wn-0nes/RootMyValet/wiki/Manual-installation-Instructions

and it's not working. My root checker app says I don't have root, and I don't see su binaries/links in the correct places.

The app does NOT work. You will need to follow the first way as it is the only one that works. If you already have everything pushed and chmoded, you will need to run "/data/local/tmp/./roothandler" manually from adb shell and the script will tell you whether you successfully gained temp root or not. If it reports that the su binary was not properly pushed, then you must completely restart your phone and try again.

 

[mrfeh]

The app does NOT work. You will need to follow the first way as it is the only one that works. If you already have everything pushed and chmoded, you will need to run "/data/local/tmp/./roothandler" manually from adb shell and the script will tell you whether you successfully gained temp root or not. If it reports that the su binary was not properly pushed, then you must completely restart your phone and try again.

Thanks for the info.

Not sure if this is "success" or not. Thoughts?

shell@android:/data/local/tmp $ ./roothandler
ro.build.product=seanplus
ro.build.id=JRO03C
search kallsyms...
1 2 3 4 5 6 7 8 9 10 11 12
(kallsyms_addresses=c066fba0)
(kallsyms_num_syms=00010e24)
kernel dump...
1 2 3 4 5 6 7 8 9

prepare_kernel_cred=c00b14c8
commit_creds=c00b113c
ptmx_fops=c09f5698

Succeeded in getroot!
RootMyValet root script for Android devices v1.1
By karmmisht, mainefungi, jjfried, and elliot-labs.

Entering character mode
Escape character is '^]'.

su: unknown user root

shell@android:/data/local/tmp # Done.
shell@android:/data/local/tmp $ ls -al
-rwxr-xr-x shell shell 517 2014-09-27 20:42 installsu.sh
-rwxr-xr-x shell shell 17768 2014-09-27 20:42 roothandler
-rwxrwxrwx shell shell 311872 2014-02-10 09:00 su

 

[pa_cap]

Does any SU app allow you to assign SU privileges to any app like: ES File Explorer, CleanMaster, Link2SD, etc.? If so, you are rooted.

 

[mrfeh]

Does any SU app allow you to assign SU privileges to any app like: ES File Explorer, CleanMaster, Link2SD, etc.? If so, you are rooted.

I installed ES File Explorer and tried to use the "Root Explorer" tool, and receive a message that it can't be done on my device. I also have "Root Checker Basic" installed, which also says root is not enabled.

Strange, since the output of the rootHandler says it had success, and the root prompt is seen before the program ends.

/system is also mounted rw:

shell@android:/ $ mount
< output deleted >
/dev/block/mmcblk0p19 /system ext4 rw,relatime,data=ordered 0 0

 

[mrfeh]

FWIW - I found out where the "unknown user root" message comes from:

# adb shell
shell@android:/ $ busybox telnet 127.0.0.1 23

Entering character mode
Escape character is '^]'.


shell@android:/data/local/tmp # id
uid=0(root) gid=0(root)
shell@android:/data/local/tmp # busybox su
su: unknown user root

 

[mrfeh]

Made some progress...using info from this page:

https://github.com/Unkn0wn-0nes/RootMyValet/issues/10

(essentially doing what the installsu.sh script does by hand), I was able to mount /system rw and place links/files in /system/xbin and /system/bin.

However, my root checker and ES File Explorer both say I don't have root. This may explain why:

shell@android:/data/local/tmp $ ls -l /system/xbin
-rwxr-xr-x root shell 55664 2013-07-19 06:20 dexdump
-rwsr-sr-x root root 311872 2014-11-06 14:29 su
shell@android:/data/local/tmp $ su
link_image[1863]: 2975 missing essential tablesCANNOT LINK EXECUTABLE

Do I have the wrong su binary?

 

[jjfriede]

Made some progress...using info from this page:

https://github.com/Unkn0wn-0nes/RootMyValet/issues/10

(essentially doing what the installsu.sh script does by hand), I was able to mount /system rw and place links/files in /system/xbin and /system/bin.

However, my root checker and ES File Explorer both say I don't have root. This may explain why:

shell@android:/data/local/tmp $ ls -l /system/xbin
-rwxr-xr-x root shell 55664 2013-07-19 06:20 dexdump
-rwsr-sr-x root root 311872 2014-11-06 14:29 su
shell@android:/data/local/tmp $ su
link_image[1863]: 2975 missing essential tablesCANNOT LINK EXECUTABLE

Do I have the wrong su binary?

I don't think that would happen because of a wrong binary but try the one i attached and see what happens.

 

[mrfeh]

I don't think that would happen because of a wrong binary but try the one i attached and see what happens.

Had the wrong binary; using the one you provided, it appears we have success:

shell@android:/data/local/tmp $ su
shell@android:/data/local/tmp # id
uid=0(root) gid=0(root) groups=1003(graphics),1004(input),1007(log),1009(mount),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats)
shell@android:/data/local/tmp #

FWIW - ES File Manager and my root checker app both still say the device isn't rooted, but it certainly seems as though I have root through ADB shell.

So, now what? Use dd to zero/write a partition? Reading back through the thread, I'm not sure what file needs to be written. I saw a couple which apparently bricked a phone, but I didn't see an image stayboogy claimed should work.

Thanks.

 

[jjfriede]

Had the wrong binary; using the one you provided, it appears we have success:

shell@android:/data/local/tmp $ su
shell@android:/data/local/tmp # id
uid=0(root) gid=0(root) groups=1003(graphics),1004(input),1007(log),1009(mount),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats)
shell@android:/data/local/tmp #

FWIW - ES File Manager and my root checker app both still say the device isn't rooted, but it certainly seems as though I have root through ADB shell.

So, now what? Use dd to zero/write a partition? Reading back through the thread, I'm not sure what file needs to be written. I saw a couple which apparently bricked a phone, but I didn't see an image stayboogy claimed should work.

Thanks.

Nice! I don't think stayboogy has posted the corrected version of the rooted boot.img on the thread yet, so maybe you could pm him.

 

[scary alien]

FWIW - ES File Manager and my root checker app both still say the device isn't rooted, but it certainly seems as though I have root through ADB shell.

mrfeh,

What version of Android does the Valet run and what were the symptoms of root not working (i.e., I'm guessing you didn't get a prompt from you Superuser / SuperSU app or did you get an error message, etc.)?

There might be a mis-match between the version of the su binary and the Super user app--what you're reporting is similar to what I've seen before with various mismatches.

jjfriede, can you post the version info for the Superuser/SuperSU app that works with the su binary that you attached?

 

[mrfeh]

mrfeh,

What version of Android does the Valet run and what were the symptoms of root not working (i.e., I'm guessing you didn't get a prompt from you Superuser / SuperSU app or did you get an error message, etc.)?

There might be a mis-match between the version of the su binary and the Super user app--what you're reporting is similar to what I've seen before with various mismatches.

jjfriede, can you post the version info for the Superuser/SuperSU app that works with the su binary that you attached?

I think it's 4.4.1, but I'm not positive (don't have the phone with me at the moment).

I don't have superuser installed. I was using the apps I mentioned in my post.

 

[jjfriede]

okay test these.

one is signed with the platform key pair, the other with the superuser key pair

using the the secure install method used by zte in their update script of the package

test each one and report results please

(should not damage your phone in any way--if it works it only installs su binary; superuser will still need to be installed if it does work to gain root access)


update-platform-signed

update-superuser-singed

1. rename to update.zip

2. copy to /sdcard

3. reboot into recovery

4. attempt to install

5. if fails, try the second one following the same directions.

6. post results

mrfeh,

What version of Android does the Valet run and what were the symptoms of root not working (i.e., I'm guessing you didn't get a prompt from you Superuser / SuperSU app or did you get an error message, etc.)?

There might be a mis-match between the version of the su binary and the Super user app--what you're reporting is similar to what I've seen before with various mismatches.

jjfriede, can you post the version info for the Superuser/SuperSU app that works with the su binary that you attached?

I got that su binary from extracting an update.zip package that stayboogy posted a while back because I was unable to download it from androidsu.com due to some kind of server issue. So I'm not sure which version it is.

 

[scary alien]

I think it's 4.4.1, but I'm not positive (don't have the phone with me at the moment).

I don't have superuser installed. I was using the apps I mentioned in my post.

I got that su binary from extracting an update.zip package that stayboogy posted a while back because I was unable to download it from androidsu.com due to some kind of server issue. So I'm not sure which version it is.

Thanks for the info and feedback, guys! :thumbup:

I was asking about the Android version and the su version since root for 4.3+ also uses a daemonsu service that communicates with su (which communicates with SuperSU).

So, root for a 4.3+ device will need a synced-up set of those pieces to properly work with an app that is asking for root access.

Root via an adb shell seems to be a slightly different beast but it will also ask the SuperSU app for permission to run in root mode (but seems to sometimes (partially) work without a Superuser/SuperSU app present).

Anyway, I've been following this thread with great interest and was just trying to add a some info/considerations that might help you guys out.

Cheers and best of luck!

 

[thefilmreel]

Hey guys sorry for sounding like a noob, but how do I root my Valet using RootMyValet.apk?

 

[jjfriede]

Thanks for the info and feedback, guys! :thumbup:

I was asking about the Android version and the su version since root for 4.3+ also uses a daemonsu service that communicates with su (which communicates with SuperSU).

So, root for a 4.3+ device will need a synced-up set of those pieces to properly work with an app that is asking for root access.

Root via an adb shell seems to be a slightly different beast but it will also ask the SuperSU app for permission to run in root mode (but seems to sometimes (partially) work without a Superuser/SuperSU app present).

Anyway, I've been following this thread with great interest and was just trying to add a some info/considerations that might help you guys out.

Cheers and best of luck!

The ZTE Valet runs Android version 4.1.1.

And thanks for your help so far!

Hey guys sorry for sounding like a noob, but how do I root my Valet using RootMyValet.apk?

That method is not functional. sorry. Right now we're mostly waiting for stayboogy's modified boot.img which is probably the only way to actually root the phone. Also, if you haven't already, do not apply the heartbleed update to your phone otherwise it won't be able to be rooted since ZTE made some major changes to the firmware in that update.

 

[scary alien]

The ZTE Valet runs Android version 4.1.1.

And thanks for your help so far!

Ah, thank you jjfriede :thumbup: and no problem...wish I could be of more help.

At least you guys don't have to worry about the daemonsu and the added complexity that entailed.

mrfeh would still need to have the Superuser app installed before his root apps would be able to work.

Cheers guys!

 

[scary alien]

Hey guys, just a quick follow-up post:

1. I read through the entire thread last night and this morning (yeah, that took a while ). I must say I'm very impressed with the depth and breadth of knowledge and information presented by everyone in an effort to get your guys' phone a permanent root :thumbup: .

2. I don't think I've seen (or I missed them?) references to viewing a logcat (adb logcat) or the kernel log (cat /proc/kmsg or dmesg (although you must have your temp root to do either of these)). These might shed some light on what is going on with the "restoration" of the /system partition.

3. The Heartbleed OTA update.zip (referenced in post #401 and post #411) is pretty interesting:

A. For those that know how to unpack a bootable image, be aware that the recovery.img and the boot.img in that update.zip contain a "BOOT_MAGIC" string that is other than "ANDROID!" that various split boot image Perl scripts typically look for. You'll have to change the Perl script to also allow for "RECOVERY" and "BOOTIMG!" strings.

B. The updater-script file contains a "mistaken" package_extract_dir command for the "recovery" folder that does not exist in the update.zip file (and it also extracts to the /system partition, which is what caught my eye). I don't think there's any funny business going on there other than a mistake on ZTE's part, but thought I would point it out.

C. I don't see anything obvious in the updater-script that also updates/populates a partition other than the /system partition--i.e., if the /system partition is being re-populated at reboot time from another location, wouldn't the OTA also need to update that area, too?​

4. This is not the first device I've read about that had it's /system partition magically re-populated after a reboot (after various changes). I'm still searching for that thread here on AF, but it's been a while and I can't remember exactly which device or thread it was in (I've posted to almost 8,300 threads here, so you can understand my quandary ). I'll post back when I've found it.

edit: found it: http://androidforums.com/solved/787090-factory-reset-without-restoring-carrier-bloatware.html

Don't think this is what is going on, but the fact that they did the factory reset which is probably handled by the recovery was involved is interesting given the references to the verify.zip and installed-files-verify.txt found in the Valet's stock recovery? :dontknow:

5. Have you guys dumped all of the partitions you can find on the device? I.e, to see if they might possibly contain the cache of files used to re-populate the /system partition--assuming its done that way of course: it's possible that the /system partition is simple cleaned of any file that's not in the verify.zip's installed-files-verify.txt file. That file reference might be the thing that needs to be searched for to see exactly how it's coming into play.

edit: interestingly enough, there are references to both the verify.zip and installed-files-verify.txt in the recovery (/system/bin/recovery):

$ strings recovery | grep -i verify
/system/etc/verify.zip
Verifying update package...
I:verify_file returned %d
Verifying file_list package...
installed-files-verify.txt
E:failed to verify whole-file signature​

6. I came pretty close to ordering a Valet yesterday--but that was before I read through the entire thread and realized you guys have been pretty thorough .

That's all I got .

Cheers and don't give up!

 

[mrfeh]

I will install superuser, just in case it is needed for something.

At this point, I'm waiting for a boot.img and instructions from stayboogy. I don't think I can do any more on my own.

Edited to add - just found out I already have Superuser installed, as well as SuperSU.

 

[PeteTheKing]

Hey I tried the kingo root and it didnt work. I also tried the SRS One Click Root even though it lists The ZTE Z665C as one of the supported devices it didnt work.

Then I tried the The SafeRoot.apk. It said that it will reboot if your device gets rooted. After about 5-7 minutes it rebooted. Then i checked the in app root checker and it said it was rooted. I then went into the actual Root Checker app and it said it didnt root. So then i went back into the SafeRoot.apk and it then said it wasnt rooted.

I cant really get those command files and root commands and stuff like that cause im not a big techie but I hope this could help!

 

[scary alien]

Welcome to our AndroidForums, PeteTheKing!

~ ~ ~

Oh, one other thought to the guys with "test" Valet devices: if you want to also see if the /system partition is a "ghost" partition or one that is getting cleaned-up (i.e., the files that are not in the verify.zip list are removed), you could try enabling the su binary's immutable state.

This would prevent any cleanup process from being able to remove the file:

busybox chattr +i /system/xbin/su​

(^^^ assuming that the su binary was installed in /system/xbin/su)

Note: I don't have a Valet myself to test this on, so if you do this be aware that there might be something that freaks-out (boot-loops?) because if won't be able to remove the su binary.

Anyway, if the file "goes away" after a reboot, then you'll know that you actually have a ghost /system partition. If it stays...well, then, you might have a permanent root .

Thanks!

Note: setting the immutable status on the su binary was the wonderfully beautiful and simple method for surviving root from an OTA update.

You should be aware, however, that leaving a file with an immutable status in /system might make future OTAs fails because of the recursive re-securing (set_metadata_recursive) that is done in recent (i.e., 4.4) OTA updates. So, if this method works and your device receives a new OTA update--you need to check the OTA's updater-script file for a set_metadata_recursive or set_perm_recursive operation on the /system partition (and/or remove any immutable files in your /system hierarchy) before attempting to install said OTA.

 

[jjfriede]

Welcome to our AndroidForums, PeteTheKing!

~ ~ ~

Oh, one other thought to the guys with "test" Valet devices: if you want to also see if the /system partition is a "ghost" partition or one that is getting cleaned-up (i.e., the files that are not in the verify.zip list are removed), you could try enabling the su binary's immutable state.

This would prevent any cleanup process from being able to remove the file:

busybox chattr +i /system/xbin/su​

(^^^ assuming that the su binary was installed in /system/xbin/su)

Note: I don't have a Valet myself to test this on, so if you do this be aware that there might be something that freaks-out (boot-loops?) because if won't be able to remove the su binary.

Anyway, if the file "goes away" after a reboot, then you'll know that you actually have a ghost /system partition. If it stays...well, then, you might have a permanent root .

Thanks!

Note: setting the immutable status on the su binary was the wonderfully beautiful and simple method for surviving root from an OTA update.

You should be aware, however, that leaving a file with an immutable status in /system might make future OTAs fails because of the recursive re-securing (set_metadata_recursive) that is done in recent (i.e., 4.4) OTA updates. So, if this method works and your device receives a new OTA update--you need to check the OTA's updater-script file for a set_metadata_recursive or set_perm_recursive operation on the /system partition (and/or remove any immutable files in your /system hierarchy) before attempting to install said OTA.

I tried it and the binary still went away after about 5 min before i could install supersu without even rebooting my phone. I wonder what happened there.

 

[scary alien]

I tried it and the binary still went away after about 5 min before i could install supersu without even rebooting my phone. I wonder what happened there.

Wow!

Did you verify the immutable bit was set (i.e., via lsattr)?

Hmm, there's some really weird/wild stuff going on there...something's "watching" the /system partition? (sounds kind of extreme for a manufacturer that seems doesn't usually go this far...)

:dontknow: