[GUIDE] Unbrick MOTO Z Play (not working yet)

[Fire21]

Yeah, you cannot safely downgrade and use OTA updates, especially with downgrading from 7.1.1 to 6.0 - the downgrade appears to work okay, but you still have your newer bootloader from Nougat. As such, when you try to apply a Marshmallow OTA - or Nougat OTA that's much older than your bootloader - you'll likely have the OTA corrupt your newer bootloader and get a hard brick.

Luckily you were able to fix it, just bear in mind that if you do downgrade, please do not use OTA updates. Only use stock firmware to update.

Ok thank you for the information. I learned it the hard way I think

 

[Sb_SharK]

C:\Users\Shiva Giri\Desktop\blankflash xda\blankflash>.\qboot.exe blank-flash
Motorola qboot utility version 3.40
[ -0.000] Opening device: \\.\COM4
[ 0.001] Detecting device
[ 0.004] ...cpu.id = 70 (0x46)
[ 0.004] ...cpu.sn = 3381611295 (0xc98f4b1f)
[ 0.004] Opening singleimage
[ 0.005] Loading package
[ 0.009] ...filename = singleimage.pkg.xml
[ 0.011] Loading programmer
[ 0.012] ...filename = programmer.mbn
[ 0.013] Sending programmer
[ 0.226] Handling things over to programmer
[ 0.228] Identifying CPU version
[ 0.234] Waiting for firehose to get ready
[ 60.540] Waiting for firehose to get ready
[120.656] ...MSM8953 unknown
[120.656] Determining target secure state
[120.663] Waiting for firehose to get ready
[180.766] ...secure = no
[180.812] Waiting for firehose to get ready
[240.919] Configuring device...
[240.926] Waiting for firehose to get ready
[301.043] Waiting for firehose to get ready
[361.158] Waiting for firehose to get ready
[421.925] ReadFile() failed, GetLastError()=0
[421.929] ReadFile() failed, GetLastError()=0
[421.930] ReadFile() failed, GetLastError()=0
[422.937] Waiting for firehose to get ready
[483.058] ERROR: do_package()->do_recipe()->do_configure()->get_fh()->no response
[483.059] Check qboot_log.txt for more details
[483.062] Total time: 483.064s
FAILED: qb_flash_singleimage()->do_package()->do_recipe()->do_configure()->get_fh()->no response

C:\Users\Shiva Giri\Desktop\blankflash xda\blankflash>pause
Press any key to continue . . .

I get the same error, did you solve it? :crying::crying:

 

[giri.shiva]

Nope, I just gave my device to service centre and they changed the motherboard

 

[pedro1520]

Can someone make these links available to me ??? I can not access them appears unau

​

work in progress! (not working yet)
Current status: does not work (but should!), exact reason unknown (to me).
If you managed to "brick" your MOTO Z Play it enters a fail-safe mode as a last resort provided by the chipset manufacturer (Qualcomm). There are packages out there called "blank-flash" that use this mode to restore a proper bootloader that in turn re-enables the use of the fastboot method to write the other flash files and restore full operation - provided the personalized partitions are still present and in good health (or you have a backup of them at hand).

Look at this thread and download the Nougat file. It contains "blank-flash" files. These "should work" but they don't (any more). As I don't have a Z Play, I cannot research the matter myself and instructing helpful others via email exchange is ... complicated.

The thing with failing updates/flash packages is that they usually fail because they do not allow downgrading - even if they allow downgrading of some sort (e.g. OS), they may limit downgrading the second stage bootloader, the signed GPT (partitioning table) etc. As I don't know if and what's the case with the Z Play, I just assumed that *if* it works, it may require the most recent files.

If you run the blank-flash files (qboot) with --debug=2 option you see that after the programmer code is sent to the phone it doesn't send a valid / expected response and ultimately causes the process to fail.

There are many programmer files out there. Most do not work, because they need to be digitally signed with the proper keys. Some are signed with Quallcomm-keys, some with Lenovo-, Motorola- and other with test-keys. And then again, they have to fit with the qboot program that's sending the data to be flashed.

A blankflash archive consists of the following files:

