Identifying the MCU from RT85 handheld Radio

[andynvkz]

ha part of the firmware opened with a simple XOR 0xAF

[andynvkz]

We discard the first six bytes, the beginning of the file is xorim 0x5F further (presumably 6F,7F,8F)
 since there are 9F and AF approximately at the end of the file, the file is xed in blocks, how to guess the size of the blocks?

[andynvkz]

the file uses a different XOR, but if you look closely, you will see labels like 0x5F575757xx57 if I'm not mistaken, this is the beginning of the block, and xx^=0x08 values ​​​​for the XOR block

[true]

I don't have one of these newer BS firmware radios, but this is what I've found from the provided updater

total data portion is 66720 bytes. Is this a 128K flash MCU?

Code: [Select]

header: 6 bytes, xor'd with 0x57
b[0:1] - length of payload, big endian
b[2:5] - target address or offset of data block, 32 bits, big endian

data portion of the blocks is thus 0x801 (2049) bytes long, too long by one byte. doing some checks, the last byte doesn't seem to be a basic checksum. could be some other checksum method. is the last byte extra or is it some byte in the middle? can this byte be ignored or is it important?

(edit: is confirmed the last byte is not the data, but we still don't know what it is yet. likely a checksum of some kind but I don't think it is simple summation.)

here's a breakdown of the 31st data block, which has ASCII text:

Code: [Select]

08 00       (length)
00 00 F0 00 (address / offset)

and a breakdown of 33rd (last) data block, which has a different length:

Code: [Select]

04 a0       (only 1184 bytes)
00 01 00 00 (address / offset)

Using XOR 0x5F on the first data block gives what could be an ARM vector table (stack pointer looks sane, a couple jumps point to PC change) though almost every vector points to a block filled with 0xE7FEE7FE. I don't reverse engineer much; is this some compiler filler or intentional?

Just a guess but it looks like the blocks are in groups of four. each block of these four is xor'd with [0x1f, 0x17, 0x0f, 0x07] though the first three bits of each page differ. so the first 4 blocks add 0x40, blocks 5-8 add 0x60, blocks 9-12 add 0x00... I don't know a pattern yet. where does the pattern come from? is it hardcoded or does it have to do with that extra byte? haven't checked in depth yet.

(edit: I believe the key uses a bit pattern: 2, 1, 0, 3, then left shifted 1: 6, 5, 4, 7. doing this creates a table which I have attached. I've not yet assembled the firmware to determine if this is valid but this pattern results in some sensical data, gives 0x5F for the first block and gives 0xAF for the block with ASCII. this pattern seems to work for the first 32 blocks. I don't know what should be used for the 33rd block.)

I don't know if a single byte key is used for each entire block as the entire firmware seems filled with data, so there aren't good zeroed out areas to test. Would have to test all values until getting valid and sane looking ARM code but it's harder to do (though possible) with block chunks.

I haven't checked the MCU datasheet to determine if there is a built-in bootloader. Perhaps there is a built-in ROM bootloader that will let us read contents. I would guess the bootloader used for updates is not a ROM bootloader since it has this encryption stuff and weird protocol. Where is it located? Does this MCU have a way of jumping to different base address when booting, or is the main firmware responsible for jumping to the bootloader upon button held at boot? I ask this because the potential vector table in the decrypted firmware points to early addresses, so this firmware is likely loaded at the beginning of flash and executed first.

I'll keep working on this BS series firmware stuff if you ultimately can't figure it out with this information.

Right now my efforts are on getting the key for the BQ firmware (8051) key. Just a note: the TEA encryption is slightly modified in SinOne's tools and library code. I may try out of band attacks on this chip in April or May to recover the key if a key is not discovered by then.

[andynvkz]

about the beginning of each block (0x5F575757xx57) everything was confirmed, I didn’t think about the last byte, the beginning of the firmware is decompiled correctly

[andynvkz]

I tried the attack on TEA, it is real in time only if you know the first couple of bytes of the key, otherwise it takes a lot of time and it is not known how many rounds were used for encryption

[true]

Assuming the firmware vendor (TYT, or whoever they contract) used the SinOne tools, then we in fact do know exactly how they used and implemented TEA.

It's one thing to decrypt, but what about sending new firmware? It would be good to know what this last byte does, and if it is necessary for sending new firmware to the radio with the existing bootloader. Perhaps write a short program that fits in the first page to send the bootloader contents out via UART?

I forgot to attach my decryption notes so here it is.

[andynvkz]

I confirm, the last byte is the checksum, the block size is 2048 bytes, without the last byte the firmware is completely decompiled

[true]

What method is being used for checksum? Simple summation? Because I tested that and it doesn't seem to work. Is the checksum also XOR'd or no?

Mind publishing the decrypted binary or should I do it?

[andynvkz]

IDA Pro 7.6

[true]

For this last byte, I have tried simple simmation, negated summation, and xor. None match.

I looked at the updater in dnspy and see a single-byte checksum function there. However I don't see it being used. It may or may not be used by the bootloader to verify loaded data but isn't used by the updater. At this point I can only assume this is the function used. Even then, the output doesn't match whether I am checking a block with the header or without, decrypted or not.

Do you want to try setting this checksum byte to 0 (every 0x806 bytes) and see if you can load the firmware to the radio? If so, we can ignore it.

[andynvkz]

if you really need, you can flash the firmware 256 times until the bootloader accepts

[true]

