[HN Gopher] I bricked my Christmas lights
___________________________________________________________________
I bricked my Christmas lights
Author : willcooke
Score : 623 points
Date : 2023-12-15 18:41 UTC (2 days ago)
(HTM) web link (www.whizzy.org)
(TXT) w3m dump (www.whizzy.org)
| willcooke wrote:
| I was trying to automate my BLE connected Christmas lights but
| instead I created e-waste. Now you can too!
| CTOSian wrote:
| you can still use them as dummy/classic lights if you bypass
| the controller
| willcooke wrote:
| +1
|
| I can just swap the micro controller with something like an
| ESP8266 and run WLED.
| green-salt wrote:
| I did this super similar (ESP32) with a set I got from
| walmart. Works great!
| wkjagt wrote:
| I find it amazing to think that your Christmas lights are
| now way more powerful than my first computer.
| green-salt wrote:
| I think about stuff like this a lot, like what
| technologies I'm (ab)using to do some silly gadget thing.
| wkjagt wrote:
| 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.
| green-salt wrote:
| Oh no negativity in the statement, I'm enjoying every
| second of it!
| elliottkember wrote:
| 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
| organsnyder wrote:
| 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.
| sva_ wrote:
| 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.
| ryukoposting wrote:
| 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.
| Someone wrote:
| 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.
| willcooke wrote:
| Oooh! Good spot. I will check other commands and see if that
| length idea works out. I think it could.
| jonhohle wrote:
| 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.
| EvanAnderson wrote:
| 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.
| fl7305 wrote:
| > 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.
| ww520 wrote:
| That's a great catch. 0x54 55 52 4E indeed are T U R N.
| kordlessagain wrote:
| Turn off the wifi.
| bilekas wrote:
| The header is fixed in this case.. By length and start point.
| avereveard wrote:
| And it's probably not padding, just a uint
| aaronmdjones wrote:
| 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).
| avereveard wrote:
| 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)
| aaronmdjones wrote:
| 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!
| MarkusWandel wrote:
| 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.
| willcooke wrote:
| Good idea! I'll get the multimeter out.
| mrb wrote:
| 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
| MegaDeKay wrote:
| 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.
| willcooke wrote:
| 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.
| willcooke wrote:
| I looked at the picture again, it does show a three wire
| set up.
| MarkusWandel wrote:
| 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%20Da
| tas...
| willcooke wrote:
| 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.
| thomasjudge wrote:
| It goes up to eleven
| nicky0 wrote:
| Icarus flew too close to the sun
| qingcharles wrote:
| But not twelve... :(
| riddley wrote:
| Why not just make ten brighter and then be on nine?
| jdshaffer wrote:
| But this goes to eleven... ;-)
| LocalH wrote:
| They're one brighter
| taylodl wrote:
| Bah! Humbug!
|
| This is why I like dumb things.
| pasc1878 wrote:
| 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...
| OJFord wrote:
| 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.
| syntaxing wrote:
| 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?
| steviej wrote:
| 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.
| gsharma wrote:
| 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
| syntaxing wrote:
| I might need to buy some and try this out, Philips hue
| pricing has gotten out of hand since covid
| eichin wrote:
| 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)
| syntaxing wrote:
| Whoa that's an interesting idea, use a tailscale exit node
| and use tcpdump on the interface
| Tijdreiziger wrote:
| https://mitmproxy.org/
| brk wrote:
| 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.
| syntaxing wrote:
| This sounds amazing, do you use ESPhomr with it?! Any
| tutorial cause I love this idea
| jccalhoun wrote:
| 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
| urbandw311er wrote:
| > Tell me how I can > break my own lights
|
| Ha! Love that.
| echelon wrote:
| 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...
| averageRoyalty wrote:
| 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.
| peterleiser wrote:
| 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.
| mft_ wrote:
| 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
| MegaDeKay wrote:
| 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
| mytailorisrich wrote:
| "We can't send plaintext over the air, it's unsafe"
|
| "Don't worry I've added AES encryption"
| ivanjermakov wrote:
| Encryption against air I suppose
| exikyut wrote:
| 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/
| LocalH wrote:
| That sounds extremely greasy
| londons_explore wrote:
| 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.
| iforgotpassword wrote:
| 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...
| treyd wrote:
| Isn't this was bluetooth was supposed to be able to help
| with?
| dceddia wrote:
| 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...
| bilekas wrote:
| 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
| m4dc4pXXX wrote:
| Why are these messages encrypted? Is that just a standard thing?
| Namidairo wrote:
| 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)
| DeathArrow wrote:
| Why do they use encryption?
| netmare wrote:
| For future DaaS perhaps. Everything is becoming a service, why
| not decoration...
| DeathArrow wrote:
| 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.
| Nextgrid wrote:
| To force you to use their app so the marketing & product people
| can get the "engagement" they need to justify their jobs of
| course.
| londons_explore wrote:
| 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.
| HumblyTossed wrote:
| Nice write up. At least it's proper bricked and not "they stopped
| working so I will reset them" bricked. You did real good.
| neop1x wrote:
| 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.
| Sophira wrote:
| 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
| heffer wrote:
| 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).
___________________________________________________________________
(page generated 2023-12-17 23:01 UTC)