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

You are a CRAZY person...and I'm glad you are! Did not know how much longer I could restrain myself from trying.

Thanks again for your relentless efforts!
 
Anyone able to help me continue searching for a root solution for this phone?

i've yet to come across anything of interest...

really confused why the recovery trick isn't working.

if i find anything i'll post.

again, might be worth a shot to contact jcase.

i still haven't bought the phone because there's no root solution
 
i've yet to come across anything of interest...

really confused why the recovery trick isn't working.

if i find anything i'll post.

again, might be worth a shot to contact jcase.

i still haven't bought the phone because there's no root solution


I will see if I can get a hold of him. Maybe he has a few ideas I can try.
 

yep.

if temp root access can be gained that way, then full root can be easily gained.

the guy over there is most likely using the wrong su binary therefore he can't remount rw, other there is nothing giving the acquired root permissions (superuser.apk) upon remount attempt. zte did not cripple the mount command in any way. no one is going through that much trouble to prevent root...

that's my guess anyway.



anyway, if someone duplicates this,

use the 22kb su binary http://dl.dropbox.com/u/8699733/chainsdd-su.zip

and set the permissions correctly with

chown 0.0 /system/xbin/su

chmod 06755 /system/xbin/su

then reboot the phone, install superuser, and check root.


i may go get one tomorrow just to try if no one else does. i've got a linux box. telnet on windows never worked right for me when i tried stuff like this for rooting a modem/router
 
yep.

if temp root access can be gained that way, then full root can be easily gained.

the guy over there is most likely using the wrong su binary therefore he can't remount rw, other there is nothing giving the acquired root permissions (superuser.apk) upon remount attempt. zte did not cripple the mount command in any way. no one is going through that much trouble to prevent root...

that's my guess anyway.



anyway, if someone duplicates this,

use the 22kb su binary http://dl.dropbox.com/u/8699733/chainsdd-su.zip

and set the permissions correctly with

chown 0.0 /system/xbin/su

chmod 06755 /system/xbin/su

then reboot the phone, install superuser, and check root.


i may go get one tomorrow just to try if no one else does. i've got a linux box. telnet on windows never worked right for me when i tried stuff like this for rooting a modem/router

I will give it a go tonight. I was able to use telnet to pull the following for you... Which I could not do before, so I agree I can get partial root...

----------------------------------------------------------------------

root@android:/ # cat /cache/recovery/last_log
Starting recovery on Tue Dec 10 21:53:07 2013
framebuffer: fd 4 (320 x 480)
recovery filesystem table
=========================
0 /tmp ramdisk (null) (null) 0
1 /boot emmc /dev/block/mmcblk0p16 (null) 0
2 /cache ext4 /dev/block/mmcblk0p21 (null) 0
3 /data ext4 /dev/block/mmcblk0p22 (null) -16384
4 /recovery emmc /dev/block/mmcblk0p17 (null) 0
5 /splash emmc /dev/block/mmcblk0p18 (null) 0
6 /misc emmc /dev/block/mmcblk0p20 (null) 0
7 /sdcard vfat /dev/block/mmcblk1p1 /dev/block/mmcblk1 0
8 /system ext4 /dev/block/mmcblk0p19 (null) 0
9 /amss emmc /dev/block/mmcblk0p13 (null) 0
10 /oemsbl emmc /dev/block/mmcblk0p3 (null) 0
11 /emmcboot emmc /dev/block/mmcblk0p15 (null) 0
12 /cefs emmc /dev/block/mmcblk0p11 (null) 0
13 /qcsblhd_cfgdata emmc /dev/block/mmcblk0p1 (null) 0
14 /qcsbl emmc /dev/block/mmcblk0p2 (null) 0

Command: "/sbin/recovery"

