DEV Community: endes0

Retevis custom programming cable and unlocking

endes0 — Sun, 13 Jul 2025 12:58:01 +0000

I recently bought a pair of Retevis RT622P walkie, and while reading the manual I discovered that they have a software for configuration.

It is very simple, in fact it works decently on wine. The communication is thought the com ports and in fact the software comes with driver for the PL23xx serial to usb. Silly me I thought the walkie had this converter integrate and you only need to connect them to the PC with the USB C cable. NO, they sell to you an "programming cable" for $28.99 on the official store or 5 € on Aliexpress. This cable is the same for the RT20 RT65 RT665 RB19 RB619 RT622P RT22P.

Making a custom cable

I didn't want to buy yet another USB to serial adapter, so after a little teardown, I traced back where they connected the serial lines.

They connected TX and RX to USB D+ and D- directly, so after a little bit of getting "creative"(doing shoddy work), I managed to connect the walkie to the software.

Also, if you are using wine, you should do this to map your serial port.

Unlocking

The software let you change every config for the channels except the frequency, TX power and wideband. This I believe it is for legal reasons (Those devices are unlicensed legal PMR446). But if you go to About->Setup and in password you put "retevis" these settings become editable.

Communication protocol

The serial port is opened at 9600 bauds 8N1 parity.
For describing the communication, I will put in italics the hexadecimals values, SW send when the software sends out a data to the serial port and walk respond when the walkie send data to the software.

Start

The following sequence is followed each time the software is going to write or read from the walkie.

SW send: 02 43 31 36 30 52 41 4d (.C160RAM)
walk respond: 06
SW send: 02
walk respond: 06 00 00 00 00 00 00 00
SW send: 06
walk respond: 06
SW send: 05
walk respond: ff ff ff ff ff ff (This possibly is the RW password)
SW send: 06
walk respond: 06

Write to the walkie

When write to walkie is selected, the software start to send sequences like 57 00 1a 0d f5 96 a8 02 f5 96 a8 02 48 11 48 11 ef (the same as the Dat files) and receiving 06. Finally, the software send 62 (Reset?).

Read from the walkie

When read from walkie is selected, the software start to send sequences like 52 00 XX 0d and receiving 57 ... sequences like the Dat files). XX is the 3rd value of the 57 ... sequences, it is basically an index value.

Dat files

They contain all the channels and other configs in a sort of tabular storage. You can see where each parameter is by saving two of these files with different values for that parameter. There are for sure some "hidden" parameters the software cannot change but I don't have the time to play around with them right now.

Analyzing the communication protocol of the Decathlon Walk by domyos

endes0 — Fri, 20 Dec 2024 17:06:29 +0000

Some months ago I bought a treadmill from Decathlon, A "Walk by domyos", a pretty basic model. It has a console where you can set the speed and see a variety of metrics (total exercise time, total kms, etc.). Of course, some weeks later, I could not resist the urge to open it up and reverse engineering it.

Teardown