• qboot, blank-flash.sh ; Linux
• qboot.exe, qboot.dll, blank-flash.bat ; Windows
• singleimage.bin ; Both

There are different versions of the qboot program. I've found the versions 2.4, 3.37 and 3.40.
The file "singleimage.bin" contains the flash files and directions crammed into a single file, thus the name:

1. cmnlib.mbn
2. cmnlib64.mbn
3. devcfg.mbn
4. emmc_appsboot.mbn
5. gpt_main0.bin
6. index.xml
7. keymaster.mbn
8. programmer.mbn
9. prov.mbn
10. rpm.mbn
11. sbl1.mbn
12. singleimage.default.xml
13. singleimage.pkg.xml
14. tz.mbn

The XML files contain the instructions (the 'recipe'):
index.xml:

<?xml version="1.0"?>
<index>
  <board id="70" name="MSM8953" storage.type="eMMC"/>
  <package compatible="cpu.name:MSM8953 protocol:qboot" filename="singleimage.pkg.xml"/>
</index>

singleimage.pkg.xml:

<?xml version="1.0"?>
<package>
  <programmer filename="programmer.mbn"/>
  <recipe filename="singleimage.default.xml"/> 
</package>

singleimage.default.xml:

<?xml version="1.0" ?> 
<recipe>
  <configure MemoryName="eMMC"/>

  <!-- Flash GPT -->
  <print what="Flashing GPT..."/>
  <flash partition="partition:0" filename="gpt_main0.bin" verbose="true"/>

  <print what="Re-initializing storage..."/>
  <storage operation="reinit"/>

  <!-- Flash bootloader -->
  <print what="Flashing bootloader..."/>
  <flash partition="aboot"     verbose="true" filename="emmc_appsboot.mbn"/>
  <flash partition="rpm"       verbose="true" filename="rpm.mbn"/>
  <flash partition="tz"        verbose="true" filename="tz.mbn"/>
  <flash partition="devcfg"    verbose="true" filename="devcfg.mbn"/>
  <flash partition="cmnlib"    verbose="true" filename="cmnlib.mbn"/>
  <flash partition="cmnlib64"  verbose="true" filename="cmnlib64.mbn"/>
  <flash partition="keymaster" verbose="true" filename="keymaster.mbn"/>
  <flash partition="prov"      verbose="true" filename="prov.mbn"/>
  <flash partition="sbl1"      verbose="true" filename="sbl1.mbn"/>
</recipe>

These files usually do not need to be modified.
programmer.mbn is the flash application that is sent to the phone.

I've compiled the following package, including all the qboot executables:
http://frickelbude.net/moto/blankflash[addison][D61DC5C7][25.211.10][1.07][2017-04-13].zip
D61DC5C7: crc32-checksum of programmer.mbn file (original, motorola signed) (find others here)
25.211.10: firmare package origin of the bootloader files
1.07: bootloader version
2017-04-13: time stamp of bootloader file

This didn't work with recently bricked Z Play phones as some testers confirmed. We also tried all the different programmer executables linked above just to be sure but no luck.

Outlook: you may want to try out Qualcomms QFIL (part of QPST package) (look e.g. at the download section of androidbrick).
However, that requires some handywork - you need to build some XML files, provide the proper programmer file etc. Maybe grab a firmware package e.g. for a Xiaomi phone that has all these files and try and deduce a proper layout for your Z play... and hope, any of the programmer files will actually run and communicate with the pc end.

(Usually the blank-flash files operate in 'sahara' mode/protocol and send the programmer.mbn to the phone. Then it waits for a positive response from the phone to enter 'firehose' mode in order to send all the flash data...)

/update 2017-06-10 a
I've created a blank-flash package based on the files @lozada81 linked below:
bootloader files extracted from: OTA tester Android 7.1.1 BRASIL patch june - Blur_Version.26.1.22.addison.retail.en.US.zip
blank-flash package: http://frickelbude.net/moto/blankflash[addison][D61DC5C7][26.1.22][C1.12][2017-05-22].zip
(Bootloader version: C1.12, GPT layout version: 0x000A)

