Physicist and squirrel gastronomer [Carsten Dannat] is trying to correlate two critical social economical factors: how many summer days do we have left, and when will we run out of nuts. His research project, the Squirrel Café, invites squirrels to grab some free nuts and collects interesting bits of customer data in return.
Building on the work of others (as is always the case!) [pepe2k] managed to get root access on the Philips Hue Bridge v2 IoT light controller. There’s nothing unusual here, really. Connect to the device over serial, interrupt the boot process, boot up open firmware, dump the existing firmware, and work the hacker magic from there.
Of course, the details are the real story. Philips had set U-Boot to boot the firmware from flash in zero seconds, not allowing [pepe2k] much time to interrupt it. So he desoldered the flash, giving him all the time in the world, and allowing him to change the boot delay. Resoldering the flash and loading up his own system let him dump the firmware.
The “hacker magic” glossed over in the intro consisted of poking around until he found a script that was called on every boot. This is how [pepe2k] gets around not knowing the root password. The script compares the hash of the typed password with an environment variable, set with the hash of the correct password. Changing that environment variable to the hash of his favorite password (“root”) made him master of the box.
And just in case you’re one of the few Hackaday readers who doesn’t understand why we do these things, besides the fact that it’s just fun, consider Philips’ (eventually retracted) clampdown on the interoperability of this very device, or Google’s red bricks. The fatal flaw of IoT devices is that they place you at the whims of companies who may decide that they’re not making enough money any more, and shut them down. Keep your hacking skills sharp.
Thanks [Jan] for the great tip!
There’s something irresistible about throwing Pokeballs at unexpectedly appearing creatures. But wait. When did you actually, physically throw a Pokeball? Swiping over colored pixels wasn’t enough for [Trey Keown], so he built a real, throwable, Pokemon-catching Pokeball for Pokemon Go.
Yet another Internet of Things service has left its customers in the lurch. IoT devices (mostly lightbulbs)
made sold by Greenwave Systems stopped talking to the outside world on July 1. More specifically, the server to which they all connected (ahem, “the cloud”) has been turned off, which rules out using the bulbs with Internet-based services like IFTTT, which was a major selling point of the Things in the first place.
[Edit: We were contacted by Greenwave, and they pointed out that they merely sold the IoT devices in question. They are made by TCP, which is also responsible for cancelling the service. And TCP has a history of doing this sort of thing before.]
It’s not the first time we’ve seen IoT companies renege on their promises to provide service, and it’s surely not going to be the last. We’re preaching to the choir here, but when even Google is willing to take the PR hit to effectively brick your devices, the only protection that you’ve got against obsolescence is an open protocol.
At least the users of
Greenwave’s TCP’s devices will continue to be able to control them from within the home. That, plus some clever hacking, will make them workable into the future. But it’s not like the convenience that was sold with the devices.
Boo to shady IoT companies! But thanks to [Adrian] for the tip.
The Internet of Things has been presented as the future of consumer electronics for the better part of a decade now. Billions have been invested, despite no one actually knowing what the Internet of Things will do. Those billions need to go somewhere, and in the case of Texas Instruments, it’s gone straight into the next generation of microcontrollers with integrated sub-GHz radios. [M.daSilva]’s entry to the 2016 Hackaday Prize turns these small, cheap, radios into a portable communicator.
This ‘modem for the 400 MHz band’ consists simply of an ATmega microcontroller, TI’s CC1101 sub-GHz transceiver, an OLED display, and a UHF power amplifier. As far as radios radios go, this is as bare bones as it gets, but with the addition of a USB to serial chip and a small program this radio can send messages to anyone or anything in range. It’s a DIY pager with a couple chips and some firmware, and already the system works.
[M.daSilva] has two use cases in mind for this device. The first is an amateur radio paging system, where a base station with a big power amp transmits messages to many small modules. The second use is a flexible mdoule that links PCs together, using Ham radio’s data modes. With so many possibilities, this is one of the best radio builds we’ve seen in this year’s Hackaday Prize.
As buzzwords go, the “Internet of Things” is pretty clever, and at the same time pretty loathsome, and both for the same reason. “IoT” can mean basically anything, so it’s a big-tent, inclusive trend. Every company, from Mattel to Fiat Chrysler, needs an IoT business strategy these days. But at the same time, “IoT” is vacuous — a name that applies to everything fails to clarify anything.
That’s a problem because “IoT Security” is everywhere in the news these days. Above and beyond the buzz, there are some truly good-hearted security professionals who are making valiant attempts to prevent what they see as a repeat of 1990s PC security fiascos. And I applaud them.
But I’m going to claim that a one-size-fits-all “IoT Security” policy is doomed to failure. OK, that’s a straw-man argument; any one-size-fits-all security policy is bound for the scrap heap. More seriously, I think that the term “IoT” is doing more harm than good by lumping entirely different devices and different connection modes together, and creating an implicit suggestion that they can all be treated similarly. “Internet of Things Security” is a thing, but the problem is that it’s everything, and that means that it’s useful for nothing.
What’s wrong with the phrase “Internet of Things” from a security perspective? Only two words: “Internet” and “Things”.
In this installment of Minimal MQTT, I’m going to cover two loose ends: one on the sensor node side, and one on the MQTT server side. Specifically, I’ll tackle the NodeMCU’s sleep mode to reduce power and step you through bridging MQTT servers to get your data securely out of your home server and into “the cloud”, which is really just other people’s servers.
If you’re just stepping into this series now, you should really check out the other three posts, where I set up a server, then build up some sensor nodes, and then flesh-out a few ways to control everything from your phone or the web. That’s the coolest material, anyway. This last installment just refines what we’ve built on. Let’s go!