Display Your City’s Emotional State with Illuminated Snow

[Hunter] wanted to do something a bit more interesting for his holiday lights display last year. Rather than just animated lights, he wanted something that was driven by data. In this case, his display was based on the mood of people in his city. We’ve seen a very similar project in the past, but this one has a few notable differences.

The display runs off of an Arduino. [Hunter] is using an Ethernet shield to connect the Arduino to the Internet. It then monitors all of the latest tweets from users within a 15 mile radius of his area. The tweets are then forwarded to the Alchemy Sentiment API for analysis. The API uses various algorithms and detection methods to identify the overall sentiment within a body of text. [Hunter] is using it to determine the general mood indicated by the text of a given tweet.

Next [Hunter] needed a way to somehow display this information. He opted to use an LED strip. Since the range of sentiments is rather small, [Hunter] didn’t want to display the overall average sentiment. This value doesn’t change much over short periods of time, so it’s not very interesting to see. Instead, he plots the change made since the last sample. This results in a more obvious change to the LED display.

Another interesting thing to note about this project is that [Hunter] is using the snow in his yard to diffuse the light from the LEDs. He’s actually buried the strip under a layer of snow. This has the result of hiding the electronics, but blurring the light enough so you can’t see the individual LEDs. The effect is rather nice, and it’s something different to add to your holiday lights display. Be sure to check out the video below for a demonstration. Continue reading “Display Your City’s Emotional State with Illuminated Snow”

Super Bowl Football Lamp Keeps You Informed

[David] loves to watch football. After his preferred team lost the playoffs, he wanted another reason to watch the big game last Sunday. He ended up building himself a football-shaped lamp that changes color based on who scored last.

[David] started with a Spark Core and a Spark Button. The Spark is the primary microcontroller and includes WiFi. The Spark Button is essentially a shield for the Spark that includes an accelerometer, some LEDs, and a few push buttons. The other part of this build was the housing. [David] used a toy football he got for free as swag from a parade.

As for the code, [David] started by first learning how to control the LEDs on the Spark Button. Then he wrote his own touchdown function to illuminate the football a specific color. Since the Spark uses the REST API, [David] is able to trigger this function by simply visiting the URL of his Spark. This makes it very simple to trigger the event.

The final part of this build was made easy thanks to IfThisThenThat (IFTTT). This is a web service that allows you to monitor and interact with various online web services. It can monitor one service, and then interact with another based on events that happen in the first service. In this case, [David] is using a “channel” added to IFTTT by ESPN. This channel can trigger when certain events happen for whatever team you specify. For this project [David] is monitoring touchdowns.

After combining all of these various services, [David] had a working light that would change colors based on which team scored. He did notice that IFTTT has anywhere between a 1 and 15 minute delay, and he hopes to improve upon this design by hooking directly to an API and skipping the extra service altogether.

When Responsible Disclosure Isn’t Enough

Moonpig is a well-known greeting card company in the UK. You can use their services to send personalized greeting cards to your friends and family. [Paul] decided to do some digging around and discovered a few security vulnerabilities between the Moonpig Android app and their API.

First of all, [Paul] noticed that the system was using basic authentication. This is not ideal, but the company was at least using SSL encryption to protect the customer credentials. After decoding the authentication header, [Paul] noticed something strange. The username and password being sent with each request were not his own credentials. His customer ID was there, but the actual credentials were wrong.

[Paul] created a new account and found that the credentials were the same. By modifying the customer ID in the HTTP request of his second account, he was able to trick the website into spitting out all of the saved address information of his first account. This meant that there was essentially no authentication at all. Any user could impersonate another user. Pulling address information may not sound like a big deal, but [Paul] claims that every API request was like this. This meant that you could go as far as placing orders under other customer accounts without their consent.

[Paul] used Moonpig’s API help files to locate more interesting methods. One that stood out to him was the GetCreditCardDetails method. [Paul] gave it a shot, and sure enough the system dumped out credit card details including the last four digits of the card, expiration date, and the name associated with the card. It may not be full card numbers but this is still obviously a pretty big problem that would be fixed immediately… right?

