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

Root ZTE ZMAX Pro (Z981) root discussion

Status
Not open for further replies.
no i am a zte zmax owner that has been rooting and testing with android for quite a while i know a bit of code but thats all im just a tester with knowlage im hoping we can get root also i too sent tenfar an email for help as i will be donating soon and trying to get more devs on board
 
you need an unlocked bootloader for this to work
How do you know your bootloader is locked? The absence of a bootloader interaction? This would be the first MetroPCS device with a locked bootloader. From my knowledge of ZTE they don't typically ship a bootloader you can interact with. But the fact that it allows a root shell you all could flash the twrp and see. As far as I know you won't be bricked the bootloader only cares about the partition booting so if recovery signature didn't match it would reboot and the boot would still proceed to system and you could of course reflash the stock recovery.img again.
 
you need an unlocked bootloader for this to work
You also need to have an unlocked bootloader in order to be able to install twrp or even to just have root, so if you truly believe the bootloader is locked down then why are you here? As I've said many many times the people at ZTE don't know jack shit about whether the bootloader is locked or not. I know this first hand because they falsely told me that the bootloader was locked on the first zmax when I contacted them in the past.
 
How do you know your bootloader is locked? The absence of a bootloader interaction? This would be the first MetroPCS device with a locked bootloader. From my knowledge of ZTE they don't typically ship a bootloader you can interact with. But the fact that it allows a root shell you all could flash the twrp and see. As far as I know you won't be bricked the bootloader only cares about the partition booting so if recovery signature didn't match it would reboot and the boot would still proceed to system and you could of course reflash the stock recovery.img again.
These people are parroting misinformation spread by the customer service idiots at ZTE who don't even know what a locked bootloader is. I swear if I see one more person assume the bootloader is locked just because someone at ZTE says so I'm going to lose it.
 
Can someone give me a list of the ramdisk contents? From adb shell or terminal emulator just type ls you'll see init.rc init.qcom.rc init.target.rc etc. Screenshot however you want just include all .rc files
 
Can someone give me a list of the ramdisk contents? From adb shell or terminal emulator just type ls you'll see init.rc init.qcom.rc init.target.rc etc. Screenshot however you want just include all .rc files
here u go
shell@urd:/ $ ls
ls
acct
cache
charger
config
d
data
default.prop
dev
dsp
etc
file_contexts
firmware
fstab.ftm.qcom
fstab.qcom
init
init.carrier.rc
init.class_main.sh
init.environ.rc
init.fingerprint.goodix_fp.rc
init.fingerprint.synafp.rc
init.ftm.rc
init.mdm.sh
init.offcharge.rc
init.qcom.bms.sh
init.qcom.class_core.sh
init.qcom.early_boot.sh
init.qcom.factory.rc
init.qcom.ftm.rc
init.qcom.rc
init.qcom.sh
init.qcom.ssr.sh
init.qcom.syspart_fixup.sh
init.qcom.usb.rc
init.qcom.usb.sh
init.rc
init.recovery.qcom.rc
init.target.ftm.rc
init.target.rc
init.trace.rc
init.usb.configfs.rc
init.usb.rc
init.vendor.rc
init.zygote32.rc
init.zygote64_32.rc
mnt
oem
persist
proc
property_contexts
res
root
sbin
sdcard
seapp_contexts
selinux_version
sepolicy
service_contexts
storage
sys
system
tombstones
ueventd.qcom.rc
ueventd.rc
vendor
verity_key
 