/update 2017-06-10 b
Same package as above, but with a different programmer.mbn, taken from an older blank-flash package that came with an Android 6.0.1 package @lozada81 linked below.
http://frickelbude.net/moto/blankflash[addison][C0A0D740][26.1.22][C1.12][2017-05-22].zip
Well, it either fails with the infamous io-error or it finally works.. please test & report back!

Can someone make these links available to me ??? I can not access them appears unauthorized

 

[usuario do Z play]

I need of the blankflash for version 8.0.0, My cell phone was at the soaktest 3.

 

[carolnap]

I need of the blankflash for version 8.0.0, My cell phone was at the soaktest 3.

sorry, still nobody have...

 

[jrgomes91]

Boa tarde meus amigos, eu também preciso do blankflash para a versão 8.0.0, meu celular estava no soaktest 2. abraços

 

[usuario do Z play]

Any news about blankflash for oreo 8.0.0?

 

[BRbrazil]

work in progress! (not working yet)
Current status: does not work (but should!), exact reason unknown (to me).
If you managed to "brick" your MOTO Z Play it enters a fail-safe mode as a last resort provided by the chipset manufacturer (Qualcomm). There are packages out there called "blank-flash" that use this mode to restore a proper bootloader that in turn re-enables the use of the fastboot method to write the other flash files and restore full operation - provided the personalized partitions are still present and in good health (or you have a backup of them at hand).

Look at this thread and download the Nougat file. It contains "blank-flash" files. These "should work" but they don't (any more). As I don't have a Z Play, I cannot research the matter myself and instructing helpful others via email exchange is ... complicated.

The thing with failing updates/flash packages is that they usually fail because they do not allow downgrading - even if they allow downgrading of some sort (e.g. OS), they may limit downgrading the second stage bootloader, the signed GPT (partitioning table) etc. As I don't know if and what's the case with the Z Play, I just assumed that *if* it works, it may require the most recent files.

If you run the blank-flash files (qboot) with --debug=2 option you see that after the programmer code is sent to the phone it doesn't send a valid / expected response and ultimately causes the process to fail.

There are many programmer files out there. Most do not work, because they need to be digitally signed with the proper keys. Some are signed with Quallcomm-keys, some with Lenovo-, Motorola- and other with test-keys. And then again, they have to fit with the qboot program that's sending the data to be flashed.

A blankflash archive consists of the following files:

• qboot, blank-flash.sh ; Linux
• qboot.exe, qboot.dll, blank-flash.bat ; Windows
• singleimage.bin ; Both

There are different versions of the qboot program. I've found the versions 2.4, 3.37 and 3.40.
The file "singleimage.bin" contains the flash files and directions crammed into a single file, thus the name:

1. cmnlib.mbn
2. cmnlib64.mbn
3. devcfg.mbn
4. emmc_appsboot.mbn
5. gpt_main0.bin
6. index.xml
7. keymaster.mbn
8. programmer.mbn
9. prov.mbn
10. rpm.mbn
11. sbl1.mbn
12. singleimage.default.xml
13. singleimage.pkg.xml
14. tz.mbn

The XML files contain the instructions (the 'recipe'):
index.xml:

<?xml version="1.0"?>
<index>
  <board id="70" name="MSM8953" storage.type="eMMC"/>
  <package compatible="cpu.name:MSM8953 protocol:qboot" filename="singleimage.pkg.xml"/>
</index>

singleimage.pkg.xml:

<?xml version="1.0"?>
<package>
  <programmer filename="programmer.mbn"/>
  <recipe filename="singleimage.default.xml"/> 
</package>

singleimage.default.xml:

