• 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.
Has anyone checked if the phone in either EDL or dfu mode gets detected by adb? If someone wants try doing these commands in normal adb environment than if nothing works try in EDL and dfu mode if adb can communicate
-adb shell
-su
-mount -o remount,rw /system /system edit: it could only be one /system and if it's not working because of the location type mount without the rest of it and find a target location to replace /system with
Than we could try to just push SU to the phone manually.
 
Last edited:
And to everyone who's stepped up and happily given their time, energy, and ideas to the group here and joined in to lend a hand thank you, without all you I'd have a busted PC and not even have tried the EDL mode yet and who knows how far or close Wed be then. We're close everyone! Can you smell the custom freedom right around the corner? We just gotta keep up the hard work and above all else work together and well have more leaps and bounds just like yesterday and be rooted in no time
 
paragontrix said:
Has anyone checked if the phone in either EDL or dfu mode gets detected by adb? If someone wants try doing these commands in normal adb environment than if nothing works try in EDL and dfu mode if adb can communicate
-adb shell
-su
-mount -o remount,rw /system /system edit: it could only be one /system and if it's not working because of the location type mount without the rest of it and find a target location to replace /system with
Than we could try to just push SU to the phone manually.
Click to expand...
I actually cant do much because i cant risk breaking my device so testing off the wall things im shying away from. Although in dfu it knows their is a device but i get the error "is the device online?”
 
You don't have to worry about bricking or anything. So long as you enter the commands I specify you'll be 100% safe. And if the command mount -o remount,rw /system /system works when you're done enter the command again except ro instead of rw. Just in case it sticks you wanna put it back to read only
 
Elix update your adb and fastboot installation, turn USB debugging off and back on, make sure OEM unlock is checked, and issue adb kill-server followed with adb start-server and see if that changes the offline issue
 
From what I've skimmed, we have a copy of the stock image, and have the ability to flash the firmware via EDL.. Does EDL verify the image being flashed or does it just flash what it's given? If it just does it without checking, could we not just add the SuperSU binaries to the stock image and flash it so the phone would have it? I have heard that you can flash custom recoveries if your phone is rooted, so we could still port TWRP that way... This is all assuming we could just add SuperSU to the stock image without EDL bitching at us lol.
I mean it IS emergency download mode.... It better take whatever we throw at it. And much like Elixx, I want to help and test, but I cannot afford to brick this phone. I broke my Nexus 5 and that's why I have this phone now, I cannot afford to spend another 120.
 
I understand. Everything I tell you guys to try is perfectly safe, and once we get to the point of flashing unknown things that's when I'll give you the warning. Right now we're just sending commands in different environments trying to get access to system as read write so someone can push su straight to the phone with adb. And no we don't have a stock firmware that's something else that's hindering progress. If we had a stock firmware yes we could do a few things to get root at that point, and I found a way to flash image files and stuff through dfu mode about 20 minutes ago so that won't give any objection to what we flash it's like Odin in a way. And like you said we have EDL mode as well to try. So many possibilities since yesterday but we need just one thing for them all lol
 
Anubis something you can do to help is if you know how to cook up kernels and stuff using Android SDK get the autoroot source I posted a page back or so, and get the kernel source elix posted a link for and build an autoroot kernel for us. That's one root method we can actually move on with attempting
 
And we could flash custom recovery with totally stock phone unrooted, but just like the system we need to be the first to pull the stock recovery as well and we could port twrp or cwm to our device at that point
 
paragontrix said:
I understand. Everything I tell you guys to try is perfectly safe, and once we get to the point of flashing unknown things that's when I'll give you the warning. Right now we're just sending commands in different environments trying to get access to system as read write so someone can push su straight to the phone with adb. And no we don't have a stock firmware that's something else that's hindering progress. If we had a stock firmware yes we could do a few things to get root at that point, and I found a way to flash image files and stuff through dfu mode about 20 minutes ago so that won't give any objection to what we flash it's like Odin in a way. And like you said we have EDL mode as well to try. So many possibilities since yesterday but we need just one thing for them all lol
Click to expand...
Hey how do I get in to edl mode? I have never heard of it so im new to edl but im familiar with everything else. Also su is not found when I type the su after typing adb shell and the "mount -o remount rw /system" thing I got permission denied in ftm mode and while booted.
 
