/tuya-cloudcutter

A tool that disconnects Tuya devices from the cloud, allowing them to run completely locally.

Primary LanguagePythonMIT LicenseMIT

Tuya Cloudcutter

This repository contains the toolchain to exploit a wireless vulnerability that can jailbreak some of the latest smart devices built with the bk7231 chipset under various brand names by Tuya. The vulnerability as well as the exploitation tooling were identified and created by Khaled Nassar and Tom Clement with support from Jilles Groenendijk.

Our tool disconnects Tuya devices from the cloud, allowing them to run completely locally. Additionally, it can be used to flash custom firmware to devices over-the-air.

ℹ️ Do you like this tool? Please consider giving it a star on Github so it reaches more people. ✨

⚠️ WARNING⚠️

Using cloudcutter means that you will NO LONGER be able to use Tuya's apps and servers. Be absolutely sure that you are never going to use them again!

Additionally, please be aware that this software is experimental and provided without any guarantees from the authors strictly for peronal and educational use. If you will still use it, then you agree that:

  1. You understand what the software is doing
  2. You choose to use it at your own risk
  3. The authors cannot be held accountable for any damages that arise

How does it work?

If you're curious about the vulnerability and how the exploit chain works, here's the detailed writeup and the proof of concept script.

Requirements

  • A device with a stand-alone wifi adapter (but not be your primary source of networking, ethernet is preferred for that)
  • An account with sudo / elevated privlidges - An account capable of making network setting changes.
  • NetworkManager / nmcli - This is used to scan for Tuya APs, connect to them, and host a CloudCutter AP to run the exploit. If you run into issues, make sure your NetworkManager service is started. You may need to use the -r parameter if you continue to have issues.
  • Docker / Docker CLI package - This is used to create a controlled python environment to handle and run the exploit
  • An active internet connection (Somewhat optional) - This is used to download the packages to build the docker container and to download new device profiles.

Usage

Check out usage instructions for info about flashing custom firmware and local cloud-less usage (detaching). There are also some host specific instructions for setups on devices like a Raspberry Pi.

FAQ

Please see the FAQ section of the wiki for the most up-to-date questions and answers.

Contribution

We'd be happy to receive your contributions! One way to contribute if you already know your way around some binary exploitation or would like to get your hands into it is by building device profiles to support more exploitable devices. Check out the detailed writeup for the information about the vulnerability and exploit chain.

Additional work on expanding the Lightleak project, which can dump unexploited firmware, could use additional attention, as well as possibly expanding it to flash firmware, similiar to regular cloud-cutter as well. A port to bash/linux may also be useful.

Device dumps

You can also contribute device dumps by making an issue with a your device dump attached, but be aware if your device was already onboarded on your WiFi AP:

  • If you don't want your SSID and/or SSID password to be out there, then it's best to dump a device that was onboarded on a dummy AP that you don't mind leaking the parameters for. Otherwise, you may also configure it on a dummy access point a few times before dumping it. This will greatly lower the chances of accidental leakage to anyone working on the building a profile from your device flash dump, but it is never zero in this case. As a rule of thumb, it's better to dump a fresh device which has been configured with a dummy AP, but if you still want to dump one that's in use on your home AP then know that you always run the risk of leaking your SSID and password.
  • Another option, when having a device paired to SmartLife/TuyaSmart, is to open the app, click the pencil icon in the top-right corner, choose Remove Device and click Disconnect and wipe data.

Note that a dump made on a device which has been already activated on Tuya's app using any working SSID and password would simplify profile building a lot for contributors, so if possible please try to do so. Flash dumps of devices that have never been joined to Smart Life (or disconnected with a data wipe) are now generally acceptable. In order to not potentially leak personal information, that may be the preferred way.

Tools to dump flash from devices:

Note: other tools, such as hid_download_py or BkWriter, create incomplete dumps, or have data out-of-order which makes processing more difficult. Please use bk7231tools instead.

  • Example dump command: bk7231tools read_flash -d COM5 device-make-and-model.bin
  • Since bk7231tools v1.0.0, the -s and -c parameters are not needed (additionally, -c is deprecated in favor of -l/--length <bytes>). The program now reads the entire flash contents by default.
  • A valid dump for a standard 2M BK7231 should be 2,097,152 bytes. If your dump is any other size, it is probably incomplete!

Additionally, device profiles require a proper Datapoint ID (DPID) schema for local configuration with stock firmware. These can be pulled directly from flash on a device (config region starts at 0x1EF000 on BK7231 devices) if it has been configured to communicate with Tuya servers at least once, or through the profiler-builder scripts with the aid of an active Smart Life account. Profile builder's pull-schema.py script will walk you through the process. If you are not comfortable with this, just submit the full 2 MiB bin in an issue and a schema will be pulled and added.

Testing if a device is exploitable

If you'd like to check if a device is exploitable, one way to lower the chance of having to pry open a device that's not exploitable is testing it out with this test script. The downside to this test is that it won't tell you if the device is BK7231 based or not, since it seems that RTL87{1,2}0 devices are also exploitable but so far no work has been done to support them.

Previous work