ESP-ing A Philips Sound System.

IoT-ifying old stuff is cool. Or even new, offline stuff. It seems to be a trend. And it’s sexy. Yes, it is. Why are people doing this, you may ask: we say why not? Why shouldn’t a toaster be on the IoT? Or a drill press? Or a radio? Yes, a radio.

[Dr. Wummi] just added another device to the IoT, the Internet of Thongs as he calls it. It’s a Philips MCM205 Micro Sound System radio. He wanted to automate his radio but his original idea of building a setup with an infrared LED to remotely control it failed. He blamed it to “some funky IR voodoo”.  So he decided to go for an ESP8266 based solution with a NodeMCU. ESP8266 IR remotes have been known to work before but maybe those were just not voodoo grade.

After opening the radio up, he quickly found that the actual AM/FM Radio was a separate module. The manufacturer was kind enough to leave the pins nicely labelled on the mainboard. Pins labelled SCL/SDA hinted that AM/FM module spoke I²C. He tapped in the protocol via Bus Pirate and it was clear that the radio had an EEPROM somewhere on the main PCB. A search revealed a 24C02 IC in the board, which is a 2K I²C EEPROM. So far so good but there were other functionalities left to control, like volume or CD playing. For that, he planned to tap into the front push button knob. The push button had different resistors and were wired in series so they generated different voltages at the main board radio ADC Pins. He tried to PWM with the NodeMCU to simulate this but it just didn’t work.

Continue reading “ESP-ing A Philips Sound System.”

OWL Insecure Internet Of Energy Monitors

[Chet] bought an electricity monitor from OWL, specifically because it was open and easy to hack on at him within the confines of his home network. Yay! Unfortunately, it also appears to be easy to hack read outside of his home network too, due to what appears to be extraordinarily sloppy security practices.

The short version of the security vulnerability is that the OWL energy monitors seem to be sending out their data to servers at OWL, and this data is then accessible over plain HTTP (not HTTPS) and with the following API: http://beta.owlintuition.com/api/electricity/history_overview.php?user=&nowl=&clientdate=. Not so bad, right? They are requiring username and password, plus the ID number of the device. Maybe someone could intercept your request and read your meter remotely, because it’s not encrypting the transaction?

Nope. Much worse. [Chet] discovered that the username and password fields appear not to be checked, and the ID number is the device’s MAC address which makes is very easy to guess at other device IDs. [Chet] tried 256 MACs out, and got 122 responses with valid data. Oh my!

Take this as a friendly reminder and a cautionary tale. If you’re running any IoT devices, it’s probably worth listening to what they’re saying and noting to whom they’re saying it, because every time you send your data off to “the cloud” you’re trusting someone else to have done their homework. It is not a given that they will have.

SST Is A Very Tidy ESP8266 Smart Thermostat

The smart thermostat has become in a way the public face of the Internet of Things. It’s a demonstration that technological uptake by the general public is driven not by how clever the technology is, but by how much use they can see in it. A fridge that offers your recipes or orders more eggs may be a very neat idea, but at street level a device allowing you to turn your heating on at home before you leave work is much cooler. Products like Nest or Hive have started to become part of normal suburban life.

There is no reason though for an IoT thermostat to be a commercial product like the two mentioned. Our subject today demonstrates this; SST is a Wi-Fi smart thermostat using an ESP8266 that can be controlled by an app, thanks to its use of the open-source Souliss IoT Framework.

The build is very well finished, with PCBs, colour display and other components in a neat 3D-printed box. It’s a project that you could put in front of an end-user, it’s finished to such a high standard. Physical entity files are available from the hackaday.io page linked above, while its firmware is available in a GitHub repository. THere is a video showing some of the device’s capabilities, which we’ve put below the break.

Continue reading “SST Is A Very Tidy ESP8266 Smart Thermostat”

33C3: Breaking IoT Locks

Fast-forward to the end of the talk, and you’ll hear someone in the audience ask [Ray] “Are there any Bluetooth locks that you can recommend?” and he gets to answer “nope, not really.” (If this counts as a spoiler for a talk about the security of three IoT locks at a hacker conference, you need to get out more.)

btle_lockUnlocking a padlock with your cellphone isn’t as crazy as it sounds. The promise of Internet-enabled locks is that they can allow people one-time use or limited access to physical spaces, as easily as sending them an e-mail. Unfortunately, it also opens up additional attack surfaces. Lock making goes from being a skill that involves clever mechanical design and metallurgy, to encryption and secure protocols.

