Simulating TuyaMCU UART Communications: Tuya Module Debugging Assistant

To repeat and as a carry-on from here, I've started a new thread to highlight the usefulness of the Tuya Module Debugging Assistant (TMDA). Discoveries/queries to be added by anyone.

TLDR: TMDA can be used to simulate a TuyaMCU or a Tuya module, communicating over UART with either a real module or a real TuyaMCU, depending on which is connected to your USB-TTL.

This is the download for v2.1.3 that offers you an update to v2.2.3.5 (at the time of posting): https://images.tuyacn.com/smart/solution/deve...urce/aa68e8df-de83-5e2e-b8c1-d189b46168e9.zip. I attach both anyway to this thread.

After installing, the program launches in Chinese. Switchable to English easily.


To demonstrate how useful this application can be: sometimes I want to flash a factory firmware backup to a BK7231N dev module/board. Maybe I then want to pair with the Tuya app. Often though the firmware will not finish booting, or will just not be discoverable, until it receives a specific response from the TuyaMCU, which of course is not present because it's not running on the real device with everything in place. The TMDA will give the necessary responses so the module is discoverable.

The Function Point JSON file used in the attachment here https://www.elektroda.com/rtvforum/topic4062465.html#21280950 will allow the device to finish boot and be discoverable in the Tuya app but it will not complete pairing.


Here's the TMDA talking to a CBU flashed with a backup of this device https://www.elektroda.com/rtvforum/topic4083219.html. Without the TMDA to respond, it would not then discoverable in the Tuya app. I assume it gets stuck around here when it tries to talk to the TuyaMCU

but then with TMDA to respond (function point JSON file loaded -> open com port-> start debugging)


the boot log looks like:


note the MCU version and the product key match what I have set in TMDA


and the device is now discoverable in the Tuya app BUT it will not pair



but carrying on, we can change the {"Pro_Key":"kpp4upyyxrllgpzg" value in the JSON to match the pk discovered when exploring the original device. This key was revealed when sniffing the communications between the module and real MCU using TuyaMCU Analyser.



Often the pk is revealed in the UART boot log.

And so with the key changed to na90jncjlvw5t0ba in the JSON, the device now pairs.





And because you can set an arbitrary MCU version, you can fool the app into offering a TuyaMCU upgrade, if there is one available. I recall the Atorch S1-B offering an update to version 1.0.7 if the version was 1.0.6. And so it does again when testing with a backup of the firmware from that device using pk sqrf2g1amfutn4co:




And here is what TMDA looks like from unpaired device boot, pairing and then MCU upgrade file transfer to the device.


That, so far, is the extent of my playing. There are many more interesting functions to play with, including Hex Send

TMDA saves the receiving MCU update file to the ..\AppData\Roaming\Tuya\TYDEBUG\Wi-Fi\GeneralProtocol path. Eg:


so now we can capture those updates for analysis too

A collection of binaries

https://github.com/divadiow/TuyaMCUBins

I wonder if we could create our own small "TuyaMCU simulator" that would run inside a C++ class that could be used for two purposes, first, for self-testing OBK in simulator (without any hardware), and then, for testing physical WiFi module with simulated MCU.