ro.boot.hardware=qcom
ro.boot.emmc=true
ro.boot.serialno=HIDDEN
ro.boot.authorized_kernel=true
ro.boot.baseband=msm
ro.serialno=HIDDEN
ro.bootmode=unknown
ro.baseband=msm
ro.bootloader=unknown
ro.hardware=qcom
ro.revision=0
ro.factorytest=0
ro.secure=1
ro.allow.mock.location=0
ro.debuggable=0
ro.build.id=JRO03C
ro.build.display.id=TF_US_Z665CV1.0.0B12
ro.build.version.incremental=20130719.183904.1197
ro.build.version.sdk=16
ro.build.version.codename=REL
ro.build.version.release=4.1.1
ro.build.date=Fri Jul 19 18:39:45 CST 2013
ro.build.date.utc=1374230385
ro.build.type=user
ro.build.user=wsys
ro.build.host=ubuntu
ro.build.tags=release-keys
ro.product.model=Z665C
ro.product.brand=ZTE
ro.product.name=P765V20
ro.product.device=seanplus
ro.product.board=seanplus
ro.product.cpu.abi=armeabi-v7a
ro.product.cpu.abi2=armeabi
ro.product.manufacturer=ZTE
ro.product.locale.language=en
ro.product.locale.region=US
ro.wifi.channels=
ro.board.platform=msm7627a
ro.build.product=seanplus
ro.build.description=P765V20-user 4.1.1 JRO03C 20130719.183904.1197 release-
ro.build.fingerprint=ZTE/P765V20/seanplus:4.1.1/JRO03C/20130719.183904.1197:
ro.build.characteristics=cdma
rild.libpath=/system/lib/libril-qc-1.so
rild.libargs=-d /dev/smd0
persist.rild.nitz_plmn=
persist.rild.nitz_long_ons_0=
persist.rild.nitz_long_ons_1=
persist.rild.nitz_long_ons_2=
persist.rild.nitz_long_ons_3=
persist.rild.nitz_short_ons_0=
persist.rild.nitz_short_ons_1=
persist.rild.nitz_short_ons_2=
persist.rild.nitz_short_ons_3=
persist.data_netmgrd_mtu=1410
ril.subscription.types=NV,RUIM
DEVICE_PROVISIONED=1
keyguard.no_require_sim=true
debug.sf.hw=1
debug.composition.7x27A.type=mdp
debug.composition.7x25A.type=mdp
debug.composition.8x25.type=dyn
debug.hwc.dynThreshold=1.9
dalvik.vm.heapsize=64m
ro.sf.lcd_density=160
persist.cne.bat.range.low.med=30
persist.cne.bat.range.med.high=60
persist.cne.loc.policy.op=/system/etc/OperatorPolicy.xml
persist.cne.loc.policy.user=/system/etc/UserPolicy.xml
persist.cne.bwbased.rat.sel=false
persist.cne.snsr.based.rat.mgt=false
persist.cne.bat.based.rat.mgt=false
persist.cne.rat.acq.time.out=30000
persist.cne.rat.acq.retry.tout=0
persist.cne.fmc.init.time.out=30
persist.cne.fmc.comm.time.out=130
persist.cne.fmc.retry=false
persist.cne.feature=0
media.stagefright.enable-player=true
media.stagefright.enable-meta=false
media.stagefright.enable-scan=true
media.stagefright.enable-http=true
media.stagefright.enable-fma2dp=true
media.stagefright.enable-aac=true
media.stagefright.enable-qcp=true
headset.hook.delay=500
audio.legacy.postproc=true
ro.opengles.version=131072
ro.use_data_netmgrd=true
persist.data.ds_fmc_app.mode=0
persist.ims.regmanager.mode=0
ro.bluetooth.request.master=true
ro.qualcomm.bluetooth.ftp=true
ro.qualcomm.bluetooth.sap=false
ro.qualcomm.bluetooth.dun=false
ro.qualcomm.bluetooth.map=true
ro.bluetooth.remote.autoconnect=true
persist.sys.strictmode.visual=false
persist.omh.enabled=1
ro.config.ehrpd=true
ro.qualcomm.cabl=1
telephony.lteOnCdmaDevice=0
ro.ril.transmitpower=true
ro.fm.analogpath.supported=true
ro.fm.transmitter=false
ro.fm.mulinst.recording.support=false
ro.emmc.sdcard.partition=18
ro.screen.layout=normal
debug.enabletr=false
ro.staticwallpaper.pixelformat=RGB_565
debug.camcorder.disablemeta=0
persist.fuse_sdcard=false
debug.camera.landscape=true
ro.max.fling_velocity=4000
httplive.enable.discontinuity=true
dev.pm.dyn_samplingrate=1
dev.pm.dyn_sample_period=700000
persist.service.cdrom.enable=1
persist.radio.set_prl_pref=false
ro.cdma.home.operator.numeric=31000
ro.feature.ztedrm.support=1
drm.service.enabled=true
persist.sys.usb.menu=enable
persist.sys.usb.config=cdrom
persist.sys.fuse.dir=auto
ro.config.sec_storage=4
ro.config.notification_sound=SMS01.ogg
ro.config.ringtone=Standard.ogg
ro.emode.enableSpecialCode=true
ro.com.google.clientidbase=android-zte
ro.com.google.clientidbase.yt=android-zte
ro.com.google.clientidbase.am=android-americamovil-us
ro.build.baseband_version=P765V20B01
ro.com.google.clientidbase.gmm=android-zte
ro.emode.flashtest=true
ro.com.google.clientidbase.ms=android-americamovil-us
ro.emode.auxi=true
ro.build.sw_internal_version=TF_US_P765V20V1.0.0B15
ro.emode.fm=0
ro.emode.keytest=camera
ro.build.hardware_version=Z665CHWV1.0
ro.emmc=1
ro.secure.version=Z665C_SEC_V11.0
ro.com.android.dataroaming=true
ro.com.android.dateformat=MM-dd-yyyy
ro.carrier=unknown
ro.config.alarm_alert=Dawn_of_the_jungle.ogg
ro.vendor.extension_library=/system/lib/libqc-opt.so
dalvik.vm.heapstartsize=4m
dalvik.vm.heapgrowthlimit=32m
ro.setupwizard.mode=OPTIONAL
ro.com.google.gmsversion=4.1_r5
persist.sys.ztelog.enable=0
ro.telephony.default_network=4
persist.radio.add_power_save=1
net.bt.name=Android
net.change=net.bt.name
dalvik.vm.stack-trace-file=/data/anr/traces.txt
init.svc.ueventd=running
init.svc.rmt_storage=running
init.svc.recovery=running
init.svc.console=running
init.svc.diagtest=running

