search

openshwprojects / OpenBK7231T_App

Open source firmware (Tasmota/Esphome replacement) for BK7231T, BK7231N, BL2028N, T34, XR809, W800/W801, W600/W601, BL602 and LN882H
https://openbekeniot.github.io/webapp/devicesList.html
1.48k stars 279 forks source link

LSC Smart Dimmer Switch #291

Open Bacto opened 2 years ago

Bacto commented 2 years ago

Hi,

First I want to thank you for the amazing work done here! I'm super happy to see that we can now use new Tuya devices :)

I have bought a LSC Smart Dimmer Switch (same as https://github.com/openshwprojects/OpenBK7231T_App/issues/218#issuecomment-1265374143). It is a wall switch, working on a battery consisting of:

I'm new at Tuya devices, OpenBekenIOT and never used Tasmota before. So all of this is new to me :)

I have flashed the WB3S module with no issue. Now I'm trying to use the rotary switch but having found how to do it.

After loading the Tuya MCU (with startDriver TuyaMCU), I have some interesting logs:

Info:TuyaMCU:TUYAMCU received: 55 AA 01 02 00 03 FF 01 01 06 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 2 (MCUconf) with 10 bytes
Info:TuyaMCU:TuyaMCU_ProcessIncoming: unhandled type 2

Info:TuyaMCU:TUYAMCU received: 55 AA 01 02 00 03 01 09 00 0F Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 2 (MCUconf) with 10 bytes Info:TuyaMCU:TuyaMCU_ProcessIncoming: unhandled type 2


- When rotating up:

Info:TuyaMCU:TUYAMCU received: 55 AA 01 02 00 05 01 24 01 01 0A 38 Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 2 (MCUconf) with 12 bytes Info:TuyaMCU:TuyaMCU_ProcessIncoming: unhandled type 2

Info:TuyaMCU:TUYAMCU received: 55 AA 01 02 00 03 01 09 01 10 Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 2 (MCUconf) with 10 bytes Info:TuyaMCU:TuyaMCU_ProcessIncoming: unhandled type 2


- When not using the devices for some seconds:

Info:TuyaMCU:Consumed 255 unwanted non-header byte in Tuya MCU buffer

Info:TuyaMCU:Skipped data (part) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00



Reset button seems do not trigger TuyaMCU logs. Pushing it for few seconds make the RGB LED blink RED but nothing more.

I tried to find some informations before openning this issue but I'm in a dead end because I have not so much informations.
I suppose that the current TuyaMCU driver doesn't support these data format for now?

Time now for some questions:
- How I can configure OpenBekenIOT to make the rotary switch work? Can I do on my side or does it requires a firmware code update?
- Is it possible to use the RGB led (which is connected to the TuyaMCU) from the WB3S?
- Any leads to get the battery status?
- When on battery, the WB3S is powered up for only 5 seconds when moving the rotary switch. Seems the logic is in the TuyaMCU. Any luck we can change this?
- How to manage deep sleep?

Thanks :)
Adrien
openshwprojects commented 2 years ago

Hey, I'll look into it right now. From what I see... image the 00 03 and 00 05 are the byte lengths of data of 0x02 packet, but I am not sure what the data is yet.

You have a batter powered device. It should follow this protocol: https://developer.tuya.com/en/docs/iot/tuyacloudlowpoweruniversalserialaccessprotocol?id=K95afs9h4tjjh but the examples linked above seem to use 0x00 version while your has ver 01.... Another great guide is here: https://images.tuyacn.com/smart/aircondition/Guide-to-Interworking-with-the-Tuya-MCU.pdf

Hmmm are those the only UART commands you get? image

I think that even if we don't know the meaning behind the bytes, I could just add a possibility to script a callback for given UART input string....

To answer your question: the 00 00 00 00 000 00 etc etc spam means that MCU just went asleep, it's not a packet, it's a noise.

Regarding other questions... first of all, do I see correctly, the battery and MCU has capability to turn off the wifi module entirely?

valeklubomir commented 2 years ago

Protocol description: https://tasmota.github.io/docs/TuyaMCU/#dpid https://developer.tuya.com/en/docs/iot/mcu-protocol?id=K9hrdpyujeotg dpID must be identified and assigned to function. MCU CONF should list all available DPs.

openshwprojects commented 2 years ago

@valeklubomir the linked example has ver 00 and 03 and the user posted data with ver = 01 image I need to get the meaning of those ebytes: image Do you happen to know them, or are you saying that those are DPids or DP roles? The FF, for example?