<?xml version="1.0" ?> 
<recipe>
  <configure MemoryName="eMMC"/>

  <!-- Flash GPT -->
  <print what="Flashing GPT..."/>
  <flash partition="partition:0" filename="gpt_main0.bin" verbose="true"/>

  <print what="Re-initializing storage..."/>
  <storage operation="reinit"/>

  <!-- Flash bootloader -->
  <print what="Flashing bootloader..."/>
  <flash partition="aboot"     verbose="true" filename="emmc_appsboot.mbn"/>
  <flash partition="rpm"       verbose="true" filename="rpm.mbn"/>
  <flash partition="tz"        verbose="true" filename="tz.mbn"/>
  <flash partition="devcfg"    verbose="true" filename="devcfg.mbn"/>
  <flash partition="cmnlib"    verbose="true" filename="cmnlib.mbn"/>
  <flash partition="cmnlib64"  verbose="true" filename="cmnlib64.mbn"/>
  <flash partition="keymaster" verbose="true" filename="keymaster.mbn"/>
  <flash partition="prov"      verbose="true" filename="prov.mbn"/>
  <flash partition="sbl1"      verbose="true" filename="sbl1.mbn"/>
</recipe>

These files usually do not need to be modified.
programmer.mbn is the flash application that is sent to the phone.

I've compiled the following package, including all the qboot executables:
http://frickelbude.net/moto/blankflash[addison][D61DC5C7][25.211.10][1.07][2017-04-13].zip
D61DC5C7: crc32-checksum of programmer.mbn file (original, motorola signed) (find others here)
25.211.10: firmare package origin of the bootloader files
1.07: bootloader version
2017-04-13: time stamp of bootloader file

This didn't work with recently bricked Z Play phones as some testers confirmed. We also tried all the different programmer executables linked above just to be sure but no luck.

Outlook: you may want to try out Qualcomms QFIL (part of QPST package) (look e.g. at the download section of androidbrick).
However, that requires some handywork - you need to build some XML files, provide the proper programmer file etc. Maybe grab a firmware package e.g. for a Xiaomi phone that has all these files and try and deduce a proper layout for your Z play... and hope, any of the programmer files will actually run and communicate with the pc end.

(Usually the blank-flash files operate in 'sahara' mode/protocol and send the programmer.mbn to the phone. Then it waits for a positive response from the phone to enter 'firehose' mode in order to send all the flash data...)

/update 2017-06-10 a
I've created a blank-flash package based on the files @lozada81 linked below:
bootloader files extracted from: OTA tester Android 7.1.1 BRASIL patch june - Blur_Version.26.1.22.addison.retail.en.US.zip
blank-flash package: http://frickelbude.net/moto/blankflash[addison][D61DC5C7][26.1.22][C1.12][2017-05-22].zip
(Bootloader version: C1.12, GPT layout version: 0x000A)

/update 2017-06-10 b
Same package as above, but with a different programmer.mbn, taken from an older blank-flash package that came with an Android 6.0.1 package @lozada81 linked below.
http://frickelbude.net/moto/blankflash[addison][C0A0D740][26.1.22][C1.12][2017-05-22].zip
Well, it either fails with the infamous io-error or it finally works.. please test & report back!

where is the balnkflash you created because this link that was made available is not available please reupload the file

 

[pedro1520]

we are in june and nothing..... whats going to happen? blankflash go out??

---------- Post added at 03:29 AM ---------- Previous post was at 03:29 AM ----------

sorry for my bad inglish

 

[fabian.stocker]

Where can I send my Phone to unbrick? No warranty. I wrote Emails to mobileunbrick but they won't answer. I'm from Germany

 

[usuario do Z play]

any news about blankflash to oreo?

 

[18Aniruddha]

Need Blank Flash files for Moto Z Play

work in progress! (not working yet)
Current status: does not work (but should!), exact reason unknown (to me).
If you managed to "brick" your MOTO Z Play it enters a fail-safe mode as a last resort provided by the chipset manufacturer (Qualcomm). There are packages out there called "blank-flash" that use this mode to restore a proper bootloader that in turn re-enables the use of the fastboot method to write the other flash files and restore full operation - provided the personalized partitions are still present and in good health (or you have a backup of them at hand).

Look at this thread and download the Nougat file. It contains "blank-flash" files. These "should work" but they don't (any more). As I don't have a Z Play, I cannot research the matter myself and instructing helpful others via email exchange is ... complicated.

The thing with failing updates/flash packages is that they usually fail because they do not allow downgrading - even if they allow downgrading of some sort (e.g. OS), they may limit downgrading the second stage bootloader, the signed GPT (partitioning table) etc. As I don't know if and what's the case with the Z Play, I just assumed that *if* it works, it may require the most recent files.

