0x08002700-2800 might not be bootloader code and might need to stay intact

[Tunas1337]

Title says most of the point.

While investigating the bootloader, I noticed that Quansheng uses that area (0x08002700-2800) as what used to be stored in "NVR" in the old UV-K5 which had DP32G030. This might be the reason that even after restoring the stock bootloader, the stock firmware does not boot. If it is not, and you do not yet know the reason, please let me know and I will keep decompiling the stock firmware to find the real reason.

I will provide further details as replies, when I get back to my computer where I have Ghidra installed.

Also - I would love to keep in touch. We have a small community of developers who are ready and willing to work on the Quansheng UV-K1 and new UV-K5, and your work blew everything we accomplished out of the water. :) I'd hope that if we collaborate, we can get further and accomplish a lot more. Thank you for your efforts!

[Tunas1337]

[muzkr]

Hello!
Thanks for you message. And yes, I'm aware of the 0516 message and the 128 bytes at the last sector of the BL area. While researching V2, I had already become aware of this, though I hadn't figured out the purpose of this data. Furthermore, the stock firmware not only checks the aforementioned data but also some data on the SPI flash (location unknown). Otherwise it will refuse to work.
In fact, before seeing your comment, I had just verified this myself: I reduced the size of my Moto bootloader to 9KB, and the stock firmware works fine. (Why was it not GitHub, but @armel that notified me someone had left a comment?)
I'm considering removing SPI flash accessing and LCD display functionality to reduce size: While I personally won't use stock firmware, I can't guarantee users won't blame me if they can no longer use stock firmware.
Yes! Let's keep in touch.

[Tunas1337]

There is definitely a RAM "overlay" that is created by the stock firmware, same as in the Talkpod A36plus and also in the UV-K5 by default. To my memory, DualTachyon determined that on the UV-K5 the overlay didn't do much at all, and/or he bypassed it by performing the operations somehow else. To my knowledge, the RAM overlay was where all of the flash-writing functions live (because you couldn't cut the branch you sit on.)

This overlay is stored in flash and there's some RLE compression applied to it; in the UV-K1 firmware, it takes up 764 bytes when decompressed into RAM, and 99.9999% certainly is the same as it was on the UV-K5 but with PY32 intrinsics instead of DP32 ones.

[muzkr]

I dont think so, Andrej. First, the stock firmware does not create "RAM overlay" (aka VTOR to RAM). Second, those 764 bytes (20000000 - 200002fc) are initialized data (the .data section).

EDIT: The ROM address of the .data section is 08014ce0. Are those bytes what you are referring to?

[Tunas1337]

Yes indeed! For some reason, there's some routine applied to them which "decompresses" them before writing them to RAM at 0x20000000. It would make sense that that's the .data section, but I am unsure why there's some weirdness thrown in. I could investigate further, but I have no reason not to trust you :)

[muzkr]

I guess the compiler (or linker?) did some smart tricks to squeeze the binary size :)

[Tunas1337]

My best attempt at understanding exactly what it does is here:

void Decompress_Zerofill_RLE(const uint8_t *src_buf, uint8_t *dest_buf, size_t dest_size) {
    const uint8_t *src_ptr = src_buf;
    uint8_t *dest_ptr = dest_buf;
    uint8_t *dest_end = dest_buf + dest_size;

    uint8_t token;
    uint32_t literal_count;
    uint32_t zero_count;

    while (dest_ptr < dest_end) {
        
        // read control token
        token = *src_ptr++;

        // decode literal length (lower nibble)
        literal_count = token & 0x0F;
        
        // if nibble is 0, the full length is in the next byte
        if (literal_count == 0) {
            literal_count = *src_ptr++;
        }

        // zero run length (upper nibble)
        zero_count = (token >> 4);
        
        // if 0 the full length is in the next byte
        if (zero_count == 0) {
            zero_count = *src_ptr++;
        }

        for (uint32_t i = 0; i < literal_count; i++) {
            if (dest_ptr < dest_end) {
                *dest_ptr++ = *src_ptr++;
            }
        }

        // zero fill
        for (uint32_t i = 0; i < zero_count; i++) {
            if (dest_ptr < dest_end) {
                *dest_ptr++ = 0x00;
            }
        }
    }
}

Not complex at all, and cleaning it up to compile as normal C was the first step to extracting the real .data section so I can put it into Ghidra's memory map. This is just in case it helps me understand some parts of the firmware that aren't the same as in the K5, and are crucial to a successful port onto the K1. :)

[armel]

Hi @Tunas1337 and @muzkr,

What’s really interesting is that this area differs from one unit to another.
Here are the bootloader dumps from two Quansheng K1 units for comparison.
These differences are probably related to the version number…

➡️ Dump 1️⃣ (version 7.02.02)

