yashsingh1/xdaforums huggingface dataset:
[ZTE Z7, Z7 Max, Z7 Mini] stayboogy:
permanent root isn't going to happen anytime some guys--when a custom recovery is flashed the bootloader won't verify the signature of the new recovery and won't let it boot, so the phone just reboots and the oe recovery is rewritten at boot time.

so, let's get some more experienced devs in on this please cause i want a permanent root to at least fix the ringer reverting to the stock one all the damn time
[ZTE Z7, Z7 Max, Z7 Mini] Rotpot09:
How do we do that? I pm'd geohot the towelroot dev here on xda to see if he would be willing to help but nothing. Not sure he is even on here anymore. We do need a dev with exploit skills or a zte dev. thanks to everybody who has been trying cuz i'm lost.[emoji1]
[ZTE Z7, Z7 Max, Z7 Mini] raven1090:
is as I said in one of my previous post is the bootloader that does not allow root not be unlocked and had tried flashing a Boot before and nothing
[ZTE Z7, Z7 Max, Z7 Mini] stayboogy:
update:

i was able to make a full raw backup of the entire emmc last night, which is just under 8gb.

i was able to view the partitions of the device and all their contents this way.

the most interesting thing that i found is the order the partitions are accessed by the bootloader which was in the last recovery log on the cache partition

there was also an encrypted keystore file on one of the other partitions but it is unfortunately unreadable.

i'm purchasing a spare device today since i just broke my screen a couple of days ago. i'm going to live restore a raw image of /system that i have made with root added since system mounted read only and see what happens. since i'll have another device i don't care if it bricks it or not. i don't suspect that it will.

i'll update later tonight.
[ZTE Z7, Z7 Max, Z7 Mini] stayboogy:
here's what i've got going on:

if a dd of the /system is made to an sdcard in the phone, the resulting image cannot be mounted under linux no matter what is tried.

if a dd of the /system is made but is nc'd through adb connection to a host pc, the resulting image can be mounted.

i have a feeling my root method is going to work just fine, i just have to get back home to my pc to do it. i have dd nc'd an image to my windows pc here at work, and mounted the image in windows just fine, i just can't add superuser and set the correct permissions in windows and have to do it from linux.

i'll update later
[ZTE Z7, Z7 Max, Z7 Mini] The_Real_Revetahw:
I just wanted to say THANK YOU ALL FOR YOUR WORK!!! And keep going.. :) I have just purchased one of these phones. Seems like a nice model, especially for the price, but SO needs ROOT access!! I have enjoyed the freedom and customisability of rooted/jailbroken access on every phone have owned. May this one be no exception! I'm not a dev or linux guy but anything i can do to help, i will! Again Thanks for your efforts!!

-Mike Frank

mikefrank@hotmail.com
[ZTE Z7, Z7 Max, Z7 Mini] stayboogy:
well,

that didn't work to get permanent root.

back to the drawing board.

i have, however, successfully frozen system apps such as dolby digital audio crap and the freeze survives reboots. i have completely disabled dolby audio and usage manager and power manager and it survives reboots--these are apps that cannot be frozen in settings. even without rw access i have at least got the crap frozen that was causing issues for me.
[ZTE Z7, Z7 Max, Z7 Mini] smaudet:
First principle of hacking - physical access is always more secure than software access. From what I can tell the ROM is supposedly 'NAND locked'. i.e. there is a physical chip that has nothing to do with linux or root which prevents any write from occurring at the level of the electrons making it to 'disk'.

Now, the temp root seems to work, however only after resetting the device, and only afaik from within Kingo Root. I was able (I think) to remove some unwanted application crap from the phone, however I was unable to su or make further modifications. Supposedly there is a way to turn off the NAND lock, and if you can get some sort of temp root then in theory you should be able to chain that and run other things (painful and slow but possible).

Being able to delete unwanted crap is a big boon in and of itself, plus the device was leaking storage somewhere, I'd like to have more control to the point where you can do things like upgrade the damn OS, play with system drivers, etc., but at a certain point its a piece of junk that not worth it...

Yeah it'd be worth it to a lot of people if there were a way to root, its a cheap device that works relatively well. Might be faster to petition that a boot unlock/root is forced to be allowed on request than to figure it out - but I'm new to the unlock scene, so I don't know how easy/hard this gets...

