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

Root ZTE Zmax Pro Official Root Discussion

Status
Not open for further replies.
Got a message about a system update package for my device. Is it possible they've already patched this vulnerability before anyone's managed to exploit it?
B21 is the latest MetroPCS update, with T-Mobile updating later. You most likely received B21.

Right now, the AVC bug is considered a 0day, so the chance of ZTE patching it before the exploit was known is highly unlikely. Their techs would have had to discover it on their own, and preemptively patch it.
 
Upvote 0
I'm actually thinking about something rather sneaky I used to do in my phreaker days. Writing a script in machine code (the horrors) for this particular processor, forcing the extension to AVC, assigning the magic bit to AVC's identifier offset so Android thinks it's AVC, then letting my ROP chains go wild. It will either fail horribly, or give me a hell of a ln exploit.

I really do hate writing machine code though. Like, I would rather write an entire operating system in assembly than a single line of code in machine code.
Give it a shot. We're pulling at straws otherwise right?
 
Upvote 0
Give it a shot. We're pulling at straws otherwise right?

Not entirely. We know how the storage is calculated, and it is exploitable. For instance, a -1 video width will crash the decoder. This is due to how it initializes the variable.
Code:
video->displayWidth = (tmpvar + 1) << 2;
            video->width = (video->displayWidth + 15) & -16;
Essentially your display width (the active screen area) is over scanned by 1, while the video itself is over scanned by 15, then underscanned by 16. A -1 video width would result in a screen scan of 0, and a video scan of -2. As there is no protection against underflowing (at least I didn't see one), any negative value would really **** this script up, either outright crashing it, or storing the entire video in RAM, which via the size calculator in the script (width*mb / vert*mb) would severely overflow the size calculation into a negative number, and because negative storage is impossible, it could very well panic the kernel, and allow unsigned code to be executed.
 
Upvote 0
Not entirely. We know how the storage is calculated, and it is exploitable. For instance, a -1 video width will crash the decoder. This is due to how it initializes the variable.
Code:
video->displayWidth = (tmpvar + 1) << 2;
            video->width = (video->displayWidth + 15) & -16;
Essentially your display width (the active screen area) is over scanned by 1, while the video itself is over scanned by 15, then underscanned by 16. A -1 video width would result in a screen scan of 0, and a video scan of -2. As there is no protection against underflowing (at least I didn't see one), any negative value would really **** this script up, either outright crashing it, or storing the entire video in RAM, which via the size calculator in the script (width*mb / vert*mb) would severely overflow the size calculation into a negative number, and because negative storage is impossible, it could very well panic the kernel, and allow unsigned code to be executed.
Where do we get exec in that equation?
 
  • Like
Reactions: 5318008
Upvote 0
Where do we get exec in that equation?

It's not that equation, it's the result of manipulating that equation. Once we are able to overflow/underflow it, our code injected via the payload video can be executed as it's stored in RAM, where RWX is present, and due to the AVC decoder being a system module, anything we execute will also have the permissions of the decoder.
 
  • Like
Reactions: 5318008 and Y314K
Upvote 0
It's not that equation, it's the result of manipulating that equation. Once we are able to overflow/underflow it, our code injected via the payload video can be executed as it's stored in RAM, where RWX is present, and due to the AVC decoder being a system module, anything we execute will also have the permissions of the decoder.
Wonderful. I was trying to think of where our payload would physically sit in memory, but this is actually a better explanation.
 
  • Like
Reactions: 5318008
Upvote 0
Wonderful. I was trying to think of where our payload would physically sit in memory, but this is actually a better explanation.

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.
 
Upvote 0
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.
Let's not hesitate. I'll render a massive 2 second vid when I'm home.
 
Upvote 0
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 currently in the (!very) very very early concept stage at this point. Testing shows a lot of promise at this time though.
 
Upvote 0
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)
 
  • Like
Reactions: 5318008
Upvote 0
Status
Not open for further replies.

BEST TECH IN 2023

We've been tracking upcoming products and ranking the best tech since 2007. Thanks for trusting our opinion: we get rewarded through affiliate links that earn us a commission and we invite you to learn more about us.

Smartphones