I bricked my Christmas lights | Hacker News Reader

I bricked my Christmas lights

whizzy.org

692 pointswillcooke82 comments

Open articleView on HN

FTA:

> When we try and decrypt the on and off packets we get:

> 05 54 55 52 4E 01 00 00 00 00 00 00 00 00 00 00

> 05 54 55 52 4E 00 00 00 00 00 00 00 00 00 00 00

> 05 54 55 52 4E 01 00 00 00 00 00 00 00 00 00 00

> 05 54 55 52 4E 00 00 00 00 00 00 00 00 00 00 00

> 05 54 55 52 4E 01 00 00 00 00 00 00 00 00 00 00

> 05 54 55 52 4E 00 00 00 00 00 00 00 00 00 00 00

> Success! This is a lot more sensible. A fixed header, byte 5 switching between a 1 and a 0 for on and off, and a bunch of zeros.

I would guess that’s not a ‘fixed header’, but a length byte (“command is 5 bytes long”), a command (“TURN”) and an argument (zero or one), padded with zeroes to 16 bytes.

Oooh! Good spot. I will check other commands and see if that length idea works out. I think it could.

That’s pretty typical of binary formats. That and offsets or addresses. And type tags. Assuming the payload isn’t compressed or encrypted, you can get pretty far assuming you’ll run into one of those eventually.

Anecdotally, earlier today I was trying to decipher Encarta data and came across the “Mind Maze” data and it’s mostly that - fixed 32-but header, question size, (answer size, answer, correct flag, something I haven’t figure out yet){4}. Then a separate file with an index value and an offset into the first file as well as a header I haven’t figured out yet.

That "54 55 52 4E" jumped right out to my eye as the uppercase alphabet. Knowing that numbers start at 0x30, uppercase letters start at 0x41, and lowercase letters start at 0x61 makes alphanumeric patterns in hex dumps easy to spot.

That knowledge is good for short strings, but the canonical hexdump format is a the best way to look at packet and memory dumps.

> uppercase letters start at 0x41, and lowercase letters start at 0x61

And the reason for the 0x20 difference is that the Shift key on old teletypes turned the 0x20 bit on and off.

In the same way the Control key turned the 0x40 bit off. So Ctrl-A = 0x01 = 'A'/0x41 - 0x40.

That's a great catch. 0x54 55 52 4E indeed are T U R N.

Turn off the wifi.

The header is fixed in this case.. By length and start point.

And it's probably not padding, just a uint

It is padding. It was encrypted with AES, which has a block size of 128 bits. Its input needs to be padded to that amount, unless you use it in some stream modes of operation (e.g. CTR).

Eugh I hope not the padding should be at block level not at content level if this was the standard zero padding from a crypto lib you'd have 0x80 before the padding bytes (and you'd get the unpadded message when decoding it correctly)

Well, they're encrypting with a statically-built-in key shared across all of their devices (and even with others). I hardly think they care about properly implementing padding!

Power supply failure? The WS281x things can go really bright, and, in bulk, suck an awful lot of current. A 12V, 3A power supply on a strip of 100 is just about enough to drive them all to full bright white, and dazzlingly bright it is. So I'd look for a blown fuse. The fact that the firmware only drives them to 31 out of a possible maximum brightness of 255 offers a clue.

Good idea! I’ll get the multimeter out.

That was my first intuition as well, seeing the brigthness limited to 0x1f. With any luck, the power supply might have a fuse, and it's just the fuse that blew up.

Anyway, if you can't salvage it, standard WS281x LED strings can be hooked up to a Raspberry Pi and you could use my open source addressable LED controller :) https://github.com/mbevand/ledthemfight It comes with built-in effects. I made it very modular so for the DIY crowd, in 2 lines of Python, you can create simple custom LED effect modules. See a demo here: https://youtu.be/qpd2rILsnM4

These don't appear to be WS2812. Look at the Ali link he posted. There is a pic of the wires that show four conductors on the strip: 12V, red, green, and blue. I think this is an analog RGB strip where are the lights in the strip are the same color vs. individually addressible.

https://www.aliexpress.com/item/1005005485885067.html

Anybody wanting to do anything with LED lighting owes it to themselves to look at WLED. Lots of built in effects, web gui, super cheap ESP32 (or ESP 8266!) as the controller, sound-reactive, etc etc etc. WLED is running my indoor Christmas lights right now and they look great.

The actual string I have is three wires. Data and + - it’s likely they have been swapped out for cheaper lesds now, or the picture is wrong.

I looked at the picture again, it does show a three wire set up.

