Prototype wrapup #37

Last time I was doing some web experiments and some stuff in a new language. This set of prototypes was a bit more practical, but still included some new language tomfoolery.

Tuesday

I've had an Arduino ECG shield kicking around for ages that I've been meaning to try out, so I figured I'd give it a try. The example sketch worked great, and it just dumps data via serial, so I figured I'd do some Rust to read the serial data and print it. I spent a while trying to figure out the right way to do packet parsing in Rust, before eventually giving up and just printing the raw data. The data looked cool, though Rust's immature library ecosystem makes it probably the wrong choice of tool for this sort of problem when compared with, say, Python.

Thursday

I wanted to try out some Elm again, after my previous attempts turned out fairly unimpressively. Elm has since ditched its effect model for a new system so I figured that would be fun. I actually felt like I was fighting things less this time, so it's nice to see the language mature. This was just a simple toy to generate random numbers (impure!) and send them over websockets (even more impure!). Worked well though, and had a much better experience than before. Elm still seems to really like starting you off with a simple mode with less options, which is just confusing because you outgrow it so quickly and then have to rewrite everything.

Saturday

I recently got some milight smart bulbs and was hoping to control them using one of the many embedded computers I have lying around. Unfortunately, the protocol has some scrambling that's just complex enough to be annoying to hobbyists, while basic enough not to add any actual security. Oh, hardware manufacturers, never change. So I figured I'd put on my reverse-engineering hat and have a crack at it. First step was to pull together the various bits of information about the new bulbs and how to communicate with them. This culminated in a patch to the openmili library, which let me dump out the data.

Sunday

Next is the unscrambling. I've never really done a lot of this, but I figured I'd just look for patterns. Each message is 9 bytes. Bytes 1-6 and 8 seem to be random, but if one is the same then they're all the same, while bytes 7 and 9 are only the same when you reset the remote, making 7 likely a counter and 9 likely a checksum. I collected enough data to find a way to predict byte 2 given byte 1. I think that technique should allow for eventually descrambling the whole thing, but I have to figure out how the counter byte changes. For now, this prototype is just the code for predicting that second byte.