Just some quick thoughts, looking at the recovery logs I see something like ro.boot.authorized_kernel=true and ro.boot.bootdevice - is it possible that we could modify the recovery.img to flip these switches? i.e. require the sd card to be loaded, boot off of that with an insecure image...

Anyways, just thoughts. For what I paid I don't mind *much* that I can't fix things, all the same its unethical that they basically have bricked the devices - what happens if/when the carrier goes out of business, or the system has a critical security bug? Users have a right to be able to fix things themselves.

Cheers.
[ZTE Z7, Z7 Max, Z7 Mini] Hurrian:
How about stopping zygote, and chrooting into another Android installation on an SD card?

I don't think we'll see a bootloader exploit unlocking the eMMC regions any time soon, so that might be an interesting... thing to explore.

I'll be diving down that stream soon enough - got my SD card properly partitioned for system and data, let's see how it does.
[ZTE Z7, Z7 Max, Z7 Mini] helvinf:
Little tricky device ZTE Maven

Well, after reading a very good part of this post, I can conclude that fellows of ZTE-AT&T have done an almost impossible way-to-hack this device. BTW, thanks a lot to the great work that many of you have done to try to get a successful rooting method. I
[ZTE Z7, Z7 Max, Z7 Mini] smaudet:
Yeah I'd like to hear if that works or not. Basically I'd planned on decommissioning the device here in a bit and going for something a bit more user friendly (something with an sd card and a custom data plan, and built-in root access) - it'd be nice to not have another useless brick sitting around. I don't really care about the eMMC, once I switch I'll probably take the phone apart to poke and prod at it. Too bad its nearly impossible to remove the eMMC chip though. Where are my nano-bot workers. =/

Also a couple idiosyncrasies I noticed today while playing around (if they help anybody), /system for me is supposedly rw when I view it with es file explorer. I can see inside /sbin too. Oddly, ls /data returns Operation not allowed, and es file explorer will show me the contents of /data. Which is odd I thought, because /data is marked as rw-r--r-- ...
[ZTE Z7, Z7 Max, Z7 Mini] stayboogy:
so, yes, temp root does provide the user with a fair amount of access to the system, the ability to freeze apps completely, dd to and from other partitions, and access to nearly everything on the device. in they terminal sometimes it will say one has in fact written to the /system, however, rw access is never actually granted and the modifications only last until the phone is reboot. now, if a root app does its modifications in such a way as the data is written to /data, the mods will persist--sometimes. here's an interesting couple of screenshots to prove the point--notice these apps that say frozen are not in the app menu in settings and being "disabled" and don't show on the all apps menu, and notice several of these are apps that cannot be disabled in settings anyway and this has persisted since i did it after many a boot.

http://www.mediafire.com/view/8jcdrj65wftu3ak/Screenshot_2016-05-30-02-22-56.png

http://www.mediafire.com/view/h933opjpb758sdv/Screenshot_2016-05-30-02-22-49.png

http://www.mediafire.com/view/kul9zwnybgsbftw/Screenshot_2016-05-30-02-23-12.png

http://www.mediafire.com/view/t2ldikd8swlas4l/Screenshot_2016-05-30-02-23-19.png

http://www.mediafire.com/view/xri8thxij9btg3a/Screenshot_2016-05-30-02-23-04.png

http://www.mediafire.com/view/4gbe8pr8bqr77fx/Screenshot_2016-05-30-02-24-09.png

http://www.mediafire.com/view/askpc40ig98tgyk/Screenshot_2016-05-30-02-49-48.png

http://www.mediafire.com/view/g697z58h8d5kzup/Screenshot_2016-05-30-02-49-57.png

i have been decompiling and debugging the aboot, tz [trusted zone], and sbl1--the bootloader is locked and will not allow an unsigned image, which is a boot.img with an incorrect sha1 variant hash and a non-zte specific header. fastboot has been disabled in the aboot and sbl1, however if volume up, then volume down, then power is used to boot the phone and done at precisely the right times one can get into the bootloader. knowing the zte specific commands that are allowed however i doubt anyone knows.

i'm by no means a master at this kind of stuff, but i've worked on several devices from many oems, and i especially like zte devices. this is a killer device at such a low pricepoint that it just doesn't make sense not to root it.

if we all work together we will get this one cracked. i'm gonna try the recovery thing again, but even when i've flashed a new one the oem one gets rewritten at boot like most every device is these days.

