Forknife, Android G1 Controlled Robot

g1bot

When we first saw [Jeffrey Nelson]’s G1 based robot we immediately wondered what the transport for the controls was. The G1‘s hardware supports USB On-The-Go, but it’s not implemented in Android yet. It turns out he’s actually sending commands by using DTMF tones through the headphone adapter. The audio jack is connected to a DTMF decoder that sends signals to the bot’s Arduino. He wrote client/server code in Java to issue commands to the robot. You can find that code plus a simple schematic on his site. A video of the bot is embedded below.

Continue reading “Forknife, Android G1 Controlled Robot”

TEMPEST: A Signal Problem

TEMPEST is the covername used by the NSA and other agencies to talk about emissions from computing machinery that can divulge what the equipment is processing. We’ve covered a few projects in the past that specifically intercept EM radiation. TEMPEST for Eliza can transmit via AM using a CRT monitor, and just last Fall a group showed how to monitor USB keyboards remotely. Through the Freedom of Information Act, an interesting article from 1972 has been released. TEMPEST: A Signal Problem (PDF link dead, try Internet Archive version) covers the early history of how this phenomenon was discovered. Uncovered by Bell Labs in WWII, it affected a piece of encryption gear they were supplying to the military. The plaintext could be read over that air and also by monitoring spikes on the powerlines. Their new, heavily shielded and line filtered version of the device was rejected by the military who simply told commanders to monitor a 100 feet around their post to prevent eavesdropping. It’s an interesting read and also covers acoustic monitoring. This is just the US history of TEMPEST though, but from the anecdotes it sounds like their enemies were not just keeping pace but were also better informed.

[via Schneier]

Sound Effects Box

vs

At first glance, this may look like a retro styled monome, but it is actually quite different. Merging a Project64 key pad and a Voice Shield for Arduino, [Spikenzie] has made a sound effects box. Each button triggers a unique sound that is stored in the Voice Shield. Of coarse, it will be like a game of memory trying to remember what sound is where. You can see a demo video here.

Wattcher, Twittering Kill A Watt Plans Posted

kill-a-watt

You probably saw [Phillip Torrone] and [Limor Fried]’s twittering Kill A Watt earlier this week. It was an entry in the Core77/Greener Gadgets Design Competition. We saw a little bit about how it was assembled, but now they’ve posted a full guide to assembling the hardware. Each Kill A Watt gets an XBee radio that transmits back to a receiver that logs the power usage. The difficult part when putting this design together was the XBee required 50mA when transmitting. This is well above the Kill A Watt’s internal power supply. They remedied this by adding a 10,000uF supercap to act as a rechargeable battery. The daily twittering is just a side-effect of the project. The Kill A Watts transmit every 2 seconds, so you’ll get a very accurate report of your power usage. This is a great project for renters who can’t permanently modify their power infrastructure. Each Kill A Watt can support quite a few appliances since they’re rated for 15A, ~1800W.

Hands Free Point Of View Camera

handsfree

Here’s an odd little footnote we found while perusing the Comic Tools blog. [Matt Bernier]’s blog is dedicated to drawing and inking tutorials for comic artists. He uses a lot of example photographs that involve both hands. This week, at the bottom of his post on cleaning brushes, he included a photo to illustrate how he takes all of these point of view shots. The camera is strapped securely to his head using an old lanyard. He can see the display and access the controls on the back. After composing his shot, he just sets the timer, and you get a picture of what the process looks like from his perspective. Sure, it looks silly from this angle, but it really helps out the posts.

Manual Protocol Analysis

packetfu

As a followup to last week’s post on automated protocol analysis, [Tod Beardsley] has written up how to start analyzing a protocol manually. He walks through several examples to show how to pull out the interesting bits in binary protocols. His first step was sending 10 identical select statements and capturing the outbound packets. He used the Ruby library PacketFu to help with the identification. It compared the ten packets and highlighted one byte that was incrementing by four with each packet, probably a counter. Looking at the response indicated a few other bytes that were also incrementing at the same rate, but at different values. Running the same query on two different days turned up what could be a timestamp. Using two different queries helped identify which byte was responsible for the statement length. While you may not find yourself buried in HEX on a daily basis, the post provides good coverage of how to think critically about it.

Road Sign Hacking

We’ve all seen these on the side of the road and wondered how we could change the message. It turns out that it is actually pretty easy. There’s a keypad inside for programming that is often still set with a default password of “DOTS”. Even if the password has been changed, you can reset it right there pretty quickly. We shouldn’t even need to warn you that it is illegal to tamper with these, so unless there really are zombies ahead, you probably shouldn’t mess with it.

[via Neatorama]