Quansheng UV5 (new 2024 V5.00.03) wont allow FW change or chirp. Any Clues?

[ruslik064]

As far as I understood from the manual, you need to write data into the data register 4 times in a row.

Operation process
Encryption
Encryption refers to the process in which AES uses the key register (KEY) and the initial vector register (IV) to encrypt the original data in different modes to obtain a series of ciphertexts. The encryption process is as follows:
1. Set AES_CR· EN=0 to disable AES;
2. Set AES_CR· MODE[1:0]=00 to configure the encryption mode, and set AES_CR· CHMOD[1:0] to configure the link mode;
3. Configure the AES_KEYRx register in ECB mode, and the AES_IVRx register in CTR or CBC mode;
4. Set AES_CR· EN=1 to enable AES;
5. Write the plaintext data to be encrypted into the AES_DINR register four times in succession (write MSB first);
6. Wait for the CCF flag in the AES_SR register to be generated;
7. Read the AES_DOUTR register four times in succession to obtain the encrypted ciphertext data (read out MSB first);
8. Repeat 5, 6, and 7 to complete the encryption of all data.
Note: The KEY used during encryption is the initial key for data encryption;
The KEY register does not change during encryption;
IV changes during CTR mode encryption;
Key derivation
Key derivation refers to the process by which AES uses the key register (KEY) to perform key derivation processing in different modes to obtain a series of derived keys. The key derivation process is as follows:
1. Set AES_CR· EN=0 to disable AES;
2. Set AES_CR· MODE[1:0]=01 to configure for key derivation mode. When deriving keys, there is no need to set
AES_CR· CHMOD[1:0] because the key derivation mode is independent of the selected link algorithm;
3. Configure the AES_KEYRx register. Configuring the AES_IVRx register is invalid;
4. Set AES_CR· EN=1 to enable AES;
5. Wait for the CCF flag in the AES_SR register to be generated;
6. At this time, the derived key will be stored in the AES_KEYRx register. If necessary, read the AES_KEYRx register to obtain the derived key;
7. If you need to restart the key derivation operation, please repeat steps 3, 4, 5, and 6.
Note: Key derivation has nothing to do with the chaining algorithm, but only with the original key KEY.
Decryption
Decryption refers to the process in which AES decrypts the input ciphertext data in different modes by using the key register (KEY) and the initial vector register (IV) to obtain a series of plaintext data. The decryption process is as follows:
1. Set AES_CR· EN=0 to disable AES;
2. Set AES_CR· MODE[1:0]=10 to configure the decryption mode, and set AES_CR· CHMOD[1:0] to configure the link mode;
3. Configure the AES_KEYRx register in ECB mode, and the AES_IVRx register in CTR or CBC mode;
4. Set AES_CR· EN=1 to enable AES;
5. Write the ciphertext data to be decrypted to the AES_DINR register four times in succession (write MSB first);
6. Wait for the CCF flag in the AES_SR register to be generated;
7. Read the AES_DOUTR register four times in succession to obtain the decrypted plaintext data (read out MSB first);
8. Repeat 5, 6, 7 Complete the decryption of all data.
Note: The KEY used in the decryption mode is the derived key, which can be generated through the key derivation mode and then used in the decryption mode;
The KEY in the CTR mode is the initial KEY, and the IV in the CTR decryption mode is the initial IV.
Key derivation + decryption
Derived key + decryption means that AES performs key derivation and decryption processes in sequence, so the key register used here
(KEY) is the initial key. The process is as follows:
1. Set AES_CR· EN=0 to disable AES;
2. Set AES_CR· MODE[1:0]=11 to configure the key derivation + decryption mode, and set AES_CR· CHMOD[1:0] to configure the link mode (CTR mode does not support key derivation + decryption mode. If this mode is configured, the hardware will force the return to decryption mode);
3. Configure the AES_KEYRx register in ECB mode, and the AES_IVRx register in CTR or CBC mode;
4. Set AES_CR· EN=1 to enable AES;
5. Write the ciphertext data to be decrypted into the AES_DINR register four times in succession (write MSB first);
6. Wait for the CCF flag in the AES_SR register to be generated;
7. Read the AES_DOUTR register four times in succession to obtain the decrypted plaintext data (read out MSB first);
8. Repeat 5, 6, 7 Complete the decryption of all data.
Note: The KEY used in this mode is the original key. The key will be derived during the AES operation, and the derived key will be stored in the AES_KEY register;
Note that this type of operation is not supported in CTR mode, and forced configuration will be returned to decryption mode by the hardware;