If you run the blank-flash files (qboot) with --debug=2 option you see that after the programmer code is sent to the phone it doesn't send a valid / expected response and ultimately causes the process to fail.

There are many programmer files out there. Most do not work, because they need to be digitally signed with the proper keys. Some are signed with Quallcomm-keys, some with Lenovo-, Motorola- and other with test-keys. And then again, they have to fit with the qboot program that's sending the data to be flashed.

A blankflash archive consists of the following files:

• qboot, blank-flash.sh ; Linux
• qboot.exe, qboot.dll, blank-flash.bat ; Windows
• singleimage.bin ; Both

There are different versions of the qboot program. I've found the versions 2.4, 3.37 and 3.40.
The file "singleimage.bin" contains the flash files and directions crammed into a single file, thus the name:

1. cmnlib.mbn
2. cmnlib64.mbn
3. devcfg.mbn
4. emmc_appsboot.mbn
5. gpt_main0.bin
6. index.xml
7. keymaster.mbn
8. programmer.mbn
9. prov.mbn
10. rpm.mbn
11. sbl1.mbn
12. singleimage.default.xml
13. singleimage.pkg.xml
14. tz.mbn

The XML files contain the instructions (the 'recipe'):
index.xml:

<?xml version="1.0"?>
<index>
  <board id="70" name="MSM8953" storage.type="eMMC"/>
  <package compatible="cpu.name:MSM8953 protocol:qboot" filename="singleimage.pkg.xml"/>
</index>

singleimage.pkg.xml:

<?xml version="1.0"?>
<package>
  <programmer filename="programmer.mbn"/>
  <recipe filename="singleimage.default.xml"/> 
</package>

singleimage.default.xml:

<?xml version="1.0" ?> 
<recipe>
  <configure MemoryName="eMMC"/>

  <!-- Flash GPT -->
  <print what="Flashing GPT..."/>
  <flash partition="partition:0" filename="gpt_main0.bin" verbose="true"/>

  <print what="Re-initializing storage..."/>
  <storage operation="reinit"/>

  <!-- Flash bootloader -->
  <print what="Flashing bootloader..."/>
  <flash partition="aboot"     verbose="true" filename="emmc_appsboot.mbn"/>
  <flash partition="rpm"       verbose="true" filename="rpm.mbn"/>
  <flash partition="tz"        verbose="true" filename="tz.mbn"/>
  <flash partition="devcfg"    verbose="true" filename="devcfg.mbn"/>
  <flash partition="cmnlib"    verbose="true" filename="cmnlib.mbn"/>
  <flash partition="cmnlib64"  verbose="true" filename="cmnlib64.mbn"/>
  <flash partition="keymaster" verbose="true" filename="keymaster.mbn"/>
  <flash partition="prov"      verbose="true" filename="prov.mbn"/>
  <flash partition="sbl1"      verbose="true" filename="sbl1.mbn"/>
</recipe>

These files usually do not need to be modified.
programmer.mbn is the flash application that is sent to the phone.

I've compiled the following package, including all the qboot executables:
http://frickelbude.net/moto/blankflash[addison][D61DC5C7][25.211.10][1.07][2017-04-13].zip
D61DC5C7: crc32-checksum of programmer.mbn file (original, motorola signed) (find others here)
25.211.10: firmare package origin of the bootloader files
1.07: bootloader version
2017-04-13: time stamp of bootloader file

This didn't work with recently bricked Z Play phones as some testers confirmed. We also tried all the different programmer executables linked above just to be sure but no luck.

Outlook: you may want to try out Qualcomms QFIL (part of QPST package) (look e.g. at the download section of androidbrick).
However, that requires some handywork - you need to build some XML files, provide the proper programmer file etc. Maybe grab a firmware package e.g. for a Xiaomi phone that has all these files and try and deduce a proper layout for your Z play... and hope, any of the programmer files will actually run and communicate with the pc end.

(Usually the blank-flash files operate in 'sahara' mode/protocol and send the programmer.mbn to the phone. Then it waits for a positive response from the phone to enter 'firehose' mode in order to send all the flash data...)

