After more experiments it became apparent that for current devices the bootloader has been locked down, so no amount of pressing the ESC key will enable you to gain access.

Glitching It

Plan B was to try the "glitch" method. This is much higher risk and more complicated, but had been reported by others as working.

Step 1 was to figure out which pin from the flash controller was SCLK.

Flash controller with SCLK pin highlighted
Pinout for flash controller

Step 2 was to connect a wire from the SCLK pin to ground in order to stop the boot process. I did this carefully as there is a high chance of data loss if the wrong pins are used or you are clumsy!

Once I had access to the bootloader I tried to read the key directly from the flash, using the technique explained here.

Creating 5 MTD partitions on "flash_bank_1":
0x000000000000-0x000000020000 : "boot+cfg"
0x000000020000-0x000000200000 : "linux"
0x000000200000-0x000000400000 : "rootfs"
0x000000400000-0x000000420000 : "tuya-label"
0x000000420000-0x000001000000 : "jffs2-fs"

Partitions created on boot.

As others have found, once you get to the bootloader the entire tuya-label partition was entirely set to 0xFF 😦

Step 3 was to download the root filesystem, extract the files, change the /etc/passwd file and then recreate an image to upload. Thankfully this is all well explained here in the Gaining Initial Access section 😄

Finally the power was cycled and the device booted normally. Once it had finished, pressing Enter gave me a login prompt. Username and password were entered and I was in.

tuya-linux login: root
Password:

Tuya Linux version 1.0
Jan  1 00:01:44 login[116]: root login on 'console'
#

Enable SSH

Looking at the /tuya/tuya_user1/tuya_start_children.sh script shows

if [ -f "/tuya/enable_ssh_flag" ];then
        echo "enable ssh!"
else
        killall dropbear
fi    

The /tuya/tuya_net_start.sh script also has this

if [ -f "/tuya/enable_ssh_flag" ];then
        /tuya/ssh_monitor.sh &
else
        killall dropbear
fi

The actual SSH server is run via the /tuya/ssh_monitor.sh script, with the final line

/tuya/tuyadropbear -P /var/run/dropbear.tuya.pid -p 2333 -K 300 -T 1

I added the file /tuya/enable_ssh_flag and rebooted.

$ ssh root@xxxxxx -p 2333
root@xxxxxx's password: 
#

Success. However, I did edit the ssh_monitor.sh file to use the standard port by removing the -p 2333.

Updates?

As there was a firmware for the device, I decided to try and do the update while I still had serial access in case it replaced the rootfs. It didn't. All was good.

The new files were installed into /tuya/tuya_user2 and the previous files from /tuya/tuya_user1 were removed. The link to the new directory was set in /tuya/start.conf

tuya_start_dir=/tuya/tuya_user2

MAC Address

The MAC address used is stored in /tuya/config/License.file1 and /tuya/config/License.file2. The contents are an encrypted JSON dictionary but the contents can be accessed and set using the /tuya/tuyamtd utility.

# cd /tuya
# ./tuyamtd read master_mac
123456789abc

Practically, this means that copying files from one device to another will result in a MAC collision unless the stored value is changed. What can be read, can also be written.

# cd /tuya
# ./tuyamtd write master_mac 123456789def
# ./tuyamtd read master_mac
123456789def