In general, all of this needs to be translated.

[radiolistener]

It appears that AES_Init and AES_Process128 functions working with data where each 32-bit word is reversed (reversed byte order).
So, this is the reason why ProcessPacket_057b() doing byte reverse for every 32-bit word before decrypt and after decrypt.
According to my tests, mode 0 works as classic AES-128 CBC encrypt and mode 3 works as classic AES-128 CBC decrypt.

But bootloader v5 uses mode 2 for decrypt. Previously I thought that this is classic AES-128 CBC decrypt, but it isn't. It don't match to AES-128 CBC decrypt and and don't match to AES-128 CBC encrypt. I'm not sure what is this mode and how it works? 

[ruslik064]

This?

AES mode selection.
00: Mode 1: Encryption
01: Mode 2: Key derivation
10: Mode 3: Decryption
11: Mode 4: Key derivation + decryption
The operating mode can only be changed when AES is disabled.
Writing to these bits when AES is enabled is prohibited to avoid unpredictable AES
behavior.
Mode 4 is prohibited if CTR mode is selected. If software attempts to configure Mode 4 for
CTR mode, Mode 3 will be forced.

 Encryption/decryption using the AES Rijndael block cipher algorithm

[radiolistener]

This?
AES mode selection.
00: Mode 1: Encryption
01: Mode 2: Key derivation
10: Mode 3: Decryption
11: Mode 4: Key derivation + decryption

Yes. When configured to use CBC:
00: Mode 1: Encryption => Works as classic AES-128 CBC encryption
11: Mode 4: Key derivation + decryption => Works as classic AES-128 CBC decryption

10: Mode 3: Decryption => the results is different than AES-128 CBC. What is this?

Here is example vector for "10: Mode 3: Decryption" (all data has 32-bit words with reversed bytes):
key: 00000000000000000000000000000000
iv: 00000000000000000000000000000000
plain: 00000000000000000000000000000000
cipher: EFA4AA0CE22B35957B4C88B24429146A

while classic AES-128 CBC decryption should produce this vector:
key: 00000000000000000000000000000000
iv: 00000000000000000000000000000000
plain: 00000000000000000000000000000000
cipher: 100F0F143D22B511177758793AECD9FF

[radiolistener]

Preliminary using mode 1 (kdf) and then mode 2 (decrypt) is the same as using mode 3 (kdf+decrypt)...
It passed some test cases, but needs to test it more deep.

If this true, then it simply uses usual AES-128 CBC with reversed bytes in 32-bit words, with nothing unusual.
Pair (key,iv) for decrytpion and encryption is taken from bootloader table by it's number.

And since ProcessPacket_057b already has byte order reverse before and after decryption, there is no need to reverse byte order. Just encrypt firmware with classic AES-128 CBC.

So, it looks like implementing firmware encryption is pretty easy, but needs to check all things more deep.

[ruslik064]

If necessary, I can test the flash on the 5th boot. Without fear of killing the station. I can always flash it with a programmer.

[radiolistener]

If necessary, I can test the flash on the 5th boot. Without fear of killing the station. I can always flash it with a programmer.

Thanks, here is test version for bootloader v5.
I tested it on simulator, but still not sure that there is no mistake.

I added confirmation on startup, it needs to type "yes" in console, otherwise it will exit.

WARNING: this is a test version of K5TOOL which is never tested on bootloader v5.
There is a high risk to brick the radio. Don't use it if you don't understand the risk and don't understand how to restore radio!

UPDATE: it seems there is mistake in this test version, so I removed it to avoid unwanted further bricks. See discussion below.

[darkspr1te]

@radiolistener
I have a pre v5 bootloader, can i flash via swd the v5 and is there any thing i need to back up ?
i've not opened my radio yet by I enjoy arm debugging and have already broken the aes128 for ActSafety A600 (software aes128 based on stm's DFU aes at chip release)
and autophix OM127 aes128 ( based on cm aes date unknown )
so i want to have a crack at re writing this bootloader,


darkspr1te

[ruslik064]

I'll test it tomorrow. But explain what to give it to boot? I have a dump of 5 firmware. Or are we trying to upload, for example, fagci?

