Eglo V-Link Tunable white light bulb

Add-ons Bindings
1

Hello,

My local hardware store (Leroy Merlin) held a competition and a I won a connected light bulb from Eglo, the Tunable White V-Link model.
The recommended way to connect to it is the following:

  1. Install the Enki app on Android/IPhone
  2. Start the app, while connected to Internet
  3. Add a new item in the app, select the bulb brand and model
  4. Turn on the bulb
  5. Connect to the wifi network provided by the bulb
  6. Let the app do its thing
  7. Connect back to the home wifi
  8. Control the bulb with the application

Now, from the manufacturer own advertisement, it is possible to control this bulb with an “enki box” that is claimed to be capable of working without any Internet connection.

I sent an email to the manufacturer asking for a detailed protocol, and I’m yet to receive an answer, but I don’t have my hopes too high on this.

So, in the meantime, I decided to attempt reverse engineering the protocol with the help of tcpdump on my rooted android device, and wireshark under windows to analyze the traces.

Here is what I found so far:

After getting connected to the bulb wifi network, the bulb is broadcasting mDns requests looking for _alljoyn._tcp.local and _alljoyn._udp.local
The android application answers this request with a reply that indicates a port to use for communication
The bulb connects to the android application on the given TCP port and the protocol is definitely AllJoyn
After a few back and forth to authenticate and exchange keys, there is a ConfigureWifi order that is sent by the android app to the bulb with an encrypted payload that I believe contains the Wifi SSID and password.
Then the bulb wifi network disappears and both the app and the bulb reconnect on the home wifi, the one that has access to Internet.
Once again, there is a bit of back and forth for the bulb and the app to find each other. This allows discovering that the bulb is most likely running MicroEJ to handle all this communication and the exact model number is EG-FWCCT8-1
The andoid app then resolves the device-broker.iot.leroymerlin.fr DNS name and starts talking to it via HTTPs. After having received a secure MQTT packet from that same host, the android now does a DNS lookup for enki-backend.iot.leroymerlin.fr and starts talking to it with HTTPs again.
In between those two, there were a few encrypted AllJoyn packets between the bulb and the android app, which I believe contain the hostname to use as the MQTT broker.

And after that, the android app sends a MQTT packet to the broker which the bulb is receiving and acting upon accordingly.

After this already long analysis, I’m wondering: does this kind of “protocol” sounds familiar to anyone?
I see that there is the AllPlay binding that uses AllJoyn to communicate with its devices, but I doubt it is anywhere near compatible with that bulb.

What would you suggest that I should try next?
I mean, considering that AllJoyn was “engulfed” inside Iotivity, I attempted to build the latter but only got as far as a compiling issue that did not seem to attract much attention.

Any help, suggestion, pointers are most welcome.

2

If it’s really running MicroEJ then there is a small possibility that it’s running on ESP32 chip. If that’s the case you might be able to reflash it to run Tasmota or ESPEasy or the like. I searched the supported devices for Tasmota and there was no mention of Eglo but often the same device will have multiple brands.

The usual approach with bulbs like these I’ve seen here is often to reflash them to one of the above. (when possible). Beyond that the API, when one is available, if often cloud based and does not support local control.

3

The MAC address for the Wifi interface has a vendor part that is attributed to Espressif, so this might well be true.
I’ll look around for Tasmota and ESPEasy support, thanks for the suggestion

1 Like
4

Well, before going all crazy with reflashing the firmware, I set up a lying DNS so that the name resolution for the MQTT broker ends up giving my own broker IP address instead of the vendor’s.
And here, I got half lucky. By that I mean that the bulb refuses to connect to my broker because it does not know the root CA for my certificate. This is kinda strange because it is the Let’s Encrypt one, but I suspect the “Alljoyn” back and forth to provide the certificate to the bulb and so it knows just one root CA.

However, on the side of the android app, it is quite happy to talk to my MQTT broker and I could see what’s being sent by the app:

{"capability":"check_bulb_state","externalId":"IDAmpoule","nodeId":"UIDNode","gatewayId":"UIDGateway","requestIdentifier":"check_bulb_state_android_GUID1_UIDRequests","responseMessageKey":"check_bulb_state","type":"CAPABILITY","userId":"UIDUser"}
{"value":"ON","capability":"switch_electrical_power","externalId":"IDAmpoule","nodeId":"UIDNode","gatewayId":"UIDGateway","requestIdentifier":"switch_electrical_power_android_GUID2_UIDRequests","responseMessageKey":"switch_electrical_power","type":"CAPABILITY","userId":"UIDUser"}
{"value":0.75,"capability":"change_brightness","externalId":"IDAmpoule","nodeId":"UIDNode","gatewayId":"UIDGateway","requestIdentifier":"change_brightness_android_GUID3_UIDRequests","responseMessageKey":"change_brightness","type":"CAPABILITY","userId":"UIDUser"}
{"value":"T2750K","capability":"change_color_temperature","externalId":"IDAmpoule","nodeId":"UIDNode","gatewayId":"UIDGateway","requestIdentifier":"change_color_temperature_android_GUID4_UIDRequests","responseMessageKey":"change_color_temperature","type":"CAPABILITY","userId":"UIDUser"}

Nothing fancy here, it’s all JSON, the only tricky part are the used UIDs which seem to have been given to the bulb during AllJoyn configuration. This makes sense in order to avoid controlling your neighbor’s bulb because in the official app, everyone is going through the same broker.
And to make things more difficult, I tried connecting to this “official” broker, but mosquitto_sub is not happy because their certificate is using a “self-signed” root CA which is hidden behind a second level CA certificate, making it effectively unreachable.

In short, if I want to go further, I need to interpret the AllJoyn messages to setup the bulb so that it goes through my own broker.
I tried using the AllJoyn dashboard for Android from here and while it sees the bulb, it tells me it has no known capability which is not too surprising actually.

The investigation continues…

5

any updates ?
I’m also interested, I have the same light bulb

6

Sadly, no.
I tried various AllJoyn clients but could not get much out of the communication.
I started hooking into the Android application with Frida, but I must admit this a bit of a daunting task. I went as far as identifying the items that “build” the communication elements but I could not get them in the clear before they are encrypted. And even then, I’m not sure I would be able to replicate this in a “homemade” application.
As it stands, I lost a bit of interest in this, the bulb is sitting on my desk doing pretty much nothing…
But it’s still in the back of my head, so please do not hesitate to explore further what can be done with this…