openshwprojects commented 2 years ago

Not sure right now. I will also add an ability to fire events when a given UART hex string is received, as a flexible work around, at least temporary.

valeklubomir commented 2 years ago

Protocol version 2 is just another version, but structure can identified. dpID: FF seems to by type bool and would represent two transitions PRESSED and RELEASSED. since it was sent from button action dpID: 01 has 2 unknown types 09 and 24. In case of rotary switch: 24 could be direction, 09 step count since last message. Or vice versa.

This would require much more data to processas

I have implemented flowchart behavior from protocol and it will report all features. And it sends command 0x08. Query working status of the MCU. I think there is also command "tuyaMcu_sendQueryState" device should then report current state of all DP. There will be also LEDs. One LED is probably controlled by wifi state, there fore not as DP

valeklubomir commented 2 years ago

Also strange version of TuyaMCU, are really events are processed as MCU CONF? I would presume 0x06 state message.

Bacto commented 2 years ago

Thanks to both of you for all these informations :)

@openshwprojects:

Having the ability to fire events depending of UART hex strings received could be great!

About the battery, yes the MCU can turn off the power (VCC) of the WiFi module. It cuts it after ~5 seconds. I suppose there is a command to send to the MCU to keep the power on? I haven't found any information in Tuya documentation about this.

@valeklubomir:

Pressing and releasing sends only one information. When I press one time I have "FF 01 00". The second time "FF 01 01". The third time it is back to "FF 01 00". etc...

About the up/down, it doesn't seem to count. When I go up for example, I only have these 2 packets "01 24 01 01 0A" and "01 09 01". Going up again sends the same data again.

For reference, here is the PCB: LSC Smart Dimmer Switch PCB

valeklubomir commented 2 years ago

@openshwprojects Button: looks like toggle function. Rotary: Have you tried quick rotate? I presume some kind of logic when rotary is moved more the one tick between UART packets. Some kind of buffered changes........

I am sorry, Since I do not have device I can help only with suggestions

openshwprojects commented 2 years ago

@Bacto , since you seem to have some good quality photos, can you post a teardown article here (info where to buy, how to flash): https://www.elektroda.com/rtvforum/forum507.html , maybe also include the captured packets data, etc, for the sake of reference so we can latest add it to our online devices database: https://openbekeniot.github.io/webapp/examples/devicesListDemo2.html Thanks in advance.

The UART handler was added to code in last commit, but not tested yet. Here is an example: https://github.com/openshwprojects/OpenBK7231T_App/commit/b0f4015bbe5daa18bee9c68401ea0b93b547de20

Regarding the power on question.... it kinda looks like it might be related for what I did for Door sensors: https://github.com/openshwprojects/OpenBK7231T_App/blob/main/src/driver/drv_tuyaMCUSensor.c the code in this file sends a data to MCU to let the MCU know that we asks for door state and wants to keep alive the device for some time

yea, same, I don't have the device at hand to check well

Bacto commented 2 years ago

@valeklubomir I have to check about quick rotation. I'll let you know.

@openshwprojects teardown article posted :) https://www.elektroda.com/rtvforum/viewtopic.php?p=20239100#20239100

Thanks for the code examples. I'll have a look at them!

@valeklubomir & @openshwprojects , I can send you a device if you're in a country where it can be send easily (I'm in France). Would you be interested and if so, in which country are you?

openshwprojects commented 2 years ago

@Bacto I'm in Poland, not that far away. But it would be also nice if you had an original firmware backup so we can sniff the communication from Tuya. It could help a bit. But maybe that's not needed, and we can just set the triggers based on UART content instead of parsing the UART data. By the way, it's the first time I see a WiFi and battery powered dimmer.

But maybe first we could try doing support for that remotely. WB3S is powered only for 5 seconds after turning the knob? Maybe WB3S has to send something to TuyaMCU in order to make TuyaMCU keep it alive a bit longer, so it can at least report values to the cloud (or to HA in our case)...

Have you tried "startDriver tmSensor" in startup command (along with startDriver TuyaMCU)?

Bacto commented 2 years ago

I'll probably not have the time for the next 2 weeks to work on it but ASAP I'll try the command "startDriver tmSensor". During this 2 weeks I'll probably go to Action to buy a new one, with the original firmware.

