Syntactic support for Kaminsky’s Interpolique in Haskell

When I recently wrote about my first impressions of Kaminsky’s Interpolique, I mentioned that the only thing I didn’t like is that PHP doesn’t offer any way to protect against syntactic mistakes, such as where the programmer mistakenly uses a $ instead of a ^^.

Today we’ll look at how Interpolique can be implemented in Haskell in such a way that we force the developer to use Interpolique when creating a SQL query, precluding the possibility of the $/^^ mixup bug. In doing so we’ll see that we don’t need anything like PHP’s eval to get the job done.

All of the code for this post is on github: InterpoliqueQQ.

(more…)

Continued weak support from Opal Kelly

A mentioned earlier, I have a XEM 3001 from Opal Kelly. I bought it for simplicity. Simple it is — supported, however, it is not.

Issues thus far:

  • The FrontPanel software, a utility for doing quick-and-dirty PC interfacing with the device, is only supported on a handful of Fedora releases. No source means no can make run on other platforms. Until this January, they only supported Fedora 5 and 7. Absurd.
  • Support is conducted via their online forum. Cute, except they rarely respond with any real info. A lot of “oh, we’ll do something about that real soon now.” Be prepared to hear back a caustic reply. The customer is always an idiot, after all.
  • The RAM3001 module — an addon for the low end XEM boards to give them some memory — isn’t really supported with the XEM3001. Sure, they say it is. It’s not. They have sample code for interfacing for all other modules. They’re response? Oh, you should be able to figure out what to do based on the source for the hardware you don’t own. So, you know, familiarize yourself with some other hardware you have nothing to do with.

I’m sure that experienced engineers can get around this. Experienced I am not. They market their products to students. Bummer.

Opal Kelly XEM3001

Today my Opal Kelly XEM3001 arrived. I’m hoping to use it for some high-speed signal processing, which I’ll write about when I have more to show for it. For the time being, I just wanted to mention that the FrontPanel software works on my MacBook Pro more or less, though I must point out that some of the samples are trying to find wave files in c:\windows, which is a cute bug, and luckily pretty harmless (these being just sample projects, after all). The sample code showed that it was possible to upload code to the FPGA (and fast!) as well as communicate to the device via USB.

Edit. Well, it works on my Mac, but not on Ubuntu. The supporting software (which is free as in beer) is shipped binary-only, and is built for Fedora 7. I found this thread where Opal Kelly responded to a user’s support question by trying to sell him a custom build.

Of course, I’d be elated if they’d just release the source, I can’t really expect everyone to wake up to the 21st century. Still, if they insist on this silly binary-only distribution, it’d be nice if they’d support the same distribution that Xilinx supports (ie, Redhat). It’d also be nice if they could find a way to ship without dynamic linking dependencies. *sigh*

Pics:

t

OpenWRT and Ubiquiti NanoStation 2

I’m scheduled to give a summary talk on the state of cryptographic attacks on WiFi for the University of Utah GSAC colloquium. I wanted to be able to demonstrate the practicality of these attacks, so I needed a platform to launch attacks from.

To this end, I picked up a Ubiquiti NanoStation 2 from Metrix. Today’s post is a bit of a how-to for getting the unit up and running with OpenWRT.

Background

OpenWRT is a framework for building a Linux distribution for use in routers and other embedded computers. Building a Linux distribution for an embedded computer is generally very difficult; OpenWRT’s main contribution is that it makes the process significantly easier. At the time of writing, the latest version of OpenWRT is Kamikaze.

Where’s a brief overview of the steps for getting OpenWRT onto the NanoStation 2, and how much work they are:

  1. Update the firmware on the NanoStation
  2. Download the OpenWRT trunk and packages (two commands)
  3. Setup the build environment (one command)
  4. Select which packages you want for your distribution (one command, a bit of menus)
  5. Compile (one command and some patience)
  6. Upload to device (one command)
Laying on my desk

Laying on my desk

So now a bit about the NanoStation 2. Seattle Wireless has a good summary of the hardware specifications. I’ll speak about the device qualitatively:

First, this is a device with excellent range with the built-in antenna. I don’t have an external antenna for the unit; in my experience, the unit performs great on its own. I’ve been using it to do analysis, and have found that it sees much more than my laptop (which is why I bought the unit, after all).

