[Moto Z Play Questions & Answers] echo92:
I'll have a go at answering this...

It's generally not the downgrading of stock Motorola firmware that bricks a device, often times it's the usage of OTA updates following a downgrade that causes the hard brick.

From what I've seen of many hard bricks (on Moto G4/Plus, G5 Plus, Z Play, though probably a similar scenario on other devices from other manufacturers):

1)You have your system firmware and your bootloader. E.g. The C1:14 version bootloader comes with the Feb 2018 7.1.1 stock Nougat firmware/OTA update. Normally, they would be matching (so you'd have the 7.1.1 Feb 2018 firmware with the C1:14 bootloader). Using OTA updates would be no problem.

2)If you downgrade your stock firmware (custom ROMs usually are not applicable in this case, regardless of the custom ROM security patch/version), you may be able to flash older stock firmware but your bootloader cannot be downgraded. E.g. you flashed the August 2017 7.1.1 stock firmware on a device previously updated to Feb 2018 stock firmware. You'd have the August 2017 system firmware but a Feb 2018 bootloader. Your device may run okay and the flash may have gone okay besides some 'security version downgrade' errors with the bootloader and GPT.

3)So your downgraded device runs okay and you get an OTA prompt to the Sept 2017 security patch OTA. This is where the problems start. OTA updates appear to only be verified by your system version, and looking through the updater scripts for various OTA updates, they check if your system partition, OEM, boot (kernel) etc are fully stock and are of the correct build to flash to. Tellingly, the OTA script does not seem to check for your bootloader version , I think the OTA assumes your bootloader and the system are of the same matching versions/patch levels. As you've downgraded your device, this assumption does not hold. Should there be a check for the bootloader version if it was possible? Perhaps.

4)Your device reboots and begins flashing the Sept 2017 OTA. So far, the OTA is checking and verifies your device is running the August 2017 firmware, and begins patching. However, the OTA can patch your bootloader with older images without verification, which means it applies Sept 2017 images to a Feb 2018 bootloader, corrupting the bootloader and thus hard bricking your device.

(EDIT - reading this page, it suggests that there are multiple bootloaders in your device, each one verifying each other to ensure integrity. https://xdaforums.com/android/general/info-android-device-partitions-basic-t3586565 My guess is that applying the old OTA images to a newer bootloader changes the signature of the bootloader we see - e.g. changing the signature of the secondary bootloader/SBL or having an old aboot image in the newer bootloader - and so fails the upstream verification, hence a hard brick.)

I'm not sure how your old device's bootloader is different, maybe it's a lot less stringent. Was it running a Qualcomm bootloader or a Mediatek bootloader?

However, with Qualcomm bootloaders, if the bootloader image is corrupted they appear to fall back to a emergency download mode (you can read more here: https://alephsecurity.com/vulns/aleph-2017028 ). To recover, you often need crytographically signed images from the appropriate OEM (Motorola in this case) to rescue a device in such a state. As I understand it, these images - including the often requested blankflashes - include methods to communicate with your device (via the sahara protocol) https://github.com/openpst/sahara and a programmer to verify your device and bootloader are suitable for repairing, before flashing a new bootloader: https://xdaforums.com/showpost.php?p=62191317&postcount=2112 https://xdaforums.com/showpost.php?p=63490742&postcount=17 We cannot make these, and any attempts to modify them would likely break the cryptographic signatures on the files, so would be rejected (else you could inject your own compromised bootloader, or downgraded bootloader as per the paper, which would be dangerous for security). This security issue is likely why OEMs do not release blankflashes or other such repair files.

If the blankflash is too old or older than the corrupted bootloader, the programmer appears to fail to rescue the device. Short of having the actual, signed files in a blankflash or similar, that are as new or newer than your current corrupted bootloader, it becomes very hard to rescue a device. That's likely why we've seen quite a few Z Play devices on 7.1.1 or 8.0 that downgraded and got corrupted by an OTA that are not rescuable at the moment - we simply do not have updated tools. Motorola (and likely other OEMs) seems to regard these blankflashes as internal development tools and as such won't give them out - all we have are leaks. I imagine Motorola's point of view also includes that since your bootloader was unlocked, you assume responsiblity for anything that happens.

If you do hard brick then I recall there are a few options:

a)Hope that a blankflash or updated MSM8953 programmer/signed images for Motorola devices is leaked. Must be as new or newer than your corrupted bootloader (recall you cannot downgrade bootloaders). No guarantee of being released if at all.

b)Hope that someone finds a JTAG or other board level repair.

c)Pay for a motherboard replacement (expensive, 60-80% of the device cost sometimes) - perhaps you may be covered by local consumer laws.

d)Buy a new device, forget about repairing this one.

As I mentioned above, hard bricks are very difficult to recover from without the correct tools. However, they are avoidable if users do not flash older stock firmware, only flashing the same stock firmware as they had on their device (matching their bootloader) or newer stock firmware. If they do downgrade, then not using OTA updates whatsoever may also save them from a hard brick (though in that case you must use the latest stock firmware to update with). Alternatively, if you unlocked your device bootloader, you could just use TWRP flashable stock ROMs and forget about using stock firmware at all - TWRP flashables in general should not affect the bootloader.

Any further comments or corrections welcome.