If you're interested I'll send it to you :) Let me know if you are also interested by other LSC products I can find at Action France: https://www.action.com/fr-fr/search/?q=lsc+smart

valeklubomir commented 2 years ago

@Bacto I'm in Slovakia. Found an Action shop in Austria(Kitsee). if I have trip to Bratislava I can make side jump and check. Also I have ordered multiple devices from aliexpress, a lot of hacking to do. At moment I have 4x BK7231N devices to test on and 2x ESP8266 to hack.

But I would still like to see some UART communication.

openshwprojects commented 2 years ago

@valeklubomir I've been doing some research on the similiar Battery Powered Device, but it followed the protocol (version 0) from Tuya docs, it was not a ver 1 like here. Still, I documented it here: https://www.elektroda.com/rtvforum/topic3914412.html

@Bacto i could send you my address on Elektroda PM, but first I'd need to check the Action store in Poland. Shipping cost may be higher than the device cost and there is a chance we also have that one, I don't know.

@valeklubomir welcome to the club, I am ordering new devices all the time to just do the hacking and teardown, and our little list grows: https://openbekeniot.github.io/webapp/examples/devicesListDemo2.html (the list is still not a public version, it's a WIP)

Bacto commented 2 years ago

Got some new dimmer switch! I haven't checked the price to send them but if it is reasonable I'll send it to you :) You can send me your postal address on Elektroda if you're still interested.

valeklubomir commented 2 years ago

Sorry I have not yet had opportunity to visit Action shop nearby.

HumbleDeer commented 2 years ago

I have one of these units, and I'm fairly good with this stuff. Any short description of what you need from a stock unit? I have the required tools. @valeklubomir

valeklubomir commented 2 years ago

I managed to get one device also. Continuing with BK7231T device and I will work on it next days.

HumbleDeer commented 2 years ago

Okay. Let me know if you need anything from my device. I'll hook mine up to the logic analyzer with the RX/TX 0 & 1 pairs and the serial to the little SOIC chip and just have it capture some of the normal chatter/traffic on the stock firmware. The stock firmware seems to behave a bit odd too.

valeklubomir commented 2 years ago

Unfortunately I made mistake, and without thinking overwriten stock firmware. I'll go and get new dimmer and keep the stock firmware.

HumbleDeer commented 2 years ago

No worries! I'll see if I can get the firmware tonight.

Anything special I need to take care of?

On Thu, 3 Nov 2022, 3:03 pm valeklubomir, @.***> wrote:

Unfortunately I made mistake, and without thinking overwriten stock firmware. I'll go and get new dimmer and keep the stock firmware.

— Reply to this email directly, view it on GitHub https://github.com/openshwprojects/OpenBK7231T_App/issues/291#issuecomment-1302162996, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD32W6EJWN5QARIP5C42VB3WGPA3NANCNFSM6AAAAAARGJYFJY . You are receiving this because you commented.Message ID: @.***>

valeklubomir commented 2 years ago

If you could catch any communication between WB3S and IC with with stock firmware, could be helpfull. I will have new device at saturday.

HumbleDeer commented 2 years ago

I'm pretty sure the WB3S module's chip, tbe BK chip, has its memory built in?

fust commented 2 years ago

I also bought one of these devices a couple of days ago and was happy to stumble upon this project and this issue.

Today I dumped and unpackaged the original firmware using uartprogram, if you still need it then please let me know the best way to share the files (original, packaged file is ~1.1MB).

I have also captured some communication between the WB3S and the IC with the stock firmware using PulseView, though I would need to redo them to be able to separate the different actions. I'll try to get some clean captures tomorrow.

valeklubomir commented 2 years ago

Finally I got to do some measurements from LSC Dimmer Switch. I got also new bulb. I paired bulb with LSC SmartApp and then paired dimmer with bulb. Running stock firmware.

Things to setup when usign OpenBK:

valeklubomir commented 2 years ago

@fust Can you share original firmware?

HumbleDeer commented 2 years ago

Wow. This dimmer is really quite shit haha. It seems useful to me, to modify this dimmer to handle the rotary button as itself. The only benefit of the current way is power efficiency. That would be sacrificed. 😅

On Sat, 5 Nov 2022, 9:56 pm valeklubomir, @.***> wrote:

@fust https://github.com/fust Can you share original firmware?

