Root ZTE Zmax Pro Official Root Discussion

[GarnetSunset]

So I've been researching the AVC exploit pretty hard, and I found the exact exploitable source code from a blackberry changelog of all things.

Quote: In decoder/ih264d_utils.c in ih264d_allocate_dynamic_bufs (of libavc), there is an out-of-bounds write issue, which could lead to remote arbitrary code execution.

This is a major bug (9.3 in the CVE severity rankings), and now we have an entry point. Out of bounds writing isn't too complex, and if we can get this rolling, we can do a pretty simple, mass exploit on the OS as a whole.

More quotes!


In decoder/ih264d_format_conv.c in ih264d_fmt_conv_420sp_to_420sp (of libavc), a heap buffer overflow could occur due to an unchecked num_rows in the memcpy, which could lead to remote arbitrary code execution in privileged process.

CVE #?

 

[EddyBoy2060]

Isn't there a way to slow down the cpu cycling and find a way to make root stay after it reboots

 

[Muchwin]

I have been following this thread for a long time now and the devs here deserve a huge pat on the back for there efforts. 
I have decided to get a new phone so I can have root and I am torn between ZTE axon 7 , even though I really don't want to give ZTE any more money lol, it has root and is in my $400 price range or the LG v20 , but from what I read the updates for the phone suck. Just wondering your guys recommendations?
I really like the zmax pro, it's been a real good phone and I got it free from metro so can't complain. I just want a phone I can root and play with. Thanks again to the devs here for trying so hard.

V20 is amazing, the audio quality is amazing and is so the camera. Root is difficult to get but not impossible.

 

[SapphireEx]

CVE #?

https://www.cvedetails.com/cve/CVE-2017-0745/

I love seeing this:

Confidentiality Impact Complete (There is total information disclosure, resulting in all system files being revealed.)
Integrity Impact Complete (There is a total compromise of system integrity. There is a complete loss of system protection, resulting in the entire system being compromised.)
Availability Impact Complete (There is a total shutdown of the affected resource. The attacker can render the resource completely unavailable.)
Access Complexity Medium (The access conditions are somewhat specialized. Some preconditions must be satistified to exploit)
Authentication Not required (Authentication is not required to exploit the vulnerability.)

 

[GarnetSunset]

https://www.cvedetails.com/cve/CVE-2017-0745/

I love seeing this:

Confidentiality Impact Complete (There is total information disclosure, resulting in all system files being revealed.)
Integrity Impact Complete (There is a total compromise of system integrity. There is a complete loss of system protection, resulting in the entire system being compromised.)
Availability Impact Complete (There is a total shutdown of the affected resource. The attacker can render the resource completely unavailable.)
Access Complexity Medium (The access conditions are somewhat specialized. Some preconditions must be satistified to exploit)
Authentication Not required (Authentication is not required to exploit the vulnerability.)

Jesus this is heavy! Any POC out there? Can't find it as it looks like it was reported by a private firm.
What they changed: https://android.googlesource.com/platform/frameworks/av/+/b6ec3bbba36a3816a936f1e31984529b875b3618

 

[SapphireEx]

Jesus this is heavy! Any POC out there? Can't find it as it looks like it was reported by a private firm.
What they changed: https://android.googlesource.com/platform/frameworks/av/+/b6ec3bbba36a3816a936f1e31984529b875b3618

I haven't been able to find a PoC, but considering how almost all of the AV decoders suffer the same bug (mpeg4 being the most prevalent), it shouldn't be too difficult to replicate.
We have the exact source file names, and changelog from Google. The only thing I can see going wrong with this is if ZTE prepatched the exploit before launch, which I doubt, but it's still a possibility considering it's a private firm bounty hunting.

 

[GarnetSunset]

I haven't been able to find a PoC, but considering how almost all of the AV decoders suffer the same bug (mpeg4 being the most prevalent), it shouldn't be too difficult to replicate.
We have the exact source file names, and changelog from Google. The only thing I can see going wrong with this is if ZTE prepatched the exploit before launch, which I doubt, but it's still a possibility considering it's a private firm bounty hunting.

This feels like stagefright 2. I'm hype.

 

[SapphireEx]

This feels like stagefright 2. I'm hype.

