Cryptoparty #2 – November 30th


cryptopartyA second Cryptoparty will be happening in 091 Labs on November 30th from 7pm!

Cryptoparties are happening all over the world. These free events are for people who are interested in encryption so they can come and learn more about basic Crypto programs and the concepts behind their operation. You can check out more info on cryptoparty.org.

There’ll be people talking about PGP/GPG, Tor, changing MAC addresses, and a bunch of other things. If you want to help out or have something you’d like to show, let us know and we’ll get some space together!

Tog in Dublin will also be hosting a Cryptoparty on the same night so no matter which half of the country you’re in, you’re covered =)

Update:

This evening is still going ahead on Friday (November 30th). Facebook link for those that use it https://www.facebook.com/events/367129280042915/ . If you can’t attend this event in Galway, it will also be taking place at TOG in Dublin.

 

Arduino IR Beam Test


A few of our members recently made a bus walking bus walking trip out to Maplin Electronics here in Galway to source some electronics. A few months ago I purchased a Velleman solder-it-yourself clapper kit, which I subsequently plugged into an Arduino and had some fun with. After picking up some resistors, piezos and other bits n’ bobs, I took another look at the solder-it-yourself section for some inspiration. I came across something which tickled my hackery-fancy, an “IR Light Barrier”, again from Velleman.

The basic principle is the following: Two PCBs, one with the sole purpose of illuminating two IR LEDs, the other having a photo transistor and a fairly large buzzer. Place the two boards across from each other, break the IR “beam” between the IR LEDs and photo transistor and the deafening buzzer starts sounding. Belated apologies to those across the road in John Mulholland.

So in a typical maker reaction, my thoughts were, “Well that sucks”. So I ripped out the buzzer, placed two wires on the PCB contacts and plugged them into my Arduino microcontroller:

What I now have is a brilliantly useful and marvellously simple security system. My next step is to hook up the Arduino code to the Twitter API and have it tweet a message every time the beam is crossed.

INTRUDER ALERT!

Workshop: Protect your (Ubuntu) laptop in one hour


This post started off in my head as a guide to firewalling your home server, but it gradually evolved, mentally, into a workshop for securing the information on your Linux laptop with GRUB, KeePass and Truecrypt. Click the (awesome Hackers) image below to RSVP your place for this once-off workshop!

Devil’s Advocate: The Microsoft Kinect Hacks


One of the sexist hardware hacking projects in the recent past has been the effort to open up Microsoft’s Kinect sensor bar to allow its control via USB from your personal computer. On November 7, a hacker claimed the USD $2,000 bounty for an open-sourced driver. It’s all standard (albeit cool) stuff. Microsoft’s reactions to the hacks and the community’s reaction to Microsoft’s reactions to the hacks where what caught my real attention. Shortly after the driver was announced, Microsoft made the following terse statement to CNET:

“Microsoft does not condone the modification of its products. With Kinect, Microsoft built in numerous hardware and software safeguards designed to reduce the chances of product tampering. Microsoft will continue to make advances in these types of safeguards and work closely with law enforcement and product safety groups to keep Kinect tamper-resistant.”

On every site I frequent for my technology news, the bias against Microsoft for this statement ran toward loud scoffing. Because, obviously, the software giant was making noise about the horse bolting after the fact. There were winks, nudges, grins (of the smug and shit-eating varieties), outright smirks, sly smiles, laughter, chuckles, mocker, derision, insults, and some spots of outright abuse. I at least hope to think that I took Microsoft’s initial hard stance a little more seriously, and I want to play devil’s advocate for a few minutes while I relate what I perceive as their reasons:

  1. Liability

    Every single piece of hardware that you purchase today has one of the below statements either stickered on the back or boldly noted in the accompanying documentation:

    No user serviceable parts within.
    Warranty void if tampered.
    Caution! Risk of electrical shock!

    Why? It isn’t just the cost of replacing user-destroyed hardware that might otherwise arise. No, it is Little Johnny Hacker who takes his brand-new Kinect home from the store, pops it open to see what is inside; in the process of applying solder to wires he somehow, tragically electrocutes himself. The headlines are going to read nothing but, “Microsoft’s Kinect killed poor Johnny Hacker!” The publicity stinks, but Microsoft can very fairly say that it wasn’t their responsibility.

  2. Intellectual Property.

    Maybe the more pressing reason. Microsoft has created custom hardware and software that, shocker, remains the property of Microsoft. When hackers crack open their Kinect they are potentially stealing this property and disseminating it. Yes, you can be prosecuted and yes, you can go to jail or be massively fined, jurisdiction dependent. At a really-guys-we-are-serious-about-this level, Microsoft doesn’t care all that much if people pirate Office or Windows 7 because it keeps them within the Microsoft ecosystem. If, however, they started trafficking in the source code for these products, Microsoft’s very own trade secrets are being opened up for all the world. People could conceivably use this to create a competitor product or (worse) open up Microsoft to liability from within and without.

  3. Creative control.

    This is the reason I most personally associate with, as a content (photography) producer myself: When you do Other Things to your Kinect, you aren’t receiving the full and intended Kinect experience. This is hugely important. To offer you a living example:

    I have found my Creative Commons-licensed images pop up in many strange and uniqe places, places that include in one example an fundamentalist Islamic prayer group. They were, thankfully, fundamentalist in the sense that they wanted to return to Muhammad’s original message, instead of blowing up the infidels. However, for a very long while before I received an authoritative clarification, I was honestly uncomfortable with my image being used on their website because:

    I’m irreligious; I don’t want to appear to be tacitly endorsing any faith.
    They are possibly militantly extremist; what might befall me if they should come to light in a negative manner?

    Microsoft’s fears are parallel to what mine were: If people begin to modify their Kinect hardware, it could potentially be embarrassing for the company as a whole. Home-made, three-dimensional, motion-captured porn, coming soon to a torrent near you courtesy of Kinect. It isn’t the end of the would, but it could be a true egg-on-your-face moment.