— Reply to this email directly, view it on GitHub https://github.com/openshwprojects/OpenBK7231T_App/issues/291#issuecomment-1304640115, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD32W6A2GJRCANTJQDWYR73WG3CXTANCNFSM6AAAAAARGJYFJY . You are receiving this because you commented.Message ID: @.***>

btsimonh commented 2 years ago

the communication could be bluetooth? a bootlog would be good.

fust commented 2 years ago

I've uploaded all files I mentioned in my previous comment to a Github repo. Unfortunately I don't have any other LSC devices to capture some logs while it is paired, might get an LED lightbulb so I can check out what's going on.

fust commented 2 years ago

Wow. This dimmer is really quite shit haha. It seems useful to me, to modify this dimmer to handle the rotary button as itself. The only benefit of the current way is power efficiency. That would be sacrificed. 😅 … On Sat, 5 Nov 2022, 9:56 pm valeklubomir, @.> wrote: @fust https://github.com/fust Can you share original firmware? — Reply to this email directly, view it on GitHub <#291 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD32W6A2GJRCANTJQDWYR73WG3CXTANCNFSM6AAAAAARGJYFJY . You are receiving this because you commented.Message ID: @.>

If we need to do hardware modifications to make this thing work I'd go the route @valeklubomir suggested but with some changes:

This does of course come at the cost of some power efficiency but less than just powering the module all the time and comes with a couple of advantages:

I might be completely off on this though :)

valeklubomir commented 2 years ago
  • Cut the trace going from Q2 (MOSFET used to switch the WB3S on/off) to the WB3S, power the WB3S directly from 3.3V.
  • Solder a wire from the output of Q2 to a GPIO on the WB3S and use it as a trigger to enter/exit low-power mode.

I think it requires little more to change. I need to spend some time on it. Powering WB3S from battery would drain the battery within few hours. The consumption at moment is too high.

miyoyo commented 1 year ago

It looks like it's some form of WiFi Direct protocol that I can't find documented anywhere, I suppose it's called "FFC".

Disassembling the binary, I see that it's almost all referenced to a project named "bk7231s_ffc_remote_ctrl", built by "tuya_user".

This appears to be a protocol similar to WiFi mesh, but it seems to have custom frames, devices are referred to by MAC, so it may be hard, if not impossible to sniff with a generic adapter in monitor mode. Will try as soon as I get a monitor-compatible AP.

API of that protocol in https://github.com/tuya/tuya-iotos-embeded-sdk-wifi-ble-bk7231t/blob/master/sdk/include/ffc_app.h

Also, I may have found some passphrases? 6xg0Qo9Cxi85oooA and 1dHRsc2NjbHltbGx3eWh5 Keeping em' there, never know.

Edit1: Looks like it's AES128 ECB encrypted, the encryption relies on a sequence number, so it's replay protected, so probably some form of hopping AES encryption? (Which would be wierd with the switch having the BK offline most of the time)

Should be sniffable if the first packet is sniffed.

Edit 2: This is called "Tuya Flexible Fast Control": Mentioned in docs here: https://developer.tuya.com/en/docs/iot-device-dev/TuyaOS-Overview?id=Kbfjtwjcpn1gc

Article about it: https://www.prnewswire.com/news-releases/tuya-announces-nine-innovations-at-the-third-annual-ai--iot-business-conference-with-its-global-partners-300839264.html Supposedly, it supports custom links beyond wifi?

It looks like Tuya engineers just... reimplemented BLE on a BLE-Capable platform?

HumbleDeer commented 1 year ago

It looks like Tuya engineers just... reimplemented BLE on a BLE-Capable platform?

Yeah, pretty much hit the nail on the head there. Tuya devs are known to do this just to make it "theirs"

HumbleDeer commented 1 year ago

If we need to do hardware modifications to make this thing work I'd go the route @valeklubomir suggested but with some changes:

  • Cut the trace going from Q2 (MOSFET used to switch the WB3S on/off) to the WB3S, power the WB3S directly from 3.3V.
  • Solder a wire from the output of Q2 to a GPIO on the WB3S and use it as a trigger to enter/exit low-power mode.

I'm having my doubt about that way of doing it actually. It might be better to have the anonymous chip source the current directly to the GPIO pin, OR connect a resistor to ground along the lines of 10k or something like that. The MOSFET may need a minimum of current to work properly as the leakage on the MOSFET could possibly give you false readings depending on how much if at all any current the WB3S would sink when it's reading an active high

miyoyo commented 1 year ago