root@android:/ #
 
yep.

if temp root access can be gained that way, then full root can be easily gained.

the guy over there is most likely using the wrong su binary therefore he can't remount rw, other there is nothing giving the acquired root permissions (superuser.apk) upon remount attempt. zte did not cripple the mount command in any way. no one is going through that much trouble to prevent root...

that's my guess anyway.



anyway, if someone duplicates this,

use the 22kb su binary http://dl.dropbox.com/u/8699733/chainsdd-su.zip

and set the permissions correctly with

chown 0.0 /system/xbin/su

chmod 06755 /system/xbin/su

then reboot the phone, install superuser, and check root.


i may go get one tomorrow just to try if no one else does. i've got a linux box. telnet on windows never worked right for me when i tried stuff like this for rooting a modem/router

Okay, I think we are on 2 different pages... This method will not allow root access in ADB Shell, only in the telnet. And the /system folder is still read only, even while in the telnet session.

Unfortunately, Cydia Impactor uses a dat file to house all the tools, so you cannot just drag and drop a new su file into the mix.

I will do some research to see if I can replicate the methods used to enable root over telnet port 22, and go from there.

Also, I noticed the ro.secure=1 is enabled in the default.prop, so I tried changing it to ro.secure=0, as I had read on another forum. Unfortunately, it reverts.. Meaning it is getting reset by the boot.img. If I can dump and extract the boot.img and edit the default.prop in there to ro.secure=1, I think we can get boot naturally. Busybox works in this telnet session, so it should be easy enough to reflash the boot.img once it is re-packed...