00002060  04 14 03 51 00 55 00 41  00 4e 00 53 00 48 00 45  |...Q.U.A.N.S.H.E|
00002070  00 4e 00 47 00 0e 03 4b  00 31 00 20 00 43 00 50  |.N.G...K.1. .C.P|
00002080  00 53 00 16 03 32 00 30  00 32 00 35 00 30 00 38  |.S...2.0.2.5.0.8|
00002090  00 30 00 38 00 30 00 31  00 00 37 2e 30 32 2e 30  |.0.8.0.1..7.02.0|
000020a0  32 00 00 00 c4 20 00 08  00 00 00 20 a0 01 00 00  |2.... ..... ....|
000020b0  c8 01 00 08 d8 20 00 08  a0 01 00 20 e0 23 00 00  |..... ..... .#..|
000020c0  60 11 00 08 a4 00 12 7a  42 02 46 5d 15 00 08 81  |`......zB.F]....|
000020d0  05 ff 39 15 00 08 01 87  00 00 00 00 00 00 00 00  |..9.............|
000020e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00002700  2c 40 c8 9b 27 88 f2 de  48 11 51 34 73 26 fc ee  |,@..'...H.Q4s&..|
00002710  8c c4 f8 b4 44 b9 ad a1  8b 1d 6d 34 bd c0 bb c6  |....D.....m4....|
00002720  32 14 3f 19 81 26 17 fc  4a 33 f1 49 30 1f ef 7c  |2.?..&..J3.I0..||
00002730  6a b1 ec 90 45 30 eb 0c  c2 d3 10 05 f4 56 15 73  |j...E0.......V.s|
00002740  02 c7 c6 9b 5f bc fd ab  40 76 87 9f fe 24 78 0f  |...._...@v...$x.|
00002750  31 2d 73 71 43 31 31 31  35 32 30 32 32 32 39 30  |1-sqC11152022290|
00002760  39 31 36 31 40 a4 38 34  00 00 00 00 00 00 00 00  |9161@.84........|
00002770  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00002800

➡️ Dump 2️⃣ (version 7.00.07)

00002060  04 14 03 51 00 55 00 41  00 4e 00 53 00 48 00 45  |...Q.U.A.N.S.H.E|
00002070  00 4e 00 47 00 0e 03 4b  00 31 00 20 00 43 00 50  |.N.G...K.1. .C.P|
00002080  00 53 00 16 03 32 00 30  00 32 00 35 00 30 00 38  |.S...2.0.2.5.0.8|
00002090  00 30 00 38 00 30 00 31  00 00 37 2e 30 30 2e 30  |.0.8.0.1..7.00.0|
000020a0  37 00 00 00 c4 20 00 08  00 00 00 20 a0 01 00 00  |7.... ..... ....|
000020b0  c8 01 00 08 d8 20 00 08  a0 01 00 20 e0 23 00 00  |..... ..... .#..|
000020c0  60 11 00 08 a4 00 12 7a  42 02 46 5d 15 00 08 81  |`......zB.F]....|
000020d0  05 ff 39 15 00 08 01 87  00 00 00 00 00 00 00 00  |..9.............|
000020e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00002700  32 ea 70 82 62 d8 50 79  42 98 b7 a4 a5 7f c0 5b  |2.p.b.PyB......[|
00002710  7f 5a 0f 85 74 17 75 29  74 99 08 a6 7b df 7e eb  |.Z..t.u)t...{.~.|
00002720  40 26 90 03 c5 18 87 64  4e 79 ab ff 09 0d 43 c0  |@&.....dNy....C.|
00002730  3b a6 54 ae 2d e9 68 f3  00 31 23 60 2d f3 60 a7  |;.T.-.h..1#`-.`.|
00002740  42 13 5a fe 50 73 73 e6  44 37 c5 8e 46 e5 89 78  |B.Z.Pss.D7..F..x|
00002750  31 2d 73 71 3c 31 31 31  35 32 30 32 32 32 39 30  |1-sq<11152022290|
00002760  38 30 35 31 c5 92 33 33  00 00 00 00 00 00 00 00  |8051..33........|
00002770  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00002800

Armel, F4HWN

[armel]

Ok so, for me, the 0x2700–0x2770 block clearly depends on the specific device (K1, K5 V3) and the bootloader version, and it’s very likely also tied to the MCU UID or other unit-specific data.
In practice, it’s a factory-provisioned area, unique to each unit, that you really shouldn’t modify if you ever plan to revert to the stock firmware. But personally, it doesn’t matter to me at all: I have no intention of running the stock firmware on these radios again 😌

Armel, F4HWN

[Tunas1337]

I agree, and it's likely storing some trim data (to distinguish it from calibration data, which is almost entirely radio chip related.) I know the original UV-K5 had a "piracy check" which would show striped bars on the screen if the chip ID was wrong, or if some of the data in NVR was wrong. DualTachyon made the executive decision to not include that code at all in his decompilation repo.

If I discover through further decompilation what/where this odd check happens (I pray it doesn't happen in the RAM overlay!) I will let you know immediately.