“Hacking” BNETA Smart LED Bulbs for MQTT Integration

Teardown of a BNETA Smart LED bulb, flashing of Tasmota firmware and integration into Home Assistant via MQTT – without any soldering.

I recently experimented with a Sonoff B1 LED WiFI bulb. These units are based on the old-faithful Espressif Systems’ ESP8266 WiFi Microcontroller.

Sonoff smart devices tout various features, all accessible through the “EWELink” app and “cloud” infrastructure (it looks super crap). Um, no, if it’s in my house and on my WiFi network it needs to run open source software (or at least be made by a trustworthy company subject to mass scrutiny – even that’s not ideal, but life’s full of trade-offs). Sonoff devices are of particular interest to me because they (1) run a well-known micro-controller that has a lot of community-driven software and support available, (2) they’re SUPER cheap [$1.50] and (3) they’re really versatile. I’m proud to say that although I own and operate more than 20x Sonoff smart devices I’ve never installed their Android app. Life’s too short for that.

I bought one Sonoff B1 R2 to test with… it was a ball-ache to programme it with custom firmware (Tasmota) but it was possible and it works well once flashed.

Flashing a Sonoff B1 R2 is far from great. I just want lights and colours, not soldering.

I recently came across an advert for a WiFi “Smart” LED light at a local mass retailer (ultimately owned by Walmart, known as Makro in South Africa). The LED light was branded by a local company but South African companies rarely produce anything original (sorry guys, we don’t, we should, I really wish we did). The light was on special too and a fair bit cheaper than the Sonoff. This was too tempting. I thought “what are the chances it’s just a rebranded Sonoff device ?”. The device has the same basic specs and power rating as the Sonoff B1. Googling for the device name only yielded the local company’s empty website, but searching for the product’s SKU “IO-WIFI60” revealed a link to a Chinese site.

Makro’s SKU

So yes, screw it, let’s give it a go. R 250 (about $19) later and we have this :

Yeah, I opened it up on the drive home 😀
Unlike the Sonoff, which either pops off or unscrews this light top has been glued on.
The line on my thumb is from voting 😉
I’m very excited at this point because that looks like an ESP8266 dev board WOOOOOHOOOOO
RGB and White LED WiFi Smart light fitting - removal of top PCB.
Screws gone. The white stuff on top feels like silicone, but below it there’s thermal paste. I assume to bond the mostly copper top PCB to the alloy base.
You can see a bit of the thermal paste going on there and what looks like a power supply PCB with the dev board riding on top of it. It’s essentially a DIP8 package. The board can’t be easily separated from the power supply PCB and the PSU PCB appears to be soldered to the base.
Tuya TYLC2V module in WiFi Smart LED Light Fitting with cloud QR code present.
And there’s the ESP8266 😄😄😄 along with what looks like a voltage regulator, clock source, etc. The bit sticking out is the PCB antenna. Once again, below the white board is a power supply PCB which runs down into the E27 fitting. At this point I didn’t know what the label/QR code/code meant.
Tuya TYLC2V module in WiFi Smart LED Light Fitting.
Label removed and ahhhh, a model number.

A quick Google search and…

Tuya Module overview diagram.

The module the MCU is on, as it turns out, is made by a company called Tuya. The label with a QR code on it that I removed is a key for Tuya’s cloud infrastructure. In short Tuya makes ready-to-go ESP8266 modules that are pre-flashed to work with their cloud infrastructure. The idea being that you point your users to a white label app branded with your logos, which configures the device via WiFi. As the manufacturing company (pffft) you buy several thousand pre-flashed/configured WiFi modules from Tuya and integrate them into your product. This is interesting but still problematic as I don’t want their firmware in my house haha. There are no easily-accessible pins to flash this device… maybe someone has hacked the OTA protocol.

More Googling and yes, the Tuya OTA protocol was reverse engineered around 4 months ago. The product of that work has allowed a popular open-source Home Automation project, called Tasmota, to utilise the device, which in-turn allows the device to be used via MQTT with OpenHAB/Home Assistant/Domoticz platforms (and that means these devices can be firewalled off from the internet). It also means their interaction via MQTT can be homogenised into a common format, regardless of manufacturer.

I can feel the excitement GROWING. Bring me the Pi!