Second, the device is powered exclusively by its Ethernet connection. I don’t own any switches that can provide power over Ethernet; however, the unit comes with an adapter that puts power on the line. I’ve never used a PoE device before, but I can tell that I’ll want more. This is a very nice feature, especially for practical use outdoors.

Third, this device is hard to brick. I’m generally nervous about flashing devices with unofficial images. While I obviously can’t claim that this device is brick-proof, I can say that it seems resilient. On more than one occasion I’ve messed up my OpenWRT installation, and was able to recover by returning to the official firmware. I’ll describe this process in a bit.

Fourth, it’s a small machine that mounts with zip-ties. Zip ties! I love it.

Mounts with zip ties.  Shown here on my camera tripod as a temporary measure during testing.

Mounts with zip ties. Shown here on my camera tripod as a temporary measure during testing.

Getting OpenWRT Up

Here’s the quick and dirty. We first need to grab the OpenWRT trunk and packages:


broker@localhost:~$ svn co https://svn.openwrt.org/openwrt/trunk/
broker@localhost:~$ cd trunk
broker@localhost:~/trunk$ mkdir feeds
broker@localhost:~/trunk/feeds$ cd feeds
broker@localhost:~/trunk/feeds$ svn co https://svn.openwrt.org/openwrt/packages

Find your way back into the trunk directory and invoke make package/symlinks:


broker@localhost:~/trunk/feeds$ cd ..
broker@localhost:~/trunk$ make package/symlinks

This command prepared the environment. At some point it brings up a configuration screen. You’ll need to select which platform you want to build for; set the Target System to “Atheros 231x/5312 [2.6].”

Once this is done we are ready to move forward and start selecting packages. Invoke


broker@localhost:~/trunk$ make menuconfig

You’ll find yourself confronted with a menu system similar to that for configuring the Linux kernel. Here you can pick which packages you want included in your build. The NanoStation 2 has 4MB of storage, so pick wisely: the build environment will strip things down as much as it can, but you still need to be prudent with storage.

This is also a good time to configure the default network settings for your image. Select “Image configuration” to set the default IP address for your device’s Ethernet controller. You can also set a DNS and gateway server for the device at this time. If you don’t, it will default to the IP address 192.168.1.1.

After you have configured what packages you want to use, you’ll be returned to the command prompt. We’re now ready to do the build:


broker@localhost:~/trunk$ make

Go grab a drink; this will take a while. OpenWRT will proceed to make its own cross-compile environment, which will take some time. It also takes some space: on my system, the trunk directory is 2.55GB!

Once the build is complete, we can find the constructed image in trunk/bin. On my system, here’s what the directory listing looks like:


broker@localhost:~/trunk/bin$ ls -l
total 20080
-rw-r--r-- 1 broker broker 519 2008-11-13 23:29 md5sums
-rw-r--r-- 1 broker broker 3801088 2008-11-13 23:29 openwrt-atheros-root.jffs2-128k
-rw-r--r-- 1 broker broker 3801088 2008-11-13 23:29 openwrt-atheros-root.jffs2-64k
-rw-r--r-- 1 broker broker 2490368 2008-11-13 23:29 openwrt-atheros-root.squashfs
-rw-r--r-- 1 broker broker 3211672 2008-11-13 23:29 openwrt-atheros-ubnt2-squashfs.bin
-rw-r--r-- 1 broker broker 3211672 2008-11-13 23:29 openwrt-atheros-ubnt5-squashfs.bin
-rwxr-xr-x 1 broker broker 2290916 2008-11-13 23:29 openwrt-atheros-vmlinux.elf
-rw-r--r-- 1 broker broker 983040 2008-11-13 23:29 openwrt-atheros-vmlinux.gz
-rw-r--r-- 1 broker broker 720896 2008-11-13 23:29 openwrt-atheros-vmlinux.lzma
drwxr-xr-x 3 broker broker 4096 2008-11-12 23:53 packages

