Root ZTE Zmax Pro Official Root Discussion

SapphireEx said:

Can you post proof? Not even sure B03 is a thing.

Click to expand...

GarnetSunset said:

AVC Encoder started to fire up, then shat itself. Don't have the logs on hand.

Click to expand...

SapphireEx said:

Sounds like a decent panic. We'll need to fetch the logcats to verify though.

Click to expand...

SapphireEx said:

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.

Click to expand...

Bigcountry907 said:

Hello all.
MY approach to getting Root.

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.

Click to expand...

Bigcountry907 said:

My thinking is this.
Adding the correct flags to the fbop un criples the fastboot commands and opens up ability to unlock the bootloader using fastboot oem_unlock.

The partition schemes will always be different. Thats why i need GPT from the devices.

The one thing that is the same is we are dealing with qualcomm chipsets.
And my approach would leverage the sahara protocol.

Everything is done in edl mode so no root is required.
What is required is to write the sahara commands to backup partitions.

As far as the fbop partition being on our devices.
It is.
If you boot to recovery and view the recovery log it list all the partition names.
cat /proc/partitions shows us all the mmcblk0 labels.

The partition is there.
We have the oem unlock switch in developer options.
Looking at the axon7 diff of the fbop partition i have a strong intuition that the allow oem unlock switch changes 1 byte from 0 to 1.

This is the diff and the byte swap

< 00001000 01 00 00 00 78 56 34 12 00 00 00 00 01 00 00 00 |....xV4.........|
---
> 00001000 00 00 00 00 78 56 34 12 00 00 00 00 00 00

If i could copy the fbop partition from my device i could verify this.

A very good explanation of the secure boot process.
http://webcache.googleusercontent.c...omm-Secure-Boot.htm+&cd=2&hl=en&ct=clnk&gl=us

Cached Webpage.

Spoiler

Notes about Qualcomm Secure Boot and Motorola High Assurance Boot (hab):

This is what I've gathered about the Moto G's MSM8226 boot process (and this actually applies to many other devices based on MSM8x60, MSM8x26 and etc.):
Part 1: Qualcomm Secure Boot:

