• 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...

Unkn0wn0ne said:
I looked at the certificate and the zte one in verify.zip says its from zte while the one you used is from google. That might be why. Here you go:

https://drive.google.com/file/d/0B1qPTRYda2ChU09XNUk4ZUMyTlU/edit?usp=sharing

Also: We have rw access to /data/app so we can remove most of zte bloatware now. (yay!)
Click to expand...

are you talking about the otacert file?

it's not a file "i used" so to speak. it's the cert the actual jelly bean sdk used...

hang on, i'll try to figure something out here shortly
 
This had also failed, but after experimenting in shell I got /system to remount rw and pushed su binary. Testing now

EDIT: Su binary was successfully pushed, but failed to survive reboot.

EDIT 2: I can now remount /system with my new method:
- Telnet exploit on system, log in and run some commands
- Telnet exploit on root
- Run command su as soon as you get in. There will be an error message
- mount -o rw,remount /system
- mount - now shows /system remounted
- happy trails!

Results:
- Discovered a new exploit with the ZTE Valet that allows remounting of /system
- su binary doesn't survive reboot, but superuser does infact know it is there. [investigating]
 
Unkn0wn0ne said:
This had also failed, but after experimenting in shell I got /system to remount rw and pushed su binary. Testing now

EDIT: Su binary was successfully pushed, but failed to survive reboot.

EDIT 2: I can now remount /system with my new method:
- Telnet exploit on system, log in and run some commands
- Telnet exploit on root
- Run command su as soon as you get in. There will be an error message
- mount -o rw,remount /system
- mount - now shows /system remounted
- happy trails!
Click to expand...

okay, it failed

what was the error code?

i have two more for you to try.

and, if you don't mind, try this root method: http://androidforums.com/6196439-post1.html

no one has posted the results from it. there's no reason to not try it. just follow what it says in the quoted box "Just download Xperia_L_ROOT.zip (2.24 MB, 6074 views) AND DO WHAT IT SAYS :p"
 
Still not there yet - but I managed to capture something that will make everyone here happy using the new exploit :
3A7z44U.png
 
Unkn0wn0ne said:
Still not there yet - but I managed to capture something that will make everyone here happy using the new exploit :
3A7z44U.png
Click to expand...


so, you going to post a how-to???

i'm ready to see how it's done.

and if it's a sure thing, i can finally break down and buy the phone lol
 
stayboogy said:
so, you going to post a how-to???

i'm ready to see how it's done.

and if it's a sure thing, i can finally break down and buy the phone lol
Click to expand...

Alright so this is how I did it. I call the kernel exploit the Unkn0wn Expliot. (Cheesy I know.) lol
One more interesting thing: After running the remount, I tried cydia impactor one time to see if it would stay permanent. It didn't but cydia impactor didn't throw an error. It completed.

-Downloaded the su binary (I used the one in your post, but was outdated)
-Push it to /sdcard using adb
-Run the telnet exploit on system using cydia impactor.
-Log into the system telnet
-Run some commands
-Now run: su (This will produce an interesting error message, saying that we need to be suid even though the binary is not installed)
-Type exit
-Run telnet exploit as root cydia impactor
-Log in via telnet again this time as root.
-Run su (There will be an error message about FIX ME. This is the exploit here).
-Now enter "cp" it will error saying it cannot be found.
-Now this is where the fun begins. You should see some numbers (ex: 127|root@android) next to the root@android. This is where we have caused a failure in the kernel and we can do just about anything now without it ignoring us.
- Run mount -o rw,remount /system (The exploit causes the kernel the accept the remount.)
-Run mount and make sure /sytem is rw, if not you might have to try this again. This happened to me when I skipped the system login
-Run busybox cp /sdcard/su /system/xbin/su (cp can't be found right after kernel exploit so this is the workaround. Not sure why)
-cd to /system/xbin
-give it the permissions. I used busybox chmod 06755 su on the time it worked.
-create symlink to /system/bin via ln -s /system/xbin/su /system/bin/su
-install supersu or superuser on phone and make sure it sees binary
-download root checker, it should report root access. That picture was not photo shopped. (I don't even own photo shop)
-have fun!

NOTE: Right now I haven't figured out how to survive reboots. But since we have true root temporary access thanks to the kernel exploit we can figure something out. I think I might try installing XPosed and create a module or something to do it. We could also create a shell script, save it to the phone, and have the kernel execute on boot. This is where the problem is.
 
Xperia_L_ROOT didn't work.

[*] Device found.
[*] Pushing exploit...
4646 KB/s (1283460 bytes in 0.269s)
[*] Pushing root tools...
3474 KB/s (91980 bytes in 0.025s)
6224 KB/s (1867568 bytes in 0.292s)
5591 KB/s (969701 bytes in 0.169s)
pkg: /data/local/tmp/Superuser.apk
Success
[*] Rooting phone...
[+] This may take a few minutes.
Bus error
[*] Cleaning up...
[*] Exploit complete. Press enter to reboot and exit.

Note that "Bus error". It was worth a try although I had tried motochopper before but perhaps the Xperia version assumes the kernel is located differently in memory.
 
Just a thought...

How about running one of the rooting tools after using Unkn0wn0ne's method of gaining temp root (srsroot, normal cydia method, L_Root, etc)? Maybe a successful rw mounting of /system prior to running them will allow one of the other methods to run through their process and make it permanent...

I can't wait til I get my new phone... Having withdrawals...
 
mainefungi said:
Just a thought...

How about running one of the rooting tools after using Unkn0wn0ne's method of gaining temp root (srsroot, normal cydia method, L_Root, etc)? Maybe a successful rw mounting of /system prior to running them will allow one of the other methods to run through their process and make it permanent...

I can't wait til I get my new phone... Having withdrawals...
Click to expand...

I actually got cydia impactor to run successfully yesterday after doing this, but I think I tampered with some things after which might have effected the results. I'll see if I can try some other utilities after remounting system. The problem with the phone is instead of directly patching the exploits, ZTE blocked the remount at kernel level which caused all these tools to fail. Now that we have the kernel exploit all tools should work in theory, they just need a little help.

I can't do much more today, but now I have more of a reason to look. Getting root checker to verify is a big achievement in this battle, don't take that for granite as now we can run rooted apps.
 
Unkn0wn0ne said:
I actually got cydia impactor to run successfully yesterday after doing this, but I think I tampered with some things after which might have effected the results. I'll see if I can try some other utilities after remounting system. The problem with the phone is instead of directly patching the exploits, ZTE blocked the remount at kernel level which caused all these tools to fail. Now that we have the kernel exploit all tools should work in theory, they just need a little help.

I can't do much more today, but now I have more of a reason to look. Getting root checker to verify is a big achievement in this battle, don't take that for granite as now we can run rooted apps.
Click to expand...

i need a pull of the /system/etc directory if possible. i think i know what might be going on with the not being able to flash a new boot with it bricking. just need the contents of this directory because it houses some scripts i need to take a look at
 
stayboogy said:
i need a pull of the /system/etc directory if possible. i think i know what might be going on with the not being able to flash a new boot with it bricking. just need the contents of this directory because it houses some scripts i need to take a look at
Click to expand...

Here are the scripts in my /system/etc:

https://drive.google.com/file/d/0Bw7b4Sw9CtykMVA1Ymx6YlZVRkE/edit?usp=sharing

There is one script under etc, init.qcom.post_fs.sh, that mounts system rw, executes a few scripts, and then remounts /system ro. This is interesting.

I had tried the root steps provided by Unkn0wn0ne exploit a few posts up and couldn't get it to work. I don't quite understand the step where it says "... do not log out" and then it says to log in two steps later. Hopefully, mainefungi will get his phone back soon and he can try it out or someone else can test it. When I had played around with the temporary root (reported in the xda-developers forum a little while ago):

[Q] Root ZTE Valet Z665c - Page 2 - xda-developers

I had reported that the root prompt came back after executing the mount command as if everything was OK yet /system was still "ro". But a couple of times, I did get it mounted rw but only for a very short time. Seems that the remount might be possible in the first attempt following a reboot and perhaps UnKn0wn0ne happened on to the right sequence and timing.

A look at dmesg following a remount attempt shows:

...
[12-29 06:25:01.450] [7626: busybox]EXT4-fs error (device mmcblk0p19):
ext4_remount:4268: Abort forced by user
...

Of course, I didn't purposefully abort the remount although the log says differently.

Good luck with the files. It would help me if you could provide more explanation on what you are trying to do with the files you want tested as updates. I'd like to learn some along the way. Also, I'm fairly cautious with my phone since I'm relying on it and am not fully understanding the risks and what you are wanting to do.
 
karmmisht said:
Here are the scripts in my /system/etc:

https://drive.google.com/file/d/0Bw7b4Sw9CtykMVA1Ymx6YlZVRkE/edit?usp=sharing

There is one script under etc, init.qcom.post_fs.sh, that mounts system rw, executes a few scripts, and then remounts /system ro. This is interesting.

I had tried the root steps provided by Unkn0wn0ne exploit a few posts up and couldn't get it to work. I don't quite understand the step where it says "... do not log out" and then it says to log in two steps later. Hopefully, mainefungi will get his phone back soon and he can try it out or someone else can test it. When I had played around with the temporary root (reported in the xda-developers forum a little while ago):

[Q] Root ZTE Valet Z665c - Page 2 - xda-developers

I had reported that the root prompt came back after executing the mount command as if everything was OK yet /system was still "ro". But a couple of times, I did get it mounted rw but only for a very short time. Seems that the remount might be possible in the first attempt following a reboot and perhaps UnKn0wn0ne happened on to the right sequence and timing.

A look at dmesg following a remount attempt shows:

...
[12-29 06:25:01.450] [7626: busybox]EXT4-fs error (device mmcblk0p19):
ext4_remount:4268: Abort forced by user
...

Of course, I didn't purposefully abort the remount although the log says differently.

Good luck with the files. It would help me if you could provide more explanation on what you are trying to do with the files you want tested as updates. I'd like to learn some along the way. Also, I'm fairly cautious with my phone since I'm relying on it and am not fully understanding the risks and what you are wanting to do.
Click to expand...

About that step on the exploit. I meant just type exit. This closes the telnet session so you can reconnect as root later. I'll clarify this in the post. The thing I noticed about the exploit is it turned # into root@android:/# which allowed me to run commands unrestricted. Also my method did succeed on reboots provided all the steps where ran, but the first time I ran it the phone was on for over an hour I believe.
 
Unkn0wn0ne said:
About that step on the exploit. I meant just type exit. This closes the telnet session so you can reconnect as root later. I'll clarify this in the post. The thing I noticed about the exploit is it turned # into root@android:/# which allowed me to run commands unrestricted. Also my method did succeed on reboots provided all the steps where ran, but the first time I ran it the phone was on for over an hour I believe.
Click to expand...

Can please you do a pull of the full /system/etc directory with privileges for stayboogy... Or at least do a ls of the directory to be sure those scripts and the verify.zip are the only contents of the directory...

Good news is I finally got a tracking number for my replacement phone yesterday. Bad news is Fedex is not registering it yet, which means it has not been scanned yet. :(
 
unkn0wn, try replacing your /system/etc/init.qcom.post_fs.sh with this one and see if root survives reboot.

Code: 
#!/system/bin/sh
# Copyright (c) 2012, Code Aurora Forum. All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are met:
#     * Redistributions of source code must retain the above copyright
#       notice, this list of conditions and the following disclaimer.
#     * Redistributions in binary form must reproduce the above copyright
#       notice, this list of conditions and the following disclaimer in the
#       documentation and/or other materials provided with the distribution.
#     * Neither the name of Code Aurora nor
#       the names of its contributors may be used to endorse or promote
#       products derived from this software without specific prior written
#       permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
# NON-INFRINGEMENT ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT OWNER OR
# CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
# EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
# PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
# OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
# WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
# OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
# ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#

# This should be the first command
# remount system as read-write.
mount -o rw,remount,barrier=1 /system

# Run modem link script
/system/bin/sh /system/etc/init.qcom.modem_links.sh

# Run mdm link script
/system/bin/sh /system/etc/init.qcom.mdm_links.sh

# Run thermal script
/system/bin/sh /system/etc/init.qcom.thermald_conf.sh

# Run wifi script
# Modified by chenjianfeng: Disable this script
#/system/bin/sh /system/etc/init.qcom.wifi.sh

# Enable root
# ebildude123
# Not tested since I don't a valet
chown 0.0 /system/xbin/su
chmod 06755 /system/xbin/su
ln -s /system/xbin/su /system/bin/su

# This should be the last command
# remount system as read-only.
mount -o ro,remount,barrier=1 /system
 
karmmisht said:
Here are the scripts in my /system/etc:

https://drive.google.com/file/d/0Bw7b4Sw9CtykMVA1Ymx6YlZVRkE/edit?usp=sharing

There is one script under etc, init.qcom.post_fs.sh, that mounts system rw, executes a few scripts, and then remounts /system ro. This is interesting.

I had tried the root steps provided by Unkn0wn0ne exploit a few posts up and couldn't get it to work. I don't quite understand the step where it says "... do not log out" and then it says to log in two steps later. Hopefully, mainefungi will get his phone back soon and he can try it out or someone else can test it. When I had played around with the temporary root (reported in the xda-developers forum a little while ago):

[Q] Root ZTE Valet Z665c - Page 2 - xda-developers

I had reported that the root prompt came back after executing the mount command as if everything was OK yet /system was still "ro". But a couple of times, I did get it mounted rw but only for a very short time. Seems that the remount might be possible in the first attempt following a reboot and perhaps UnKn0wn0ne happened on to the right sequence and timing.

A look at dmesg following a remount attempt shows:

...
[12-29 06:25:01.450] [7626: busybox]EXT4-fs error (device mmcblk0p19):
ext4_remount:4268: Abort forced by user
...

Of course, I didn't purposefully abort the remount although the log says differently.

Good luck with the files. It would help me if you could provide more explanation on what you are trying to do with the files you want tested as updates. I'd like to learn some along the way. Also, I'm fairly cautious with my phone since I'm relying on it and am not fully understanding the risks and what you are wanting to do.
Click to expand...

thanks for the pulls.

i'm not trying to make an update at the moment.

what i'm doing is trying to find the script that is responsible for verifying the recovery and boot.img's hash. my xoom tablet had one of these scripts that flashed and verified the recovery on every boot as it was stock.

i'm thinking there is a script that does the same thing on this device. the verify.zip only verifies files on the /system partition and has nothing to do with the recovery and boot partitions. but it will have to be removed if one of the scripts is changed on the /system partition as well cause it will fail verification.

thanks again.

this phone is a challenge to root... who would've thought...
 
ebildude123 said:
unkn0wn, try replacing your /system/etc/init.qcom.post_fs.sh with this one and see if root survives reboot.

Code: 
#!/system/bin/sh
# Copyright (c) 2012, Code Aurora Forum. All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are met:
#     * Redistributions of source code must retain the above copyright
#       notice, this list of conditions and the following disclaimer.
#     * Redistributions in binary form must reproduce the above copyright
#       notice, this list of conditions and the following disclaimer in the
#       documentation and/or other materials provided with the distribution.
#     * Neither the name of Code Aurora nor
#       the names of its contributors may be used to endorse or promote
#       products derived from this software without specific prior written
#       permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
# NON-INFRINGEMENT ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT OWNER OR
# CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
# EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
# PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
# OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
# WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
# OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
# ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#

# This should be the first command
# remount system as read-write.
mount -o rw,remount,barrier=1 /system

# Run modem link script
/system/bin/sh /system/etc/init.qcom.modem_links.sh

# Run mdm link script
/system/bin/sh /system/etc/init.qcom.mdm_links.sh

# Run thermal script
/system/bin/sh /system/etc/init.qcom.thermald_conf.sh

# Run wifi script
# Modified by chenjianfeng: Disable this script
#/system/bin/sh /system/etc/init.qcom.wifi.sh

# Enable root
# ebildude123
# Not tested since I don't a valet
chown 0.0 /system/xbin/su
chmod 06755 /system/xbin/su
ln -s /system/xbin/su /system/bin/su

# This should be the last command
# remount system as read-only.
mount -o ro,remount,barrier=1 /system
Click to expand...

i like your style.

and great effort, but

this won't work, as it is right now anyway

1) the verify.zip must be removed first, and whatever file calls it's function. changing the script changes its hash

2) su has to already be on the phone for your commands to work, which it's not.

it would need something like

cp /sdcard/su /system/xbin

then

chown 0.0 /system/xbin/su
chmod 06755 /system/xbin/su
ln -s /system/xbin/su /system/bin/su


but then it would also run at every boot, unless later modified not to do so.

3) also, after init.qcom.thermald_conf.sh is run, the system is mounted ro once again (last line of that script), so the root command would have to come right after the rw mount of this script


hypothetically, though, your method would work as long as these hiccups are dealt with first.
 
stayboogy said:
this phone is a challenge to root... who would've thought...
Click to expand...

More of a challenge than I would have thought... Why go to such great efforts locking down a $80 device... when there a devices worth much more that are pretty easy by comparison?

Though I think I know the answer. I am sure these efforts are part of the agreements between the cell phone carriers and Straight Talk/Tracfone/Net10...
 
You must log in or register to reply here.
Back
Top Bottom