[Verizon Galaxy Note 3 General] bftb0:
With locked bootloader phones, there is an "anti-rollback" provision that prevents you from down-rev'ing firmware using Odin. There are some very limited cases where it can be done, for instance from NC2->MJE, but in general it is not possible.

Moreover, the "unlock" exists in the "aboot" portion of the boot layer, so if you down-rev'ed the boot firmware - if it were possible - you would immediately lose your unlocked bootloader. AND, it would be a tremendously bad idea to try combining your (now-customized) "aboot" partition with components of other firmware release versions (e.g. sbl1.mbn, tz.mbn, etc). That could lead to a perma-brick (hard brick possibly without even a "debrick image" rescue method).

What happens is that when you use Odin, Odin is actually communicating with the "aboot" portion of the firmware. It examines incoming (boot layer) firmware and based on some "fuse" values in the hardware that describe current versioning, it will refuse to flash anything with prior versions.

There is an interesting possibility that is unknown, and so therefore extremely high risk. AFAIK, nobody has tried it:

- The bootloader unlock method could be tweaked to perform the DE SignatureChange(CID) on an offline file blob... which would be the "aboot" portion of the firmware that you intend to flash.

- That modded firmware blob (aboot) would be combined with all the other stock components of the same firmware revision into an Odin flashable .tar.md5 file, and a flash of that attempted.

There are at least two issues that are not completely known about this (although [MENTION=766721]ryanbg[/MENTION] might have some good ideas):

(1) It is apparent that this exploit (modding the aboot DE signature) does not trip up the chain-of-trust sequence during booting. That is, "sbl1" is happy to execute "aboot" even though it has been slightly modified. This suggests that the DE signature is actually not covered by the Samsung crypto hash signature. So, it is quite possible that whatever "aboot" is running on the phone and communicating with Odin, it will not flag the (offline-modded) aboot as an invalid image due to mismatched crypto sigs.

(2) the "RP SWREV" (Rolllback Protection Software Revision) checking is likely 100% independent of the blob signature checking; in which case the fact that one check is disabled in DE phones (blob signature checking), you still may not be able to flash a prior version.

Having noted that (2) applies only to firmware reversals, it is possible that this could be a way for people on older bootloaders to upgrade their bootloader firmware while still retaining an unlocked condition. If that is the case, it would allow them to avoid dodgy rooting methods in newer stock ROMs as they could simply flash a custom recovery and then have their way with whatever ROM was installed.

If I were ever to do this for myself I certainly wouldn't distribute the Odin tarballs. Idiots will flash them to their phones without changing their CID first and brick. (soft or hard, I don't know).

There is one other option for [MENTION=5415037]seadooman[/MENTION] of much lower risk:

Make TWRP backups of the current ROM (& get copies off the phone!) and then flash using Odin only the "ROM" components of the Odin bundle for 4.4 roms. (boot.img, system.img.ext4, cache.img.ext4 and then "factory reset" in the custom recovery). It is quite possible that it will boot. {*1} If not, you will still have your custom recovery and you can go back to your current ROM by restoring it in TWRP.

(I'm not sure I would try 4.3 ROMs this way, though. With absolute certainty I can tell you that the way that DTB (flattened device tree) blobs were attached to 4.3 kernels used an older (v1) indexing method, and the newer method (v2) causes the (MJ7) bootloader to puke. {*2} Going in the reverse direction it might be possible if the newer bootloaders have conditional code that understands both versions v1 & v2 of the QCDT header.

{*I} think the attestation signatures that the TZ apps use to verify the various components are shipped with the ROM, but it is sort of unknown whether downward compatibility of TZ apps works correctly). That is to say, it is unknown whether the TZ apps in tz.mbn from a later release will be happy with the attestation data they find in older ROMs.

{*2} There's more to it than just this. I have partially booted 5.x kernels on MJ7 by re-packing the QCDT & DTB kernel attachments, but the resulting kernel dies within a few seconds after a tremendous number of complaints.

.