if you really need, you can flash the firmware 256 times until the bootloader accepts

As I said, I don't have a BS radio yet. I only have BQ radios with the SinOne MCU.

Still, that would be 256 times per block - what about when re-flashing with more blocks? It would be nice to know the method. This method could be used for a firmware that fits in one block to then dump the contents of flash out of the serial port.

My intention is to write a replacement firmware for this radio, and maybe other BK4815 radios like the RA685 (easy encryption, GD32F330 ARM MCU). The user interface provided with these radios sucks. I want to make an amazing user interface and add features.

Were you able to figure out the xor key for the last block?

[andynvkz]

I also have BQ, I found this firmware on the forum, a person bought this station and the seller sent him this firmware, what last block are you talking about?
station serial number starts with S
rewriting firmware is cool, but I'm only interested in removing the restriction on frequency input

[true]

In the BS firmware we've been discussing, there are 33 blocks.

I sent the pattern for decoding the first 32 blocks. I was wondering if you figured out the xor key for the last block.

The last block may only be data and not code, so maybe you didn't...

[true]

I think I've figured out the checksum. I've only verified on the first two blocks so far but it matches.

It's a standard summation of all decrypted bytes in a block, including the header. Decrypt each with its own key: 0x57 for header, and whatever for data block.
Then do (256 - sum) & 0xff.
Then xor with the block's xor key.

So if you want to hack your functionality into an update, use the following function (pseudocode) to encrypt your data and include a checksum. pass in unencrypted data with a large enough buffer size.

Code: [Select]

/* assumes a full data block. (and perhaps block size influences the cipher?)
 * todo: check data length from passed header.
 */
void encrypt_and_checksum_block(uint8_t data[0x807], uint8_t xorkey)
{
uint8_t sum = 0;
uint16_t i;

for (i = 0; i < 6; i++) {
sum += unencrypted_data[i];
data[i] ^= 0x57;
}

for (i = 6; i < 0x806; i++) {
sum += unencrypted_data[i];
data[i] ^= xorkey;
}

data[0x806] = ((uint16_t)(0x100 - sum) & 0xff) ^ xorkey;
}

If interested I can write a bash shell, php script, python, C code or anything else to do this automatically: to convert a factory firmware file to a binary, or convert a binary to an uploadable firmware file.

Knowing this may also help me bruteforce the last block's xor key. I'll write some code in a little bit to try that.

edit: wrote a script to bruteforce matching checksums on each block (is in a future post). I have confirmed my analysis for previous xor values is correct. was also able to determine that the xor key for the 33rd block is 0xF2. of course this does not tell us what checksum to use with further blocks should we want to use this additional space for more code. if I get my hands on a BS radio, I'll write code to attempt to dump the bootloader to determine the sequence.

[andynvkz]

on the checksum, I matched the second block, the first did not match
of course, if there is a station, one first block is enough to write a program that will issue a bootloader via UART

[true]

All blocks matched what I earlier guessed.

Here's my bruteforce code which determines the key based on checksum matching.

Code: [Select]

<?php

if (!@$argv[1]) die('usage: '.$argv[0].' <single data block incl header and cksum>'>

$b = unpack("C*", file_get_contents($argv[1]));

for ($keytest = 0; $keytest <= 0xff; $keytest++) {
        $sum = 0;

        end($b);
        $last = key($b);

        for ($i = 1; $i <= 6; $i++)
                $sum += ($b[$i] ^ 0x57);
        for ($i = 7; $i < $last; $i++)
                $sum += ($b[$i] ^ $keytest);

        $sum = (256 - $sum) & 0xff;

        if (($sum ^ $keytest) == $b[$last])
                printf("key %02X matches\n", $keytest);
}

?>

And yes, as discussed before I think it would be nice to dump the bootloader with a small program that fits in one block.

[andynvkz]

yes checksum applies to all blocks, block headers separately xor 0x57

[true]

I also have BQ, I found this firmware on the forum, a person bought this station and the seller sent him this firmware

Do you have a radio with BQ or BS series firmware? Or do you have both kinds of radios? This firmware will not work with a BQ radio, only with BS radio. I'm pretty sure you know this though.

yes checksum applies to all blocks, block headers separately xor 0x57

This is exactly what my code shows...

[andynvkz]

I have BQ, I know that different MCUs, as I understand the block header consists of two bytes block size and 4 bytes block address, each byte XOR each other + XOR 0x57 we get the key

it's strange why the TYT website does not have this firmware ...

Compiled a program for encrypting and decrypting the firmware

[true]

Appreciate the decrypter. However, it does not work. It's also a random binary and not source code. We generally prefer source code on this forum when available: we all like to share and improve for each other =) I can always make one too.

For us BQ radio owners I'll have time to do side channel attacks to recover the key in April or may.  I know you may not be interested in a new firmware, but imagine a cheap HT like this with better, simpler and clearer menus in your native language... that's only one of my goals =)

[yanki]

UV 88 programı bulamıyorum servisi cihaz parası kadar para istiyor bende yenisini aldım

[yanki]

lazer ile yakmamışlar  entegrenin ismini arkadaşlar bu entegre gerçekten fiziksel olarak yanıyormu yoksa programmı uçuyor bilgisi olan varmı  yeniden programlanabiliyormu  entegreyi söktüm ama boşunamı söktüm diye merk ediyorum cevaplarsanız teşekkür ederim

[andynvkz]

MCU uzun zamandır biliniyor