[ruslik064]

I have a pre v5 bootloader, can i flash via swd the v5 and is there any thing i need to back up ?

Don't do anything yet. You need to understand if what is written works. It's not worth risking without having recovery methods. The path we've taken is long. Don't torture yourself yet. The dump taken from the station and the beginning of this topic took a lot of time. You shouldn't kill your stations if you don't understand what you're doing.

can i flash via swd the v5

You can, but it's unlikely that you'll come back)

[radiolistener]

I'll test it tomorrow. But explain what to give it to boot? I have a dump of 5 firmware. Or are we trying to upload, for example, fagci?

I think anything that can work. If custom firmware don't works due to some config/nvram compatibility issue, you can flash firmware v5, the tool supports raw firmware format with command -wrflashraw, but there is no crc check for raw firmware, so if you use -wrflashraw, then make sure you're using correct image (in plain format as is, with no encryption and no version header).

Since there is version check in the bootloader, you're needs to specify * or 5 as version parameter, otherwise bootloader v5 will not accept the firmware.

So, if you try to flash custom firmware from packed image with version 2 in the header, the bootloader v5 will reject it.It needs to unpack the firmware and then use -wrflashraw with manual version 5 or * parameter.

[ruslik064]

Programming on 5 bootloader is successful. But the station does not start. I read the dump after programming, there is a mess.

!!!!!!!!!!!!!
!!!WARNING!!!
!!!!!!!!!!!!!
This is a test version of K5TOOL and is intended to use by qualified tester!
If you use it to upload flash on UV-K5 radio with bootloader v5
THERE IS A HIGH RISK TO BRICK YOUR RADIO!
This version implements a new protocol which is never tested on UV-K5 radio!
Are you sure to continue? [yes/NO]: yes
Opening COM10
Read unpacked FLASH image from newk5dump.bin...
Waiting for bootloader beacon...
   Bootloader: "5.00.01"
Using ProtocolV5...
Write FLASH size=0xf000 (space usage 100,00 %)
Send version "5"...
   Bootloader: "5.00.01"
   Write 0000...0100: [beacon]OK
   Write 0100...0200: OK
   Write 0200...0300: OK
   Write 0300...0400: OK
   Write 0400...0500: OK
   Write 0500...0600: OK
   Write 0600...0700: OK
   Write 0700...0800: OK
   Write 0800...0900: OK
   Write 0900...0a00: OK
   Write 0a00...0b00: OK
   Write 0b00...0c00: OK
   Write 0c00...0d00: OK
   Write 0d00...0e00: OK
   Write 0e00...0f00: OK
   Write 0f00...1000: OK
   Write 1000...1100: OK
   Write 1100...1200: OK
   Write 1200...1300: OK
   Write 1300...1400: OK
   Write 1400...1500: OK
   Write 1500...1600: OK
   Write 1600...1700: OK
   Write 1700...1800: OK
   Write 1800...1900: OK
   Write 1900...1a00: OK
   Write 1a00...1b00: OK
   Write 1b00...1c00: OK

[ruslik064]

Are we trying to upload a clean, unencrypted aes dump to the station? Is the dump encrypted before flashing?

[radiolistener]

hm... yes, if you see "Using ProtocolV5", it sends encrypted firmware. But there is possible mistake with byte order for keys, because there is mess with byte order and word order in bootloader code. But at a glance it should be ok according to my tests with openocd.

I'm not sure why output ends at 1b00..1c00.  It should be ef00..f000.
Is this is a full output?

Can you read firmware dump with openocd? Does it match with image which you upload?
If yes, and it ends with ef00..f000 and Done message, then upload firmware looks good.
There is also possible incompatibility with eeprom/nvram content which can block firmware from running.

But I think more likely cause is possible mistake with encryption. In this case decrypt will produce random bytes and firmware will not work.
There is need to get flash content to understand what is actually going on and analyze it.

We can try to play with different byte order for keys, but it's better to get the dump and analyze it.

Can you share the firmware image which was used to upload and firmware dump taken with openocd?
It should help to identify where is mistake and fix it.

Currently I suspect that there is no need to reverse bytes in the keys, but needs to check it. The firmware dump from the radio can give the answer.

[ruslik064]

this is not a complete output. everything ends normally. (done). i read the dump after the firmware but unfortunately i left on business. i will post it as soon as i can.