It isn’t all bad. On Friday ( November 19), a second statement from Microsoft’s Kinect developers demonstrated a remarkable change in outlook:

“Kinect was not actually hacked. Hacking would mean that someone got to our algorithms that sit inside of the Xbox and was able to actually use them. Which hasn’t happened. Or, it means that you put a device between the sensor and the Xbox for means of cheating, which also has not happened. That’s what we call hacking, and that’s what we put a ton of work and effort in to make sure doesn’t actually occur.

“What has happened is someone wrote a open source driver for PCs, which essentially opens the USB connection, which we didn’t protect by design, and reads the inputs from the sensor.”

My guess is that between the first and second statements Microsoft very intensively looked at what their liability might be, and what the intellectual property loss might be, in relation to the Kinect hacks.

So, there you go. Five minutes of devil’s advocacy on the hacks.

Build a(n Ubuntu) home server in one hour…


Tux!

…and secure it too.

When Aaron, Matthew and I incepted our Linux classes, we did so with a nebulous aim of offering a course of comprehensive beginner material, with our ultimate, nebulous goal being to offer “more advanced stuff”. Well, here we are. I dove into the basics of manipulating the Bash shell, simple scripting, SSH, and confidently administering a headless system as root. In the midst of my preparations for these classes, I had a theatric lightbulb-over-head moment: How hard would it be, really, to turn a desktop into a basic home server? Set aside performance and security concerns for a moment and just consider accessibility and turnaround time to live access on the Internet.

As it turns out, this takes about one hour. Maybe two if you are installing Linux from scratch. All you need to begin is a method to connect your dynamic home IP to a static domain and then a method to remotely access your home server:


apt-get update
apt-get upgrade
apt-get install openssh-server openssh-client

Sign up for a free DynDNS account and domain (remember to complete checkout!).


apt-get install ddclient

Populate three lines in /etc/ddclient/ddclient.conf with:

  1. Your DynDNS user name.
  2. Your DynDNS password.
  3. Your DynDNS domain.


/etc/init.d/ddclient restart
/etc/init.d/ssh start

Now give DynDNS and ddclient about five minutes (on the safe side) to update. Congratulations, you have a live Internet server for your file-access, media streaming, jerking-around-while-at-work, and general geek needs.

Now, we have a server. Locking down its Internet connection? Mmm, ten minutes. It was actually over an hour for me because I was engrossed in crash-learning netfilter/iptables syntax from scratch.


#/bin/sh

# Clear all existing iptable rules.
iptables -F
iptables -X

# Drop all incoming, outgoing and forwarded packets.
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# Permit loopback activity (client and server programs on this machine).
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Permit TCP connections to and from this machine on port 22 (SSH).
iptables -A INPUT -p tcp -dport 22 -j ACCEPT
iptables -A OUTPUT -p tcp -sport 22 -j ACCEPT

You’ll eventually need to open up ports for NTP, mail, DNS and others, but really: This is all there is to it. And because I am awesome, I wrote all of this up on Google Docs and made it freely available for download. Any notes suggesting alterations, additions or deletions can be made directly on the document, or by email to me directly.

Your Home Server and You