{"id":1130,"date":"2022-12-21T16:00:38","date_gmt":"2022-12-21T15:00:38","guid":{"rendered":"https:\/\/security.humanativaspa.it\/?p=1130"},"modified":"2025-09-24T08:45:55","modified_gmt":"2025-09-24T08:45:55","slug":"a-journey-into-iot-unknown-chinese-alarm-part-4-internal-communications","status":"publish","type":"post","link":"https:\/\/hnsecurity.it\/it\/blog\/a-journey-into-iot-unknown-chinese-alarm-part-4-internal-communications\/","title":{"rendered":"A journey into IoT – Unknown Chinese alarm – Part 4 – Internal communications"},"content":{"rendered":"

Disclaimer: as many other security researchers approaching IoT, I have a background in computer science and I started to work on these subjects with little knowledge about electronics and often with a\u00a0\u201cYOLO\u201d approach<\/a> (blame it on an old colleague of mine \ud83d\ude42). So, it is definitely possible that many of the things you will read here can be inaccurate or can be done in a much better way, especially with more knowledge in the field. Sorry about that. I take advantage of this disclaimer to add a thing: pay particular attention when you put your hands on electronics, especially when you deal with cheap Chinese devices powered by 220V! Some capacitors can cause serious damages even if the device is not plugged into the electric socket!<\/em><\/p>\n

Today we will have a look at the ports we discovered in the first article<\/a> of this blog series<\/a> in our initial analysis with the device powered off. The ports we discovered were the following:<\/p>\n

\"\"<\/p>\n

We already analyzed the SWD port in the second article of the series<\/a>, using that port to dump the firmware. Now we will look at the two potential UART ports<\/strong> and to the unknown port named “RF”<\/strong> on the board.<\/p>\n

For this analysis we will use a logic analyzer<\/strong>, a hardware device able to read, show and often interpret digital signals. One of the best choices for this type of instrument is the Saleae Logic Analyzer<\/strong>,<\/a> that comes with an awesome software able to decode multiple protocols on its own. Depending on the model, the original Saleae Logic Analyzer costs from 400\u20ac to 1200\u20ac.<\/p>\n

Let’s start to analyze the UART communication port between our main ARM microcontroller and the Tuya WB3S wireless module. The easiest way to sniff communications is to connect the Saleae to the pins of the Tuya module, which are quite large on the board and very easy to reach. The documentation of the module gives us the location of the UART pins:<\/p>\n

\"\"<\/p>\n

The datasheet shows two serial ports (TXD1-RXD1 and TXD2-RXD2), but according to the documentation the second one should not be available to Tuya customers (but obviously we will verify that<\/strong>).<\/p>\n

UART Port 1 – Tuya module and ARM microcontroller<\/h3>\n

Let’s start with the fist serial port (TXD1-RXD1). During our initial analysis<\/a>, we hypothesized that this would be some kind of communication port between the main ARM micro-controller and the WiFi Tuya chip.<\/p>\n

To sniff communications we need to connect the logic analyzer to the pins of the serial UART port. A quick solution that does not require soldering is to use specific probes<\/strong>. At the office we have a great kit of hands-free probes by SensePeek<\/a>, but when working on this project I was at home and I had only a basic Chinese BDM frame:<\/p>\n

\"\"<\/p>\n

Once connected, we can run the Saleae software and power on our device. As we can see at the beginning of the track (when the device powers on) both pins pass from “Low” (~0V) to “High” (~3.3V) and then we can see some sort of potential communications (the vertical lines):<\/p>\n

\"\"<\/p>\n

If we zoom into the sections in which we saw the vertical lines, we can clearly see that probably some data is transmitted on those pins:<\/p>\n

\"\"<\/p>\n

We know from the Tuya documentation<\/a> that this port should be an UART port. The Saleae software already implements some modules name “Analyzers” able to decode many different protocols, including this one (named “Async Serial”). We can go to the “Analyzers” section (at the right) and add a new analyzer of type “Async Serial” on each of our two channels (that I renamed RXD1 and TXD1 for convenience). To be correctly interpreted, the UART protocol requires some parameters<\/strong>, among which the baud rate<\/strong>, the number of data bits and stop bits<\/strong> and the presence of a parity<\/strong> bit.<\/strong> Old versions of the Saleae software implemented auto-detection of the baud rate<\/strong> while newer ones don’t have this feature anymore. Anyhow, there are simple ways to manually estimate this value or we can use a dedicated Saleae plugin for the job, as described in the Saleae Support website<\/a>. For data, stop and parity bit we can follow a trial-and-error approach, but usually these protocols use only a couple of different configurations.<\/p>\n

Our “Async serial” parameters are the following:<\/p>\n

\"\"<\/p>\n

We can add this analyzer to both our channels and have a look at the decoded data (with a right click on the data we can select different data visualizations: binary, decimal, hexadecimal or ascii<\/strong>):<\/p>\n

\"\"<\/p>\n

UART ports work this way: the TX pin of one party is connected to the RX of the other and vice-versa. Each pin is used by a party to transmit and by the other to receive. The names I used in the screenshots are related to the Tuya side and consequently:<\/p>\n