I'll personally be testing the PoC on B08 and B14, and there are a ton of people here on B20/B21 as well. A full OS exploit could help future patches as well, as we can pull EDL firm files, and create our own firehose for people to root with as well. The possibilities are real. Hype.

 

[GarnetSunset]

I'll personally be testing the PoC on B08 and B14, and there are a ton of people here on B20/B21 as well. A full OS exploit could help future patches as well, as we can pull EDL firm files, and create our own firehose for people to root with as well. The possibilities are real. Hype.

Hype! This can be applied in many many places, so I'm excited.

 

[SapphireEx]

This place is dead i got the B21 if there is anything i could probably do is to pull the system from it just dont know where the pull ends up going or how to make it into a file

Not dead at all man. Just busy. Generally you rip the system update while it's being downloaded/ before applying it. Ripping it after you install is impossible unless your particular phone just forgot to delete the update file after flashing.

 

[SapphireEx]

Alright, so I'm rendering a test video now. The official code I'm attempting to exploit is

video->nTotalMB = video->width / MB_SIZE * video->height / MB_SIZE

Which really is a terrible implementation, as a zero height video could play havoc with this.
I have blender set up to continuously pipe out 0 height animations, but with +1 horiz count pixels per run. Let's see if anything happens eh?

*Edit Well VLC freaked out on my computer, but it plays it just fine on Android. Gonna need to change something.
This really bothers me

            video->displayWidth = (tmpvar + 1) << 2;
            video->width = (video->displayWidth + 15) & -16;

Attempting to overflow. Video width is 65545, with a 100 height. Gotta make the decoder panic some how.
Nothing. Reduced frame time to 3 frames, locked horiz at 65536 and vert is increased to 150. Size is increasing exponentially.

*Edit 2
VLC hangs for a decent period attempting to render AVCHD M2TS. May need to increase the size once more. Blender is limiting my total resolution though. Current video size is 144mb for AVI RAW test render (Plays fine), but the 260kb AVCHD video hangs between frames.

Switching to hardware decoder mediacodec shows no change. Testing IOMX. No change. Testing software only render. Render times reduced, no hanging on AVCHD. Forcing full hardware decoding causes another 50-100ms frame time.

*Edit 3
Built in Video Player refuses to run the AVI video. May be a missing codec.
Built in Video Player refuses to even list the AVCHD video.

*Edit 4
Gallery refuses to list the AVCHD video
Google Photos can't play the AVI
Forcing Photos to play the AVCHD results in a standard play
Forcing Video Player to play AVCHD results in a "Can't play this video." error. May be a missing codec.

Will attempt to render a 2 frame, 65536x65536 video soon. Pretty sure it's going to be too large to actually fit though.

Will convert to pure AVC soon.

*Edit 5
Ahahaaaaaaa.

Megapixels: 4295 MP (4,294,967,296 pixels)
Aspect ratio: 1
RAW size of 1 frame (Bayer masked): 6.44 GB (4295 MP x 12 bits)
Uncompressed RGB 8-bit frame: 12.9 GB (4295 MP x 24 bits)
Uncompressed RGB 16-bit frame: 25.8 GB (4295 MP x 48 bits)

 

[Y314K]

Alright, so I'm rendering a test video now. The official code I'm attempting to exploit is

*Edit 5

<br> Ahahaaaaaaa.

<br>

<div style='margin: 1em auto' title='Code'>

<ol class='text' style='font-family:monospace;'>

  <li style='font-weight: normal; vertical-align:top;'>

   <div style='font: normal normal 1em/1.2em monospace; margin:0; padding:0; background:none; vertical-align:top;'>

    Megapixels: 4295 MP (4,294,967,296 pixels)

   </div></li>

  <li style='font-weight: normal; vertical-align:top;'>

   <div style='font: normal normal 1em/1.2em monospace; margin:0; padding:0; background:none; vertical-align:top;'>

    Aspect ratio: 1

   </div></li>

  <li style='font-weight: normal; vertical-align:top;'>

   <div style='font: normal normal 1em/1.2em monospace; margin:0; padding:0; background:none; vertical-align:top;'>

    RAW size of 1 frame (Bayer masked): 6.44 GB (4295 MP x 12 bits)

   </div></li>

  <li style='font-weight: normal; vertical-align:top;'>

   <div style='font: normal normal 1em/1.2em monospace; margin:0; padding:0; background:none; vertical-align:top;'>

    Uncompressed RGB 8-bit frame: 12.9 GB (4295 MP x 24 bits)

   </div></li>

  <li style='font-weight: bold; vertical-align:top;'>

   <div style='font: normal normal 1em/1.2em monospace; margin:0; padding:0; background:none; vertical-align:top;'>

    Uncompressed RGB 16-bit frame: 25.8 GB (4295 MP x 48 bits)

   </div></li>

