mirror of
https://github.com/tuya-cloudcutter/tuya-cloudcutter.git
synced 2026-02-19 21:51:18 +01:00
b28723ae61
* Initial RTL8720CF support * Fix RTL8720CF_OTA file validation. * be a bit more robust on chip string matching * Really rough refactor of haxomatic for RTL8720CF, not complete. * Update RTL8720CF 2.3.0 haxomatic hex match strings * Remove length validation from authkey/uuid so it can work with both Tuya and CloudCutter generated keys. * Fix bk7231 string detection Add second RTL8720CF 2.3.0 profile * Refactor haxomatic to be more modular and maintainable. * haxomatic - minor cleanup * profile-building - Pull PSK when pulling schema. * Haxomatic - Search all binaries for patch patterns. Update known RTL8720CF match pattern identifiers. * Change network to custom 10.204.0.1/24 network (204 = 0xCC) Send multiple DNS servers, which may help devices that hang after DHCP Spend less time sending wifi connect requests so AP can start listening sooner. * Update exploit for new offsets. * Haxomatic - Add 1.0.x SDK * Update haxomatic for newer found patterns. * Minor tweaks * Updates to profile-building * Add storage parsing to extract_rtl8720cf * Switch to bk7231tools to extract rtl8720cf storage to remove an unneeded dependency. * remove debug code * Add special case for sdk identification for single build missing standard string. * Find swv before device_class, as we may want to search directly after it. * Update comments, seek entire bin for storage. * Add missing new address in profile. Add ability to process inactive OTA app. * Update documentation. * fix typo. * Fix a type in beken extract. * Add haxomatic pattern for oddball BK7231N 2.3.1 SDK. * Haxomatic - Add RTL8720CF 2.3.1 SDK pattern. * Fix copy/paste typo * profile-building - proceess_app - add more device class match strings. * one more * profile-building - better log SDK data * Add a special thanks section. * fix typo * Clean up documentation. * documentation - use numbered lists. * process_app - add another device class identifier.
2.3 KiB
2.3 KiB
Running with known secrets
Why would this be useful?
If you have a device that would normally require serial flashing (patched devices), but you don't have access to all the bootstrapping pins (common on RTL8720CF), but can access TX2 and GND (minimum needed to read UART logs).
When can I use this?
You can only use this method if you know
- AuthKey (32 characters if from Tuya, 16 characters if overridden by CloudCutter)
- UUID (16 characters if from Tuya, 12 characters if overridden by CloudCutter)
- PSKKey (37 characters if from Tuya, empty string if overridden by CloudCutter)
How can I find the secrets necessary?
- UUID - This can be found one of two ways:
- Via iot tuya account, similar to finding the local/secret keys via the instructions from Tiny Tuya method 3 - Tuya Account
- Via uart logging (not all devices)
- AuthKey
- Via uart logging (not all devices)
- PSKKey
- Via API, included when running profile-building's
pull_schema(requires a Tuya token, see instructions included with script). Requires already having UUID and AuthKey
- Via API, included when running profile-building's
Finding secrets via UART logging
Some devices will output a string on their UART logging (usually on UART_LOG_TX / TX2 [Pin P0 on Beken, Pin PA16 on RTL8720CF])
Look for a logged line that has a group of 3 strings with random characters that looks something like upd product_id type:1 keyxxxxxxxxxxxxx abcd1234e5566f78 6W9ckhSD4v1PB8Jwk8O1OVoiTzsdyLh7.
- The first string of 16 characters is either the Firmware Key, Product Key, or Factory Pin. This isn't needed, but helpful for identifying the pattern for the other two fields.
- The second string of 16 characters is the UUID. It will consist of numbers and lower case letters (usually just a-f, but not guaranteed).
- The third string of 32 characters is the AuthKey. It will consist of numbers and both upper and lower case letters. This is currently the only known way to find this value.
I have all the needed secrets, how do I proceed?
You can proceed by running CloudCutter with the -a (AuthKey), -u (UUID), and -k (PSKKey) parameters. A profile is still necessary to help verify the available firmware to flash, but the exploit is not needed or run if you provide all three fields.