Note that it builds a few different images; we’re interested in openwrt-atheros-ubnt2-squashfs.bin. If you don’t have this file, but the build didn’t complain, then the most likely cause is that the image was going to be more than 4MB. You see, the build process knows that the NanoStation 2 has only 4MB of storage, and won’t bother making an image for the device that is larger than this size. If you doubt this is the issue, you can try the build again with the V=99 option, which enables verbosity. Here’s what it would look like:


broker@localhost:~/trunk$ make V=99

Grep through the results to find the command which was going to make the openwrt-atheros-ubnt2-squashfs.bin file and see if it complained.

So now that we’ve got the image, it’s time to upload it to the device. By default, the NanoStation 2 is configured to run at 192.168.1.20. It supports image upload by tftp:


broker@localhost:~/trunk$ cd bin
broker@localhost:~/trunk/bin$ tftp 192.168.1.20
tftp> bin
tftp> put openwrt-atheros-ubnt2-squashfs.bin

If you find that this fails, check to verify that your NanoStation has is running the latest Ubiquiti firmware. Go to the Ubiquiti NanoStation 2 Support page for the latest firmware. I found that the firmware the unit shipped with wouldn’t accept my OpenWRT image, but the newer firmware does.

Once you’ve uploaded the image to the NanoStation 2, you should be able to telnet to the device. It will drop you to a root shell without authentication. Once you change your root password, it will disable the telnet daemon and only respond via SSH.

If you want to enable the wireless, edit /etc/config/wireless. Note that there’s a line you need to comment-out to enable the controller! For more detailed configuration information, consult with the documentation.

Getting aircrack-ng and Kismet to work

If you decided to deploy Kismet and aircrack-ng on your NanoStation, you will probably want to know more about how to use these utilities on this device.

Here’s how I got Kismet to work on the device:

  1. First, I had to disable the existing ath0 device. To do this, simply issue airmon-ng stop ath0. To be honest, I do not know why this has been necessary; however, it has been my experience that ath0 isn’t able to enter monitor mode after the device has booted — my guess is that something about its initialization isn’t hacker-friendly. So we go through this airmon-ng business to remedy that.
  2. Now re-create ath0 by issuing airmon-ng start wifi0. We can verify that this did what we wanted:
    root@OpenWrt:/# iwconfig
    lo        no wireless extensions.
    eth0      no wireless extensions.
    wifi0     no wireless extensions.
    br-lan    no wireless extensions.
    ath0      IEEE 802.11g  ESSID:""  Nickname:""
              Mode:Monitor  Frequency:2.457 GHz  Access Point: [censored]
              Bit Rate:0 kb/s   Tx-Power:16 dBm   Sensitivity=1/1  
              Retry:off   RTS thr:off   Fragment thr:off
              Encryption key:off
              Power Management:off
              Link Quality=0/70  Signal level=-96 dBm  Noise level=-96 dBm
              Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
              Tx excessive retries:0  Invalid misc:0   Missed beacon:0
    
  3. We now need to configure kismet_drone to use the proper device. This is done by editing /etc/kismet/kismet_drone and setting source=ath5k,ath0,wireless. While in there, don’t forget to edit the rest of the file — especially the line that controls which IP addresses kismet clients are allowed to connect from!
  4. We can now launch kismet_drone. We need to tell it where to find the configuration file:

  5. root@OpenWrt:/# kismet_drone -f /etc/kismet/kismet_drone.conf

This procedure is enough to get started with the rest of aircrack-ng. Tonight I verified that the device is capable of pulling off the PTW attack; for instructions, see the Simple WEP Crack Tutorial.

Conclusion

The NanoStation 2 is a wonderful device; at under $100, this thing packs much more punch than any other device like it that I’ve used. OpenWRT support for the unit is fantastic. With judicious selection of packages, there’s sufficient room on the device for aircrack, kismet_drone, and nmap.

My LCD arrived!

This just game in the mail today. I’m so excited!

So basically, here’s how it goes:

At Robothon this year, I won this GPS eval board in the raffle. After writing a quickie program for my Mac to pull out coordinates, I decided to get a microcontroller and try to build something a bit more hand-held.

So I got one of these and have been happily playing around with programming it to do cute things over serial.

I’ve got some craftsmanship-y stuff to do before I’ve got a hand-held GPS coordinate readout, but I’m on my way :)

LCD hooked up to my Arduino