Of course the first thing I did was to open it up, the entire thing (or at least the console and motor control board) seems to be manufactured by ShangaHai Electronics Way Co. Ltd (It took me a while to find the manufacturer website, it doesn't pop up when you search it).

The motor control board is labeled as the model B408D. The microcontroller and other logic ics are on another pcb soldered perpendicular to the main one, and it seems to have a layer of some protective material on top of the board, so reading the ics markings is difficult. There is also a 4 pin header labeled "PROGRAM", 2 of these pins are ground and 5V, I'm pretty sure this is the programming port used to upload the firmware. The connector to the console board is well labeled on every pin and isolated by optocouplers.

The console board is labeled as "A1835B1", the labeling seems to also includes the firmware file on the mcu: "TC8_A1835_S115_60509.mot". The board has basically a main mcu and a display driver (the ht1621). Identifying the mcu is not easy, the package is a TSSOP20 and has the following markings "0C000 H3AG", which are not very helpful. After searching "0c000 mcu tssop20" on google this showed up on Aliexpress, so it seems to be a Renesas mcu, maybe a r8c o rl78 series. The main mcu is not directly connected to the RX and TX pins of the connector to the motor control board, but through a circuitry that does a voltage level shifting.

The cable that connects both the board is basically made of 5 lines: The power lines, 12v and GND; the communication lines, RX and TX; and the "SW", that the console connects to 12v when the key is inserted.

I didn't do any more analysis or found anything interesting on the boards, sure it will be interesting to analyze how the motor boards control the motor itself at an electronic level, but it is outside of my knowledge area and sincerely for me, it would be boring.

Tapping the communication between the console and motor board

Now comes the fun part, and of course the most important, as if we reverse the communication protocol we can potentially replace the console with one custom-made with more functionalities or do some fun things (like going more than 8km/h).

The first thing I did was to plug in my cheap logic analyzer into the RX and TX cables without even thinking about if the voltages level were compatible. Of course, it seems that these voltages were too high, and a fun thing happened: When I plugged the analyzer on both cables, the communication got interrupted and the error 5 showed up on the console, but if I only plugged it on the receiving part of each board it didn't interfere.

Fortunately, there were 3 jumpers(0 ohm resistors) nearby the mcu, these were for gnd, rx and tx lines. Luckily those RX and TX lines were before the level shifting and can be tapped without problems. After taking some captures I could decode the protocol as UART at a baud rate of 2400 bauds. For discovering this baud rate, which for me was a very unusual baud as I have never seen this value, but is understandable as maybe a higher rate would be problematic because the cable length or the interference (the motor generates a lot), I used the Sigrok guess baudrate function, which resulted to be very useful.

Unfortunately, while doing some experiments with the console, I accidentally inverted the polarity and broke something, possibly the input pin on the mcu that detects that the key is present. So the console now is useless, which means I could not continue to do all the tests I was doing, so the next parts may come short in some aspects.

Analyzing the messages

All the messages sent by both the console and motor control board follows the next structure.

Byte position	0	1	2..n	n+1	n+2
Name	Header	length	Data	Checksum	Footer
Description	Seems to be the unit address. 0x68 for the console. 0x73 for the motor board.	Byte size of the data + checksum + footer	Content. Console normally sends 7 bytes and the motor 10 bytes.	Sum of the data and length mod 0xFF	Always 0x43
Example	0x68	0x8	0x80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0	0x88	0x43

Console data

The console every second or so sends a message containing the following 7 bytes of data.

Byte position	0	1	2	3	4	5	6
Name	Key status?	Start/stop	Speed	?	?	?	?
Description	0x80 if key is present, 0x81 if not.	0x80 when the treadmill is running, 0 when not.	selected km/h * 10	Always 0	Always 0	Always 0	Always 0
Example	0x80	0x80	0x06	0x0	0x0	0x0	0x0

On startup, after an initial delay, the console sends this 31 bytes message multiple times.

0x87, 0x2, 0x24, 0x29, 0, 0, 0, 0, 0x1, 0xc, 0, 0, 0x8, 0x8, 0, 0, 0, 0, 0, 0, 0, 0x19, 0, 0, 0x50, 0, 0, 0, 0, 0, 0

I really don't know what it is, maybe the configuration for the motor board?. It doesn't seem to change, I have tried to reset the console, change the units or increment the total kilometers.

Motor board data

In response to the message sent by the console, the motor board sends a message containing the following 10 bytes data.

Byte position	0	1	2	3	4	5	6	7	8	9
Name	unknown	Measured speed	voltage?	Another measured speed?	motor amperage?	unknown	status	unknown	unknown	unknown
Description	always 0xa0	From the IR rotatory sensor. km/h * 10	Fluctuates between 230 – 250.	km/h * 10	see below	Always 0	0x21 when ready (you can hear a relay clicking) 0x22 or 0x23 when running	Always 0	Always 0	Always 0
Example	0xa0	0x05	0xf6	0x06	0xa	0	0x22	0	0	0

The byte 4 (motor amperage?) seems something that is directly measured from the motor, it fluctuates but seems to increment with the speed (see the table below) and if the motor gets disconnected from the board it goes to a pretty high value (~100).

speed(km/h)	value
5	71
2.5	38
1	11
0.5	11

Errors code

The console can give a variety of errors to the user, I thought it would be interesting documenting each one, as the official manual is not very helpful. But, as I said earlier I broke my console board halfway through, so this part is pretty incomplete. In fact I really don't know how most errors get triggered with the motor board messages.

Error 2: It popups when the motor is disconnected from the control board.
Error 5: Display board after startup is not receiving motor board messages or are malformed.

By the way, disconnecting the IR rotary speed sensor doesn't seems to trigger an error.

Making a very simple console

As I have broken mine and it is not easy to find, I had to do one for still using the treadmill and not having a giant paperweight at home. The first thing I did for making it run was creating and running a python script in my pc connected through a serial adapter and reusing the level shifting circuitry of the old board. It was not very comfortable to use the treadmill in that way. So with an Arduino UNO, a touch screen shield (MCUFRIEND 2.4” TFT Display) and a horrible written code (I swear I'm a professional software developer, during my shift) I made a simple console to set the speed and start and stop the treadmill.

Here is the gist of the code, keep in mind that is something that I did very fast and when I was tired.

What's left

There are still things left to do for the future, so I might do a follow up post.

I want to finish understanding and documenting both message data, especially the control board messages, which I can still capture and do tests.
As I broke the console I should try to dump the firmware, so I can reverse engineer the code and so I maybe understand more the messages and errors.
Implement a better console with more functionalities, with an esp32 so I could do cool things.

USB HID Down the rabbit hole: Logitech G435 dongle

endes0 — Sun, 30 Jun 2024 11:32:21 +0000

Last time, in the first post of this series, I explored the vendor interface of my Logitech Mouse, now let's explore the dongle of my headphones. As I said last time, it caught my attention that it can send "phone" HID events. Also, Logitech doesn't provide any official software for configuring the headphones(like the sidetone volume) or seeing their status(like the battery remaining).

// Detect dark theme var iframe = document.getElementById('tweet-1805693034950181110-778'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1805693034950181110&theme=dark" }

The dongle I have is the HDT647(PID 0acb). After a bit of research, the first thing that pop up is the FCC Internal teardown images report. Unfortunately, the chips markings aren't readable, but the IC interfacing the USB port is clearly from Realtek, while the other one seems to be the PAUxxxx SoCs from the defunct audiowise (Acquired by Airoha, a subsidiary of MediaTek).

// Detect dark theme var iframe = document.getElementById('tweet-1807083928458551475-512'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1807083928458551475&theme=dark" }

I didn't want to open the dongle, as opening it up is a little "destructive", but I couldn't resist the urge. So, after opening the dongle, I read the chips markings. The Realtek codec is the ALC4021 (which is used in "similar" aplications), no datasheet available. The other is the PAU1823, again used in "similar" applications and no datasheet online(except one image and this forum post, which I cannot access the downloads as it requires an account). The last chip is a 512kb SPI flash (the MX25V512E), it can be for any of the other two chips.

So it is basically a Bluetooth Audio Dongle. It seems that Lightspeed is just that, Bluetooth 5.2 with their patented GreenRadio technology for low latency. But I'm not very sure.

On the other hand, in the research I found a bunch of software programs for this dongle. There is the official update software. There are also these "unofficial" pairing(and more) tools on the Logitech Reddit. These tools seem widely used, as I found the logs of these on other Reddit posts and even on GitHub!. Also, both the official and unofficial tools seem based on the same sources.

Finally, I also found a compatible dongle on eBay, which also provides a link to the previous "unofficial" tools.

The USB interface

It has a good quantity of snd-usb-audio interfaces and an HID one.

HID descriptor

# Logitech G series G435 Wireless Gaming Headset
# 0x05, 0x0c,                    // Usage Page (Consumer Devices)       0
# 0x09, 0x01,                    // Usage (Consumer Control)            2
# 0xa1, 0x01,                    // Collection (Application)            4
# 0x85, 0x03,                    //  Report ID (3)                      6
# 0x15, 0x00,                    //  Logical Minimum (0)                8
# 0x26, 0x8c, 0x02,              //  Logical Maximum (652)              10
# 0x19, 0x00,                    //  Usage Minimum (0)                  13
# 0x2a, 0x8c, 0x02,              //  Usage Maximum (652)                15
# 0x75, 0x10,                    //  Report Size (16)                   18
# 0x95, 0x02,                    //  Report Count (2)                   20
# 0x81, 0x00,                    //  Input (Data,Arr,Abs)               22
# 0xc0,                          // End Collection                      24
# 0x05, 0x0b,                    // Usage Page (Telephony Devices)      25
# 0x09, 0x01,                    // Usage (Phone)                       27
# 0xa1, 0x01,                    // Collection (Application)            29
# 0x85, 0x05,                    //  Report ID (5)                      31
# 0x15, 0x00,                    //  Logical Minimum (0)                33
# 0x26, 0xbf, 0x00,              //  Logical Maximum (191)              35
# 0x19, 0x00,                    //  Usage Minimum (0)                  38
# 0x2a, 0xbf, 0x00,              //  Usage Maximum (191)                40
# 0x95, 0x02,                    //  Report Count (2)                   43
# 0x81, 0x00,                    //  Input (Data,Arr,Abs)               45
# 0xc0,                          // End Collection                      47
# 0x06, 0xc0, 0xff,              // Usage Page (Vendor Usage Page 0xffc0) 48
# 0x09, 0x01,                    // Usage (Vendor Usage 0x01)           51
# 0xa1, 0x01,                    // Collection (Application)            53
# 0x06, 0xc1, 0xff,              //  Usage Page (Vendor Usage Page 0xffc1) 55
# 0x85, 0x06,                    //  Report ID (6)                      58
# 0x15, 0x00,                    //  Logical Minimum (0)                60
# 0x26, 0xff, 0x00,              //  Logical Maximum (255)              62
# 0x09, 0xf0,                    //  Usage (Vendor Usage 0xf0)          65
# 0x75, 0x08,                    //  Report Size (8)                    67
# 0x95, 0x07,                    //  Report Count (7)                   69
# 0x81, 0x02,                    //  Input (Data,Var,Abs)               71
# 0x09, 0xf1,                    //  Usage (Vendor Usage 0xf1)          73
# 0x75, 0x08,                    //  Report Size (8)                    75
# 0x96, 0x02, 0x02,              //  Report Count (514)                 77
# 0x91, 0x02,                    //  Output (Data,Var,Abs)              80
# 0x09, 0xf2,                    //  Usage (Vendor Usage 0xf2)          82
# 0x75, 0x08,                    //  Report Size (8)                    84
# 0x95, 0x3f,                    //  Report Count (63)                  86
# 0xb1, 0x02,                    //  Feature (Data,Var,Abs)             88
# 0xc0,                          // End Collection                      90
# 0x06, 0xc3, 0xff,              // Usage Page (Vendor Usage Page 0xffc3) 91
# 0x09, 0x01,                    // Usage (Vendor Usage 0x01)           94
# 0xa1, 0x01,                    // Collection (Application)            96
# 0x06, 0xc4, 0xff,              //  Usage Page (Vendor Usage Page 0xffc4) 98
# 0x85, 0x34,                    //  Report ID (52)                     101
# 0x15, 0x00,                    //  Logical Minimum (0)                103
# 0x26, 0xff, 0x00,              //  Logical Maximum (255)              105
# 0x09, 0xf3,                    //  Usage (Vendor Usage 0xf3)          108
# 0x75, 0x08,                    //  Report Size (8)                    110
# 0x95, 0x14,                    //  Report Count (20)                  112
# 0x81, 0x02,                    //  Input (Data,Var,Abs)               114
# 0x09, 0xf4,                    //  Usage (Vendor Usage 0xf4)          116
# 0x75, 0x08,                    //  Report Size (8)                    118
# 0x95, 0x02,                    //  Report Count (2)                   120
# 0x91, 0x00,                    //  Output (Data,Arr,Abs)              122
# 0xc0,                          // End Collection                      124

The Consumer Control is for the volume up and down key press. The Telephony Devices I still cant find to trigger anything for this input event. And of course there are the Vendor Usage Page which are the most interesting ones. The usage of those is "strange", the only one used seems to be the report 6 in a curious way: The total size is completely ignored, usually sending 64 bytes of data. For writing, a standard send feature is used, but for reading, some messages come as a input, so you have to listen to it, while others you have to issue a get feature.

Reverse engineering the software

Both the program and the AwToolLIB are made in C# mono and shipped with some obfuscation(.NET reactor). At first, I thought it wasn't obfuscated and lost a lot of time trying to understand fake symbols and hashed string constants. But after removing the string hashing with .NET reactor slayer and knowing some symbols were fake, it was relatively "easy" navigating the code with ILSpy. This code is pretty complete, containing all the classes to interface with their different devices and functions. It also includes some internal resources, including what seems to be the firmware (file headset_RTK).

Protocol

The protocol can be divided into two layers. The first layer is used to communicate with the Realtek driver to send commands to the Audio SoC, possibly through one of its serial interfaces (most probable UART, but it can also be SPI or I2C). The second layer is these commands.

RTK communication protocol

Messages are sent as a HID send feature. On every message sent, an ack is received as a HID input event. For example, an OK ack looks like this:

0	1
6	90
Report ID	OK

The messages I found so far are the following.

Message	0	1	2	3	4	5	6	7	8
Enter Bootloader	6	1	3	0	0	0	0	0	0
Exit Bootloader	6	8	3	0	0	0	0	0	0
Send command	6	4	3	CMD_LEN	CMD_LEN	.	.	.	.

The write command message is appended with the command at the end and requires entering the bootloader or strange and unusable behaviors will happen. Unfortunately, entering the bootloader will stop the audio functionalities.

Commands

On top of the RTK protocol, the manufacturer has what it seems to be a proprietary command-response protocol. For sending a command, a RTK write is used and for reading the response, a hid get feature is used.

Here is a quickly done dump of all commands I found. Keep in mind that some of these commands append arguments at the end, and surely I messed up writing some of them. Also, the bytes 4 is used to write the length in bytes of the command after this byte (sometimes is this length - 1). The byte 3, if 0 and the total command length is more than 5, is used as a command counter which gets incremented until 128.

It is curious that all of them start with [80,65]. Most of the commands seem to follow the following format, with a lot of exceptions.

0	1	2	3	4	5
Always 80	Always 65	Command "category"	Generally commands sent counter	Generally length after this byte	Command ID

The commands category seems to be the following. Also, take it with a grain of salt.

Value	Category
0	-
1	-
2	-
3	Debug
4	Audio
5	-
6	OTA
7	?
8	Customer custom commands
9	DSP
10	Noise cancellation
11	NVDS (Non-volatile memory)
12	Touch
13	-
14	Wireless connection
15	RF test

The responses are another story that I might explore in a future blog post. The responses are read as 64 bytes blocks with an HID get feature at the report 6.

Bluetooth scan example

As an example, the following python snippet does a Bluetooth scan, listing all devices found.

Pairing sequence

Looking at the pairing software logs, I can extrapolate the following sequence to pair a dongle with a headset. To illustrate, let's say that the Bluetooth MAC address of the headsets is [X0, X1, X2, X3, X4, X5]. The bytes relative to the standard command are underlined. Counter is the commands counter I mentioned on the protocol section.

Enter Bootloader
Sends LQ_DFU_BT_INQUIRY_SCAN (80, 65, 14, counter, 2, 240, 00) to enumerate all the Bluetooth devices.
Sends TX_DG_CREATE_CONNECT_EX (80, 65, 14, counter, 9, 229, 00, X5, X4, X3, X2, X1, X0) to pair the dongle with the headsets.
Sends REMOTE_GET_CONNECT_STATUS (80, 65, 14, counter, 1, 227) to check that the pairing was successful. If it fails, it retries the previous step.
Sends REMOTE_GET_MODE (80, 65, 14, counter, 1, 224) to get the "mode", maybe related to the connection mode on the headset (Bluetooth or lightspeed)?. If it is 01, it skips to the last step.
Sends REMOTE_SET_MODE (80, 65, 14, counter, 2, 225, 01) to set the mode to 01.
Sends REMOTE_GET_MODE (80, 65, 14, counter, 1, 224) to check that the mode has changed to 01.
Sends OTA_CMD_GET_IMAGE_VERSION (80, 65, 6, counter, 4, 0, 52, 01, 77, 67) to checks that the headset and the update tool (I think) firmware version are the same.

So, can we read the battery level?

Yes, but as it requires sending a command, so entering the bootloader, a cut on the audio will be produced which is bothering. Maybe this is why Logitech doesn't support these headphones on their software programs?. Here was where I lost interest in this, as the main reason I started researching about these headphones was for knowing the battery level. There are a lot of commands and fun things still worth exploring, which can result in interesting information for implementing an app for these headsets, but this is it for now.

USB HID Down the rabbit hole: Reverse engineering the Logitech CU0019 USB receiver

endes0 — Thu, 30 May 2024 09:04:12 +0000

Recently, I have an obsession with USB HID devices. So let's go through this rabbit hole. These devices send a descriptor which specifies the format of the "packets" they send or receive. Most fields are defined in the standard, so your hid driver can interact with the device out of the box. Some devices implement curious fields, like my headphones can send phone "events" like calls.
Most of them implement custom vendor specific fields. This is where it gets interesting.

Let's introduce my laptop mouse (below is Jaime playing with it), it's a Logitech M185. Almost all the Logitech hid devices implement their proprietary standard hid++, which is well-known. Mine is the exception.

It uses the CU0019 dongle (aka PID C542), here are some internal photos thanks to the FCC.

Nano Receiver with USB ID C542 does not use HID++ #1835

yesimxev posted on Nov 10, 2022

Dmesg log

[21837.663373] usb 2-2: new full-speed USB device number 9 using xhci_hcd
[21837.815411] usb 2-2: New USB device found, idVendor=046d, idProduct=c542, bcdDevice= 3.02
[21837.815419] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[21837.815422] usb 2-2: Product: Wireless Receiver
[21837.815424] usb 2-2: Manufacturer: Logitech
[21837.819645] input: Logitech Wireless Receiver Mouse as /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/0003:046D:C542.000D/input/input38
[21837.819801] hid-generic 0003:046D:C542.000D: input,hidraw0: USB HID v1.11 Mouse [Logitech Wireless Receiver] on usb-0000:00:14.0-2/input0

Describe the bug Adapter CU0019 not recognised (same on windows Logitech utilities). Tried multiple of these adapters.

To Reproduce

Plug in
Start solaar

Screenshots

View on GitHub

It uses the Telink TLSR8366. While Telink openly publishes a lot of tools, documents and code on their website, it is an amalgam of things which don't do a good job explaining themselves, so most of the time I was like "huh?". Oh, they also implement their own ISA called TC32, which is undocumented. Fortunately, GitHub users trust1995 and rgov have done a fairly decent job of implementing it on Ghidra.

trust1995 / Ghidra_TELink_TC32

Ghidra processor specification for the Telink TC32

Telink TC32 Processor Specification for Ghidra

This repository contains a fairly complete processor specification for the Telink TC32 architecture, used by all of Telink's System-On-Chips. The work herein is based on Ryan Govostes' work and extended with various fix-ups and actual P-code implementation.

Right now decompilation is working well with several tested TC32 ELFs.

Usage

Copy the Telink_TC32 repository to Ghidra/Processors. Restart Ghidra Afterwards, when importing a TC32 binary, when prompted for the binary's "Language", select the "Telink_TC32" processor.

For analysing Telink ELFs, I use the following process (using some plugins from my GhidraPlugins repo):

Import the binary, do not Auto-Analyse
Run the fix_funcnames.py plugin
Run the disas_symbols.py plugin
Run the Auto-Analysis, without call convention identification
Parse the register header file into the Data Type Manager (Grab the Telink SDK, redefine the REG_ADDR%X macros in register_82XX.h as integers instead of as pointers)
Export the register/defines values just imported from…

View on GitHub

The HID descriptor, apart from the standard mouse report, exposes a vendor report with ID 5. This report has a feature (aka input and output interface) of 7 bytes. Reading from it returns nothing.



0x90,              // Output
0x05, 0x01,        // Usage Page (Generic Desktop Ctrls)
0x09, 0x02,        // Usage (Mouse)
0xA1, 0x01,        // Collection (Application)
0x85, 0x01,        //   Report ID (1)
0x09, 0x01,        //   Usage (Pointer)
0xA1, 0x00,        //   Collection (Physical)
0x05, 0x09,        //     Usage Page (Button)
0x19, 0x01,        //     Usage Minimum (0x01)
0x29, 0x05,        //     Usage Maximum (0x05)
0x15, 0x00,        //     Logical Minimum (0)
0x25, 0x01,        //     Logical Maximum (1)
0x95, 0x05,        //     Report Count (5)
0x75, 0x01,        //     Report Size (1)
0x81, 0x02,        //     Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)
0x95, 0x01,        //     Report Count (1)
0x75, 0x03,        //     Report Size (3)
0x81, 0x01,        //     Input (Const,Array,Abs,No Wrap,Linear,Preferred State,No Null Position)
0x05, 0x01,        //     Usage Page (Generic Desktop Ctrls)
0x09, 0x30,        //     Usage (X)
0x09, 0x31,        //     Usage (Y)
0x16, 0x01, 0x80,  //     Logical Minimum (-32767)
0x26, 0xFF, 0x7F,  //     Logical Maximum (32767)
0x75, 0x10,        //     Report Size (16)
0x95, 0x02,        //     Report Count (2)
0x81, 0x06,        //     Input (Data,Var,Rel,No Wrap,Linear,Preferred State,No Null Position)
0x09, 0x38,        //     Usage (Wheel)
0x15, 0x81,        //     Logical Minimum (-127)
0x25, 0x7F,        //     Logical Maximum (127)
0x75, 0x08,        //     Report Size (8)
0x95, 0x01,        //     Report Count (1)
0x81, 0x06,        //     Input (Data,Var,Rel,No Wrap,Linear,Preferred State,No Null Position)
0xC0,              //   End Collection
0xC0,              // End Collection
0x05, 0x01,        // Usage Page (Generic Desktop Ctrls)
0x09, 0x00,        // Usage (Undefined)
0xA1, 0x01,        // Collection (Application)
0x85, 0x05,        //   Report ID (5)
0x06, 0x00, 0xFF,  //   Usage Page (Vendor Defined 0xFF00)
0x09, 0x01,        //   Usage (0x01)
0x15, 0x81,        //   Logical Minimum (-127)
0x25, 0x7F,        //   Logical Maximum (127)
0x75, 0x08,        //   Report Size (8)
0x95, 0x07,        //   Report Count (7)
0xB1, 0x02,        //   Feature (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile)
0xC0,              // End Collection

// 91 bytes

Getting a firmware dump

I started the house by the roof, instead of trying to fuzz the vendor report, I tried to dump the firmware "the hardware way". These chips have a SWIRE pin, which is a proprietary protocol for debugging and accessing the memory. This interface requires a Telink EVK tool, which isn't cheap, but GitHub user pvvx has written some tools for reading and writing the memory. The 826X tools are compatible with the 836x series.

pvvx / TlsrComSwireWriter

TLSR826x/825x COM port Swire Writer

TlsrComSwireWriter

TLSR826x/825x COM port Swire Writer Utility

Telink SWIRE simulation on a COM port.

Using only the COM port, downloads and runs the program in SRAM for TLSR826x or TLSR825x chips.

COM-RTS connect to Chip RST or Vcc.

usage: ComSwireWriter [-h] [--port PORT] [--tact TACT] [--file FILE] [--baud BAUD]

TLSR826x ComSwireWriter Utility version 21.02.20

optional arguments:
    -h, --help            show this help message and exit
    --port PORT, -p PORT  Serial port device (default: COM1)
    --tact TACT, -t TACT  Time Activation ms (0-off, default: 600 ms)
    --file FILE, -f FILE  Filename to load (default: floader.bin)
    --baud BAUD, -b BAUD  UART Baud Rate (default: 230400)

Added TLSR825xComFlasher:

usage: TLSR825xComFlasher.py [-h] [-p PORT] [-t TACT] [-c CLK] [-b BAUD] [-r]
                             [-d]
                             {rf,wf,es,ea}
TLSR825x Flasher version 00.00.02

positional arguments:
  {rf,wf,es,ea}         TLSR825xComFlasher {command} -h for additional help
    rf                  Read Flash to binary file
    wf                  Write file to Flash with sectors erases
    es                  Erase Region (sectors)

…

View on GitHub

After adapting the tools to use my FTDI ft2332HL board and dumps the memory and soldering cables to the reset and Swire pin (fortunately these pins aren't connected to anything), the dumper kinda worked. It was very unstable, but the data seemed good (it wasn't). Seeing the KNLT, Logitech, Wirless Receiver and TLSR8366 strings was a good confirmation that it wasn't just garbage.

// Detect dark theme var iframe = document.getElementById('tweet-1793635090746257531-109'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1793635090746257531&theme=dark" }

I could have wasted countless days trying to work with this dump, hopefully, I decided to do things right and started fuzzing the HID vendor report using a fastly written Python script. The results were, let's say, very verbose. A lot of send commands responded with data. Also, I thought I bricked the device as the mouse stopped working, luckily a reset fixed it.

On the results instantaneously something catches my attention. When the fuzzer was changing the data of the second byte, the received data was like sliding.



i: -064 j: -082 send dat: [5, 192, 174, 0, 0, 0, 0, 0]   recv dat: [0, 0, 0, 128, 3, 8, 33, 132]
i: -064 j: -081 send dat: [5, 192, 175, 0, 0, 0, 0, 0]   recv dat: [0, 0, 128, 5, 3, 8, 33, 132]
i: -064 j: -080 send dat: [5, 192, 176, 0, 0, 0, 0, 0]   recv dat: [0, 128, 5, 0, 3, 8, 33, 132]
i: -064 j: -079 send dat: [5, 192, 177, 0, 0, 0, 0, 0]   recv dat: [128, 5, 0, 0, 3, 8, 33, 132] 
i: -064 j: -078 send dat: [5, 192, 178, 0, 0, 0, 0, 0]   recv dat: [5, 0, 0, 0, 3, 8, 33, 132] 
i: -064 j: -077 send dat: [5, 192, 179, 0, 0, 0, 0, 0]   recv dat: [0, 0, 0, 0, 3, 8, 33, 132] 
i: -064 j: -076 send dat: [5, 192, 180, 0, 0, 0, 0, 0]   recv dat: [0, 0, 0, 0, 3, 8, 33, 132]  
i: -064 j: -075 send dat: [5, 192, 181, 0, 0, 0, 0, 0]   recv dat: [0, 0, 0, 147, 3, 8, 33, 132] 
i: -064 j: -074 send dat: [5, 192, 182, 0, 0, 0, 0, 0]   recv dat: [0, 0, 147, 0, 3, 8, 33, 132]    
i: -064 j: -073 send dat: [5, 192, 183, 0, 0, 0, 0, 0]   recv dat: [0, 147, 0, 0, 3, 8, 33, 132]
i: -064 j: -072 send dat: [5, 192, 184, 0, 0, 0, 0, 0]   recv dat: [147, 0, 0, 0, 3, 8, 33, 132]

My intuition was that we were reading memory!. I quickly write a dumper and Tachan! We got a more stable, easy and correct dump.

// Detect dark theme var iframe = document.getElementById('tweet-1794070181775327239-961'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1794070181775327239&theme=dark" }

Beyond are the scripts I made for dumping, they are crappy and require the hid-tools package.

Analyzing the firmware dump

After renaming the symbols of the startup code according to the names on the boot c startup assembly code of the SDKs, I found that a constant was different from those. After a quick GitHub code search, VOILA here are the possible SDK they used.

I'm lazy, I wanted to generate a Fidb for Ghidra to automatically recognize functions from the SDK, especially the ones related to USB, but I didn't want to setup and compile the SDK. Fortunately, there was a precompiled bin with its symbols on one of the repos.

A great find

After generating a Fidb and doing an analysis, for me, it was clear to me that the firmware was a slightly modified version of the 8366_dongle project on that repo(I already had my suspicions at the moment I opened the disassembly of the bin).

After a little bit of digging, tachan! This seems to be the code that handles the vendor HID Report.


 Cpp
        case HID_REPORT_CUSTOM:
#if (USB_CUSTOM_HID_REPORT)
        {   //Paring, EMI-TX, EMI-RX
            if (data_request) {
                int i=0;
                usbhw_reset_ctrl_ep_ptr (); //address
                for(i=0;i<8;i++) {
                    host_cmd[i] = usbhw_read_ctrl_ep_data();
                }
#if (USB_CUSTOM_HID_REPORT_REG_ACCESS)
                custom_reg_cmd = (host_cmd[1] & 0xf0) == 0xc0;
                if (custom_reg_cmd) {
                    host_cmd[0] = 0;
                    int adr = *((u16 *)(host_cmd + 2));
                    int len = host_cmd[1] & 3;
                    if (host_cmd[1] == 0xcc && adr == 0x5af0) { //re-enumerate device
                        usb_dp_pullup_en (0);           //disable device
                        sleep_us (300000);
                        reg_ctrl_ep_irq_mode = 0xff;    //hardware mode
                        usb_dp_pullup_en (1);           //enable device
                    }
                    else {
                        adr += 0x800000;
                    }

                    if ((host_cmd[1] & 0x0c)==0) {  //write core register
                        if (len == 0) {
                            for (int k=0; k<4; k++) {
                                custom_read_dat = (custom_read_dat >> 8) | (read_reg8 (adr++) << 24);
                            }
                        }
                        else if (len == 1) {
                            write_reg8 (adr, host_cmd[4]);
                        }
                        else if (len == 2) {
                            write_reg16 (adr, *((u16 *)(host_cmd + 4)));
                        }
                        else {
                            write_reg32 (adr, *((u32 *)(host_cmd + 4)));
                        }
                    }
                    else {  //read core register
                        if (len == 0) {
                            custom_read_dat = analog_read (host_cmd[2]);
                        }
                        else {
                            analog_write (host_cmd[2], host_cmd[4]);
                        }
                    }
                }

...

        case HID_REQ_GetReport:
#if(USB_SOMATIC_ENABLE)
            if(usbsomatic_hid_report_type((control_request.wValue & 0xff))){
            }
            else
#elif (USB_CUSTOM_HID_REPORT)
            if( control_request.wValue==0x0305 ) {
                if (USB_CUSTOM_HID_REPORT_REG_ACCESS && custom_reg_cmd) {
                    usbhw_write_ctrl_ep_data (custom_read_dat);
                    usbhw_write_ctrl_ep_data (custom_read_dat>>8);
                    usbhw_write_ctrl_ep_data (custom_read_dat>>16);
                    usbhw_write_ctrl_ep_data (custom_read_dat>>24);
                    usbhw_write_ctrl_ep_data (0x10);
                    usbhw_write_ctrl_ep_data (0x20);
                    usbhw_write_ctrl_ep_data (0x40);
                    usbhw_write_ctrl_ep_data (0x80);
                }
                else {
                    usbhw_write_ctrl_ep_data (0x04);
                    usbhw_write_ctrl_ep_data (0x58);
                    usbhw_write_ctrl_ep_data (0x00);
                    usbhw_write_ctrl_ep_data (host_cmd_paring_ok ? 0xa1 : 0x00);  //For binding OK
                    usbhw_write_ctrl_ep_data (0x00);
                    usbhw_write_ctrl_ep_data (0x00);
                    usbhw_write_ctrl_ep_data (0x08);
                    usbhw_write_ctrl_ep_data (0x00);
                }
            }
            else
#endif          
            {   //  donot know what is this
    //          usbhw_write_ctrl_ep_data(0x81);
    //          usbhw_write_ctrl_ep_data(0x02);
    //          usbhw_write_ctrl_ep_data(0x55);
    //          usbhw_write_ctrl_ep_data(0x55);
            }
            break;

/proj/drivers/usb.c


 Cpp
void usb_host_cmd_proc(u8 *pkt)
{
    extern u8       host_cmd[8];
    extern u8       host_cmd_paring_ok;

    u8   chn_idx;
    u8   test_mode_sel;
    u8   cmd = 0;
    static emi_flg;


    if((host_cmd[0]==0x5) && (host_cmd[2]==0x3) )
    {
        host_cmd[0] = 0;
        dongle_host_cmd1 = host_cmd[1];

        if (dongle_host_cmd1 > 12 && dongle_host_cmd1 < 16){  //soft paring
            host_cmd_paring_ok = 0;
            rf_paring_tick = clock_time();  //update paring time

            if(dongle_host_cmd1 == 13){     //kb and mouse tolgether
                mouse_paring_enable = 1;
                keyboard_paring_enable = 1;
            }
            else if(dongle_host_cmd1 == 14){ //mouse only
                mouse_paring_enable = 1;
            }
            else if(dongle_host_cmd1 == 15){  //keyboard only
                keyboard_paring_enable = 1;
            }
        }
        else if(dongle_host_cmd1 > 0 && dongle_host_cmd1 < 13)  //1-12:����EMI
        {
            emi_flg = 1;
            cmd = 1;

            irq_disable();
            reg_tmr_ctrl &= ~FLD_TMR1_EN;
            //rf_stop_trx ();

            chn_idx = (dongle_host_cmd1-1)/4;
            test_mode_sel = (dongle_host_cmd1-1)%4;
        }
    }

    if(emi_flg){
        emi_process(cmd, chn_idx,test_mode_sel, pkt, dongle_cust_tx_power_emi);
    }
}

/vendor/dongle/dongle_emi.c

Mouse Device ID

I think I also found the memory address where the current paired Mouse is stored(custom_binding[0]): 0x809160. I can't confirm it as I don't have another mouse and the value is a little bit off for me.

Potentially, this can be used to send a USB HID read memory and obtain the current mouse ID.

Ghidra symbols

Here are all the symbols I found, it can be imported with the ImportSymbolsScript.py.

USB HID custom commands

So, after analyzing the firmware, fuzzer output and doing some test, I found the following USB HID set feature commands.

1	2	3	4	5	6	7	Description
0xD	0x3	-	-	-	-	-	Software pairing: Mouse and keyboard
0xE	0x3	-	-	-	-	-	Software pairing: Mouse
0xF	0x3	-	-	-	-	-	Software pairing: Keyboard
0x1	0x3	-	-	-	-	-	EMI: channel low, mode carrier
0x2	0x3	-	-	-	-	-	EMI: channel low, mode cd
0x3	0x3	-	-	-	-	-	EMI: channel low, mode rx
0x4	0x3	-	-	-	-	-	EMI: channel low, mode tx
0x5	0x3	-	-	-	-	-	EMI: channel medium, mode carrier
0x6	0x3	-	-	-	-	-	EMI: channel medium, mode cd
0x7	0x3	-	-	-	-	-	EMI: channel medium, mode rx
0x8	0x3	-	-	-	-	-	EMI: channel medium, mode tx
0x9	0x3	-	-	-	-	-	EMI: channel high, mode carrier
0xA	0x3	-	-	-	-	-	EMI: channel high, mode cd
0xB	0x3	-	-	-	-	-	EMI: channel high, mode rx
0xC	0x3	-	-	-	-	-	EMI: channel high, mode tx
0xC0	addr&0xff	(addr>>8)&0xff	-	-	-	-	Memory: read 32 bits from addr + 0x800000
0xC1	addr&0xff	(addr>>8)&0xff	dat	-	-	-	Memory: write 8 bits dat* to addr + 0x800000*
0xC2	addr&0xff	(addr>>8)&0xff	dat&0xff	(dat>>8)&0xff	-	-	Memory: write 16 bits dat* to addr + 0x800000*
0xC3	addr&0xff	(addr>>8)&0xff	dat&0xff	(dat>>8)&0xff	(dat>>16)&0xff	(dat>>24)&0xff	Memory: write 32 bits dat* to addr + 0x800000*
0xC4	addr	-	-	-	-	-	Memory: read analog address addr
0xC5	addr	-	dat	-	-	-	Memory: write 8 bits dat at analog address addr
0xCC	0xF0	0x5A	-	-	-	-	Misc: "renumerates USB devices"

Notes: Take the italics entries with a grain of salt, as I didn't test it. Byte 0 is always the report ID, in this case 5.

It seems that software pairing is broken, Keyboard and Mouse pairing command always return success while the other 2 never succeed. Also, all the pairing commands disconnect the mouse, and it won't work until restarting the dongle.

Issuing the "renumerate" command will connect the device as a USB printer "Telink Semiconductor USB DevSys" with VID 248A and PID 5320. Maybe this is the "USB programming mode" for interfacing with Telink BDT tools? Taking a look at the sources of web BDT tool, the PID doesn't seem to match. So I thought it wasn't.


 Javascript
async function  usb_connect(){
    const myfilters = [
      { 'vendorId': 0x2341, 'productId': 0x8036 },
      { 'vendorId': 0x248A, 'productId': 0x826A }, ]; //'productId': 0x826A

The analog read I think it reads the "3.3V analog registers" referenced in the datasheet.

Another "great" dump

Before I said that when the device renumerates as "Telink Semiconductor USB DevSys" maybe it is for the BDT tools, well after launching the desktop tools on Windows, it connects, so it is.

This is great as we can have total access to all the memory spaces and also some debugging functions.

Let's just say that the memory access tool, well, umh, it's not great. The CORE access it also seems to start at address 0x800000, but if we read 0x808000 it seems to contain errors, or maybe another program.

The analog read works like the USB HID analog read, the flash read always returns 0xFF (In theory this chip doesn't have flash at all) and unfortunately the OTP read doesn't work. This is bad news, as the OTP memory is likely to have something.