I don't have an FFC compatible device (I'll grab one tomorrow), I did a network capture though.

When unpaired, turning the switch on does not trigger any packets, only when pairing.

Interestingly enough, it seems that the pairing process is two-step? There are searches for wildcard SSIDs, as well as "tuya_smart" specifically.

PCAPNG here: tuya_scan.zip

I also stumbled upon this video about ultra-low-power ESP programming, where the trigger is done using monitor mode on an openwrt router: https://www.youtube.com/watch?v=I3lJWcRSlUA

This just may be a solution that does not involve modding or hacking these switches, it will just involve:

FFC seems to be an 802.11 management Vendor-Specific action (Tag 0xDD, 221) with "FFC" as an OUI, not sure about the format, but it looks like there is some sequence about it:

46 46 43 01 01 09 00 00 00 01 00 10 bb 66 a8
46 46 43 01 01 09 00 01 00 01 00 0c 94 1c 69
46 46 43 01 01 09 00 02 00 01 00 b1 13 e4 ca
46 46 43 01 01 09 00 07 00 01 00 ed 9d 96 cf
46 46 43 01 01 09 00 08 00 01 00 92 1d 5f 30
...
46 46 43 01 01 09 00 3e 00 01 00 7b 72 ac c6

Not sure what everything corresponds to, but my best guess would be the incremental number is the sequence number, and the last 4 bytes are encrypted data?

Decompiling the SDK, here's what I can tell:

  MAGIC |VERSION|HOP|CMD|SEQUENCE|DATA LEN|DATA|   HASH
46 46 43|01     |01 |09 |00 3e   |00 01   | 00 |7b 72 ac c6

struct ffc_head_t

Offset Length Mnemonic DataType Name
0 3 uint8_t[3] uint8_t[3] magic
3 1 uint8_t typedef uint8_t __uint8_t version  
4 1 uint8_t typedef uint8_t __uint8_t hop  
5 1 uint8_t typedef uint8_t __uint8_t cmd  
6 2 uint16_t typedef uint16_t __uint16_t sequence  
8 2 uint16_t typedef uint16_t __uint16_t data_len  
10+ 0 uint8_t[0] uint8_t[0] data

struct ffc_tail_t

Offset Length Mnemonic DataType Name
0 4 uint32_t typedef uint32_t __uint32_t hash  

Here are the commands:

Command Name Command ID
FFC_SLAVER_INIT 0x0
FFC_MASTER_INIT 0x0
FFC_GROUP_0 0x0
FFC_BIND_PROBE_CMD 0x1
FFC_SLAVER_GROUP_CTRL_CMD 0x1
FFC_MASTER_BINDING 0x1
FFC_GROUP_1 0x1
FFC_SLAVER_PREPARE 0x1
FFC_SLAVER_BINDING 0x2
FFC_SLAVER_GROUP_INFO_CMD 0x2
FFC_BIND_REQ_CMD 0x2
FFC_MASTER_CONTROL 0x2
FFC_GROUP_2 0x2
FFC_JOIN_REQ_CMD 0x3
FFC_GROUP_3 0x3
FFC_SLAVER_CONTROL 0x4
FFC_AUTH_REQ_CMD 0x4
FFC_BIND_RSP_CMD 0x5
FFC_JOIN_RSP_CMD 0x6
FFC_AUTH_RSP_CMD 0x7
FFC_AUTH_FAST_CMD 0x8
FFC_BEACON_CMD 0x9
FFC_CTRL_CMD 0xa
FFC_MAX_CMD 0xb

This should be implementable on an ESP with the following setup&callback: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/network/esp_wifi.html#_CPPv422esp_wifi_set_vendor_ieb21wifi_vendor_ie_type_t19wifi_vendor_ie_id_tPKv

Note: The 970709 Smart Filament LED does not work with the switch.

miyoyo commented 1 year ago

Alright, I finally got my hands on an FFC compatible bulb (3000272).

FFC... is absolute dogshit.

