Bootloader-based exploit chain question about tuya-cloudcutter

[notkmhn]

We've tried that path to no avail. Surprisingly, we've found that there are many bootloader variations from the different device models from even the same manufacturer are not the same. Maybe the first ~600ish bytes are similar, but other than that there's too much disparity to do anything useful. And in order for a ret2bootloader style chain to work, we'd need a lot more than a handful of instructions to match because no matter the chain it'll have to do a lot more work than the current chain does: resetting the AP listener for more payloads, maybe carving out a section of memory to write instructions, etc.

There are also other issues with a payload of that style, since the first return must have an address where the 2nd MSB (little endian) has a value other than 0x00, but the bootloader is loaded in RAM at 0 <= max bootloader address < 0x10000.
EDIT: the above doesn't really apply, old notes.

That being said, it's only more useful that more pairs of eyes are looking at it so please go ahead and check it out. It'd sort out the whole issue of having to do this per device model/make.

https://github.com/khalednassar/bk7231tools can dump and dissect a full flash image including the bootloader. Only decryption isn't supported due to lack of time to RE and we decided not to provide the encrypt binary as part of the repo (for specific reasons).
Decryption is pretty much the same thing you do, the only difference is that the start address given to the encrypt binary is 0 instead of 10000.

[notkmhn]

I have to agree though that this is super weird and more likely are probably only a some different bootloaders out there and we may have seen all of them already. It may make a lot of sense to try and pool these together from the different devices and see if there may be a very small number of different chains which can be tried on a device blindly in a reasonably short period of time.