Raspberry Pi 3 and TUYA-based Smart WiFi LED Light.
Yes, that Pi will do. Hands ftw.
unzip 2019-04-08-raspbian-stretch-lite.zip
dd if=2019-04-08-raspbian-stretch-lite.img bs=64k of=/dev/sde status=progress
mount /dev/sde1 /mnt/sde
touch /mnt/sde/ssh
sync
umount /mnt/sde
<some time later>
# GO GO GO!
ssh [email protected]
sudo mount -o remount,async,commit=500,discard,noatime,nodiratime /
# ^ It's called living dangerously :D Speeeeeeeeeed
sudo apt update
sudo apt install byobu git
byobu
git clone https://github.com/ct-Open-Source/tuya-convert
cd tuya-convert
./install_prereq.sh
# You're not going fast enough :<
./start_flash.sh

Go go go!

pi@raspberrypi:~/tuya-convert$ ./start_flash.sh
~/tuya-convert/scripts ~/tuya-convert
======================================================
TUYA-CONVERT

https://github.com/ct-Open-Source/tuya-convert
TUYA-CONVERT was developed by Michael Steigerwald from the IT security company VTRUST (https://www.vtrust.de/) in collaboration with the techjournalists Merlin Schumacher, Pina Merkert, Andrijan Moecker and Jan Mahn at c't Magazine. (https://www.ct.de/)


======================================================
PLEASE READ THIS CAREFULLY!
======================================================
TUYA-CONVERT creates a fake update server environment for ESP8266/85 based tuya devices. It enables you to backup your devices firmware and upload an alternative one (e.g. ESPEasy, Tasmota, Espurna) without the need to open the device and solder a serial connection (OTA, Over-the-air).
Please make sure that you understand the consequences of flashing an alternative firmware, since you might lose functionality!

Flashing an alternative firmware can cause unexpected device behavior and/or render the device unusable. Be aware that you do use this software at YOUR OWN RISK! Please acknowledge that VTRUST and c't Magazine (or Heise Medien GmbH & Co. KG) CAN NOT be held accountable for ANY DAMAGE or LOSS OF FUNCTIONALITY by typing yes + Enter

yes
======================================================
  Starting AP in a screen
  Stopping any apache web server
  Starting web server in a screen
  Starting Mosquitto in a screen

======================================================

IMPORTANT
1. Connect any other device (a smartphone or something) to the WIFI vtrust-flash
   The wpa-password is flashmeifyoucan
   This step is IMPORTANT otherwise the smartconfig will not work!
2. Put your IoT device in autoconfig/smartconfig/pairing mode (LED will blink fast). This is usually done by pressing and holding the primary button of the device
3. Press ENTER to continue


======================================================
Starting pairing procedure in screen
RTNETLINK answers: File exists
~/tuya-convert
Waiting for the upgraded device to appear
If this does not work have a look at the '*.log'-files in the 'scripts' subfolder!
....................................................................................................................

Okay, so, that didn’t work. Tailing the log files indicates the device is present but rejected connection attempts. Probably a race condition. Let’s try again. Off, On Off On Off On… blinking fast. Here we go.

Yesssssss
Thank you, I WILL HAVE FUN Merlin Schumacher, Pina Merkert, Andrijan Moecker and Jan Mahn. Did I mention they came up with this very slick project ? Thank you!
curl http://10.42.42.42/flash3
pi@raspberrypi:~/tuya-convert/scripts$ tail -f smarthack-web.log
Target device retrieving the firmware during OTA 😀

Go to your mobile phone and connect to the Tasmota-created network, then go to your phone’s browser and navigate to 192.168.4.1

Enter your wifi network’s SSID and password and click “Save”. Do this quickly, you have 3 minutes from boot to do it otherwise the device reboots.

Okay, so at this point we have an ESP8266 running the base Tasmota firmware. The Tasmota firmware has different modules which allow it to manage different kinds of devices. There’s a big variety involved though, like dimmers, switches, temperature sensors, etc. So we need to be fairly specific about the kind of device we’re trying to control. I need a Tasmota “template”. I’m hoping something someone else has created will work with this device. Looking at this page one particular candidate stands out : (there’s that “60” again from the Makro SKU…)

The device is on my home network now, so I can configure it using my desktop machine’s browser yay.

Go to the device IP with a browser and click : Configuration -> Configure Other

Paste the following into the “Template” textbox :

{"NAME":"OM60/RGBW","GPIO":[255,255,255,255,140,37,0,0,38,142,141,255,255],"FLAG":0,"BASE":18}

The device will reboot.

Once again, yessssssss

So this is great, but now I want to get the device to talk to Home Assistant. To do that start by configuring the device name :

Configure -> Other : Set Friendly Name

Set your MQTT config to point to your HA system.

And then my favourite: go to the console and run the following :

Sleep 0
NTPServer 8.8.8.8 #as an example
Timezone 2

#and then some fun : Set the colour to red :
Color ff00000000
#green
Color 00ff000000
#blue
Color 0000ff0000
#white
Color 000000ff00
# all on - it's damn bright
Color ffffffff00

# These allow HA to auto-detect the device - but you'll need to upgrade from the basic to classic firmware first.
SetOption19 1 
SetOption31 1

Home Assistant's Single RGB Light Interface.
Of course the real benefit of all this is integration into Home Assistant’s web interface 🙂 Now I can script the lights as part of a larger network of devices… think continuously adjusting house lighting based on presence and current exterior lighting conditions.
Home Assistant's Group Lighting Interface operating on a group of RGB lights.
Controlling groups of lights.

And that’s about that. Hopefully this helps someone 🙂

Reverse Engineering the Ubbey Box

Some time ago I came across an ICO (distressed choir wails in the background as if welcoming lucifer to a dark cathedral) and said ICO was aiming to build a decentralised storage system. “Cool”, I thought, eager to experiment with a small amount of Ethereum on a diverse set of ICOs. I gave them some ETH… but before doing so I discovered that decentralised storage isn’t a new thing. Several projects have tried (and somewhat succeeded) in building dencentralised storage networks already; big examples being BitTorrent and IPFS being (neither offer in-band remuneration). In addition, cryptocurrency-supported examples include SiaCoin and StorJ – both of which have serious issues. After contributing to the Ubbey/Universal Labs ICO I decided to give Sia hosting a try… but that’s another story.

Ubbey’s 2000 Ethereum ICO was ultimately successful and I got some tokens. Shortly thereafter Ubbey allowed ICO participants to use some of their tokens to order their “Ubbey Box” at discounted rates. By this stage I had acquired additional Ubbey tokens at a fraction of the ICO price on decentralised exchanges (I love DEXs). Yesterday, the Ubbey box I ordered arrived. I only recently got a chance to play with it.

As with most boxes I don’t control, the Ubbey box has gone onto a DMZ network, which means it can’t access my home security cameras, storage machines, geyser controller, irrigation controllers… you get the idea.

First things first, unpacking :

Very nice Ubbey… the packaging looks good, even after being bashed around by DHL.

An Ubbey Box, by Universal Labs

This box is very obviously a general purpose media player that’s been rebranded to fit Ubbey’s needs. There’s nothing wrong with that, it’s sensible. They inadvertently hint at it being a general purpose media box with their specs, which quote the device as having an ARM CPU in it with 2 GBs of RAM, a VERY common configuration for ARM dev boards from around 2 years ago. This is begging to be disassembled…

So, onto the DMZ it goes. I installed the Ubbey app from the Google Play Store and soon enough it found the box (through what looked like an IP scan of the local subnet). The scan was followed by a login prompt and then a firmware update (forced) :

Unfortunately, it’s been about 2 hours now and it’s still updating…

While we wait for it to update, let’s see what’s inside :

This is how the device looks inside with the lower cover removed (it’s upside down in this shot).
The Ubbey logo is illuminated by an over-spec’ed 7-segment LED display.
The top-side of the main board of the Ubbey Box.

The top side of the main board of the Ubbey Box is -very- interesting. The device is equipped with a dual-chain/MIMO wifi module and the box has antennas for it installed. The top cover of the box has a large metal mass, which is squeezed against the top of that shielded cage/case with a thermal pad sandwiched inbetween. The board is clearly designed to have multiple display outputs with one set of traces unpopulated. The FORESEE module is probably flash “ROM” storage for the OS, which is OpenWRT. Also present are traces/holes for a TTL UART, an SD Card module and two USB ports (one of which appears to be USB 3).

It should be noted that the Ubbey Box runs an SSH daemon by default – attempts to log in to it using root/root, root/password, root/etc. proved fruitless.

The top side of the Ubbey Box PCB with the CPU/RAM shield/case and thermal pad removed.

A quick Google search for SEA Beelink SEA I found me this Amazon page :

Wireshark packet sniffing indicates that the device spends a lot of time communicating with 47.100.119.151, which seems to reverse-resolve to api.yqtc.co. Visiting the server with https indicates that the server’s HTTP certificate expired in May… so I thought the client device may be less than strict with it’s certificate acceptance. Some DNAT rules on my router and mitmproxy later and I got this :

mitmproxy is very cool software. Unfortunately the Ubbey Box’s Go client, although permissive, isn’t that permission 😉

It would appear that the best way of gaining access to this device is via the TTL UART.

Update 22 September 2018 : Serial Debug Console

Not my neatest work, but I now have access to the device’s debug console…
Part of the Ubbey Box’s boot process and the OpenWrt failsafe mode entry point.
The Ubbey Box’s labeled partitions.
The contents of description.xml inside what looks like an overlay filesystem called “nasetec”

More to follow…