/update 2017-06-10 a
I've created a blank-flash package based on the files @lozada81 linked below:
bootloader files extracted from: OTA tester Android 7.1.1 BRASIL patch june - Blur_Version.26.1.22.addison.retail.en.US.zip
blank-flash package: http://frickelbude.net/moto/blankflash[addison][D61DC5C7][26.1.22][C1.12][2017-05-22].zip
(Bootloader version: C1.12, GPT layout version: 0x000A)

/update 2017-06-10 b
Same package as above, but with a different programmer.mbn, taken from an older blank-flash package that came with an Android 6.0.1 package @lozada81 linked below.
http://frickelbude.net/moto/blankflash[addison][C0A0D740][26.1.22][C1.12][2017-05-22].zip
Well, it either fails with the infamous io-error or it finally works.. please test & report back!

i need blank flash file for moto z play (Android Oreo)

 

[essen212]

All of the blankflash links in this thread are dead. Could someone please re-up them?

Thanks.

 

[echo92]

All of the blankflash links in this thread are dead. Could someone please re-up them?

Thanks.

Here's the blankflash from the Moto Z2 Play (codename: albus) https://drive.google.com/open?id=1Kn6og2fRksBMwUnI7YDhIXVP4kiTe-E-

You could also try this blankflash here: https://forum.xda-developers.com/showpost.php?p=73411048&postcount=206

However, depending on what was the most recent firmware on your device, these blankflashes may or may not work. If your device was on the later 7.1.1 stock firmwares or 8.0 stock firmware, even if you've downgraded, these may not work. Good luck either way.

 

[KrisM22]

Here's the blankflash from the Moto Z2 Play (codename: albus) https://drive.google.com/open?id=1Kn6og2fRksBMwUnI7YDhIXVP4kiTe-E-

You could also try this blankflash here: https://forum.xda-developers.com/showpost.php?p=73411048&postcount=206

However, depending on what was the most recent firmware on your device, these blankflashes may or may not work. If your device was on the later 7.1.1 stock firmwares or 8.0 stock firmware, even if you've downgraded, these may not work. Good luck either way.

If either of these works for anyone, please respond with the state of your phone before and after, and how you used/executed it. Thanks!!!

 

[essen212]

Here's the blankflash from the Moto Z2 Play (codename: albus) https://drive.google.com/open?id=1Kn6og2fRksBMwUnI7YDhIXVP4kiTe-E-

You could also try this blankflash here: https://forum.xda-developers.com/showpost.php?p=73411048&postcount=206

However, depending on what was the most recent firmware on your device, these blankflashes may or may not work. If your device was on the later 7.1.1 stock firmwares or 8.0 stock firmware, even if you've downgraded, these may not work. Good luck either way.

Thanks for this. Tried both, no luck unfortunately. Sahara I/O error on both.

 

[Fuzo]

Has anyone tried this? I do not have time, but I will try tomorrow.
I have not yet enough posts so the link is divided.

https : // www_droidsavvy_com/unbrick-qualcomm-mobiles

 

[tpx00]

If you are asking about the blankflash from this thread. I did it for nougat and it worked like a charm. My phone was bricked for 3 months before I was able to get it back up and running

 

[echo92]

Has anyone tried this? I do not have time, but I will try tomorrow.
I have not yet enough posts so the link is divided.

Hmm, the QFIL/QPST depends on having new enough programmer files that are properly signed by Motorola to be successfully used in unbricking a Moto device. We unfortunately don't have those files. As mentioned above, the albus blankflash may be able to unbrick a device that had been updated to an early 7.1.1 stock firmware. However, for devices updated to a later 7.1.1 or 8.0 stock firmware, the blankflash may not work on a newer, corrupted bootloader.

The other option of having a full 'clone' of a working device - all the partitions of the internal storage, may in theory work (and has been demonstrated on the G5S/G5 and the Z if I recall). However, that requires a user making a full image of their device, including their IMEI and other device specific info. If no-one is prepared to make such a clone from a working device, your other option is to take your device to a service centre for a repair.