Tuya Cloudcutter for Local-Only Firmware on Supported IoT Devices

Tuya Cloudcutter's Supported-Device Boundary

Tuya Cloudcutter addresses a narrow hardware and firmware category: Tuya-branded devices built around Beken BK7231T, BK7231N, or Realtek RTL8710BN and RTL8720CF chipsets when their firmware remains exploitable. The README lists examples such as WB3S, WB3L, CB3S, CBU, WR1, and WBR1, but examples are not a substitute for checking the specific model. The repository also supports devices with known secret values.

The defining boundary is the February 2022 SDK patch. Devices compiled against a patched SDK cannot be exploited by this toolchain, even when their product name or enclosure resembles a supported model. The README places patched Beken devices, patched RTL8720CF devices, and patched or non-vulnerable RTL8710BN devices in the unsupported category. Older RTL8710BN devices using SDK 2.0.0 are specifically described as apparently non-vulnerable.

Support also becomes less predictable on newer Realtek hardware. The RTL8720CF platform may lack profiles for some otherwise vulnerable devices until more samples are available. An address needed by the exploit chain can also prevent exploitation when it contains a null byte. RTL8710BN has two profiles for each firmware version, with only one expected to work for a particular device. These are device-specific compatibility constraints, not general statements about Tuya hardware.

The intended users are people who already own compatible hardware, understand the consequences of altering embedded-device firmware, and want local control after detaching the product from Tuya infrastructure. The tool can also serve educational and firmware-development work, but its README labels it experimental and limits its stated purpose to personal and educational use.

How the Dockerized Cloudcutter Workflow Reaches the Device

The repository separates the launcher, Python source, device profiles, proof of concept, and container environment. According to `Dockerfile`, the image pins Python 3.11 because the exploit depends on PSK TLS behavior with a binary PSK identity. Python 3.12 removed `ssl.wrap_socket()` and enforces UTF-8 PSK identities, while the documented dependency path expects `sslpsk3` 1.1.1 to pass the identity as raw bytes on Python 3.11 or earlier.

The operational boundary is the Wi-Fi adapter. The launcher selects it with `-w`, which defaults to `wlan0`, verifies that it exists, and moves it into the container's network namespace. From that point, scanning, joining the Tuya access point, DHCP, DNS, MQTT, and hosting the CloudCutter access point occur inside the container. Host NetworkManager is not used for those operations. This arrangement gives the tool direct control over the network interfaces and services needed during the process.

The documented vulnerability writeup describes the underlying exploit chain, while `proof-of-concept/poc.py` is identified as the proof of concept. The repository's `device-profiles/` directory contains the profiles used to target particular devices, while `profile-building/` and `scripts/` provide supporting repository areas. The README does not provide enough detail to describe every protocol exchange in the exploit, and it does not document a rollback procedure.

The end result can be local operation without Tuya applications and servers, or installation of custom firmware over the air. These are materially different uses. Detaching removes access to the vendor's cloud-dependent controls. Flashing replaces the device's firmware behavior and therefore requires a correct device profile and compatible image.

Host Preparation with install-requirements.sh

The host needs Linux networking support, Docker with the Docker CLI, and `iw`. A stand-alone Wi-Fi adapter with AP mode support is also required. The adapter must not be the computer's primary network connection, and the README recommends Ethernet for that connection because the adapter is moved fully into the container for the duration of a run. Moving it into the container network namespace requires sudo or equivalent elevated privileges.

The repository provides a script that installs missing host packages through the system package manager. The README gives this command exactly:

sudo ./install-requirements.sh

The script is intended to install whatever host requirements are missing, including Docker and `iw`. Its exact package selection is delegated to the host's system package manager and is not fully listed in the README excerpt. An internet connection is described as somewhat optional: it is needed to download packages while building the container and to download new device profiles. A local build or previously available profile may therefore change the connection requirement.

After preparing the host, users should follow `INSTRUCTIONS.md` for the actual detaching or custom-firmware procedure. The README does not give a complete runnable exploit command, so this article does not invent one. `HOST_SPECIFIC_INSTRUCTIONS.md` covers setups on devices such as Raspberry Pi. Before changing firmware, identify the exact device and compare it with the repository's supported and patched firmware information. The expected result of installation is a usable Docker environment and an available adapter; neither condition confirms that the target device itself is exploitable.

Choosing Detaching or Custom Firmware in Cloudcutter

Cloudcutter supports two distinct outcomes, and the README's warning applies particularly to the first. Detaching disconnects a Tuya device from Tuya's cloud so it can operate locally. Once detached, the original Tuya applications and servers are no longer available to that device. The README says this in unusually direct terms: using Tuya CloudCutter means no further use of Tuya's apps and servers. A buyer who expects occasional cloud control cannot treat the process as a reversible setting change.

Custom firmware serves a different purpose. It can be flashed over the air, subject to device support and compatibility. The presence of `custom-firmware/` indicates a place for firmware images, but the README excerpt does not identify a universal image or document a universal image-selection procedure. Users must not assume that an image built for one Tuya-branded product is valid for another product with a similar name.

Patched devices expose the clearest trade-off. According to the README, a device compiled against patched firmware is not exploitable through Cloudcutter, but third-party firmware may still be applied through serial. That makes serial flashing a different approach for a class of hardware Cloudcutter cannot address over the air. It changes both the access method and the software path rather than attempting to reuse the supported wireless exploit.

The README also points to Lightleak as a related project for dumping unexploited firmware and says that expanding it into a flashing tool could be useful. It does not present Lightleak as a currently supported Cloudcutter alternative for the full detach workflow. For evaluation purposes, serial firmware replacement is the documented alternative for patched devices, while Lightleak is presented as a possible direction rather than a replacement with documented workflow parity.

Cloudcutter Risks, Recovery Gaps, and MIT Licensing

The principal operational risk is loss of vendor functionality. Detaching deliberately removes access to Tuya's applications and servers, so local operation may replace cloud configuration, remote control, or account-linked behavior. The README also warns that the software is experimental and carries no guarantees from the authors. That warning is material because device support depends on chipset, firmware patch level, profile availability, and properties such as null bytes in required exploit addresses.

Another risk is ambiguous firmware state. The repository does not document a rollback command in the README, and the top-level layout does not establish an automatic backup-and-restore path. It points to custom firmware and profile-building resources, but those entries do not prove that every device image can be reverted after a failed flash. Someone adopting the project should determine what recovery path their chosen firmware image supports before beginning.

The repository is licensed under the MIT License. That identifier permits use and modification under the license's terms, including its notice and warranty conditions, while the repository's separate experimental-use warning limits how the authors describe intended use. This is not legal advice. Users still need to consider device ownership, local law, firmware licensing, and the consequences of changing product behavior.

The repository is not archived, and its last push was on 2026-10-03. That indicates recent repository activity, but there are no GitHub releases. There is consequently no documented release train or versioned upgrade path. Container changes, new device profiles, and future firmware revisions can therefore add operational variables without a release-based migration plan.

Editorial conclusion

Adopt Tuya Cloudcutter only when you have a supported, unpatched BK7231T, BK7231N, RTL8710BN, or RTL8720CF device, can provide the required Linux host and dedicated Wi-Fi adapter, and are prepared to give up Tuya applications and servers. Do not adopt it for patched firmware or expect it to be a reversible cloud-control switch. Verify the exact model and firmware against the project's supported or patched lists, read `INSTRUCTIONS.md`, and inspect the `device-profiles/` entries before modifying the device. For a patched device that accepts third-party firmware, serial flashing is the documented alternative approach.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. tuya-cloudcutter/tuya-cloudcutter on GitHub