Hackaday Prize Entry: New Firmware For A Smartwatch

Smartwatches are the next big thing. Nobody knows what we’re going to use them for, but that’s never stopped a product from being the hottest item around. The WeLoop Tommy isn’t the Apple Watch, it isn’t the Moto360, and it isn’t the Microsoft Band. It is, however, a nice smartwatch with a Sharp memory display and a battery that lasts longer than a few days. For his Hackaday Prize entry, [Krzysiek] is making an open source firmware for the WeLoop Tommy that will add capabilities no other smartwatch has.

This project is a complete reverse engineering of the WeLoop Tommy smartwatch. [Krzysiek] is tearing everything down to the bare components and figuring out how the RAM, Flash, buttons, LCD, and accelerometer connect to the processor. After that, it’s time for custom firmware.

Already [Krzysiek] has a test app that displays [OSSW] on the Sharp memory display. It’s not much, but the hardware is solid. With the right firmware, the WeLoop Tommy will be able to do just about everything an Android, Apple, or Microsoft smartwatche can do using repurposed hardware and open source firmware.

The 2015 Hackaday Prize is sponsored by:

29 Year Old Apple Computer Finally Gets An OS Update

The Apple IIGS is the 16 bit upgrade to the popular 8 bit Apple II computer line, and with its massive boost in graphics, an Ensoniq sound system, and backwards compatibility with the 8 bit machines makes this box desirable to many retro enthusiast. The last OS update, 6.0.1, was released over 22 years ago. While it worked well for the early 90s, it was by no means perfect.

Last Sunday, a post popped up on callapple.org, announcing Apple IIgs System 6.0.2. Updates include a driver for the unreleased Apple II Ethernet card,  fixes various bugs in the file system translation system, various bugfixes to existing system programs,  fast drawing and animation tools, and of course an update to the finder to show the new revision number.

With a hope for even more bug fixes in a possible 6.0.3 revision its good to see people still giving the old Apple II line some love, as the old Apples don’t have as large of a following as their Atari and Commodore brethren.

Artificial Killing Machine

L.A. artist [Jonathan Fletcher Moore] sent us this fantastic tech-art piece on dehumanization and drone warfare. Talking too much about art is best left to the artists, so we’ll shut up and let you watch the video below the break.

The piece is essentially a bunch of old cap guns with servos that pull their triggers. A Raspberry Pi with an Internet connection fetches data on US drone strikes from www.dronestre.am and fires off a cap every time someone is killed. At the same time, the story version of the data is printed out in thermal paper that cascades onto the floor.

Viewers are encouraged to sit underneath all the cap guns and wait. Talk about creepy and suspenseful. And a tiny reflection of the everyday fears that people who live under drone-filled skies.

How To Make Amazon Echo Control Fake WeMo Devices

[Chris] has been playing with the Amazon Echo. It’s sort of like having Siri or Google Now available as part of your home, but with built-in support for certain other home automation appliances like those from Belkin WeMo and Philips. The problem was [Chris] didn’t want to be limited to only those brands. He had other home automation gear that he felt should work with Amazon Echo, but didn’t. That’s when he came up with the clever idea to just emulate one of the supported platforms.

The WeMo devices use UPnP to perform certain functions over the network. [Chris] wanted to see how these communications actually worked, so he fired up his laptop and put his WiFi adapter into monitor mode. Then he used Wireshark to start collecting packets. He found that the device detection function starts out with the Echo searching for WeMo devices using UPnP. The device then responds to the Echo with the device’s URL using HTTP over UDP. The Echo then requests the device’s description using that HTTP URL. The description is then returned as an HTTP response.

The actual “on/off” functionality of the WeMo devices is simpler since the Echo already knows about the device. The Echo simply connects to the WeMo over the HTTP interface and issues a “SetBinaryState” command. The WeMo then obliges and returns a confirmation via HTTP.

How Echo Communicates with WeMo Devices

[Steve] was able to use this information to set up his own WeMo “virtual cloud”. Each virtual device would have its own IP address. They would also need to have a listener for UDP broadcasts as well as an HTTP listener running on the WeMo port 49153. Each virtual device would also need to be able to respond to the UPnP discovery requests and the “on/off” commands.

[Chris] used a Linux server, creating a new virtual Ethernet interface for each virtual WeMo switch. A single Python script runs the WeMo emulation, listening for the UPnP broadcast and sending a different response for each virtual device. Part of the response includes the device’s “friendly name”, which is what the Echo listens for when the user says voice commands. Since the virtual WeMo devices are free, this allows [Chris] to make multiple phrases for each device. So rather than be limited to “television”, he can also make a separate device for “TV” that performs the same function. [Chris] is also no longer limited to only specific brands of home automation gear.

There’s still a long way to go in hacking this device. There’s a lot of hardware under the hood to work with. Has anyone else gotten their hands (and bench tools) on one of these?

ProxyGambit Better Than ProxyHam; Takes Coffee Shop WiFi Global

