The only thing I see being a pain in the ass will be truncation of the payload. Overflows by nature are chaotic, and it could truncate the payload anywhere. We are going to have a lot of 'off by one' errors before we get the location right, but after that we should be golden.
The only thing I see being a pain in the ass will be truncation of the payload. Overflows by nature are chaotic, and it could truncate the payload anywhere. We are going to have a lot of 'off by one' errors before we get the location right, but after that we should be golden.
I've read every single post on this thread just hoping to find root and on these last threads I see that we are so close to find a working exploit have you tested it yet?
I've read every single post on this thread just hoping to find root and on these last threads I see that we are so close to find a working exploit have you tested it yet?
I've read every single post on this thread just hoping to find root and on these last threads I see that we are so close to find a working exploit have you tested it yet?
I'm rooting for you guys (pun intended). I'm using the BLADE Z MAX and 7.1 is pretty cool. But, the BLADE isn't really worth the $160 to upgrade away from the PRO (in my opinion). If you can get root, staying with the PRO would be the best choice.
I'm rooting for you guys (pun intended). I'm using the BLADE Z MAX and 7.1 is pretty cool. But, the BLADE isn't really worth the $160 to upgrade away from the PRO (in my opinion). If you can get root, staying with the PRO would be the best choice.
I'm still waiting for Ubuntu Touch lol. That's really the only reason I want to root this phone; Just to flash Linux/GNU. I'm sure once we are done with the Z981, we will move on to other ZTE protected devices (I know I will at least)
I'm still waiting for Ubuntu Touch lol. That's really the only reason I want to root this phone; Just to flash Linux/GNU. I'm sure once we are done with the Z981, we will move on to other ZTE protected devices (I know I will at least)
Rendered a 2 second video with an absurd res. Totally failed. Phone couldn't handle a 28k video for 2 seconds. I think thats a native decoder fail... possibly. Gonna try setting the height to 0 and working back from there. Dunno where to hide the payload and call it, but, I'll give it a shot.
Rendered a 2 second video with an absurd res. Totally failed. Phone couldn't handle a 28k video for 2 seconds. I think thats a native decoder fail... possibly. Gonna try setting the height to 0 and working back from there. Dunno where to hide the payload and call it, but, I'll give it a shot.
Thank you Sapphire for not giving up <3. I have a bunch of parts for z981 that I have enough to be able to slap together to do some testing if you need.
Tested and crashed the AVC decoder. Here's a list of things we can do to narrow down the exact entry point, then post crash exploiting.
1. Reduce number of frames one by one until we don't get a crash or apphang, then increase by one. Test. If it crashes, we found the magic frame (this arbitrary frame number could be potentially pointless if it's just the raw total number of frames crashing it, and not a specific frame point). Then overwriting the image data of that frame with our custom script. We should probably start with something simple like opening a custom error dialogue or playing a sound.
1a. This only applies if we have high level language execution.
Create a script that disables/ removes DM-verity, while also giving RWX to all users for /system/ and /dev/. While this is a security issue, it'll be used temporarily to gather the resources needed to do a public, safe rooting method.
2. Track the CPU/RAM usage of the decoder during the video playback, and find when exactly it crashes (if it crashes in a non chaotic way), then lower the file size until we can reliably crash the decoder without a gigabyte+ video needed. Then, do 1/1a.
3. Check if file content actually matters. If actual video frames don't matter, overwrite the entire file with 0s, then replace whatever bit of code at the front of the data with our custom code, then do 1/1a. We may need to preserve content headers and magic bit, but that's about it.
4. Attempt to completely crash the kernel with a video so large the stack just stops responding. This could lead to one of two things. Either
4a. We gain complete, unprotected access to the system or
4b. Kernel just panics and restarts the main thread, leaving us back to 1/2/3.
My Z981 might've actually died. Lol. Was testing it last night. And after about 2 seconds of waiting. The phone was blisteringly hot and then shut down. Hasn't come on since. End of my journey.
Tested and crashed the AVC decoder. Here's a list of things we can do to narrow down the exact entry point, then post crash exploiting.
1. Reduce number of frames one by one until we don't get a crash or apphang, then increase by one. Test. If it crashes, we found the magic frame (this arbitrary frame number could be potentially pointless if it's just the raw total number of frames crashing it, and not a specific frame point). Then overwriting the image data of that frame with our custom script. We should probably start with something simple like opening a custom error dialogue or playing a sound.
Hello all.
I see that i was mentioned a wile back.
Not to be off topic but im working on rooting the zte blade x max.
This is on topic because what is going to work to root one current ZTE device should be similar to other current ZTE Devices.
Please don't bash me if you disagree with anything i suggest.
My approach is much different and largely based off of my experience cracking the VZW Bootloader on HTC Desire 526 HTC Desire 626 and HTC Desire 530. Took 6 months but i was successful.
The newer android M and N as we know requires system less root. Much that applied to earlier rooting of lp no longer applies.
Im leaning to believe that convention root methods just aren't going to work.
After researching how the bootloader is unlocked for the axon 7.
Downloading axon 7 firmware i found that the unlock is very similar to HTC but much easier.
ZTE provided a Fastboot.img that enables fastboot and allows oem unlock.
My guess is that the fastboot image they provided was originally made for zte to service the device.
My thought is if we can make the same changes in the fastboot (FBOP) partition (Set the flags to allow fastboot and oem-unlock) we can flash FBOP using miflash.
Who knows if we are lucky the axon 7 fastboot.img might work on our devices with small modifications.
So as said Miflash can flash partitions as long as we have the firehose. We can get the firehose cause ZTE uses default qualcomm hoses. Unsigned.
The axon 7 is unbrickable using MIFlash and the firehose from Zuk Z2.
We know that the firehose is not Vendor specific cause it works for the ZUK 2 and the Axon 7 and theese are from different Vendors.
I would bet our devices have the same security scheme as the axon 7.
Another interesting fact is that there is a axon7tool that can backup axon7 partitions and GPT with the phone in edl mode.
This tool has to use the same protocol as MiFlash.
Maybe saraha ??
I know these protocols are very well documented so it is very possible someone can write a linux tool using these protocols to backup the partitions from our devices. And write them too.
This is the difference from the unlockable fastboot and stock fastboot for the axon 7.
After researching how the bootloader is unlocked for the axon 7.
Downloading axon 7 firmware i found that the unlock is very similar to HTC but much easier.
ZTE provided a Fastboot.img that enables fastboot and allows oem unlock.
My guess is that the fastboot image they provided was originally made for zte to service the device.
My thought is if we can make the same changes in the fastboot (FBOP) partition (Set the flags to allow fastboot and oem-unlock) we can flash FBOP using miflash.
Who knows if we are lucky the axon 7 fastboot.img might work on our devices with small modifications.
So as said Miflash can flash partitions as long as we have the firehose. We can get the firehose cause ZTE uses default qualcomm hoses. Unsigned.
We know that the firehose is not Vendor specific cause it works for the ZUK 2 and the Axon 7 and theese are from different Vendors.
I would bet our devices have the same security scheme as the axon 7.
Another interesting fact is that there is a axon7tool that can backup axon7 partitions and GPT with the phone in edl mode.
This tool has to use the same protocol as MiFlash.
Maybe saraha ??
I know these protocols are very well documented so it is very possible someone can write a linux tool using these protocols to backup the partitions from our devices. And write them too.
This is the difference from the unlockable fastboot and stock fastboot for the axon 7.
So where im at is.
#1 We know how to write partitions using MIflash.
#2 We know flags in FBOP partition allow the bootloder to be unlocked.
What we are missing.
#3 we need a copy of the GPT from our devices.
#4 we need a copy of all partitions from our devices.
Conclusion.
If we can develop a tool like axon7tool that uses the same protocol as miflash we can get these things.
Hi friend. Welcome to our hell. The Axon is a phone with an unlockable bootloader and is massively different from the Zmax pro. We don't have root on the ZMax so we can't grab partitions.
#1 We do, but, our access to FB and all of that is extremely limited.
#2 The partition is probably different from the Axon 7, which is a device aimed toward devs.
#3 Yes we do. We need root.
#4 Yes. We need root.
One thing you could help with, since you seem knowledgeable, is to look into the CVE Sapphire linked a couple pages ago. He's got a couple tests going, and so did I before my phone died last night.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
End of my journey.