This may be a last resort, but any thoughts on it would be welcome...
 
Okay, I think we are on 2 different pages... This method will not allow root access in ADB Shell, only in the telnet. And the /system folder is still read only, even while in the telnet session.

Unfortunately, Cydia Impactor uses a dat file to house all the tools, so you cannot just drag and drop a new su file into the mix.

I will do some research to see if I can replicate the methods used to enable root over telnet port 22, and go from there.

Also, I noticed the ro.secure=1 is enabled in the default.prop, so I tried changing it to ro.secure=0, as I had read on another forum. Unfortunately, it reverts.. Meaning it is getting reset by the boot.img. If I can dump and extract the boot.img and edit the default.prop in there to ro.secure=1, I think we can get boot naturally. Busybox works in this telnet session, so it should be easy enough to reflash the boot.img once it is re-packed...

This may be a last resort, but any thoughts on it would be welcome...

i realize that telnet is what has root, and therefore adb is not running--a psuedo root of sorts. but plain ole linux commands such as cp will work in that shell. but if system is indeed only ro when in the telnet session that's no good for copying su to the xbin location

try this:

***add a directory to your PATH in the terminal before you begin that houses this file, or just open a terminal from the folder that has this fine in it and run telnet***

dd

once root in telnet

cp dd /data/local/tmp

chmod 777 /data/local/tmp/dd
/data/local/tmp/dd if=/dev/block/mmcblk0p16 of=/sdcard/valet-stock-boot.img bs=4096


then upload the boot.img if it works, i'll unpack, change the prop, repack it, and you see if you can flash. the boot.img has to be dd'd for emmc devices like so

/data/local/tmp/dd if=/sdcard/valet-root-boot.img of=/dev/block/mmcblk0p16
 
i realize that telnet is what has root, and therefore adb is not running--a psuedo root of sorts. but plain ole linux commands such as cp will work in that shell. but if system is indeed only ro when in the telnet session that's no good for copying su to the xbin location

try this:

***add a directory to your PATH in the terminal before you begin that houses this file***

once root in telnet

cp dd /data/local/tmp
chmod 777 /data/local/tmp/dd
/data/local/tmp/dd if=/dev/block/mmcblk0p16 of=/sdcard/valet-stock-boot.img bs=4096

then upload the boot.img if it works, i'll unpack, change the prop, repack it, and you see if you can flash. the boot.img has to be dd'd for emmc devices like so

/data/local/tmp/dd if=/sdcard/valet-root-boot.img of=/dev/block/mmcblk0p16

cp dd /data/local/tmp produces the following error...

~ # cp dd /data/local/tmp
cp: can't stat 'dd': No such file or directory
~ #
 
Sorry if I am ignorant or -
- Can't we just set the ro.secure property in the root telnet session even though it will be temporary. Then we can access privileged adb as long as we don't reboot the phone? Even if the ro.secure doesn't stay after reboot it won't matter as we will already have pushed su to /system/xbin/su and given it execute permissions?
 
cp dd /data/local/tmp produces the following error...

~ # cp dd /data/local/tmp
cp: can't stat 'dd': No such file or directory
~ #

you either a) don't have the directory housing dd in PATH, or

b) you don't have dd where telnet is being run from

either way, just copy to your phone's internal sdcard manually, then

cp /{path-to-internal-sdcard}/dd /data/local/tmp

***this will vary from system to system. my internal on my xoom tablet running jb is /data/media, /storage/sdcard0, and a symlink from the previous to /sdcard***
 
Correction...

I was able to run the following without moving dd to the tmp folder....

dd if=/dev/block/mmcblk0p16 of=/sdcard/valet-stock-boot.img bs=4096

Here is a copy of the output file...

https://www.dropbox.com/s/ocqkyspg926ause/valet-stock-boot.img

ive got it downloaded but itll be a lil while before i can unpack it. my crap laptop is lockednup cause im building cm for another device at the moment. always lags at libwebcore.so

ill have it back to you asap