The WS2815 (12V version) actually is a 4 wire setup. It has a "backup data wire" that allows a single failed LED unit to be bypassed.

http://www.normandled.com/upload/201808/WS2815%20LED%20Datas...

There are individually addressable leds that have their ‘address’ burned into them and use a ws2812-style protocol, it could be that. There will only be one continuous data wire, which is cheaper to assemble and resistant to single LED failures.

Thanks for the tip off.

I've updated the code to shift right by 3 places and so go back to a 5 bit number.

That's a neat way of limiting the power usage.

Nice writeup! It reminded me of trying to reverse engineer some lights I have, only to discover they’re encrypted. One is an amaran 60d and then the rest are a handful of SmallRig RM75 battery LED lights, and I wanted to make a script to turn them all on/off instead of fiddling with 2 separate apps.

I spent a bunch of time trying to reverse engineer the apps and the protocol, and it turns out both of these lights seem to use the same negotiation process but use different libraries to do it. I tried to mimic the Diffie-Hellman key exchange process they do on connection, and then kinda gave up. IIRC there was another step or 2 after that, one where it sent a random-looking number (another key? After sending the first key??) and I couldn’t figure out what it wanted there.

Your writeup makes me think I should just go try that hardcoded key and see if it works…

Oh, I would so love to see you succeed with the Amaran lights, which presumably would lead to all of the Aputure stuff being reverse engineered? I think if there was an open-source integration for them with say the Elgato Stream Deck or Home Assistant, it would be a major, major success story. For all those YouTube folks that do talking head at their desk this would be sooo much better than controlling them via an app on the phone.

I was trying to automate my BLE connected Christmas lights but instead I created e-waste. Now you can too!

you can still use them as dummy/classic lights if you bypass the controller

I can just swap the micro controller with something like an ESP8266 and run WLED.

I did this super similar (ESP32) with a set I got from walmart. Works great!

I find it amazing to think that your Christmas lights are now way more powerful than my first computer.

I think about stuff like this a lot, like what technologies I'm (ab)using to do some silly gadget thing.

Even though it's way more powerful than my first computer, it uses only a fraction of the energy. So yes, in a way maybe you're abusing a pretty powerful computer to do some silly gadget thing, but there's no real negative impact. I know what you mean though. I've only recently gotten into microcontrollers, and because of the time of year I've been thinking of Christmas lights too, and felt the same thing. Then again: I'm also using my M1 Macbook to write a comment on HN, which is only a fraction of what it can do.

Oh no negativity in the statement, I'm enjoying every second of it!

If you get into FastLED, try out the emulator I made – https://editor.soulmatelights.com/gallery/732-rainbow-conway

I haven't worked on it at all recently (COVID project) but it's fun for experimenting. You can also flash ESP32s from the downloadable desktop app

I bought a big spool of addressable lights from Aliexpress and hooked them up to an ESP32. Took some soldering and other hacking, but they’re really, really, nice.

Not sure what you did with it, but I found that some of this SmartTrash does a hard reset when you do some magic sequence such as quickly turning if off/on 5 times in a row.

If you want a more GUI-oriented way of doing BLE packet sniffing, try the nRF Connect app. Not sure about iPhone, but if you let it sit in the background on Android, you can pick up BLE activity from a nice little GUI on your phone. I use it every day.

Reminds me somewhat of certain keyboard MCUs that would also brick when fed certain lighting commands.

OpenRGB ended up having to disable the particular module from running automatically on that hardware. (Although the vendor software would also trigger said bug, on occassion.)

Unfortunately, the usual way for triggering the in-system programming mode required sending a usb hid report, but affected devices wouldn't even enumerate anymore. (Assuming it was even firmware corruption and not some other undefined behaviour causing hardware damage)

"We can't send plaintext over the air, it's unsafe"

"Don't worry I've added AES encryption"

Encryption against air I suppose

Tuya is so hilarious in this regard. The protocol is just TLS over TCP, but the app happily sprays your Wi-Fi password to every STA in the area every time you add a new device.