Even at 3 meters, with 10 packets per command, I still experience a fuck ton of packet loss (And the fact that the lamp state is stored locally, instead of being just a toggle command, makes one packet lost require 2 button presses to actually go back to where you want it to be.

Wakeup times can be up to 500ms.

Upside though, you can connect an FFC remote to a bulb without configuring the bulb itself, so it COULD be an option if future devices become too hard to flash (or you're lazy), all you need is an emitter that can change it's mac (since the emitted packets do not have the MAC of the bulb, only the MAC of the switch, so you'll need one mac per device), so a Tuya FFC bridge, probably ESP-based, could be an option.

Multiple slaves can follow one master, but they will then be synced (All lamps, plugs, etc will turn on and off at the same time)

Here's a capture of the switch being used, it appears to be 100% one way (haven't checked pairing yet).

Here are the actions corresponding to the sequence ID: 0x00FD: Click ON 0x00FE: Click OFF 0x00FF: Click ON Not sure about the exact mapping, but roughly half of the remaining packets are Raise brightness, the other half is lower brightness.

Remember: the data on these are encrypted

I'll work on capturing the pairing process. tuyaclick.zip

EDIT: here's a full pair cycle, the switch is 7c:f6:66:b5:67:8f, the bulb is d8:1f:12:fe:9b:b1 tuyapair.zip

HumbleDeer commented 1 year ago

It's possible that there's already devices out there suited for making such a Tuya FFC Bridge. As far as I understand this, it just needs Bluetooth support, and access to that transmitter/RF driver? Sonoff has a lot of cool little boxes that do many of the popular protocols at once (eg the new BT+Wifi+Zigbee+future matter support)

On Tue, 29 Nov 2022 at 17:00, miyoyo @.***> wrote:

Alright, I finally got my hands on an FFC compatible bulb (3000272).

FFC... is absolute dogshit.

Even at 3 meters, with 10 packets per command, I still experience a fuck ton of packet loss (And the fact that the lamp state is stored locally, instead of being just a toggle command, makes one packet lost require 2 button presses to actually go back to where you want it to be.

Upside though, you can connect an FFC remote to a bulb without configuring the bulb itself, so it COULD be an option if future devices become too hard to flash (or you're lazy), all you need is an emitter that can change it's mac (since the emitted packets do not have the MAC of the bulb, only the MAC of the switch, so you'll need one mac per bulb), so a Tuya FFC bridge, probably ESP-based, could be an option.

Here's a capture of the switch being used, it appears to be 100% one way (haven't checked pairing yet).

Here are the actions corresponding to the sequence ID: 0x00FD: Click ON 0x00FE: Click OFF 0x00FF: Click ON Not sure about the exact mapping, but roughly half of the remaining packets are Raise brightness, the other half is lower brightness.

Remember: the data on these are encrypted

I'll work on capturing the pairing process. tuyaclick.zip https://github.com/openshwprojects/OpenBK7231T_App/files/10114771/tuyaclick.zip

— Reply to this email directly, view it on GitHub https://github.com/openshwprojects/OpenBK7231T_App/issues/291#issuecomment-1330872578, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD32W6EYJLTQSJJH2STZVK3WKYSCTANCNFSM6AAAAAARGJYFJY . You are receiving this because you commented.Message ID: @.***>

fust commented 1 year ago

I've dug in to this for a bit as well, though not as thoroughly as @miyoyo, partly because I haven't quite figured out how to disassemble the firmware (yet).

It's possible that there's already devices out there suited for making such a Tuya FFC Bridge. As far as I understand this, it just needs Bluetooth support, and access to that transmitter/RF driver?

Not likely, unfortunately. As far as I can tell FFC is built on top of IEEE 802.11 (AKA, WiFi) so Bluetooth won't help. What I didn't know was how exactly they did that until I read the above post about them using a vendor-specific action. That would mean an out-of-the-box solution would be difficult, at the very least handling of the custom action would need to be implemented. WiFi AP mode on whatever ends up being used as the "bridge" could also be required, not sure on that one.

What could be somewhat easier (but is very, very hacky) is to crack open a device (like a lamp) that uses the FFC protocol, grab the module from it and use that as a "bridge". Some custom code to integrate nicely with the rest of the ecosystem would be cool but even without that the "lamp" could just be powered from something like a USB plug. That should, as far as I understand, "just work" without any furhter modifications.

HumbleDeer commented 1 year ago

I'd be more than happy to look into the hardware hacking aspect of things if necessary!

On Thu, 1 Dec 2022, 8:07 pm fust, @.***> wrote:

I've dug in to this for a bit as well, though not as thoroughly as @miyoyo https://github.com/miyoyo, partly because I haven't quite figured out how to disassemble the firmware (yet).

It's possible that there's already devices out there suited for making such a Tuya FFC Bridge. As far as I understand this, it just needs Bluetooth support, and access to that transmitter/RF driver?

Not likely, unfortunately. As far as I can tell FFC is built on top of IEEE 802.11 (AKA, WiFi) so Bluetooth won't help. What I didn't know was how exactly they did that until I read the above post about them using a vendor-specific action. That would mean an out-of-the-box solution would be difficult, at the very least handling of the custom action would need to be implemented. WiFi AP mode on whatever ends up being used as the "bridge" could also be required, not sure on that one.

What could be somewhat easier (but is very, very hacky) is to crack open a device (like a lamp) that uses the FFC protocol, grab the module from it and use that as a "bridge". Some custom code to integrate nicely with the rest of the ecosystem would be cool but even without that the "lamp" could just be powered from something like a USB plug. That should, as far as I understand, "just work" without any furhter modifications.

— Reply to this email directly, view it on GitHub https://github.com/openshwprojects/OpenBK7231T_App/issues/291#issuecomment-1334223044, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD32W6EZ74PKUBKVN46NZPTWLDZP7ANCNFSM6AAAAAARGJYFJY . You are receiving this because you commented.Message ID: @.***>

miyoyo commented 1 year ago

The bridge just requires access to control frames, as far as I can tell, this does not require monitor mode on the ESP, as it's a driver-supported feature: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/network/esp_wifi.html#_CPPv422esp_wifi_set_vendor_ieb21wifi_vendor_ie_type_t19wifi_vendor_ie_id_tPKv

Implementing this to listen (and maybe emit) FFC frames should do the trick, without any modifications or custom WiFi firmware

I'm trying to decode packets right now, I know the hash contains:

NULL Source MAC Destination MAC Frame Length Frame ...
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...

Update, I was wrong, that's just some other thing.

The encryption key used to secure the Switch->Device communication is md5(mac, authkey)

...which it fucking dumps in the logs. GG Tuya.

The bind key is hardcoded, so not that hard to extract, it's md5(6xg0Qo9Cxi85oooA), or ff54a67eb21be251d5452301e641cfa9

@fust , your Encryption key is md5(s7IabMZ0Rl61RysZGBHHICZyaqaWfpjL, [7c:f6:66:b4:59:51]), or 5d452cf018234ffef305221de00b449c, all encrypted with aes128_ecb

miyoyo commented 1 year ago

Let this be a reminder that you shouldn't use a 2013 Macbook Pro for wifi capture.

...here's an actual capture file that captures way more shit. ax200.zip

miyoyo commented 1 year ago

M->S: 1 = FFC_MASTER_BINDING, channel used for binding, I think? S->M: 2 = FFC_BIND_REQ_CMD, uuid_md5 M->S: 5 = FFC_BIND_RSP_CMD, random_a + ctrl seq S->M: 3 = FFC_JOIN_REQ_CMD, random_b M->S: 6 = FFC_JOIN_RSP_CMD, md5(uuid_md5,random_a,random_b) XOR ctrl key's first 16 bytes S->M: 4 = FFC_AUTH_REQ_CMD, Byte for hash mode + EITHER md5(uuid_md5,random_a,random_b,ctrl_key) OR crc32i(uuid_md5,random_a,random_b,ctrl_key) M -> S: 7 = FFC_AUTH_RSP_CMD, group_index + hash mode (3 or 4)

Everything here is encrypted with bind_key, and sometimes XOR'd with more shit. Which means that, yes, you can sniff the control key in command 6. And, since the same control key and sequence number is used for everything, you can copy any FFC remote by pretending to be a pairing device, and just copying the key, and spamming channels without consequences.

So, IN ADDITION to reimplementing BLE, they are badly reimplementing Diffie-Hellman. Nice.

Edit: There it is frens, I believe it is my key: f16b7839f23184d7182714fb29d25514

It appears that command packets have a custom format that supports groups, will need to investigate, can't decode just yet.

HumbleDeer commented 1 year ago

Bad implementation of D-H is not a surprise. But that's not a bad thing for us. It is amusing though. Nice work! Is there anything I can do to help with sniffing out anything? I've got dedicated strong Wi-Fi hardware sitting unused.

On Sat, 3 Dec 2022 at 21:22, miyoyo @.***> wrote:

M->S: 1 = FFC_MASTER_BINDING S->M: 2 = FFC_BIND_REQ_CMD, uuid_md5 M->S: 5 = FFC_BIND_RSP_CMD, random_a + ctrl seq S->M: 3 = FFC_JOIN_REQ_CMD, random_b M->S: 6 = FFC_JOIN_RSP_CMD, md5(uuid_md5,random_a,random_b) XOR ctrl key's first 16 bytes S->M: 4 = FFC_AUTH_REQ_CMD, Byte for hash mode + EITHER md5(uuid_md5,random_a,random_b,ctrl_key) OR crc32i(uuid_md5,random_a,random_b,ctrl_key) M -> S: 7 = FFC_AUTH_RSP_CMD, group_index + hash mode (3 or 4)

Everything here is encrypted with bind_key, and sometimes XOR'd with more shit. Which means that, yes, you can sniff the control key in command 6. And, since the same control key and sequence number is used for everything, you can copy any FFC remote by pretending to be a pairing device, and just copying the key, and spamming channels without consequences.

So, IN ADDITION to reimplementing BLE, they are badly reimplementing Diffie-Hellman. Nice.

— Reply to this email directly, view it on GitHub https://github.com/openshwprojects/OpenBK7231T_App/issues/291#issuecomment-1336251761, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD32W6AYEN7GKYECUFAPNZ3WLOTY7ANCNFSM6AAAAAARGJYFJY . You are receiving this because you commented.Message ID: @.***>

miyoyo commented 1 year ago

If you can sniff a pairing process, and if you can access your UART logs, that would be great, so I can double-check my math, I currently don't have an uart to usb converter that works with this.

HumbleDeer commented 1 year ago

What issues are you having with your UART bridge? It shouldn't matter too much as long as your settings are fine (port & bitrate etc)

miyoyo commented 1 year ago

I think the bridge itself is fried, can't read anything coherent out of it, I've ordered a different one but it won't be here for a while.

HumbleDeer commented 1 year ago

I think the bridge itself is fried, can't read anything coherent out of it, I've ordered a different one but it won't be here for a while.

If you're getting gibberish, your baudrate may be set incorrectly.

miyoyo commented 1 year ago

I tried all of the standard ones, and even less standard ones (I've had the joke of nonstandard baudrates with Bob the Dishwasher), I think it's just firing randomly.

HumbleDeer commented 1 year ago

Okay. I'll have a look and see what I can extract from it.

HumbleDeer commented 1 year ago

boot_capture.txt With the WB3S module desoldered from the board

unpaired, clicking or rotating:

[01-01 18:12:57 TUYA Notice][tuya_device.c:326] fr_type:2                       
[01-01 18:12:57 TUYA Err][ffc_master.c:649] ffc not in control state. 0         
[01-01 18:12:57 TUYA Notice][tuya_device.c:350] ffc_send end !!!

This already mentions ffc_master.c // I bet this means the source code might be out there for the ffc... let's see!

Edit: In fact, FFC is already a thing in the original bk7231n/t sdk's as well as the ESP8266 SDK's! https://github.com/tuya/tuya-iotos-embeded-sdk-wifi-ble-bk7231n/blob/master/sdk/include/ffc_app.h

pressing and holding the reset button:

[01-01 18:12:40 TUYA Notice][tuya_device.c:326] fr_type:5

Pressing and holding the dimmer button for pairing (device nearby):

[01-01 18:19:51 TUYA Notice][tuya_device.c:326] fr_type:4                       
[01-01 18:19:51 TUYA Notice][tuya_device.c:358] mesh cmd bind time 8                                                                              
[01-01 18:20:02 TUYA Notice][tuya_device.c:298] ffc app binding falied -> 0                                                                                
[01-01 18:20:02 TUYA Notice][tuya_device.c:285] get status -> 1                                                                               
[01-01 18:20:02 TUYA Notice][tuya_device.c:301] set status -> 0

Pressing and holding the dimmer button for pairing (device in pairing mode):

[01-01 18:22:13 TUYA Notice][tuya_device.c:326] fr_type:4                       
[01-01 18:22:13 TUYA Notice][tuya_device.c:358] mesh cmd bind time 8
do td cur_t:278--last:idx:16,t:287 -- new:idx:15,t:275                          
--0xc:08, shift_b:0, shift_g:0, X:1
[01-01 18:22:23 TUYA Notice][tuya_device.c:29
8] ffc app binding falied -> 0         
[01-01 18:22:23 TUYA Notice][tuya_device.c:285] get status -> 0

But I still can't get it to pair to anything. I actually never paired it at all before trying to modify it, though it should be stock as far as connections go.