Commodore Home – Your Smart Home For 1983

November 20, 2016 by Brian Benchoff 14 Comments

The Internet of Things is a horrific waste of time, even though no one knows exactly what it is. What would make it better? Classic Commodore gear, of course. Now you can run your smart home with a Commodore 64 and Commodore Home, the newest smart home framework from [retro.moe].

Commodore Home comes with the standard smart home features you would expect. The home lighting solution is a dot matrix printer, a few gears, and string tied to the light switch. Activate the printer, and the lights turn on and off. Brilliant. Multiple light switches can be controlled by daisy chaining printers.

Security is important in the smart home, and while the intruder alarm isn’t completely functional, future versions of Commodore Home will dial a modem, log into a BBS, and leave a message whenever an authorized person enters your home.

All of this is possible thanks to advances in UniJoystiCle technology, also from [retro.moe]. This device takes a standard ESP8266 WiFi module and turns it into a smartphone-to-joystick port bridge for the Commodore 64.

Unlike every other piece of IoT hardware being sold today, Commodore Home won’t stop working when the company behind it goes belly up; Commodore has been dead for twenty years already. You can grab all the software for Commodore Home over on the Githubs, or you can check out the video below.

Continue reading “Commodore Home – Your Smart Home For 1983” →

Jenkins And Slack Report Build Failure! Light The Beacons!

November 19, 2016 by Rich Hawkes 10 Comments

When you have a large software development team working on a project, monitoring the build server is an important part of the process. When a message comes in from your build servers, you need to take time away from what you’re doing to make sure the build’s not broken and, if it’s broken because of something you did, you have to stop what you’re doing, start fixing it and let people know that you’re on it.

[ridingintraffic]’s team uses Jenkins to automatically build their project and if there’s a problem, it sends a message to a Slack channel. This means the team needs to be monitoring the Slack channel, which can lead to some delays. [ridingintraffic] wanted immediate knowledge of a build problem, so with some software, IoT hardware, and a rotating hazard warning light, the team now gets a visible message that there’s a build problem.

An Adafruit Huzzah ESP8266 board is used as the controller, connected to some RF controlled power outlets via a 434MHz radio module. To prototype the system, [ridingintraffic] used an Arduino hooked up to one of the RF modules to sniff out the codes for turning the power outlets on and off from their remotes. With the codes in hand, work on the Huzzah board began.

An MQTT broker is used to let the Huzzah know when there’s been a build failure. If there is, the Huzzah turns the light beacon on via the power outlets. A bot running on the Slack channel listens for a message from one of the developers saying that problem is being worked on, and when it gets it, it sends the MQTT broker a message to turn the beacon off.

There’s also some separation between the internal network, the Huzzahs, and the Slack server on the internet, and [ridingintraffic] goes over the methods used to communicate between the layers in a more detailed blog post. Now, the developers in [ridingintraffic]’s office don’t need to be glued to the Slack channel, they will not miss the beacon when it signals to start panicking!

Waiting For A Letter? This IoT Mailbox Will Tell You Exactly When It Arrives.

November 15, 2016 by James Hobson 29 Comments

If you’re waiting for a much sought-after letter, checking your mailbox every five minutes can be a roller-coaster of emotion — not to mention time-consuming. If you fall into this trap, Hackaday.io user [CuriosityGym] as whipped up a mailbox that will send off an email once the snail-mail arrives.

The project uses an Arduino Uno, an ESP 8266 wifi module, and an idIoTware shield board — making specific use of its RGB LED and light dependent resistor(LDR). Configuring the RGB LED on the idIoTware board to a steady white light sets the baseline for the LDR, and when a letter is dropped in the box, the change in brightness is registered by the LDR, triggering the Arduino to send off the email.

Continue reading “Waiting For A Letter? This IoT Mailbox Will Tell You Exactly When It Arrives.” →

ArduWorm: A Malware For Your Arduino Yun

November 11, 2016 by Elliot Williams 24 Comments

We’ve been waiting for this one. A worm was written for the Internet-connected Arduino Yun that gets in through a memory corruption exploit in the ATmega32u4 that’s used as the serial bridge. The paper (as PDF) is a bit technical, but if you’re interested, it’s a great read. (Edit: The link went dead. Here is our local copy.)

