LSC Smart Dimmer Switch

[Bacto]

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:

• A WB3S module
• A Tuya MCU with no reference written
• A rotary switch
• 2 LEDs
  • One that seems RGB (seems connecter to the TuyaMCU)
  • One green (seems to be related to the charge function)
• A power switch
• A reset button
• A 3.7V battery
• A USB C connector use to charge the battery

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:

• When pushing the rotary button, I have one of these 2 messages (alternating one of the other):

  Info:TuyaMCU:TUYAMCU received: 55 AA 01 02 00 03 FF 01 00 05 
  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 FF 01 01 06 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 2 (MCUconf) with 10 bytes
Info:TuyaMCU:TuyaMCU_ProcessIncoming: unhandled type 2

• When rotating down:

  
  Info:TuyaMCU:TUYAMCU received: 55 AA 01 02 00 05 01 24 02 01 0A 39 
  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 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]

Hey, I'll look into it right now. From what I see... 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?

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]

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]

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

[openshwprojects]

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]

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]

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

[Bacto]

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:

[valeklubomir]

@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]

@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]

@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]

@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]

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]

@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]

@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]

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]

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

[HumbleDeer]

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]

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

[HumbleDeer]

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]

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

[HumbleDeer]

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]

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]

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

[fust]

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]

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.

• Special IC on the board handles rotary switch and push button. Is connectd to WB3S only by RX1,TX1. Communication with WB3S module is via modified TuyaMCU protocol. It is pretty stripped protocol to minimum commands.
• Button works in toggle principle and sends binary value to WB3S. Paired LED bulb reacts on real value stored in the Special IC. When for example bulb is switched OFF with dimmer and swithed ON by phone application then you need press button twice to switch bulb OFF.
• Rotary switch sends out increments with each movement. In case of quick rotation, a.k.a. multiple increments, these are sent out one by one. Special IC does not sends out block movements in single packet. Each increment is transmitted to bulb. As packets are received by bulb, bulb changes brightness in steps with some delay per step. Steps are the visible. Increment contains also direction bit, but sometimes steps seem to mess little bit, it looked like for split of second brigthness dimming changes direction.
• 2 Extra commands are sent out by Special IC during request for pairing, executed by long pres of 5 secs.
• Some of the received packets are confirmed by MCU. Button togple and rotary increment events.
• When pressing button or rotating switch Special IC switches 3.3V power ON for WB3S and holds it for short period of time. Est. 8-10 sec. During this time WB3S needs to connect to bulb and transmit command. Stock firmware has pretty fast reaction. 100-300 ms.
• Protocol will not be full WiFi. Some kind of proprietary protocol transparent on wifi channels. Received directly by paired bulb. Or may be bluetooth, I do not know if BK7231T can maintain Wifi and Bluetooth communication at same time.

Things to setup when usign OpenBK:

• Firmware must connect to Wifi and MQTT very quickly.
• May be modification of circuit to enable WB3S hold power supply longer, would be neccessary, I am not sure if Special IC support any command to hold power ON longer.

[valeklubomir]

@fust Can you share original firmware?

[HumbleDeer]

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]

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

[fust]

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]

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:

• 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.

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:

• It's a very doable change for the majority of people as there are some pretty decent-sized pads which could be used.
• The module is always powered so it doesn't need to connect to WiFi/MQTT in a couple of milliseconds.
• The anonymous IC is still handling the rotary encoder so we only need to handle the UART packets it sends

I might be completely off on this though :)

[valeklubomir]

• 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]

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]

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]

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]

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:

• Reverse engineering the protocol
• Figuring out the keys used, but they're probably hardcoded anyway
• having a permanently-active wifi receiver in monitor mode, which is probably only viable in small homes

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[HumbleDeer]

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.