In this beautiful and well-documented reverse engineering feat of strength, [Eric Cohen] reverse-engineered a 1971 Singer calculator to gain control of the fabulous Nixie tubes inside. Where a lesser hacker would have simply pulled the tubes out and put them in a more modern housing, [Eric] kept it all intact.
Not even content to gut the box and toss some modern brains inside, he snooped out the calculator’s internal wiring, interfaced a Raspberry Pi to it, and overrode the calculator’s (860 Hz) bus system. With the Pi on the inside, controlling the Nixie tubes, he did what any of us would do: set up a UDP server and write an Android app for his phone to push ASCII data over to the former calculator. When it’s not running in its default clock mode, naturally.
All of this is extraordinarily well documented both on his website, in a slide presentation (PDF), and in video (embedded below). Our hats are tipped to the amazing attention to detail and fantastic documentation.
Now where is that Singer EC1117 calculator from 1971 that we’ve been saving for just such an occasion?
[jamesone111] bought a Transcend WifiSD card, presumably for photography, but it may just have been because he heard that they’re actually tiny Linux servers.
He read a post about these cards on the OpenWRT forums. They’re all a similar configuration of a relatively large amount of memory (compared to the usual embedded computer), a WiFi chip, and an ARM processor running a tiny Linux install. The card acts as a WiFi access point with a little server running on it, and waits for the user to connect to it via a website. It also has a mode where it will connect to up to three access points specified by the user, but it doesn’t actually have a way to tell the user what its IP address is; which is kind of funny.
[jamesone111] hacked around with the Transcend card for a bit. He found it pretty insecure, which as long as you’re not a naked celebrity, shouldn’t be a huge issue. For the hacker this is great as it opens up the chance of hacking the firmware for other uses.
Some have already pulled off some cool hacks with these cards. For example, [peterburk] hacked a similar card by PQI to turn his iPod into a portable file server.
If you’re playing Hackaday Buzzword Bingo, today is your lucky day! Because not only does this article contain “Pi 3” and “IoT”, but we’re just about to type “ESP8266” and “home automation”. Check to see if you haven’t filled a row or something…
Seriously, though. If you’re running a home device network, and like us you’re running it totally insecurely, you might want to firewall that stuff off from the greater Interwebs at least, and probably any computers that you care about as well. The simplest way to do so is to keep your devices on their own WiFi network. That shiny Pi 3 you just bought has WiFi, and doesn’t use so much power that you’d mind leaving it on all the time.
Even if you’re not a Linux networking guru, [Phil Martin]’s tutorial on setting up the Raspberry Pi 3 as a WiFi access point should make it easy for you to use your Pi 3 as the hub of your IoT system’s WiFi. He even shows you how to configure it to forward your IoT network’s packets out to the real world over wired Ethernet, but if you can also use the Pi 3 as your central server, this may not even be necessary. Most of the IoT services that you’d want are available for the Pi.
Those who do want to open up to the world, you can easily set up a very strict firewall on the Pi that won’t interfere with your home’s normal WiFi. Here’s a quick guide to setting up iptables on the Pi, but using even friendlier software like Shorewall should also get the job done.
Still haven’t filled up your bingo card yet? “Arduino!”
There’s a great game of capture-the-flag that takes place every year at HITCON. This isn’t your childhood neighborhood’s capture-the-flag in the woods with real flags, though. In this game the flags are on secured servers and it’s the other team’s mission to break into the servers in whatever way they can to capture the flag. This year, though, the creators of the game devised a new scoreboard for keeping track of the game: a lightsaber.
In this particular game, each team has a server that they have to defend. At the same time, each team attempts to gain access to the other’s server. This project uses a lightsaber stand that turns the lightsabers into scoreboards for the competition at the 2015 Hacks In Taiwan Conference. It uses a cheap OpenWRT Linux Wi-Fi/Ethernet development board, LinkIt Smart 7688 which communicates with a server. Whenever a point is scored, the lightsaber illuminates and a sound effect is played. The lightsabers themselves are sourced from a Taiwanese lightsabersmith and are impressive pieces of technology on their own. As a bonus the teams will get to take them home with them.
While we doubt that this is more forced product integration advertisement from Disney, it certainly fits in with the theme of the game. Capture-the-flag contests like this are great ways to learn about cyber security and how to defend your own equipment from real-world attacks. There are other games going onall around the world if you’re looking to get in on the action.
There seems to be a hacker maxim that whatever gadget you are working with, it would be better to have several of them running together. That might explain the ESP8266 web server farm that [Eldon Brown] has built. Yup, a web server farm made from three of everyone’s favorite WiFi dongle, the humble ESP8266.
His page isn’t anything too fancy but it is impressive considering it is running on about $30 worth of hardware, including the breadboard it is wired into. The page includes dynamically-generated graphics and some back-end stuff. I don’t think that it will replace any LAMP servers anytime soon (the ESP8266 took about 2.6 seconds to generate the page below), but it is an impressive hack. [Eldon] has made the full code of the web server that is running the pages available. So, lets add web server farm to the list of things that this neat little device can handle, next to plant weigher, Bitcoin price tracker, MP3 player and many more…
We were delighted at a seeing 96 MacBook Pros in a rack a couple of days ago which served as testing hardware. It’s pretty cool so see a similar exquisitely executed hack that is actually in use as a production server. imgix is a startup that provides image resizing for major web platforms. This means they need some real image processing horsepower and recently finalized a design that installs 44 Mac Pro computers in each rack. This hardware was chosen because it’s more than capable of doing the heavy lifting when it comes to image processing. And it turns out to be a much better use of rack space than the 64 Mac Minis it replaces.
Racking Mac Pro for Production
Each of the 11 R2 panels like the one shown here holds 4 Mac Pro. Cooling was the first order of business, so each panel has a grate on the right side of it for cold-air intake. This is a sealed duct through which one side of each Pro is mounted. That allows the built-in exhaust fan of the computers to cool themselves, pulling in cold air and exhausting out the opposite side.
Port access to each is provided on the front of the panel as well. Connectors are mounted on the right side of the front plate which is out of frame in this image. Power and Ethernet run out the back of the rack.
The only downside of this method is that if one computer dies you need to pull the entire rack to replace it. This represents 9% of the total rack and so imgix designed the 44-node system to deal with that kind of processing loss without taking the entire rack down for service.
Why This Bests the Mac Mini
3 racks – Linux. Mac Min, Mac Pro
Here you can see the three different racks that the company is using. On the left is common server equipment running Linux. In the middle is the R1 design which uses 64 Mac Minis for graphic-intensive tasks. To the right is the new R2 rack which replace the R1 design.
Obviously each Mac Pro is more powerful than a Mac Mini, but I reached out to imgix to ask about what prompt them to move away from the R1 design that hosts eight rack panes each with eight Mac Minis. [Simon Kuhn], the Director of Production, makes the point that the original rack design is a good one, but in the end there’s just too little computing power in the space of one rack to make sense.
Although physically there is room for at least twice as many Mac Mini units — by mounting them two-deep in each space — this would have caused several problems. First up is heat. Keeping the second position of computers within safe operating temperatures would have been challenging, if not impossible. The second is automated power control. The R1 racks used two sets of 48 controllable outlets to power computers and cooling fans. This is important as the outlets allow them to power cycle mis-behaving units remotely. And finally, more units means more Ethernet connections to deal with.
We having a great time looking that custom server rack setups. If you have one of your own, or a favorite which someone else built, please let us know!
[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?
