Root ZTE Zmax Pro Official Root Discussion

[Moxlon69]

Does anyone have this app on there phone it just downloaded it's self it says it's from ZTE but All the reviews from ZTE devices below say it's malware that can't be deleted https://play.google.com/store/apps/details?id=com.zte.zdm

Havent checked the forum in a while, life and other obvious reasons. I'd assume this is not a legit ZTE app, it's not on my T-Mo 0B13 variant. I have seen this (and several similar apps) around, never trusted them.

Dan

 

[Ethorbit]

So if anyone is still working on rooting this phone, could you share your progress?
Thread is dead.

Remember that time when I said don't get your hopes up?
...

 

[biledigger]

So if anyone is still working on rooting this phone, could you share your progress?
Thread is dead.

Remember that time when I said don't get your hopes up?
...

The people that are currently working on a method or project for such a thing as root would more than likely not reply to you due to the fact you have said there will pretty much never be a root for this device. Yet you still hang around in this root thread for the device you said would never be rooted? You sound like you were the worker from ZTE who tried to make this phone root proof and is waiting until someone finally discovers a method that works. So who are you with and why are you here? Are you with the general users who want root? Or are you a ZTE employee who is scared someone will find a root method to your product?

 

[biledigger]

Havent checked the forum in a while, life and other obvious reasons. I'd assume this is not a legit ZTE app, it's not on my T-Mo 0B13 variant. I have seen this (and several similar apps) around, never trusted them.

Dan

Open the app up yourself using a root explorer and read the manifest. This app is what is triggered to check and download the firmware updates to your device.

 

[Greysworld007]

Havent checked the forum in a while, life and other obvious reasons. I'd assume this is not a legit ZTE app, it's not on my T-Mo 0B13 variant. I have seen this (and several similar apps) around, never trusted them.

Dan

there is a service or cert here that it gives sha and md5 hashes on called "com.zte.zdm" and com.zte.zdmdaemon" that look very interesting or even the system update file "com.update.zde" or "com.android.shell", "sample.authenticator.service", "secprotect" etc.etc...


This program gives:

Key type
created
subject
issuer
sha1
sha256

signing certificate options, generate pin, and the best part it gives you the option to upload these files to virustotal to get very very detailed info on these files. The virustotal info gives a ton of info like the "strings" in the files and everything (taken from the old thread ) by @EliiphasLevi7414

 

[Brandonleee1996]

Will this help us any found this post from chainfire. Im sorry if i was wrong. Just thought it may or may not work it was worth sharing. It was posted 5/3/17 by chainfire https://forum.xda-developers.com/an...signing-boot-images-android-verified-t3600606

 

[JIMMYHENDRIX]

there is a service or cert here that it gives sha and md5 hashes on called "com.zte.zdm" and com.zte.zdmdaemon" that look very interesting or even the system update file "com.update.zde" or "com.android.shell", "sample.authenticator.service", "secprotect" etc.etc...


This program gives:

Key type
created
subject
issuer
sha1
sha256

signing certificate options, generate pin, and the best part it gives you the option to upload these files to virustotal to get very very detailed info on these files. The virustotal info gives a ton of info like the "strings" in the files and everything (taken from the old thread ) by @EliiphasLevi7414

Great find

 

[Brandonleee1996]

LINK...
https://forum.xda-developers.com/an...signing-boot-images-android-verified-t3600606


COPY AND PASTE of Post from chainfire on xda


Various Android devices support Android Verified Boot (AVB). A part of this is more commonly known as dm-verity, which verifies system (and vendor) partition integrity. AVB can however also verify boot images, and stock firmwares generally include signed boot images. Of course this does not mean that all signed boot images are using AVB, many OEMs have their own signature verification scheme.

Note: AOSP is moving towards the use of avbtool (taken from Brillo), the following is the old way for signing boot images.