[Paul] disclosed the vulnerability responsibly to Moonpig in August 2013. Moonpig responded by saying the problem was due to legacy code and it would be fixed promptly. A year later, [Paul] followed up with Moonpig. He was told it should be resolved before Christmas. On January 5, 2015, the vulnerability was still not resolved. [Paul] decided that enough was enough, and he might as well just publish his findings online to help press the issue. It seems to have worked. Moonpig has since disabled its API and released a statement via Twitter claiming that, “all password and payment information is and has always been safe”. That’s great and all, but it would mean a bit more if the passwords actually mattered.

Reverse Engineering the Kayak Mobile API

The travel meta-search website Kayak apparently used to have a public API which is no longer available. We can’t say we mourn the loss of the interface we’d never known about. If you are someone who was automating their searches for that perfect vacation getaway deal, there’s still hope. But either way you’ll like this one. [Shubhro Saha] figured out how to access the API used by the Kayak mobile app. We like that he details how to sniff the traffic between an app and the internet and make sense of what is found.

His tool of choice is the Python package Mitmproxy. We haven’t heard of it but we have heard of Wireshark and [Shabhro] makes the case that Mitmproxy is superior for this application. As the name suggests, you set it up on your computer and use that box’s IP as the proxy connection for your phone. After using the app for a bit, there is enough data to start deconstructing what’s going on between the app and remote server which which it communicates. We could have a lot of fun with this, like seeing what info those free apps are sending home, or looking for security flaws in your own creations.

[Thanks Juan via Twitter]

Home Automation With The Amazon Echo

The Amazon Echo is the answer to Apple’s Siri, Microsoft’s Cortana, and [Orwell]’s Telescreen – a device that sits in your home, listens to everything you say, and will gladly oblige if you want to buy something on Amazon. Brilliant. Despite being a pretty cheap device, there’s not really a whole lot it can do; sure, Echo, or more accurately Alexa, the personality in the Echo, can tell you the weather, queue up a playlist, or read a Wikipedia entry, but there’s a definite lack of imagination when it comes to the Echo.

Now, thanks to some clever API hacks, you can do far more with the Echo. [Noel] is using the Echo to turn lights in his house on and off, ring his home phone, and basically everything else you can do with some wire and a bit of code.

[Noel] got his idea from [Owen Piette] who recently investigated the Echo API. It’s all unpublished by Amazon, but it is possible to poll the todo list for random key phrases. By polling this API and getting new results, it’s pretty easy to set up some logic to do arbitrary actions.

Right now [Noel] can turn a light on and off and call his phone, but the sky really is the limit here. If you have a web-enabled thermostat, Alexa can turn the heat on or off. Want to text yourself something? That’s easy too. Anything that can be put in a todo list can be done with the Echo, the only obstacle is doing all the programming and electronics.

Website Response Speedometer

Here’s something that will probably make it to a wall right next to the people responsible for the Hackaday servers sometime soon, and should be something every web dev should build at some point: a website response meter, an analog gauge that will tell you how long it takes to reach your website.

The build is simple enough, with a micro servo working as a gigantic analog gauge. There are also a pair of four-digit, seven-segment displays for displaying a digital number and the number of website requests per second. There’s also an 8×8 matrix of bi-color LEDs for showing a green happy face or a red frowny face, just in case all that data wasn’t self-evident to the uninitiated.

All the electronics are handled by an Arduino, but what really makes this build useful, or even possible, is the bit of code that runs on a computer. The computer uses an API from New Relic, a software analytics company, to come up with the response time and requests per second. That data is pulled down and piped up to the Arduino that displays everything on a beautifully milled acrylic sheet.

Will Dance For Bitcoin

It seems that Bitcoin is all over the news nowadays, but the Bitcoin Bot is probably the first robot that will dance for Bitcoins.

[Ryan] at HeatSync Labs in Mesa, AZ, is a fan of the cryptocurrency, and decided to build something to accept it. He discovered that Coinbase, a popular hosted Bitcoin wallet service, has a callback API. This causes Coinbase to fetch a specified URL any time a wallet receives a transaction, and provides information on the transaction in the request. A Python script handles these requests and updates a running count of the BTC balance sent to the robot’s wallet.

On the hardware side, an Arduino with an Ethernet Shield checks the balance. If it has changed, it calls the dance function and the luau girl dances.

The robot sits in the window of the hackerspace, so anyone passing by can read about Bitcoin and make a donation. The source code is on Github, and a video follows after the break.

Continue reading “Will Dance For Bitcoin”