</ol>

</div>

Really like Edit 5. Can't wait for the next updates. Better then preseason football. Can this CVE also or simultaneously target the locked bootloader ? Or make it irrelevant. I hope.
In the back of my mind. It seems the B21 update might of come out of nowhere probably because of this CVE. At least that is my gut feeling.
Keep up the great work.

 

[SapphireEx]

Really like Edit 5...  Can't wait for the next updates.  Better then preseason football.  Can this CVE also or simultaneously target the locked bootloader ?  Or make it irrelevant.  I hope.
In the back of my mind.  It seems the B21 update might of come out of nowhere probably because of this CVE.  At least that is my gut feeling.
Keep up the great work.

It really depends. That is similar to getting admin access on Windows to remove the BIOS password. The best thing we could do is create legitimate MBNs and just straight flash our own bootloader, completely ignoring the locked state, but if for some reason Android has bootloader access then we will remove the lock from inside the OS.

 

[SapphireEx]

Seems I'm missing something rather basic. While VLC hangs trying to render the video, that's all it does. I may need to analyze the code some more.

 

[GarnetSunset]

Seems I'm missing something rather basic. While VLC hangs trying to render the video, that's all it does. I may need to analyze the code some more.

Excellent work though. Any POC would be bonkers and would land you on the map. Can you hmu with what you've got so far? I'd be interested to apply this on other devices as well. (Credit to you of course, quote me on that.)

 

[SapphireEx]

Excellent work though. Any POC would be bonkers and would land you on the map. Can you hmu with what you've got so far? I'd be interested to apply this on other devices as well. (Credit to you of course, quote me on that.)

It's really nothing special, just a standard AVCHD video I rendered in Blender. There's no coding or anything in it, just testing if I could cause a panic in the module.

If you want to make it yourself, download Blender (it's free), go over to render properties, set the desired resolution (Blender caps out at 65536x65536), select "animation" instead of render, set the output folder to whatever, then render it. Remember to select "frame start" to 0 or 1, and frame end to something manageable like 5. It takes about 2 minutes on a Ryzen 1700 OC'd to 4ghz. Then just convert your output to AVC or AVCHD. The frame lag was caused via a resolution of 65536x100, and *x150 caused greater frame lag.

I would post the video link itself, but I'm currently at work for the next 8 hours.

*Edit I don't need credit man. The community gets the credit here.

 

[GarnetSunset]

It's really nothing special, just a standard AVCHD video I rendered in Blender. There's no coding or anything in it, just testing if I could cause a panic in the module.

If you want to make it yourself, download Blender (it's free), go over to render properties, set the desired resolution (Blender caps out at 65536x65536), select "animation" instead of render, set the output folder to whatever, then render it. Remember to select "frame start" to 0 or 1, and frame end to something manageable like 5. It takes about 2 minutes on a Ryzen 1700 OC'd to 4ghz. Then just convert your output to AVC or AVCHD. The frame lag was caused via a resolution of 65536x100, and *x150 caused greater frame lag.

I would post the video link itself, but I'm currently at work for the next 8 hours.

*Edit I don't need credit man. The community gets the credit here.

Ryzen R7 1700 for life!!
Thanks man, I'll give it a shot. Was gonna say, getting any type of exec this early would be nutty.

 

[SapphireEx]

Ryzen R7 1700 for life!!
Thanks man, I'll give it a shot. Was gonna say, getting any type of exec this early would be nutty.

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.

 

[Craniosis]

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?

 

[SapphireEx]

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.

 

[GarnetSunset]

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?

 

[SapphireEx]

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.

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.

 

[GarnetSunset]

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.

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?

 

[SapphireEx]

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.

 

[GarnetSunset]

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.