In a normal boot process, the PBL (Primary Boot Loader, stored in the device ROM) loads and authenticates SBL1 (SBL stands for Secondary Boot Loader), stored in a partition on the device's internal storage.
If the secondary boot loader or its authentication has failed, the PBL will go to HS-USB Emergency Download mode (a.k.a. Emergency boot, Emergency host download, EhostDL).
The PBL authenticates the image being downloaded via EHostDL (e.g. programmer.mbn) using the same mechanism used to authenticate sbl1.
For this reason, programmer.mbn and sbl1 share the same binary format: Header (80 bytes), followed by the executable bytecode, followed by a signature and certificates.
The header contains the following fields (little-endian):
0x00 - CodeWord ("D1 DC 4B 84")
0x04 - Magic ("34 10 D7 73")
0x08 - Image type (0x0D = eHostDL image, 0x15 = SBL1, "5A 43 0B 7D" means the actual header is ahead (commonly at 0x2800), and "FF FF FF FF")
0x14 - Header size (I think, it's always 0x50)
0x18 - Loading address (Execution start address)
0x1C - Body size (Code + Signature + Certificate store size, the size qboot expects to get following the header)
0x20 - Code size
0x24 - Signature address
0x28 - Signature length (256 bytes)
0x2C - Certificate store address (after loading the image [without the header] to device memory using Loading address)
0x30 - Certificate store length
So if you want to load the file in IDA Pro, you should save the file without the header, and use the 'Loading address' specified in the header you removed.
And if you want to analyze the certificate store, open the file (the one you saved without the header), and start copying from [Certificate address - Loading address].
The certificate format is BER encoding of ASN.1 (.cer), and the certificates are written in sequence.


While there are some execptions (e.g. Lenovo S856, Samsung SHV-E160L), most devices are configured to authenticate the secondary executable.
The process goes like this:
1. Certificate store validation: the lowest level X.509 certificate is verified using the standard X.509 procedure (See Note 1), each certificate is verified this way up to, but not including, the root certificate.
2. Root certificate validation: the entire certificate is hashed using SHA256 and compared with OEM_PK_HASH (which is blown into the QFuses of the device).
3. The image signature is RSA-decrypted (PKCS #1 v1.5) using the 2048-bit public key stored in the lowest-level certificate, this is the hash the image is expected to have.
4. The image is hashed using an HMAC (see Note 2, Note 3) and compared against the expected image hash.
Note 1: X.509 certificate validation: the signature is RSA-decrypted using the public key of the parent certificate and compared with the hash of the tbsCertificate.
Note 2: The 'Subject' field in the lowest-level certificate instructs which hash function should be used for the image HMAC, possible entries:
"OU = 07 0000 SHA1"
"OU = 07 0001 SHA256"
If no such entry exists, the PBL will use SHA1.
Note 3: This is how the image HMAC is calculated:
SHA1(o_key_pad || SHA1(i_key_pad || SHA1(header || code))
or, if the hash function is SHA256:
SHA256(o_key_pad || SHA256(i_key_pad || SHA256(header || code))
MSM8x26 / MSM8x60 / MSM8974 (e.g. Moto G / Nexus 4 / Nexus 5):
o_key_pad = o_key XOR {0x5C, 0x5C, 0x5C, 0x5C, 0x5C, 0x5C, 0x5C, 0x5C}
i_key_pad = i_key XOR {0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36}
(o_key = HW_ID of the device and i_key = SW_ID, both are 8 bytes long)
(HW_ID & SW_ID are stored in the QFPROM in reversed byte order, o_key & i_key use the original byte order)
Other devices have different o_key_pad and i_key_pad construction and length (can be either 8 or 64 bytes).
Note 4: I was able to read the OEM_PK_HASH from my Moto G using the Sahara protocol using CMD=3 (qboot uses CMD=1 to read the serial number and CMD=2 to read the HW_ID).
Note 5: The target HW_ID & SW_ID for a given image can be found in the 'Subject' field in the lowest-level certificate.
Note 6: I have written a small C# program that validates the executable against the HW_ID, SW_ID and OEM_PK_HASH: Download the software, Download the source code.


References:
8960_Boot_Architecture.pdf
Secure boot and servicing
Samsung SHV-E160L PBL Dump


Relevant information:
Why is a 2048-bit public RSA key represented by 540 hexadecimal characters in X.509 Certificates?
mbnimg-parser
SBL header information
Part 2: Motorola High Assurance Boot (hab):

I belive there's a Qualcomm reference implementation to secure additional steps in the booting process, and OEMs can customize it if they wishes, Motorola's secondary boot loader implements its own trusted boot mechanism (called hab) to load additional executable images,



The header of those third-level executable images contains the following fields (little-endian):
0x00 - Type (0x05 = APPSBL)
0x04 - Version (0x00000003)
0x0C - Loading address
0x10 - Body size (code + signature + certificate store size)
0x14 - Code size (the size of the executable without the header / signature / certificate store)
0x18 - Signature address
0x1C - Signature length
0x20 - Certificate store address
0x24 - Certificate store length


The format is not specific to Motorola, however, Motorola uses a proprietary certificate store / signature structure,
Because the image does not contain a standard BER encoding of ASN.1, the 'Certificate store length' field will be set to 0, and both the certificate store and the signature will be stored in the signature section.
In addition, The last 4 bytes of the code segment are the version number of the image, trying to flash an image with a lower number will result in "downgraded security version" and "preflash validation failed".
The structure starts with 'B4 01' followed by a 2-byte integer that points to the first certificate in the chain (relative to the structure start).
The number of the certificates in the structure is not stored in the structure, and has to be known by the reader, there are X certificates (the first is the top-level certificate) followed by X-1 file signatures (each has the same length as the modulus of the matching certificate).
The certificate structure contains the following fields:
Certificate Identifier ('01 0A')
String Identifier ('01 00 04')
Certificate Name Length (1 byte)
Certificate Name
Unknown1 (4 bytes)
Unknown2 (4 bytes)
String Identifier ('01 00 04')
Issuer Name Length (1 byte)
Issuer Name
Byte fields identifier ('02 00')
Exponent Length (2 bytes)
Exponent
Modulus Length (2 bytes)
Modulus
Certificate Signature Length (2 bytes)
Certificate Signature
The image authentication process goes like this:
1. The top-level certificate is authenticated using the SRK (super root key, see Note 7):
- The certificate signature is RSA-decrypted (PKCS #1 v1.5) using the SRK modulus and exponent.
- The certificate (excluding the signature) is hashed using the function specified in the PKCS prefix and the hash is compared to the hash specified in the decrypted signature.
2. Each child certificate is authenticated using the top-level certificate.
3. The file signature is RSA-decrypted (PKCS #1 v1.5) using the matching certificate.
4. The relevant portion of the file is hashed using the function specified in the PKCS prefix (part of the decrypted signature) and the hash is compared to the hash specified in the decrypted signature.
Note 7: Some phone models (e.g. the XT1032) embed the SRK in SBL1.


References:
Reverse Engineering Android's Aboot


Relevant information:
aboot header information
Please contact me if you have something to correct / add: tal.aloni.il@gmail.com

Tal Aloni

Click to expand...

GarnetSunset said:

&lt;div&gt;

&lt;b&gt;Spoiler:Bigcountry907, post: 7602214, member: 1897004&lt;/b&gt;

&lt;p&gt;My thinking is this.&lt;br&gt; Adding the correct flags to the fbop un criples the fastboot commands and opens up ability to unlock the bootloader using fastboot oem_unlock.&lt;br&gt; &lt;br&gt; The partition schemes will always be different. Thats why i need GPT from the devices.&lt;br&gt; &lt;br&gt; The one thing that is the same is we are dealing with qualcomm chipsets.&lt;br&gt; And my approach would leverage the sahara protocol.&lt;br&gt; &lt;br&gt; Everything is done in edl mode so no root is required.&lt;br&gt; What is required is to write the sahara commands to backup partitions.&lt;br&gt; &lt;br&gt; As far as the fbop partition being on our devices.&lt;br&gt; It is.&lt;br&gt; If you boot to recovery and view the recovery log it list all the partition names.&lt;br&gt; cat /proc/partitions shows us all the mmcblk0 labels.&lt;br&gt; &lt;br&gt; The partition is there.&lt;br&gt; We have the oem unlock switch in developer options.&lt;br&gt; Looking at the axon7 diff of the fbop partition i have a strong intuition that the allow oem unlock switch changes 1 byte from 0 to 1.&lt;br&gt; &lt;br&gt; This is the diff and the byte swap&lt;br&gt; &lt;br&gt; &amp;lt; 00001000 &lt;span style='color: #0000ff'&gt;01&lt;/span&gt; 00 00 00 78 56 34 12 00 00 00 00 01 00 00 00 |....xV4.........|&lt;br&gt; ---&lt;br&gt; &amp;gt; 00001000 &lt;span style='color: #5900b3'&gt;00&lt;/span&gt; 00 00 00 78 56 34 12 00 00 00 00 00 00&lt;br&gt; &lt;br&gt; If i could copy the fbop partition from my device i could verify this.&lt;br&gt; &lt;br&gt; A very good explanation of the secure boot process.&lt;br&gt; &lt;a href='http://webcache.googleusercontent.c...2&amp;amp;hl=en&amp;amp;ct=clnk&amp;amp;gl=us' target='_blank' class='externalLink' rel='nofollow'&gt;http://webcache.googleusercontent.c...2&amp;amp;hl=en&amp;amp;ct=clnk&amp;amp;gl=us&lt;/a&gt;&lt;br&gt; &lt;br&gt; Cached Webpage.&lt;br&gt; &lt;/p&gt;

&lt;div&gt;

&nbsp; &lt;b&gt;Spoiler&lt;/b&gt;

&lt;/div&gt;

&lt;p&gt;&lt;/p&gt;

&lt;/div&gt;

&lt;br&gt; Best of luck then. I don't have one of these devices anymore, so I can't even test the thing

&lt;div&gt;

&lt;b&gt;Spoiler:2001698&lt;/b&gt;

&lt;p&gt;@SapphireEx&lt;/p&gt;

&lt;/div&gt; and I were looking into, so, unless anyone has a throwaway device, I'm limited to saying, good luck.

&lt;div&gt;

&lt;b&gt;Spoiler:1983077&lt;/b&gt;

&lt;p&gt;@messi2050&lt;/p&gt;

&lt;/div&gt;, got any info for my man here?

Click to expand...

SapphireEx said:

My debug unit is still on B08, so I can test anything that comes from this.

Click to expand...

GarnetSunset said:

Thanks man, best I can do is ask the community if they have any leftovers, damaged or not, anything is super helpful. Hell... I did most of my Nexus 7 Bypass stuff on an OTG mouse because the touch screen died. ;P

Click to expand...

SapphireEx said:

At least we have 2 separate avenues of approach now. Getting fastboot enabled would be a massive boon as we could sideload a recovery over the native boot and do whatever we want.

I'll still be going after the AVC method, but now that it seems that it can cause a total SoC failure I gotta be more careful now.

Hopefully @Bigcountry907 can make something of their path, and I'm sure @messi2050 would be interested in it as well.

Click to expand...

GarnetSunset said:

I wouldn't worry about it too much, I think I just killed the balling on the SOC because I was in an 85 degree room and pushing the little bastard to its limit.

&lt;br&gt;

&lt;br&gt; Good luck to everyone, I'll continue to test on other devices of mine, with similar SOCs so that I get something comparable.

Click to expand...

SapphireEx said:

If you're feeling brave and wanting to spend some money, I could use some assistance in rooting the Insignia Flex 8 (ns-p08a7100). This cheap little tablet is my absolute bane.
Since your phone is effectively dead, you could try and hardmod it for true NAND access. That would help bigcountry with the GPT tables he needs.

Click to expand...

GarnetSunset said:

Best of luck then. I don't have one of these devices anymore, so I can't even test the thing @SapphireEx and I were looking into, so, unless anyone has a throwaway device, I'm limited to saying, good luck. @messi2050, got any info for my man here?

Click to expand...

Bigcountry907 said:

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.

Ok enough of that and please dont bash me.

-------------------------------------------------------------------------------------------------

MY approach to getting Root.

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.

http://www.androidbrick.com/zte-axon-7-unbrick-guide-qd-loader-9008-edl/#
http://www.androidbrick.com/zuk-z2-z2-pro-qpst-qfil-miflash-rom-flashing-guide/

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.

Spoiler

bigcountry907@bigcountry907-NV55S:~$ hexdump -C -v /home/bigcountry907/Desktop/ZTE/FB-UL-EDL/A2017U_FASTBOOT_UNLOCK_EDL/fastboot.img > /home/bigcountry907/Desktop/ZTE/FB-UL-EDL/fbunlck.txt
bigcountry907@bigcountry907-NV55S:~$ diff home/bigcountry907/Desktop/ZTE/FB-UL-EDL/fbunlck.txt /home/bigcountry907/Desktop/ZTE/stock/fbstock.txt
diff: home/bigcountry907/Desktop/ZTE/FB-UL-EDL/fbunlck.txt: No such file or directory
bigcountry907@bigcountry907-NV55S:~$ hexdump -C -v /home/bigcountry907/Desktop/ZTE/FB-UL-EDL/A2017U_FASTBOOT_UNLOCK_EDL/fastboot.img > /home/bigcountry907/Desktop/ZTE/FB-UL-EDL/fbunlck.txt
bigcountry907@bigcountry907-NV55S:~$ diff /home/bigcountry907/Desktop/ZTE/FB-UL-EDL/fbunlck.txt /home/bigcountry907/Desktop/ZTE/stock/fbstock.txt
257c257
< 00001000 01 00 00 00 78 56 34 12 00 00 00 00 01 00 00 00 |....xV4.........|
---
> 00001000 00 00 00 00 78 56 34 12 00 00 00 00 00 00 00 00 |....xV4.........|
579,595c579,595
< 00002420 62 6f 6f 74 02 02 20 00 04 82 01 00 04 e0 4f a3 |boot.. .......O.|
< 00002430 b8 c0 79 df 98 9a ce 8b 47 ed f6 23 61 e8 3e 4d |..y.....G..#a.>M|
< 00002440 7a 43 fc 4b d4 39 60 c5 5a a6 96 ea c0 4d e2 52 |zC.K.9`.Z....M.R|
< 00002450 27 3e b6 d0 21 72 72 c8 59 03 44 90 ff 4a 86 3b |'>..!rr.Y.D..J.;|
< 00002460 29 2c 16 7a 04 2b 36 07 6f 8f 04 8e 35 7c f2 9f |),.z.+6.o...5|..|
< 00002470 cc 29 e5 0b 74 30 e9 0c ec cd 23 4b 19 84 c7 d1 |.)..t0....#K....|
< 00002480 f7 46 9b 7d dc 8b 6b bb 01 d3 f0 0a ab 96 ca 7e |.F.}..k........~|
< 00002490 a2 6e 91 6b d9 38 d6 d6 2e 4f 50 3e 2d 17 55 e3 |.n.k.8...OP>-.U.|
< 000024a0 e5 50 e4 1f dc 03 26 9e e9 22 19 dc 60 e1 0b a0 |.P....&.."..`...|
< 000024b0 b5 06 25 bd e4 08 24 4f 7b dd 42 29 82 55 06 84 |..%...$O{.B).U..|
< 000024c0 a1 5f d7 c1 99 3f 83 30 5d 10 59 5e 9d 2a 31 3f |._...?.0].Y^.*1?|
< 000024d0 f9 87 54 55 1e 82 40 68 5b c8 e4 18 98 80 d1 ec |..TU..@h[.......|
< 000024e0 df d7 01 d1 ec a5 a2 e4 c1 86 76 63 e0 82 13 35 |..........vc...5|
< 000024f0 61 30 63 d7 cd e8 21 33 73 e9 c4 93 ad 65 68 77 |a0c...!3s....ehw|
< 00002500 3e eb 3e 90 8a bb 8b 07 1b 26 ff d5 0d 37 a4 6c |>.>......&...7.l|
< 00002510 ec c6 69 30 dd 22 1b 9f 69 79 47 69 22 ba 9e c8 |..i0."..iyGi"...|
< 00002520 0c 23 96 f8 cf 66 74 74 11 98 d6 e4 |.#...ftt....|
---
> 00002420 62 6f 6f 74 02 02 20 00 04 82 01 00 a8 e0 dd 69 |boot.. ........i|
> 00002430 5b b2 47 12 bf 74 41 7a 00 37 a0 b8 10 15 d4 4e |[.G..tAz.7.....N|
> 00002440 a6 59 74 9b 7d a4 df 95 eb 3f 1a 29 1c 60 23 7c |.Yt.}....?.).`#||
> 00002450 91 37 2a 07 d3 e9 45 17 ac ac ab a9 ba b4 42 70 |.7*...E.......Bp|
> 00002460 46 5f 67 22 f7 37 1f de 46 f9 67 44 74 d7 26 42 |F_g".7..F.gDt.&B|
> 00002470 49 9c e8 ee 98 78 89 2b b2 1e c3 58 a8 d2 3a 7f |I....x.+...X..:.|
> 00002480 39 7d 22 09 c6 01 c5 0f 95 65 57 1e af 79 d9 d6 |9}"......eW..y..|
> 00002490 8d 99 84 4f 24 ff 55 b2 b0 20 07 00 39 e6 9a 27 |...O$.U.. ..9..'|
> 000024a0 a0 bc 97 dd 27 7d f2 a2 88 b6 b5 53 4a ba 7a 8e |....'}.....SJ.z.|
> 000024b0 65 98 f6 ef 4d 7e 2e 91 01 66 35 9e e1 da 15 c4 |e...M~...f5.....|
> 000024c0 fe a4 d2 26 a1 99 88 a3 55 2f ac 65 71 f8 5f 86 |...&....U/.eq._.|
> 000024d0 a7 79 f8 b5 61 b5 da 2c 7b 89 39 3b ff 45 a3 7f |.y..a..,{.9;.E..|
> 000024e0 dc 92 d5 4e 8b df 68 c0 e9 43 18 7b 60 5a 03 60 |...N..h..C.{`Z.`|
> 000024f0 18 da 96 84 e7 97 a7 09 a9 1a 2d b6 5b d3 d2 f6 |..........-.[...|
> 00002500 c8 33 a2 8f ef 32 5e 6a 45 39 66 b5 a6 a4 35 0f |.3...2^jE9f...5.|
> 00002510 03 0c 9d 57 79 28 43 09 9a 3e 7b 01 8c 6e 66 b2 |...Wy(C..>{..nf.|
> 00002520 1a f3 3d 92 d1 66 91 04 4a 3e 79 69 |..=..f..J>yi|
bigcountry907@bigcountry907-NV55S:~$ hexdump -C -v /home/bigcountry907/Desktop/ZTE/Fastboot-UL/fastboot.img > /home/bigcountry907/Desktop/ZTE/Fastboot-UL/fbul2.txt
bigcountry907@bigcountry907-NV55S:~$ diff /home/bigcountry907/Desktop/ZTE/FB-UL-EDL/fbunlck.txt /home/bigcountry907/Desktop/ZTE/Fastboot-UL/fbul2.txt
bigcountry907@bigcountry907-NV55S:~$

Its not alot.
And to flash the FBOP image this is the line from the partition.xml used by MiFlash.

This is from partition.xml

Spoiler

<data><program SECTOR_SIZE_IN_BYTES="4096" file_sector_offset="0" filename="fastboot.img" label="fbop" num_partition_sectors="32" partofsingleimage="false" physical_partition_number="0" readbackverify="false" size_in_KB="128.0" sparse="false" start_byte_hex="0x321a8000" start_sector="205224"/></data>

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.
#1 we need a copy of the GPT from our devices.
#2 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.

Click to expand...

JIMMYHENDRIX said:

Yeah I just cracked my screen today what a load of shit

Click to expand...

Beany23 said:

Would this help.... http://www.zte.com.cn/mobile/uaprof/Z981.xml

Click to expand...