Having yet to get my CPS to recognize my set, I’ve not explored if there’s a means via the CPS (there is for the CPS for the AT-878UV‘s).
If there’s a means, it’ll be via the CPS or (much harder) finding where the boot screen image is embedded in the firmware, then extracting it to figure out what you need to do to encode/compress a regular image file content into the same raw data format, ensuring you use no more data size than the size of the extract since it may already occupy max space in the FW.
Having got it into that same raw extract state, you can then test overwriting the segment in the uncompressed firmware image with your modded data, ensuring you start overwriting at the same base offset as the image section did.
Assuming this gets done, when you are flash the modded FW, you may find the flashing tool rejects it as invalid or the RTOS bootloader in the radio rejects it and halts. In either case, assuming you’ve not touched any other fW offsets, points to a checksum error and resolving that is a whole other game.
If you are lucky, the FW contains a read-only file system for an RTOS, like the encapsulated filesystem image within the extracted contents of a Pi memory card and maybe it’s mountable under Linux and you’ll find a contained image file (something like ‘bootpic’ maybe?) which could be replaced if the mounted filesystem image is made RW and returned to RO status before recompression and flashing.
It’s either idiot simple, or a hacking grade pain in the backside. But if it’s not in the CPS, the example you know of was a workaround based effort on the part of dealer and his/her cronies.