The crux of the hack is getting the AVR to run out of RAM, which more than a few of us have done accidentally from time to time. Here, the hackers write more and more data into memory until they end up writing into the heap, where data that’s used to control the program lives. Writing a worm for the AVR isn’t as easy as it was in the 1990’s on PCs, because a lot of the code that you’d like to run is in flash, and thus immutable. However, if you know where enough functions are located in flash, you can just use what’s there. These kind of return-oriented programming (ROP) tricks were enough for the researchers to write a worm.

In the end, the worm is persistent, can spread from Yun to Yun, and can do most everything that you’d love/hate a worm to do. In security, we all know that a chain is only as strong as its weakest link, and here the attack isn’t against the OpenWRT Linux system running on the big chip, but rather against the small AVR chip playing a support role. Because the AVR is completely trusted by the Linux system, once you’ve got that, you’ve won.

Will this amount to anything in practice? Probably not. There are tons of systems out there with much more easily accessed vulnerabilities: hard-coded passwords and poor encryption protocols. Attacking all the Yuns in the world wouldn’t be worth one’s time. It’s a very cool proof of concept, and in our opinion, that’s even better.

Thanks [Dave] for the great tip!

IoT Coop Door Cares For Chickens, Tests Home Automation

November 6, 2016 by Dan Maloney 28 Comments

Most chickens are pretty good at putting themselves to bed when the sun sets, and [Eddy]’s chickens are no exception. But they’re not terribly thoughtful about closing up after themselves, so he set about on a long-term project to automate the door of their coop.

An open door overnight leaves chickens and their food vulnerable to predation. Rather than handle the chore manually and risk one forgetful moment that could wipe out his flock, [Eddy] used a servo to power the door and an Arduino to control it. To keep track of bedtime and wakeup, a Raspberry Pi looks up the local civil dawn and twilight times online and tells the Arduino when the moment is at hand. The Pi cleverly caches the times for use the next day in case the WiFi connection is down, and also provides a web interface to check on the door’s status and manually override the cycle. Result: safe, happy chickens.

If all this seems a bit much for a simple job, [Eddy] agrees. But he’s using this as a testbed to develop a home automation framework that can be retasked at will. Sounds like he’s on the right track to us, but for more IoT animal husbandry tips, he’ll want to check out this small farm automation effort.

Continue reading “IoT Coop Door Cares For Chickens, Tests Home Automation” →

Hajime, Yet Another IoT Botnet

October 20, 2016 by Brian Benchoff 31 Comments

Following on the heels of Mirai, a family of malware exploiting Internet of Things devices, [Sam Edwards] and [Ioannis Profetis] of Rapidity Networks have discovered a malicious Internet worm dubbed Hajime which targets Internet of Things devices.

Around the beginning of October, news of an IoT botnet came forward, turning IP webcams around the world into a DDoS machine. Rapidity Networks took an interest in this worm, and set out a few honeypots in the hopes of discovering what makes it tick.

Looking closely at the data, there was evidence of a second botnet that was significantly more sophisticated. Right now, they’re calling this worm Hajime.

Continue reading “Hajime, Yet Another IoT Botnet” →

UK IT Specialist Unable To Boil Water, Make Tea

October 20, 2016 by Elliot Williams 54 Comments

In our latest episode of “IoT-Schadenfreude Theater” we bring you the story of [Mark], a British man who can’t boil water. Or more specifically, a man who can’t integrate MQTT with Amazon Echo, or IFTTT with HomeKit.

Yes, yes. We all love to laugh at a technology in its infancy. It’s like when robots fall down: it’s a cheap shot and things will surely get better, right? Indeed, the Guardian has had its fun with this particular WiFi kettle before — they’re British and nothing is more important than a remote-controlled cuppa.

Every time we hear about one walled-garden protocol not speaking to another, and the resulting configuration mayhem that ensues, we can’t help think that [Mike] was right: home automation has a software problem. But that’s putting the blame on the technology. (We’re sure that [Mark] could have made the kettle work if he’d just applied a little Wireshark.)

There’s another mismatch here — one of expectations about the users. A water kettle is an object that should be usable by grandmothers, and a complex networked device is clearly aimed at techies and early adopters. Combining the two is asking for trouble. Non-functioning IoT devices are the blinking 12:00 of our generation.

What do you think? Where’s the blame here? Poor design, bad software stack, stupid users, or failure of mega-corps to integrate their systems together? More importantly, how could we make it better?

Headline image:Fredy Velásquez Orozco, via Wikimedia Commons Thumbnail image: Markus Schweiss, also Wikimedia Commons.