master_jtagIn this fun talk, [Ray] looks at three “IoT” locks. One, he throws out on mechanical grounds once he’s gotten it open — it’s a $100 lock that’s as easily shimmable as that $4 padlock on your gym locker. The other, a Master lock, has a new version of a 2012 vulnerability that [Ray] pointed out to Master: if you move a magnet around the outside the lock, it actuates the motor within, unlocking it. The third, made by Kickstarter company Noke, was at least physically secure, but fell prey to an insecure key exchange protocol.

Along the way, you’ll get some advice on how to quickly and easily audit your own IoT devices. That’s worth the price of admission even if you like your keys made out of metal instead of bits. And one of the more refreshing points, given the hype of some IoT security talks these days, was the nuanced approach that [Ray] took toward what counts as a security problem because it’s exploitable by someone else, rather than vectors that are only “exploitable” by the device’s owner. We like to think of those as customization options.

IoT-ifying An Old LED Signboard

Scrolling LED signs were pretty keen back in the day, and now they’re pretty easy to come by on the cheap. Getting a signboard configured for IoT duty can be tricky, but as [kripthor] shows us, it’s not that bad as long as security isn’t your top concern and you can tweak a serial interface.

dec-16-2016-10-57-pm-edited[kripthor] chanced upon an Amplus AM03127 signboard that hails from the days when tri-color LEDs were the big thing. The unit came with a defunct remote thanks to leaking batteries, but a built-in serial interface offered a way to connect. Unfortunately, the RS-232 standard on the signboard wants both positive and negative voltages with respect to ground to represent the 1s and 0s, and that wouldn’t work with the ESP8266 [kripthor] was targeting. The ubiquitous MAX-232 transceiver was enlisted to convert logic levels to RS-232 signals and a small buck converter was added to power the ESP. A little scripting and the signboard is online and ready for use and abuse by the interwebz — [kripthor] says he’ll regret this, but we’re pleased with the way the first remote access turned out. Feel free to check out the live video feed and see what the current message is.

Personally, we don’t have much use for a signboard, but getting RS-232 devices working in the Arduino ecosystem is definitely a trick we’ll keep in mind. If asynchronous serial protocols aren’t your strong suit, you might want to check out this guide to what can go wrong by our own [Elliot Williams].

Solving IoT Problems With Node.js For Hardware

Tod Kurt knows a thing or two about IoT devices. As the creator of blink(1), he’s shipped over 30,000 units that are now out in the wild and in use for custom signaling on everything from compile status to those emotionally important social media indicators. His talk at the 2016 Hackaday SuperConference covers the last mile that bridges your Internet of Things devices with its intended use. This is where IoT actually happens, and of course where it usually goes astray.

Continue reading “Solving IoT Problems With Node.js For Hardware”

Google Scrubs Brillo, Reveals Android Things

Another week goes by and another new IoT platform surfaces. Google has announced Android Things, a build of the mobile operating system designed for smart devices rather than the latest slab of mobile eye-candy. The idea is that the same Android tools, framework and APIs that will already be familiar to app developers can be used seamlessly on IoT Things as well as in the user’s palm.

Of course, if this is sounding familiar, it’s because you may have heard something of it before. Last year they announced their Project Brillo IoT platform, and this appears to be the fruit of those efforts.

So you may well be asking: what’s in it for us? Is this just another commercial IoT platform with an eye-watering barrier to entry somewhere, or can we join the fun? It turns out the news here is good, because as the project’s web site reveals, there is support for a variety of Intel, NXP, and Raspberry Pi development boards. If you have a Raspberry Pi 3 on your bench somewhere then getting started is as simple as flashing a disk image.

The Things team have produced a set of demonstration software in a GitHub repository for developers to get their teeth into. Never one to miss an opportunity, the British Raspberry Pi hardware developer Pimoroni has released an Android Things HAT laden with sensors and displays for it to run on.

The IoT-platform market feels rather crowded at times, but it is inevitable that Android Things will gain significant traction because of its tight connections with the rest of the Android world, and its backing by Google. From this OS will no doubt come a rash of devices that will become ubiquitous, and because of its low barrier to entry there is every chance that one or two of them could come from one of you. Good luck!