(It's how pairing is done - the app blindly broadcasts packets to 255.255.255.255 and the target device (lightbulb, power outlet, et al) just sits in promiscuous mode. The packet contents are protected by WPA2 et al, but the packet lengths aren't, so the protocol sends a bajillion tiny packets with each packet's length set to the ASCII byte value of the next character in the setup handshake. I believe it sends it multiple times in a row. This is why pairing takes 2 minutes then always abruptly stops before the counter reaches zero.)

\o/

That sounds extremely greasy

Very clever.

IoT pairing is a tricky problem because phone/laptop devices give a very limited API for communicating with a new WiFi device that isn't yet on your WiFi network.

I've seen an iot app do it via multicast - the destination MAC isn't encrypted in the wifi frames, and the last one or two bytes of them are controlled by the sending app.

I figured this out when I tried to debug why the pairing didn't work from my phone, but did from an old Samsung A2: the iot device only had a 2.4ghz module, my new phone was on 5ghz...

Isn't this was bluetooth was supposed to be able to help with?

I suspect Tuya wants a solution that lets them implement a solution stack for Wi-Fi+BT and Wi-Fi-only MCUs alike.

All of the decent WiFi-only IoT devices I've seen bootstrap the process by acting as an access point of their own until they're configured. There are some opportunities for securing that initial connection better, like ensuring that the WPA2 key for the temporary AP mode is complex and unique to each device, but I haven't come across a fundamental flaw in the approach. Are you aware of any?

I'd prefer an out-of-band option, like "physically connect the new device to the IoT hub's 'new device' port to configure it automatically before moving it to its permanent location", or "scan the QR code on the new device, which contains a public key that the IoT hub will use to broadcast the WiFi credentials over RF", but I understand that at least for mass-market residential products, that's unlikely because it generally involves more components on each device.

This is what I was really afraid of when I reverse engineered my fireplace BLE controller last year. Especially since the "Set password" command accepts raw bytes for input but the OEM app only ever sends length-limited numeric data.

Luckily, it seems to completely forget anything that happened to it after a brief power loss.

Which is probably why most of the BLE controllers of the same brand simply stay at the default password of "0000". A power outage will eventually get you back to that. If you're really bored that'd probably make for some great BLE wardriving.

But I, too, ended up putting the results of my reverse engineering into a Home Assistant integration (https://github.com/kaechele/napoleon-efire) and documented the system and protocol (https://bonaparte.readthedocs.io/en/latest/index.html).

I'm looking for some flexible, robust lights for my car's roof rack. I'm wondering if anyone knows a set that will fit these requirements:

  - Battery powered and outdoor / all weather compatible

  - Easy to attach the battery box to surfaces using ties

  - Ideally "mini" form factor ("T5") [1]

  - Ideally RGB and programmable. I'd like to use them for 
    Christmas (red/green), Halloween (purple/orange), and 
    other seasons.

Does anyone know of anything that fits this bill? I've had trouble finding anything that fits the last criterion. Walmart and Home Depot will sell the first three.

When I search for this, I just get noise.

[1] https://cdn.christmaslightsetc.com/images/CategoryDetail/788...

You can check out "bullet string" style WS2811s. They're 12v native if you're tying back to your car's 12v, usually come waterproof with xConnect pigtails, and are very attachable/flexible. They're easy to resolder with extensions and chain too:

https://www.aliexpress.com/item/4000105913323.html

From what I've ready, they or similar 5V lights seem standard in outdoor Christmas lighting for shows.

12V is used more often than 5V for outdoor shows. This vendor is very popular, and also has a discussion about 12V vs. 5V: https://www.holidaycoro.com/kb_results.asp?ID=126 Also, the xConnect pigtails are great for wiring up large shows and for adding longer run extension cables.

Your direction depends (I guess) on how much DIY effort you're willing to put in?

For example, you can get 12v LED strips which are IP67 (waterproof inside a silicon tube) pretty easily [0] and which would probably give a much more impressive effect than a string of Christmas-style lights, due to having lots more LEDs to play with.

However, you'd need to do the leg-work of also buying and programming a micro-controller (something like an Arduino, ESP32, or ESP8266 [1]) and figuring out how to power them from your car battery. You could probably house all of the electronics inside the car and just run wires out of the boot, relying on the existing boot seal to keep everything waterproof.

[0] https://www.aliexpress.com/item/1005004289391906.html [1] https://www.aliexpress.com/item/1005005977505151.html

Join the WLED Discord and look in the #projects and #showcase channels. There are lots of projects with people outfitting their vehicle with RGB LED lights. Just beware that it is really easy to get hooked on this stuff!

Here's an invite: https://discord.gg/eVhhh2Wh

It goes up to eleven

Icarus flew too close to the sun

But not twelve... :(

Why not just make ten brighter and then be on nine?

But this goes to eleven... ;-)

They're one brighter

Can we see a disassembly of the dead christmas lights?

Knowing what chip they have inside can give a clue if there is flash memory and if it might be easy to dump.

Why do they use encryption?

For future DaaS perhaps. Everything is becoming a service, why not decoration...

Nice, so they can get my money monthly. Where do I sign up? Can I also rent custom lighting schemes? I would love one to light up on the notes of Twinkle, Twinkle Little Star.

To force you to use their app so the marketing & product people can get the "engagement" they need to justify their jobs of course.

I've read enough... A set of lights with BLE, I'm out. Thanks to the author for referencing them.

It did remind me of the analog Technology Connections video : https://www.youtube.com/watch?v=va1rzP2xIx4

Why are these messages encrypted? Is that just a standard thing?

I don't think that's standard, probably just manufacturer crap but i never tried to hack christmas lights

It might be worth looking at the decompiled app code some more and seeing if it contains any clues as to the type of command you may have sent, just in case it happens to be some command used for updating the firmware or something. It probably isn't, but you never know.

That said, I suspect you're right and the order of operations was probably something like this, assuming the light controller uses a microprocessor:

1. Controller receives valid command to switch to light pattern 12.

2. Light pattern 12 is saved as user's preference (so it can be restored on power-on).

3. Controller attempts to find light pattern 12 and hits a bounds overflow in the pattern lookup table.

4. There's probably no error checking for this because this "can't happen"[0], so it tries to use the data it finds, which is garbage.

(The next steps depend on how the lookup table is formed, but for the sake of example, let's say the lookup table is an array of pointers to callback routines for each pattern.)

5. The controller remembers whatever garbage it found, treating it as a pointer.

6. The next time the controller wants to update the lights, it tries to call this garbage pointer (which is possibly just a null pointer).

7. Microprocessor tries to execute code there, but whatever it finds causes it instead to infinitely loop.

8. Dimming LEDs typically require a PWM signal, which they're no longer getting, so they go dark.

9. It's dead, Jim.

When you switch off and on again, the process restarts at step 3.

In other words, there may be a possibility for unbricking if you can factory reset, or find out how it stored your light pattern. (Though the latter will probably require at least opening it up and hoping you find a JTAG header, and a lot of patience and Zen. Don't do things willy-nilly!)

In any case, that's my best guess as to what happened here, based purely on the story and without any knowledge of the architecture or home integration ecosystem. If you attempt to fix it, good luck!

[0] http://www.catb.org/jargon/html/C/can-t-happen.html

Beginners question, is there a reason we can’t reverse engineer something similar for lights made by Govee? Is it because it’s WiFi and harder to MITM?

I have a couple of Govee light bulbs in my garage I control with an M5StickC using BLE: https://github.com/stevenjohnstone/reversing-tools/blob/main... . Looking at the decompiled Govee android app, there are many products with similar control over BLE in addition to wifi.

The Govee strips I have do support Bluetooth connectivity. In fact, that’s how they are setup initially.

Your comment prompted me to search for “Govee LAN” and found HomeAssistant LAN integration. Time to dig deeper!

https://www.reddit.com/r/homeassistant/s/bppM4AR3uA

I might need to buy some and try this out, Philips hue pricing has gotten out of hand since covid

There may be an easier way, but another HN thread pointed out that you can use tailscale to make it easier to tcpdump phone apps (because you can send all of the phone traffic through an endpoint you control.) (Presumably raw wireguard is enough? I haven't tried (or seen tutorials for) either approach, it was just a "that sounds clever, save it for my next sniffer project" idea)

Whoa that’s an interesting idea, use a tailscale exit node and use tcpdump on the interface

https://mitmproxy.org/

I like the form factor of some of the Govee string lights. I’ve thrown out their controller and hooked them to ESP32’s with WLED. Best of both worlds that way.

This sounds amazing, do you use ESPhomr with it?! Any tutorial cause I love this idea

There are a few projects on github for govee lights. On windows I have used https://github.com/ib0b/RGB-PC to connect to mine by bluetooth but the problem is that govee lights can only be connected to one bluetooth device at a time

Nice write up. At least it’s proper bricked and not “they stopped working so I will reset them” bricked. You did real good.

> Tell me how I can > break my own lights

Ha! Love that.

Nice writeup! It could be that it wrote the last value to some flash memory but since it is invalid and overflows something, it panics and will never finish booting.

Bah! Humbug!

This is why I like dumb things.

Christmas tree lights always were unreliable.

From the UK's Telegraph (which does have a older pre computer readership who would fully understand this )

https://www.telegraph.co.uk/content/dam/news/2023/12/05/TELE...

And to be fair it wasn't their 'smartness' that killed them anyway, it was hacker mindset!

Christmas tree lights had different pattern modes etc. even before they were LED, for decades. I honestly think swapping button on the controller/power supply brick for a Bluetooth remote is a reasonable level of smart in this day and age. It's not like they wanted to connect to WiFi and be app-controlled via their servers or something.

Reply on news.ycombinator.com