and no you cant just edit the default.prop cause its reading it from the kernel and ifnyou change the one in the root directory it doesnt do anything cause its just a copy of whats in the ramdisk. its not actually being used and the therefore its useless. trust me ive been around the block a few times lol

we can just unpack the boot.img, then extract the default.prop from the ramdisk and echo the new settings, repack, all in the tmp folder then reboot. but this way is just as easy
 
Thanks for that. I'll need to take note of that in the future. Also, by any chance if the bootloaders are locked can we still flash it? (Can't test if the bootloader is locked atm. This computer doesn't have fastboot installed).
 
Correction...

I was able to run the following without moving dd to the tmp folder....

dd if=/dev/block/mmcblk0p16 of=/sdcard/valet-stock-boot.img bs=4096

Here is a copy of the output file...

https://www.dropbox.com/s/ocqkyspg926ause/valet-stock-boot.img


here it is: https://www.dropbox.com/s/15yzgx3ewzsnjne/valet-root-boot.img

make sure and dd it properly

dd if=/path-to-boot.img/valet-root-boot.img of=/dev/block/mmcblk0p16

**don't worry about size difference--not going to explain it, it just doesn't matter***
 
cp dd /data/local/tmp produces the following error...

~ # cp dd /data/local/tmp
cp: can't stat 'dd': No such file or directory
~ #

here it is: https://www.dropbox.com/s/15yzgx3ewzsnjne/valet-root-boot.img

make sure and dd it properly

dd if=/path-to-boot.img/valet-root-boot.img of=/dev/block/mmcblk0p16

**don't worry about size difference--not going to explain it, it just doesn't matter***

Before I try it, is that the only command I need? Then reboot. I am not a pro, lol. I do not need to use busybox?
 
Before I try it, is that the only command I need? Then reboot. I am not a pro, lol. I do not need to use busybox?

yes the only command you need.

no. no busybox. it's garbage anyway. not needed for anything, hardly ever. don't get me started with busybox nonsense lol

you will have to substitute the proper path for the new boot.img location, but other than that, yes, it's the only command you need. but you'll have to be in temp root status to do it. so make sure you're back in temp root like you were to dump it in the first place

then,

dd if=/this is the path where your new img is located/valet-root-boot.img of=/dev/block/mmcblk0p16

so if the new boot.img is on your sdcard

dd if=/sdcard/valet-root-boot.img of=/dev/block/mmcblk0p16
 
Thanks for that. I'll need to take note of that in the future. Also, by any chance if the bootloaders are locked can we still flash it? (Can't test if the bootloader is locked atm. This computer doesn't have fastboot installed).

this isn't a fastboot flashing deal for this device

don't mess with it if you don't know what you're doing.

for this zte emmc device it requires dd to write the boot.img at the moment.
 
yes the only command you need.

no. no busybox. it's garbage anyway. not needed for anything, hardly ever. don't get me started with busybox nonsense lol

you will have to substitute the proper path for the new boot.img location, but other than that, yes, it's the only command you need. but you'll have to be in temp root status to do it. so make sure you're back in temp root like you were to dump it in the first place

then,

dd if=/this is the path where your new img is located/valet-root-boot.img of=/dev/block/mmcblk0p16

CRAP, I think it is bricked. When I when I rebooted the phone it said "Verify Error"... Now it is completely dark, and nothing happens when I push the power button.

I tried pulling the battery and trying it again, but it does not even react to the power button at all...

Suggestions?!
 
CRAP, I think it is bricked. When I when I rebooted the phone it said "Verify Error"... Now it is completely dark, and nothing happens when I push the power button.

I tried pulling the battery and trying it again, but it does not even react to the power button at all...

Suggestions?!

yikes! did not see this coming.

makes me wonder if you flashed it correctly or not.

not sure what if any security the bootloader would have unless it verifies a hash of the boot partition with some preset value, which i haven't read of any doing so. although i do know some have other security features, but they are usually locked too, and have working fasboot.

if you plug your device to your pc, can you adb device it at all, or is it completely dead???
 
Back
Top Bottom