Bootloaders might or might not accept unsigned boot images, and might or might not accept boot images signed with our own keys (rather than the OEM's keys). This depends on the device, bootloader version, and bootloader unlock state.

For example, with the bootloader unlocked, the Google Pixel (and XL) devices accepted unsigned boot images up to (but not including) the May 2017 release. From the May 2017 release onwards, the boot images must be signed if flashed (booted works without), but may be signed with your own key rather than the OEM's.

Note: The situation changes when you re-lock the bootloader. I have not tested this, but documentation implies that (one of) the keys used in the current boot image must be used for future flashes until it is unlocked again.

Generating custom signing keys

The following openssl commands generate all the keys we need. Execute them line-by-line rather than copying the whole block, as you will be asked for input.

Code:

# private key openssl genrsa -f4 -out verifiedboot.pem 2048 openssl pkcs8 -in verifiedboot.pem -topk8 -outform DER -out verifiedboot.pk8 -nocrypt # public key openssl req -new -x509 -sha256 -key verifiedboot.pem -out verifiedboot.x509.pem openssl x509 -outform DER -in verifiedboot.x509.pem -out verifiedboot.x509.der

For future signings, you do not need the .pem files, and they can safely be deleted once the .pk8 and .der files are generated. In AOSP's implementation, they were never even written to disk in the first place.

Security-wise, documentation states it is advisable to use a different set of keys for each device you support; though obviously this doesn't matter much if the device is running with the bootloader in unlocked state.

Signing the boot image

Download the attached BootSignature.jar file (built from AOSP sources), and sign the boot image using the keys generated above with the following commands:

Code:

java -jar BootSignature.jar /boot boot.img verifiedboot.pk8 verifiedboot.x509.der boot_signed.img java -jar BootSignature.jar -verify boot_signed.img

Instead of /boot, /recovery and other values may be used. Their use should be obvious.

From Android

Attached is also BootSignature_Android.jar, which is a version ProGuard-reduced against SDK 21 and then dexed. Provided /system is mounted as is usual on Android (on the Pixel (XL), TWRP mounts this differently by default!), it can be used like this:

Code:

dalvikvm -cp BootSignature_Android.jar com.android.verity.BootSignature /boot boot.img verifiedboot.pk8 verifiedboot.x509.der boot_signed.img dalvikvm -cp BootSignature_Android.jar com.android.verity.BootSignature -verify boot_signed.img

The base command can be extended as follows to make it able to run without any precompiled files present on the device:

Code:

/system/bin/dalvikvm -Xbootclasspath:/system/framework/core-oj.jar:/system/framework/core-libart.jar:/system/framework/conscrypt.jar:/system/framework/bouncycastle.jar -Xnodex2oat -Xnoimage-dex2oat -cp BootSignature_Android.jar com.android.verity.BootSignature ...

Flashable ZIP

Attached is also VerifiedBootSigner.zip, this is a flashable ZIP for FlashFire/TWRP/etc that signs the currently flashed boot image, if it isn't signed already. You can simply flash this after installing a SuperSU version or custom boot image or whatever that doesn't sign the boot image itself already.

I've tried to make it very portable (borrowing ample script from the SuperSU ZIP, as well as its signing keys), but I have only tested it on my Pixel XL.

Note that it does depend on Android files in the system partition, so if (aside from the unsigned boot image) your system isn't functional, the ZIP may not work either.

If the boot image is already signed when you flash the ZIP, it will offer to abort or force re-sign.

If you place custom.pk8 and custom.x509.der files inside the ZIP, these keys will be used for flashing instead of SuperSU's default keys. Additionally, /tmp/avb/custom.pk8 and /tmp/avb/custom.x509.der will override any keys from the ZIP.

There is some more documentation in the update-binary file inside the ZIP as well.

Note: If you're using TWRP's manual slot selection on the Pixel (XL), you must be using TWRP-v3.1.0-RC2 or newer, or it will not work as expected.

Todo
- test what happens when the bootloader is re-locked on multiple devices supporting AVB
- test what happens when dm-verity is kept enabled on a custom/modified boot image with a different image signature than dm-verity signature

 

[Ethorbit]

The people that are currently working on a method or project for such a thing as root would more than likely not reply to you due to the fact you have said there will pretty much never be a root for this device.

That's funny because I never once said the phone was never getting rooted.
It's almost like you made this up.

I sound like I'm a worker from ZTE? You have mistaken me for someone else for sure.

 

[SapphireEx]

That's funny because I never once said the phone was never getting rooted.
It's almost like you made this up.

I sound like I'm a worker from ZTE? You have mistaken me for someone else for sure.

Irregardless of what you said, you still take the time out of your day to tell everyone you don't think this phone can be rooted. It's not helpful at all, does not contribute to discussions, and is overall bad for moral.

Next, I've hit a wall with dm-verity. It refuses to allow any modification. I've frozen the shell to poke around, but I can't gain access to any suid, let alone anything worth while. Self signed bootloader images might be nice, but I have no way of getting the boot source, let alone signing it.

 

[Nyrixa]

While poking around in the root folder with ES File Explorer, File Viewer, Root Spy, and the root file manager in RomToolbox I've found several different things. There's the possibility of changing the buildprop, by using build prop editor. I'm not sure if it woulf take effect without having root, but your can change some of the security settings. I've also found a file called releasekey.x509.pem, and was able to export it to the user dir. It had a key file inside, not sure if it's what we need, and there was another one for Macs as well.

 

[Nyrixa]

While poking around in the root folder with ES File Explorer, File Viewer, Root Spy, and the root file manager in RomToolbox I've found several different things. There's the possibility of changing the buildprop, by using build prop editor. I'm not sure if it works take effect without having root, but your can change some of the security settings. I've also found a file called releasekey.x509.pem, and was able to export it to the user dir. It had a key file inside, not sure if it's what we need, and there was another one for Macs as well.

 

[Brandonleee1996]

Irregardless of what you said, you still take the time out of your day to tell everyone you don't think this phone can be rooted. It's not helpful at all, does not contribute to discussions, and is overall bad for moral.
Next, I've hit a wall with dm-verity. It refuses to allow any modification. I've frozen the shell to poke around, but I can't gain access to any suid, let alone anything worth while. Self signed bootloader images might be nice, but I have no way of getting the boot source, let alone signing it.

Will this help?

 

[JIMMYHENDRIX]

LINK...
https://forum.xda-developers.com/an...signing-boot-images-android-verified-t3600606


COPY AND PASTE of Post from chainfire on xda


Various Android devices support Android Verified Boot (AVB). A part of this is more commonly known as dm-verity, which verifies system (and vendor) partition integrity. AVB can however also verify boot images, and stock firmwares generally include signed boot images. Of course this does not mean that all signed boot images are using AVB, many OEMs have their own signature verification scheme.

Note: AOSP is moving towards the use of avbtool (taken from Brillo), the following is the old way for signing boot images.

Bootloaders might or might not accept unsigned boot images, and might or might not accept boot images signed with our own keys (rather than the OEM's keys). This depends on the device, bootloader version, and bootloader unlock state.

For example, with the bootloader unlocked, the Google Pixel (and XL) devices accepted unsigned boot images up to (but not including) the May 2017 release. From the May 2017 release onwards, the boot images must be signed if flashed (booted works without), but may be signed with your own key rather than the OEM's.

Note: The situation changes when you re-lock the bootloader. I have not tested this, but documentation implies that (one of) the keys used in the current boot image must be used for future flashes until it is unlocked again.

Generating custom signing keys

The following openssl commands generate all the keys we need. Execute them line-by-line rather than copying the whole block, as you will be asked for input.

Code:

# private key openssl genrsa -f4 -out verifiedboot.pem 2048 openssl pkcs8 -in verifiedboot.pem -topk8 -outform DER -out verifiedboot.pk8 -nocrypt # public key openssl req -new -x509 -sha256 -key verifiedboot.pem -out verifiedboot.x509.pem openssl x509 -outform DER -in verifiedboot.x509.pem -out verifiedboot.x509.der

For future signings, you do not need the .pem files, and they can safely be deleted once the .pk8 and .der files are generated. In AOSP's implementation, they were never even written to disk in the first place.

Security-wise, documentation states it is advisable to use a different set of keys for each device you support; though obviously this doesn't matter much if the device is running with the bootloader in unlocked state.

Signing the boot image

Download the attached BootSignature.jar file (built from AOSP sources), and sign the boot image using the keys generated above with the following commands:

Code:

java -jar BootSignature.jar /boot boot.img verifiedboot.pk8 verifiedboot.x509.der boot_signed.img java -jar BootSignature.jar -verify boot_signed.img

Instead of /boot, /recovery and other values may be used. Their use should be obvious.

From Android

Attached is also BootSignature_Android.jar, which is a version ProGuard-reduced against SDK 21 and then dexed. Provided /system is mounted as is usual on Android (on the Pixel (XL), TWRP mounts this differently by default!), it can be used like this:

Code:

dalvikvm -cp BootSignature_Android.jar com.android.verity.BootSignature /boot boot.img verifiedboot.pk8 verifiedboot.x509.der boot_signed.img dalvikvm -cp BootSignature_Android.jar com.android.verity.BootSignature -verify boot_signed.img

The base command can be extended as follows to make it able to run without any precompiled files present on the device:

Code:

/system/bin/dalvikvm -Xbootclasspath:/system/framework/core-oj.jar:/system/framework/core-libart.jar:/system/framework/conscrypt.jar:/system/framework/bouncycastle.jar -Xnodex2oat -Xnoimage-dex2oat -cp BootSignature_Android.jar com.android.verity.BootSignature ...

Flashable ZIP

Attached is also VerifiedBootSigner.zip, this is a flashable ZIP for FlashFire/TWRP/etc that signs the currently flashed boot image, if it isn't signed already. You can simply flash this after installing a SuperSU version or custom boot image or whatever that doesn't sign the boot image itself already.

I've tried to make it very portable (borrowing ample script from the SuperSU ZIP, as well as its signing keys), but I have only tested it on my Pixel XL.

Note that it does depend on Android files in the system partition, so if (aside from the unsigned boot image) your system isn't functional, the ZIP may not work either.

If the boot image is already signed when you flash the ZIP, it will offer to abort or force re-sign.

If you place custom.pk8 and custom.x509.der files inside the ZIP, these keys will be used for flashing instead of SuperSU's default keys. Additionally, /tmp/avb/custom.pk8 and /tmp/avb/custom.x509.der will override any keys from the ZIP.

There is some more documentation in the update-binary file inside the ZIP as well.

Note: If you're using TWRP's manual slot selection on the Pixel (XL), you must be using TWRP-v3.1.0-RC2 or newer, or it will not work as expected.

Todo
- test what happens when the bootloader is re-locked on multiple devices supporting AVB
- test what happens when dm-verity is kept enabled on a custom/modified boot image with a different image signature than dm-verity signature

@messi2050 hey can you try this and read up on new discoverys

 

[messi2050]

@messi2050 hey can you try this and read up on new discoverys

This would be useful if we have the signing key, also no way to flash a modified boot.img atm.

 

[Brandonleee1996]

<font color ='#9e9e9e'>Nyrixa </font>
<font color ='#9e9e9e'>While poking around in the root folder with ES File Explorer, File Viewer, Root Spy, and the root file manager in RomToolbox I've found several different things. There's the possibility of changing the buildprop, by using build prop editor. I'm not sure if it works take effect without having root, but your can change some of the security settings. I've also found a file called releasekey.x509.pem, and was able to export it to the user dir. It had a key file inside, not sure if it's what we need, and there was another one for Macs as well. </font>



@messi2050'will this help you for the keys. Just trying to help

 

[SapphireEx]

While poking around in the root folder with ES File Explorer, File Viewer, Root Spy, and the root file manager in RomToolbox I've found several different things. There's the possibility of changing the buildprop, by using build prop editor. I'm not sure if it works take effect without having root, but your can change some of the security settings. I've also found a file called releasekey.x509.pem, and was able to export it to the user dir. It had a key file inside, not sure if it's what we need, and there was another one for Macs as well.

Viewing the prop is entirely different than writing to the prop. If we could edit it, we could disable selinux and DM-Verity. Try changing and saving a value yourself

 

[SapphireEx]

<font color ='#9e9e9e'>Nyrixa </font>
<font color ='#9e9e9e'>While poking around in the root folder with ES File Explorer, File Viewer, Root Spy, and the root file manager in RomToolbox I've found several different things. There's the possibility of changing the buildprop, by using build prop editor. I'm not sure if it works take effect without having root, but your can change some of the security settings. I've also found a file called releasekey.x509.pem, and was able to export it to the user dir. It had a key file inside, not sure if it's what we need, and there was another one for Macs as well. </font>



@messi2050'will this help you for the keys. Just trying to help

If that really is the release key, there's tons of things we can do with it. We need a way to flash images though.

 

[Brandonleee1996]

If that really is the release key, there's tons of things we can do with it. We need a way to flash images though.

With the temp root can you use flashfire or flashify to pull boot?

 

[SapphireEx]

With the temp root can you use flashfire or flashify to pull boot?

It's not stable enough for that. Even if it survives a reboot, I still panic doing anything. Someone else may be able to use a more stable method.

 

[Brandonleee1996]

It's not stable enough for that. Even if it survives a reboot, I still panic doing anything. Someone else may be able to use a more stable method.

Oh ok i just wondering not trying to get on anyone's nerves

 

[SapphireEx]

Oh ok i just wondering not trying to get on anyone's nerves

It's all good. Fresh ideas may help someone down the line. My current plans of attack are Android OS exploits, ZTEs psudo download mode, and the bootloader. Messi may be working on something else, looney may be on another etc.
Someone will pick it up eventually.

 

[Nyrixa]

Viewing the prop is entirely different than writing to the prop. If we could edit it, we could disable selinux and DM-Verity. Try changing and saving a value yourself

I understand now, however it is possible?
https://forums.androidcentral.com/a...how-do-i-edit-build-prop-without-rooting.html
Or the theory is possible at least.

 

[Brandonleee1996]

It's all good. Fresh ideas may help someone down the line. My current plans of attack are Android OS exploits, ZTEs psudo download mode, and the bootloader. Messi may be working on something else, looney may be on another etc.

Someone will pick it up eventually.

I been following this thread for a long time now. No worries i can wait root.

 

[SapphireEx]

I understand now, however it is possible?
https://forums.androidcentral.com/a...how-do-i-edit-build-prop-without-rooting.html
Or the theory is possible at least.

Requires TWRP.