CHIRP

I have recently purchased the KG-UV950PL (European version with 6m/4m/2m/70cm) and have started work on the driver. Currently trying to understand the protocol used. It is similar to (but sufficiently different from) the KG-UV8D.

Attached are my captures of the download/upload from the Wouxun software. The encoding does show a pattern for the memory slots (\xda \x85 records on the upload). There is a similarity with the KG-UV9D as in #2671
Based on the number of packets sent, it looks like the radio/software transfers 4 memory slots at a time and seems to use 16 or 18 bytes per slot.

Analysing the dumps, and looking at the 4th packet from download.txt (DA 82 00 06 57 1B 1B 1B 1B 1B 1F) and the 3rd packet from upload.txt (DA 83 FF 06 57 1B 1B 1B 1B 1B 1F), the "checksum" (1F) is the same even though 2 bytes in the header (DA 82 00 06 vs DA 83 FF 06) are different. This indicates that the 4 header bytes are not used in the calculation of the "checksum".

Since the initialisation packet (1st packet sent to the radio) seems to always provoke a reply with a 100 byte payload, I am beginning to suspect that the encoding/encryption key is buried in that first packet. The initialisation packet (DA 80 FF 00 58) does use the same checksum algorithm as the KG-UV8D. i.e. Start with -1 then add in the first four bytes using modulo 256.

Hi Ron et all.

I did some tinkering with the serial logs and the crypt protocol is similar to the used by the KG-UV8D Plus, but the checksum of each packet is unknown yet.

It has some different approach but I did manage to decode packet data, so there is an advance, notes and sample code are at home, so tomorrow will upload all of them.

Just need to give the good news to the group, we have an advance on this one.

73 Pavel CO7WT.

Hi to all.

As promised here comes the scripts with the tests, the test.py script will read the data_down_clean (this is the transfer data extracted from the download.txt file of this issue) and will output the decoded data stream payload.

As you will see the crypt trick is almost the same but the checsum algorithm is unknown yet and need more work.

Some example output:

===================================================%<-------------------------------------------------
pavel@agatha-lt:~/Chirp/KG-UV950P$ python test.py
Ident record
Decrypted payload [100][100]
000: 4b 47 2d 55 56 39 35 30 52 32 43 10 80 17 90 42 KG-UV950R2C....B
016: 00 46 90 05 00 05 40 07 00 07 60 32 00 39 90 70 .F....@...2.9.p
032: 00 98 50 14 00 17 30 42 00 46 90 05 00 05 40 07 ..P...0B.F....@.
048: 00 07 60 14 00 17 30 00 10 80 17 90 42 00 46 90 .....0.....B.F.
064: 05 00 05 40 07 00 07 60 32 00 39 90 70 00 98 50 ...@...2.9.p..P
080: 14 00 17 30 42 00 46 90 05 00 05 40 07 00 07 60 ...0B.F....@...
096: 14 00 17 30 00 00 00 00 00 00 00 00 00 00 00 00 ...0............

Invalid packet
Decrypted payload [3][3]
000: 00 4c 04 00 00 00 00 00 00 00 00 00 00 00 00 00 .L..............

Invalid packet
Decrypted payload [6][6]
000: 00 4c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .L..............

Invalid packet
Decrypted payload [3][3]
000: 08 10 10 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
===================================================%<-------------------------------------------------

You can at a glance see the ident string and some of the bad edges in the first packet, yet the checksum is invalid [Invalid packet]

73 Pavel CO7WT.

I no longer have this radio so I am unable to proceed

Please see issue 10498 for updates on the 950P

https://chirp.danplanet.com/issues/10498