I can't help with that, sorry. Unless you want me to code it in MIPS Assembly or javascript... lmao
Is there a way to get a stock image or atleast backup the image we have? I mean, we can't write system files without SU, but can we read them? All it would take is someone to backup their phone and then modify that and flash the modified backup.
 
Idk if we are past this but I did adb pull system and this is what I got.
 

Attachments

  • Screenshot (1).png
    Screenshot (1).png
    151.7 KB · Views: 160
http://android.stackexchange.com/questions/28296/full-backup-of-non-rooted-devices
We might be on to something... ADB seems to support backups on Android 4.0+
Is this the same as a full image backup or is it only for apps and settings? We might be able to abuse ADB backup if it works similar to a nandroid or stock image backup.

mussio said:
Idk if we are past this but I did adb pull system and this is what I got.
Click to expand...
What's this? The contents of the device? Maybe paragon could do something with it.
 
anubis2048 said:
http://android.stackexchange.com/questions/28296/full-backup-of-non-rooted-devices
We might be on to something... ADB seems to support backups on Android 4.0+
Is this the same as a full image backup or is it only for apps and settings? We might be able to abuse ADB backup if it works similar to a nandroid or stock image backup.


What's this? The contents of the device? Maybe paragon could do something with it.
Click to expand...
Nah he cant, it denies permissions for some files. At least last time I did it. Its kind an incomplete backup. I can try again to do an adb pull though
 
Elix9000 said:
Nah he cant, it denies permissions for some files. At least last time I did it. Its kind an incomplete backup. I can try again to do an adb pull though
Click to expand...

When you restore an image from EDL or some other tool, is the image that is already on the device deleted? Could we just have a blank image with the SuperSU binaries in the right places and flash that? Or do you need a full image? So many questions about how the flashing works. Does EDL even verify the images, if not, what rules does it follow? Wipe device then flash? Wipe device optional and can be ignored? I'd assume that it wipes by default and EDL would verify the images, but who knows. We won't until some poor soul gives it a try.

*Edit*
Obviously it's possible to flash new content into an existing image using a custom recovery so we do know this infact is a thing that happens(like flashing gapps), but does the EDL wipe the internal storage first? If it doesn't then we could just patch in SuperSu by using a specially crafted image file. Hell, isn't that what the regular SuperSu.zip file does?
 
Fastboot is in there cause it's his adb/fastboot dir and pull will put it in the same location. And sadly yeah without SU working and us getting the full thing nothing we can do. SuperSU.zip is a recovery flashable zip file that runs commands to put SuperSU.apk and the binaries into the correct system locations
 
Alright guys got something to do. This whole time were trying to get fastboot to work yet assuming there is non cause it won't detect our device anywhere right? I thought I had the right drivers find but obviously not. So we're gonna delete the drivers for our phone so we get a clean start. Install the drivers I've provided right here, and this pack for our phone has quite a few different ones so I feel it's this or nothing lol. So once adb is detected go ahead and adb reboot bootloader. Since we have nothing to flash I guess a good way to test is once adb goes away try fastboot devices at phones boot splash screen cause that'll be when the bootloader is communicating. If it still sticks at waiting for device repeat steps but have device manager open and when android debug bridge disappears watch for the fastboot one to pop up. If there's the warning triangle for driver issues you right click it and go update it and let you browse comp and manually choose the driver C:\Users\*youraccount"\AppData\Local\Android\sdk\es\google\usb_driver or wherever you installed Android SDK, if no SDK install it, and choose android_winusb.inf and update.
 
Is this useful??? if not my apologies just trying to help
found a folder named zte_security and inside was this...
 

Attachments

  • Screenshot (6).png
    Screenshot (6).png
    122.6 KB · Views: 177
With marshmallow and nougat SuperSU and its binaries don't go in /system. Instead, the boot image is modified and a new mount point is created at /su and that is where the binaries go. The SuperSU app is then placed in /data/app the same place where it would go if you installed it from the play store. The only way to have SuperSU and its binaries installed to /system is to flash a custom kernel before flashing SuperSU.

As far as cf auto root goes, Chainfire only builds it for devices that use fastboot or Odin, and for those of you who don't know how it works, it flashes a custom recovery to your device then uses that recovery to flash SuperSU and then reinstalls the stock recovery.

Adb pull /system will only give you a partial dump of system files because there are a lot of libs and binaries that can't be copied without root privileges. As for pulling partition images from the device like a boot.img, recovery.img, or system.img that cannot be done without root access.
 
Status
Not open for further replies.
Back
Top Bottom