there are several bootloader exploits out in the wild that would most likely work on this device if they were specifically crafted for it--mainly there is moto bootloader exploit that runs unsigned coded in the tz that allows the user to boot any img they want or run any specific or arbitrary code at boot time.

there seems to be a number of possibilities, but it's going to take some people who are willing to take risks and experiment and share. i've got three of these devices at the moment, one for dev, one for use, and one unopened just in case. i'll either brick all of these, or have permanent root and a recovery on at least one of them.
[ZTE Z7, Z7 Max, Z7 Mini] Hurrian:
Holy crap, that is bananas. Is the key sequence read in aboot or sbl1 (I'm guessing aboot).

I'm hoping "fastboot oem unlock" would work, given that the Developer Settings toggle doesn't spaz out when turned on.

I'm in the Philippines right now so it's not too easy to run down to Walmart and throw down another $30 if I brick it, so I'm staying away from attacking TZ and the bootloader for now.

Good news: Shutting down Android and chrooting into a /system partition (FlashFire style!) on an SD card seems to work. The stock ROM doesn't seem to like it though, so I'm gonna lower my expectations and try to start a more minimal system... like TWRP.
[ZTE Z7, Z7 Max, Z7 Mini] techadvocate:
I am willing to purchase another ZTE Maven for tinkering as the one I currently have was given to me for free, but seeing as I am very unfamiliar with most of this (the software stuff I can mostly follow but any sort of hardware modification I would need a thorough walkthrough). If anyone is interested in using me as a guinea pig please let me know and I can go grab 1 or 2 more, they are crazy cheap and Target and Walmart are both very close to me.

---------- Post added at 02:38 PM ---------- Previous post was at 02:21 PM ----------

Hurrian - can you explain this a little more in detail? Can you give a general description of how to chroot into /system of a partition on an SD card? Do you use adb with microSD already inserted in the phone?
[ZTE Z7, Z7 Max, Z7 Mini] stayboogy:
fastboot is completely disabled in the aboot--no fastboot commands will work

zte did this on purpose obviously

boot to the bootloader and try for yourself--press and hold volume up, then press and hold volume down, then press and hold power key, and keep holding all keys, the screen will stay black and will not produce the splash and the led will be solid red. this is the bootloader, although cripled. it took me a few tries to get it right and the only way i knew it could be done was through the strings output of the aboot

my thoughts are that sbl1 really is just a placeholder and doesn't do much of anything on this device. aboot and tz seem to be the things responsible for getting the device to boot. sbl1 may be what is used to boot the recovery or prevent remount of /system rw. i'm really not sure at this point honestly. zte has gone through a lot of trouble to lock this phone down...

i would love for you to explain as well how you chroot'd into a /system on the sdcard??? this could help greatly. it would be good to just edit the stock recovery.img to be insecure and debuggable and boot that extracted system layout from the sdcard--this would effectively give "adb remount" a chance to mount /system rw and hopefully install su binary
[ZTE Z7, Z7 Max, Z7 Mini] smaudet:
Cool, care to share your sources? Or your methods. I'm still in noob-land with Kingo Root :P

Sounds promising. I went out and bought a backup myself, also a cheaper 20$ model (different manufacturer), supposedly its rootable...and then I have 3 nexus devices to practice rooting on. Part of my problem is I still don't know where to go/what to look at, and what's sitting where in my way.

So yeah, anyways we have 5 brick-able devices between the two of us, surely we can get somewhere! :P I also have a logic port reader, if that'd be useful for anyone (just let me know what to hook up where and what you want).

My 20$ device is fyi a coolpad rogue (t-mobile), unlike the zte maven it definitely has a fastboot mode of some sort (reboot to bootloader works, a screen comes up), I can in fact ask it to fastboot oem unlock, and the device has the decency to say "not allowed" back. So I at least verified what everybody said about there not being a known fastboot mechanism on the zte maven. :P

Kingo Root didn't work on the coolpad rogue, tried a couple others so far, no luck, another interesting thing to note, the coolpad rogue is listed as being a 5.1.1 device, even though the box only claims 5.0, and the zte maven is only a 5.1 device. I think before I factory reset the zte maven, it was at 5.1.1 as well, and I was seeing a similar behavior in the way the root was failing i.e. the root would fail halfway through, so I hypothesize something updated in the OS to prevent whatever exploit Kingo Root was relying on.
[ZTE Z7, Z7 Max, Z7 Mini] Hurrian:
I based this technique off the one I use for booting Linux distros on Android phones without patched ramdisks/kernels:

You need to extract a whole Android root filesystem to a partition/multiple partitions on the SD card (this depends on how you want to go around things)

That means you extract the contents of boot.img to the root directory, system to.... /system, and optionally make a new, blank /data partition and assign its mount in the board fstab file in the root directory.

For example, assuming we're mounting the new root filesystem in /data/local/tmp/android:

In an ADB shell, issue the commands as root:

setprop ctl.stop media & setprop ctl.stop zygote & setprop ctl.stop surfaceflinger & stop
chroot /data/local/tmp/android/init

This halts the current Android (ZTE's stock ROM) and starts another instance of Android, booting off the SD card where the write protection the bootloader uses doesn't work.

Note that you'll have to re-root and then issue the above commands again if you power cycle your phone! That's the part that sucks about having a locked bootloader and NAND write locked /system partition...
[ZTE Z7, Z7 Max, Z7 Mini] Frameender:
I managed to get the phone's BootLoader open? tbh idk what version you guys are running compared to mine it's a ZTE Z812, but you guys are making it look like a challenge just to get to the Bootloader..

Here is a picture taken by another phone I had, everything is clear enough to read

http://s33.postimg.org/ok1bt42v3/20160531_052836.jpg

I have nothing to work off of after this though, if anyone could point me to anything it would be really nice, or if this is the same version that you guys own I will tell you how to replicate the Bootloader it isn't hard it's very similar to most

Hold power button, and Volume up after you reboot the device from the on position till it force reboots during that initial reboot then wait till you get the black screen and let go of the two buttons it will boot you into the bootloader just fine...
[ZTE Z7, Z7 Max, Z7 Mini] bndnrd321:
Uhh that is the recovery menu not the bootloader.
[ZTE Z7, Z7 Max, Z7 Mini] stayboogy:
that's recovery, not the bootloader...

---------- Post added at 09:55 AM ---------- Previous post was at 09:22 AM ----------
[ZTE Z7, Z7 Max, Z7 Mini] Frameender:
Ugh damn that's my bad I'm still new to this phone I'm not use to running anything but a Galaxy :/
[ZTE Z7, Z7 Max, Z7 Mini] stayboogy:
with this technique, since the real /system is no longer being read from or being used, would it then be possible to umount /system and then remount it or umount it and then dd a new system.img to that partition??? i have successfully rooted a dd of the oe /system but wasn't able to dd it back since /system was mounted. i'm just curious what exactly can be done from chrooting into another android system like if modifications can then be made to the actual /system since it's not actually active. i'm thinking not since it's mounted in data/local/tmp/android, but what do i know lol
[ZTE Z7, Z7 Max, Z7 Mini] smaudet:
So anyways basically the 'state of the hack' is thus far:

Kingo Root has a windows app that apparently has a working root exploit, but only for some versions of the phone.

It can't install su to /system but there is a workaround posted for running su with another app.

Hurian knows how to run su through adb, and knows how to boot off of the sd card

There is (most probably) a NAND lock, from my research on NAND locks there may be some command you can issue to the eMMC, however I don't know enough about the MMC protocol yet to say or be sure. Finding the NAND lock first would be the best course of action (or proving that one doesn't exist). A NAND lock seems consistent with programs seeing different levels of access (rw but not actually rw). Permission to read/write is not the same thing as the ability to read/write - anybody who's ever had a broken/corrupted HDD knows this.

Someone else knows a way to decompile the system.img and the boot.img

Things left to do:

* Someone should decompile the Kingo Root app to find out what root mechanism it is using. I can think of at least three ways to do this:

- Decompile the windows binary (don't know how to do, maybe someone who knows decompilers really well can do this)

- Decompile the apk (should be easy if its just java)

- Decompile the transmission stream between Kingo Root/the app on the phone it installs - us Wireshark or something similar to capture the stream it sends.

* Someone should probably explain what they're doing with decompiling the images they found on the phone - a road map and/or picture would be nice. Especially because a second pair of eyes vs just one would be very helpful.

* Someone should be researching NAND locks, esp. eMMC.

* Someone should be taking the phone apart, looking up part numbers online and seeing if they can glean any information, esp. with regards to anything that works like a switch, chip operation, etc.
[ZTE Z7, Z7 Max, Z7 Mini] stayboogy:
(everthying here assumes pseudo-root with kingoroot)

(1) here's the strings pulled from aboot, sbl1, and tz. this is just basic decompile using "strings aboot.img" in a linux box or using strings.exe on windows, and using dd to pull the images from /dev/block/bootdevice/by-name/aboot et al.

i've done other decompiling as well, but i honestly don't know what i'm doing and it requires hex rays with arm plugins and other things that aren't legally free or easy to use and i by no means am a master at--jcase and other devs in his range are more familiar with these types of tools...

(2) full nand dump can be performed by doing thus:

TERMINAL ONE [LINUX BOX] *can be done in windows as long as nc.exe is used

adb forward tcp:5555 tcp:5555

adb shell

su

busybox nc -l -p 5555 -e dd if=/dev/block/platform/7824900.sdhci/mmcblk0

TERMINAL TWO [LINUX BOX]*can be done in windows as long as nc.exe is used

adb forward tcp:5555 tcp:5555

nc 127.0.0.1 5555 | pv -i 0.5 > maven-nand.dd

(3) the possibility of there actually being two chips on the board

or

the possibility of two nearly identical copies of the filesystem present on one chip are quite high in my opinion at this point, and here is why i think this:

there appear to be two seperate solid state devices listed in /dev

(a) /dev/block/bootdevice/

(b)/dev/block/platform/7824900.sdhci

i suppose i need to dump each one individually and start the slow process of decompiling them and seeing if they differ

(4) as far as kingoroot goes, all the files it downloads and uses are in the C:\Users\XXXX\AppData\Local\Kingosoft\King Root folder but they are either in Chinese or binary format and not easily deciphered. if i knew of other tools to use to see exactly what was going on i would...

i need more info on how to boot an extracted filesystem from the sdcard and that will help me tremendously cause i've got some tricks up my sleeve from some reading today that indicate some wonderful bypassing of locked bootloaders from such methods, just no clear directions on how it is done--booting a ramdisk or rom from sdcard that is...
[ZTE Z7, Z7 Max, Z7 Mini] Hurrian:
Getting around the NAND lock would mean jack squat if you can't disable dm-verity in the kernel... and thus disable signature checking for the kernel... and thus pwn the bootloader.

I'm definitely not anywhere close to the magical voodoo of bootloader pwnage, so I chose to go the long way around and chroot into another Android installation on an sd card.

Oh, and if calling "chroot" doesn't work for you, use a statically linked copy of busybox.
[ZTE Z7, Z7 Max, Z7 Mini] LenAsh:
Thread cleaned.

"Trolling" is a one-way road to Goodbyeville - you know who you are and if you continue to make claims you cannot substantiate...
[ZTE Z7, Z7 Max, Z7 Mini] LgnVcell:
Okay, if this was a big deal, there'd be crap-tons of threads talking about this so it could be an obvious thing. But this phone isn't very popular.

So just to be sure, we've ruled out ALL the availible, actual, compatible rooters?

Also, if you saw this guys' post:

He was able to access the recovery, and I can access it too. So maybe, even though this is probably stupid, can try and root from recovery? As I said, probably stupid, but it might be possible? :D :o
[ZTE Z7, Z7 Max, Z7 Mini] LgnVcell:
So I tried to get chase to help, but apparently, he has no time. So screw that.. :eek: :crying:
[ZTE Z7, Z7 Max, Z7 Mini] LgnVcell:
Just a notice

Okay, so before when I tried to access the shell by doing:

adb shell

It always kicked me out.

Now, I tried rooting twice with KingoRoot,, and now I can access the shell? Another stupid thing, or is it?

(Guys, I'm n00b at this. Don't think I'm a pro, because I'm not.)
[ZTE Z7, Z7 Max, Z7 Mini] stayboogy:
okay guys, here's something interesting i've found along the lines of my original root idea of exploiting a zte app to gain root privileges.

app6939 which is what runs as "user root" when the zte backup and restore app is working uses a zte specific busybox that is located in /data/data/com.zte.backup.mmi/files/busybox and it contains a su applet and sulogin applet. here's our way of gaining temp root in a way that we can duplicate at will without kingoroot.

calling all other dev minded who've looked into this--join me in working this out.
[ZTE Z7, Z7 Max, Z7 Mini] LgnVcell:
Want me to find some people, maybe devs to help? :rolleyes: :confused: