[Nathan] is a mobile application developer. He was recently debugging one of his new applications when he stumbled into an interesting security vulnerability while running a program called Charles. Charles is a web proxy that allows you to monitor and analyze the web traffic between your computer and the Internet. The program essentially acts as a man in the middle, allowing you to view all of the request and response data and usually giving you the ability to manipulate it.
While debugging his app, [Nathan] realized he was going to need a ride soon. After opening up the Uber app, he it occurred to him that he was still inspecting this traffic. He decided to poke around and see if he could find anything interesting. Communication from the Uber app to the Uber data center is done via HTTPS. This means that it’s encrypted to protect your information. However, if you are trying to inspect your own traffic you can use Charles to sign your own SSL certificate and decrypt all the information. That’s exactly what [Nathan] did. He doesn’t mention it in his blog post, but we have to wonder if the Uber app warned him of the invalid SSL certificate. If not, this could pose a privacy issue for other users if someone were to perform a man in the middle attack on an unsuspecting victim.
[Nathan] poked around the various requests until he saw something intriguing. There was one repeated request that is used by Uber to “receive and communicate rider location, driver availability, application configurations settings and more”. He noticed that within this request, there is a variable called “isAdmin” and it was set to false. [Nathan] used Charles to intercept this request and change the value to true. He wasn’t sure that it would do anything, but sure enough this unlocked some new features normally only accessible to Uber employees. We’re not exactly sure what these features are good for, but obviously they aren’t meant to be used by just anybody.
[Nightflyer] has been working on an open source project he calls CAMdrive. CAMdrive is designed to be a multi-axis controller for time-lapse photography. It currently only supports a single axis, but he’s looking for help in order to expand the functionality.
You may already be familiar with the idea of time-lapse photography. The principal is that your camera takes a photo automatically at a set interval. An example may be once per minute. This can be a good way to get see gradual changes over a long period of time. While this is interesting in itself, time-lapse videos can often be made more interesting by having the camera move slightly each time a photo is taken. CAMdrive aims to aid in this process by providing a framework for building systems that can pan, tilt, and slide all automatically.
The system is broken out into separate nodes. All nodes can communicate with each other via a communication bus. Power is also distributed to each node along the bus, making wiring easier. The entire network can be controlled via Bluetooth as long as any one of the nodes on the bus include a Bluetooth module. Each node also includes a motor controller and corresponding motor. This can either be a stepper motor or DC motor.
The system can be controlled using an Android app. [Nightflyer’s] main limitation at the moment is with the app. He doesn’t have much experience programming apps for Android and he’s looking for help to push the project forward. It seems like a promising project for those photography geeks out there. Continue reading “CAMdrive is an Open Source Time-lapse Photography Controller”
With all of the various web applications we use nowadays, it can be daunting to remember all of those passwords. Many people turn to password management software to help with this. Rather than remembering 20 passwords, you can store them all in a (presumably) secure database that’s protected by a single strong password. It’s a good idea in theory, but only if the software is actually secure. [Matteo] was recently poking around an Android password management software and made some disturbing discoveries.
The app claimed to be using DES encryption, but [Matteo] wanted to put this claim to the test. He first decompiled the app to get a look at the code. The developer used some kind of code obfuscation software but it really didn’t help very much. [Matteo] first located the password decryption routine.
He first noticed that the software was using DES in ECB mode, which has known issues and really shouldn’t be used for this type of thing. Second, the software simply uses an eight digit PIN as the encryption key. This only gives up to 100 million possible combinations. It may sound like a lot, but to a computer that’s nothing. The third problem was that if the PIN is less than eight characters, the same digits are always padded to the end to fill in the blanks. Since most people tend to use four digit pins, this can possibly lower the total number of combinations to just ten thousand.
As if that wasn’t bad enough, it actually gets worse. [Matteo] found a function that actually stores the PIN in a plain text file upon generation. When it comes time to decrypt a password, the application will check the PIN you enter with the one stored in the plain-text file. So really, you don’t have to crack the encryption at all. You can simply open the file and reveal the PIN.
[Matteo] doesn’t name the specific app he was testing, but he did say in the Reddit thread that the developer was supposedly pushing out a patch to fix these issues. Regardless, it goes to show that before choosing a password manager you should really do some research and make sure the developer can be trusted, lest your secrets fall into the wrongs hands.
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]
[Oliver] is back with an update to his recent coffee maker hacks. His latest hack allowed him to add a coffee payment system to an off-the-shelf coffee maker without modifying the coffee maker itself. This project is an update to his previous adventures in coffee maker hacking which logged who was using up all of the coffee.
The payment system begins with an Arduino Uno clone inside of a small project enclosure. The Arduino communicates with the coffee maker via serial using the coffee maker’s service port. This port is easily available from outside the machine, so you won’t have to crack open the case and risk voiding your warranty.
The system also includes an RFID reader and a Bluetooth module. The RFID reader allows each user to have their own identification card. The user can swipe their card over the reader and the system knows how many credits are left in their account. If they have enough credit, the machine will pour a delicious cup of coffee.
The Arduino communicates to an Android phone using the Bluetooth module. [Oliver’s] Android app was built using MIT’s app inventor. It keeps track of the account credits and allows the user to add more. The system can currently keep track of up to forty accounts. [Oliver] also mentions that you can use any Bluetooth terminal program to control the system instead of a smart phone app. Continue reading “Coffee Payment System Doesn’t Void Your Warranty”
[Daniel Whiteson and Michael Mulhearn], researchers at the University of California, have come up with a novel method of detecting ultra-high energy cosmic rays (UHECR) using smartphones. UHECR are defined as having energy greater than 1018eV. They are rare and very difficult to detect with current arrays. In order to examine enough air showers to detect UHECR, more surface area is needed. Current arrays, like the Pierre Auger Observatory and AGASA, cannot get much larger without dramatically increasing cost. A similar THP Quarterfinalist project is the construction of a low-cost cosmic ray observatory, where it was mentioned that more detection area is needed in order to obtain enough data to be useful.
[Daniel Whiteson and Michael Mulhearn] and colleagues noted that smartphone cameras with CMOS sensors can detect ionizing radiation, which means they also will pick up muons and high-energy photons from cosmic rays. The ubiquitous presence of smartphones makes their collective detection of air showers and UHECR an intriguing possibility. To make all this happen, [Whiteson and Mulhearn] created a smartphone app called CRAYFIS, short for Cosmic RAYs Found In Smartphones. The app turns an idle smartphone into a cosmic ray detector. When the screen goes to sleep and the camera is face-down, CRAYFIS starts taking data from the camera. If a cosmic ray hits the CMOS sensor, the image data is stored on the smartphone along with the arrival time and the phone’s geolocation. This information is uploaded to a central server via the phone’s WiFi. The user does not have to interact with the app beyond installing it. It’s worth noting that CRAYFIS will only capture when the phone is plugged in, so no worries about dead batteries.
The goal of CRAYFIS is to have a minimum of one million smartphones running the app, with a density of 1000 smartphones per square kilometer. As an incentive, anyone whose smartphone data is used in a future scientific paper will be listed as an author. There are CRAYFIS app versions for Android and iOS platforms according to the site. CRAYFIS is still in beta, so the apps aren’t publicly available. Head over to the site to join up!
We finally got our hands on a Chromecast over the weekend and we love it! But it wasn’t without a bit of a speed bump. Including a quick initial setup, we had a YouTube video playing in our living room about three minutes after the package hit our mailbox. But we spent the next twenty minutes feeling like a moron because we couldn’t get the Netflix app on an Android phone to cast the video. Turns out there is a bug in the Netflix app that doesn’t add the Chromecast icon for all devices.
The issue is that the newest version of the Netflix app isn’t pushed to all devices. A fix is on the way, but we’re not good at waiting. We used this technique to trick Netflix into thinking we have different hardware. Notice from the screenshots above that one lists our device as an LG-P769 manufactured by LGE. That’s how our /system/build.prop file originally looked. By using the BuildProp Editor app we changed those settings to Nexus S by samsung. After rebooting several of our apps were missing from the app drawer, including Netflix. But they all still worked hitting the Play Store for reinstallation and we now have no problem casting Netflix.