Last weekend saw the announcement of ProxyHam, a device that anonymizes Internet activity by jumping on WiFi from public libraries and cafes over a 900MHz radio link. The project mysteriously disappeared and was stricken from the DEFCON schedule. No one knows why, but we spent some time speculating on that and on what hardware was actually used in the undisclosed build.

[Samy Kamkar] has just improved on the ProxyHam concept with ProxyGambit, a device that decouples your location from your IP address. But [Samy]’s build isn’t limited to ProxyHam’s claimed two-mile range. ProxyGambit can work anywhere on the planet over a 2G connection, or up to 10km (6 miles) away through a line-of-sight point to point wireless link.

The more GSM version of ProxyGambit uses two Adafruit FONA GSM breakout boards, two Arduinos, and two Raspberry Pis. The FONA board produces an outbound TCP connection over 2G. The Arduino serves as a serial connection over a reverse TCP tunnel and connects directly to the UART of a Raspberry Pi. The Pi is simply a network bridge at either end of the connection. By reverse tunneling a TCP connection through the ‘throwaway’ part of the build, [Samy] can get an Internet connection anywhere that has 2G service.

Although it’s just a proof of concept and should not be used by anyone who actually needs anonymity, the ProxyGambit does have a few advantages over the ProxyHam. It’s usable just about everywhere on the planet, and not just within two miles of the public WiFi access point. The source for ProxyGambit is also available, something that will never be said of the ProxyHam.

Nixie Tube Speedometer In Motorcycle Handlebars

The handlebars of this Honda CL175 ended up being perfect for holding two Nixie tubes which serve as the speedometer. There are two circular cavities on the front fork tree which are the same size as the Nixies. Wrapping the tubes in a bit of rubber before the installation has them looking like they are factory installed!

This isn’t a retrofit, he’s added the entire system himself. It starts with a hall effect sensor and magnets on the rear wheel and swing arm. Right now the result is 4 MPH resolution but he plans to add more magnets to improve upon that. For now, the driver and speedometer circuitry are hosted on protoboard but we found a reddit thread where [Johnathan] talks about creating a more compact PCB. If your own bike lacks the fork tree openings for this (or you need help with the drivers) check out this other Nixie build for a slick-looking enclosure idea.

The link at the top is a garage demo, but last night he also uploaded a rolling test to show the speedometer in action. Check out both videos after the break.

Panopticlick: You Are A Beautiful And Unique Snowflake

We all like to think we’re unique, but when it comes to remaining anonymous online that’s probably not such a good idea. By now, it’s common knowledge that advertising firms, three-letter agencies, and who-knows-who-else want to know what websites you’re visiting and how often. Persistent tracking cookies, third-party cookies, and “like” buttons keep tabs on you at all times.

For whatever reason, you might want to browse anonymously and try to plug some of the obvious sources of identity leakage. The EFF and their Panopticlick project have bad news for you.

The idea behind Panopticlick is simple: to try to figure out how identifiable you are even if you’re not accepting cookies, or if you’ve disabled Flash, or if you’re using “secure” browsers. To create a fingerprint of your browser, Panopticlick takes all the other little bits of identifying information that your browser gives up, and tries to piece them together.

For a full treatment of the project, see this paper (PDF). The takeaway from the project is that the information your browser gives up to servers can, without any cookies, specifically identify you.

For instance, a server can query which plugins your browser supports, and if you’ve installed anything a tiny bit out of the ordinary, you’re fingerprinted. Your browser’s User Agent strings are often over-specific and tell which browser sub-sub-sub version you’re running on which OS platform. If you’re running Flash, it can report back which fonts you’ve got installed on your system. Any of these can be easily as rare as one-in-a-million. Combining them together (unless they’re all highly correlated) can fingerprint you uniquely.

You can’t necessarily win. If you disable Flash, the remote site doesn’t get your font list, but since only one in five browsers runs with Flash disabled, you’re still giving up two bits of information. If you run a “privacy-enhancing” niche browser, your chances of leaving a unique fingerprint go through the roof unless you’re also forging the User Agent strings.

I ran the Panopticlick experiment twice, once with a Firefox browser and once with an obscure browser that I actually use most of the time (dwb). Firefox runs a Flash blocker standard, so they didn’t get my font list. But still, the combination of browser plugins and a relatively new Firefox on Linux alone made me unique.

It was even worse for the obscure browser test. Only one in 1.4 million hits use dwb, so that alone was bad news. I also use a 4:3 aspect-ratio monitor, with 1280×1024 pixels at 24-bit color depth, which is apparently a one-in-twenty-four occurrence. Who knew?

Finally, I tried out the Tor browser, which not only routes your traffic through the Tor network, but also removes a lot of the specific data about your session. It fared much better, making me not uniquely identifiable: instead only one in a thousand. (Apparently a lot of people trying out the Panopticlick site ran Tor browser.)

If you’re interested in online anonymity, using something like Tor to obscure your IP address and disabling cookies is a good start. But Panopticlick points out that it may not be enough. You can never use too many layers of tinfoil when making your hat.

Try it out, and let us know in the comments how you fare.