here u go
shell@urd:/ $ ls
ls
acct
cache
charger
config
d
data
default.prop
dev
dsp
etc
file_contexts
firmware
fstab.ftm.qcom
fstab.qcom
init
init.carrier.rc
init.class_main.sh
init.environ.rc
init.fingerprint.goodix_fp.rc
init.fingerprint.synafp.rc
init.ftm.rc
init.mdm.sh
init.offcharge.rc
init.qcom.bms.sh
init.qcom.class_core.sh
init.qcom.early_boot.sh
init.qcom.factory.rc
init.qcom.ftm.rc
init.qcom.rc
init.qcom.sh
init.qcom.ssr.sh
init.qcom.syspart_fixup.sh
init.qcom.usb.rc
init.qcom.usb.sh
init.rc
init.recovery.qcom.rc
init.target.ftm.rc
init.target.rc
init.trace.rc
init.usb.configfs.rc
init.usb.rc
init.vendor.rc
init.zygote32.rc
init.zygote64_32.rc
mnt
oem
persist
proc
property_contexts
res
root
sbin
sdcard
seapp_contexts
selinux_version
sepolicy
service_contexts
storage
sys
system
tombstones
ueventd.qcom.rc
ueventd.rc
vendor
verity_key
Just like the Axon 7 init.qcom.ftm.rc is not used we can override this file with dirtcow and set the device permissive I'm testing this now I had to recompile the exploit to work for my device. I'll let you all know if it works. I'm unrooted as well for testing.
 
Last edited:
lol which one is the used init
init.ftm or init.qcom.ftm or init.qcom ?
I ended up using init.fingerprint.goodix_fp.rc because the file is shorter. The thing about that is you all have to have the goodix fp sensor. Can you cat init.fingerprint.goodix_fp.rc and getprop ro.build.fingerprint_hw to ensure we have the same sensor.
 
I ended up using init.fingerprint.goodix_fp.rc because the file is shorter. The thing about that is you all have to have the goodix fp sensor. Can you cat init.fingerprint.goodix_fp.rc and getprop ro.build.fingerprint_hw to ensure we have the same sensor.
i got permission denied for the first cmd and goodix_fp for the second cmd
 
does anyone understand Chinese or at least code in mandarin or at least Cantonese, or Taiwanese, etc,,,, just give us a shot...

need some help here ... the regular adb connection protocols are useless....

I can read Chinese and speak Mandarin reasonably well now. However I don't have this phone, and have never done anything root wise with a ZTE device. If you want a screen-shot or something translated, I can do that.
 
The same on the zmax pro , i tried with init.qcom.rc and it didn't work on reboot it's still enforcing...
You haven't encountered the issue where writing the fill puts the wrong data inside? I finally caught why my image didn't boot the beginning of the file is wrote incorrectly and so is the last bytes

http://pastebin.com/EjJ0sdUU

Notice the beginning data and how it cuts off adb in the end if you can succeed here with yours with abd insecure you technically have root and can dd I have no idea why he didn't think of this instead of going through the trouble of trying to disable selinux in the recompiled image.
 
Wait a second....are you'll using the dirty cow exploit.......even if you could get root, I am just worried what else it could be done to it....like we all are currently vulnerable......praise the all mighty root but at what price....and i seen that team regular photo i some other phone forms maybe from xda but i don't remember.
 
I'm patient as can be. I'm by know means a dev but some think that if a root hasn't been discovered this far into the release that it's not going to happen. I've been rooted or jailbroke since 2008 when the 2nd iPhone first came out. Than went to the Android world in 2014. It is killing me not being able to do what I want with the phone

This time is different, since the DirtyCow exploit is public, I'm pretty sure KingRoot is going to come up with some exploit to get root using that and then we can use our rooted phone to push the recovery image and then flash the recovery and then a proper root. All we have to do is wait.
 
I'm patient as can be. I'm by know means a dev but some think that if a root hasn't been discovered this far into the release that it's not going to happen. I've been rooted or jailbroke since 2008 when the 2nd iPhone first came out. Than went to the Android world in 2014. It is killing me not being able to do what I want with the phone
There really isn't any way of knowing that for sure. It took several months for the first zmax to get root.
 
Downloaded new kingroot from XDA root got to 60%. Didn't try again but before it would only go to 19 or 20% maybe they will figure it out. I have the z988 wich is basically the same phone.
 
Status
Not open for further replies.
Back
Top Bottom