µPy FT10

Searching for more resources on this MCU platform, I discovered that the vendor put a playlist on YouTube where an engineer goes over every aspect of the hardware and SDK.

Based on the reverse engineering efforts outlines in the last logs, I developed a python utility similar to esptool - which I hence named rtltool.

The functionality is very rudimentary. It provides commands for reading, erasing, writing and verifying contents of the micro controllers flash via UART.

To obtain a complete flash dump of the FT10 smart watch, run

./rtltool.py read_flash 0x00800000 0x00800000 ft10-flash_dump.bin

 This can then be verified with

./rtltool.py verify_flash 0x00800000 ft10-flash_dump.bin

After using the flashing tool to create a flash dump for backup reasons, I read a 8kiB (0x2000) section of the start of flash and then wrote it back using the User Data feature of the tool.

The MessageBox logs two EraseFlash and then two consecutive WriteFlash and VerifyFlash events.

This is also visible in the captured signals. I also tested the Chip Erase function of the tool and captured its operation and response code. By checking the numbers of bytes transmitted, recording more examples and using reveng I found more uses of the CRC.

After finding a repository with software utilities for this chip, I tried to use the MPTool, which after first inspections seems to provide flash read, erase and write functionalities. When clicking the Detect button it lists all available COM ports and enables the Open button. When clicking this, all ports returned fail.

On the smart watch I found five labeled test points - GND, RX, TX, RST and LOG. To make everything more accessible I opened and unfolded the smart watch into a perf board. The PCB is held in place by tiny screws through it's original mounting holes, which land in holes of the perf board. The test points are connected with small solid core wires to the header on the top left.

I removed the sticker antenna from the watch housing and used a short length of wire to solder it to a test point that is opposite to the spring that normally makes contact with the antenna. I also used more solid core wires to give easy access to the LCD signals for probing at the bottom pin header.

The image shows an FT232 also used as logic analyzer. Due to bad performance and sample rate discrepancies I later switch to a Saleae Logic clone

Handshake

After some testing around, I found out that the LOG signal acts like as a strapping pin, similar to GPIO0 of the ESP32. If it is pulled to GND during hardware reset, one of the the COM ports report OK when clicking the Open button. This is caused by a handshake, which consist of a magic byte string that is answered by the MCU with another magic byte string.

Flasher Stub

Sadly apart from the handshake, nothing else seemed to work under wine. Trying to read flash content caused the application to freeze after transferring a bunch data, as indicated by the LEDs od the USB UART adapter. Therefore I was forced to use with a Windows VM instead of wine.

According to the Memory User Guide the flash starts at address 0x00800000. Reading the first 1kiB (0x400) the tool prints the following logs in the message box.

It logs four events called OpenPort, DownloadFW, UpdateBaudrate and ReadFlash. These events are clearly visible when looking at the signal

Looking through the files next to the flasher tool I found one called firware0.bin. Comparing its content with the recording, I found the section where it's transmitted. This is reminiscent of the flasher stub of esptool.

$ xxd -g 1 Bee2MPTool_kits_v1.0.4.0/Bee2MPTool/Image/firmware0.bin | head -n 2
00000000: 05 00 03 01 92 27 00 00 00 01 00 00 6d 67 de f1  .....'......mg..
00000010: 3e 33 e8 11 b1 02 4d 2d f4 0c de 01 f0 38 20 00  >3....M-.....8 .

All frames but the last was are preambled with 0120FC, followed by one bytes containing the length of the rest of the frame, then one byte with the frame number, followed by up to 252 bytes of data. Every frame is acknowledged by the MCU with 040E0502FC00 followed by one byte with the frame number.

After the last frame is finished, a magic sequence is transmitted, that presumably causes the stub to run, which is acknowledged with 040E040262FC00. After ~100ms delay the MCU sends another 70 bytes, presumably containing some information about it, like version number and address ranges.

Side note: at this point is seems that every response from the MCU ends with FC00.

Baud Rate Change

After receiving the last response from the MCU, the flashing tool sends the UpdateBaud command. The baudrate 921600 (0xe1000) can be seen as a 32 bit value with the LSB send first.

After that the tool sends three further bytes. The response starts with the same three bytes as the request, then five 00 bytes and two more. Suspecting that the two bytes at the end are a CRC, I processed the byte strings with reveng.

$ ./reveng -w 16 -s 87101000100E00FF7F94 87101000000000005AD7
./reveng: warning: you have only given 2 samples
./reveng: warning: to reduce false positives, give 4 or more samples
width=16  poly=0x8005  init=0x0000  refin=true  refout=true  xorout=0x0000  check=0xbb3d  residue=0x0000  name="CRC-16/ARC"

Although printing a warning about the number of samples being too low, it still gives us a result, that even has the name CRC-16/ARC and when plugging the byte strings into crccalc.com, the result is 0.

Flash Read

~400ms after the MCU acknowledges the baud rate change, the flasher tool begins to transmit again, now with the new baud rate.

After that no more signals were transmitted.

Clicking the ReadAll button in the flashing tool, I seems that reads are transmitted in 1kiB big segments.

A quick search for RTL8762CK on the usermanualwiki yields some results, such as the SDK User Guide outlining general firmware development steps as well as showcasing some programming software, the Memory User Guide showing the memory map, OTA User Manual describing an update mechanism over BLE, as well as the Flash User Guide and Peripheral Manual documenting some hardware function interfaces of the SDK.

Looking for the IC marking RTL8762 on GitHub one finds a repository containing an RTL_Tools directory with zip files.

Following the wine wiki I redirected /dev/ttyUSB0 to COM0 with wine regedit.

Running wine Bee2MPTool_kits_v1.0.4.0/Bee2MPTool/MPTool.exe for the first time crates a Log directory and MPToolSetting.ini file. The title screen let's one choose between IC types and languages

After that one isn't greeted with many options. Clicking the unlock button let's one set a password which later can be used to unlock again, and is stored as plaintext in the ini file.

It's only after running wine Bee2MPTool_kits_v1.0.4.0/Registry\ Set/RegistrySet.exe That the Type menu of the window becomes available. The RegistrySet.exe simply adds the key RTKMPToolKey to the HKEY_CURRENT_USER in the registry.

Switching from Type>MP to Type>Debug switches the window content to an interface the appears to be used for reading and writing sections of the flash.

The MCU on the watch is marked RTL8762CK.

One seller listed the "G-sensor" as STK8321, which is a "Digital Output 3-axis MEMS Accelerometer" featuring I²C and some interrupt pins.

I also suspect the heart rate sensor and touch screen to be I²C devices.

The LCD is marked, but a search on the internet doesn't yield anything of relevance. The watch is advertised to have an 1.3 inch240x240 IPS LCD. It's connected via 18 Pins and a quick analysis with the scope showed bursts of 5MHz square waves packages on one signal, indicating either SPI or parallel bus. Maybe it's a ST7789 controller.