Airpwn Documentation
Supported Cards
In theory airpwn supports any cards supported by the LORCON framework. This list as of 5/27/09 is: wlan-ng, hostap, airjack, prism54, madwifing, madwifiold, r8180, r8187, rt2500, rt2570, rt61, rt73, zd1211rw-softmac, bcm43xx and mac80211 (including acx-mac80211, ath5k, ath9k, b43, b43legacy, iwl3945, iwlagn, p54, rt2x00, rtl8180, rtl8187 and zd1211rw-mac80211).
Airpwn has been tested successfully with an Atheros (AR5xxx) card (standard on IBM thinkpads) using the madwifi driver, an RTL8187L using r8187 & rtl8187, and a ZD1211B using zd1211rw (mac80211 version). If you have success using other cards/drivers please let me know and I’ll update this page.
How Airpwn Works
Airpwn works by spoofing 802.11 packets to look as if they came from a legitimate access point (AP). When you use a traditional 802.11 network, you are communicating all your data to the AP, and all responses come from the AP. One drawback of wireless networks is that all the data you send to the AP is in fact broadcast to every other computer in your general area. By eavesdropping on the data you send to the AP and spoofing a response from the AP, airpwn can appear to be whatever computer you are communicating with. (This is similar, but not identical to a classic man-in-the-middle attack.)
Here’s an example: Say you type “google.com” into your web browser using a wireless network. Your browser sends a series of packets to the AP in order to setup a TCP connection, then sends an HTTP request packet to the google IP (via the AP) on port 80 that looks something like this:
Under normal circumstances, the google webserver processes this request and returns an HTTP response with HTML content, such as:
If airpwn were running and configured to respond to simple HTTP requests, airpwn would spoof a response from google (via the AP) and send is to your wireless client. Most operating systems will accept the first packet they see as valid (after all, they’re trying to get the data to you ASAP), so as long as airpwn delivers the spoofed packet before google does, you will see airpwn’s data instead of google’s. For example, airpwn might inject:
In practice, beating google’s packet (or any site for that matter) is easy. Average internet latencies easily extend into the tens of milliseconds, while airpwn, being local, can respond within a few microseconds. By the time the google packet(s) arrive, the airpwn packet has likely been accepted and processed, and the duplicate data from google is silently ignored.
If the legitimate site sends more data than airpwn (which tends to be a common scenario) the remainder of the legitimate content may be appended to the end of the injected data. (This can be controlled by using the reset option, or by using protocol hints like HTTP’s Content-length.) Another trick is to end your injected content with some markup (in the case of HTML) that will hide the remainder of the content. For example, ending your injected data with the following tends to work well:
The remainder of the legitimate content is wrapped in an HTML comment inside an invisible DIV element placed far off the screen.
Airpwn Configuration Files
At runtime, a single configuration file is passed to airpwn in addition to the command line parameters. The configuration contains one or more entry. Each entry contains some match criteria and a link to the content to be sent in response.
The match criteria are a (required) PCRE expression to match, and an optional PCRE expression to use as an ‘ignore’ filter. Airpwn will spoof a response to a packet if the match expression is found and the ignore pattern (if present) does not match. Here’s a sample config file to match non-image HTTP requests:
![begin greet_html
match ^(GET|POST)
ignore ^GET [^ ?]+\.(?i:jpg|jpeg|gif|png)
response content/greet_html](Documentation_files/shapeimage_6.png)
In this example, all HTTP requests using the GET or POST method are matched that don’t request one of the common content types. This is useful for replacing webpage contents without breaking images. The response keyword specifies the path to a file containing the response to be sent by airpwn. In this case, the contents are:
When combined, these two files have the effect of replacing all webpages with a friendly blinking red message.
Multiple entries can be specified in the same configuration file, allowing for nearly limitless configurations. For example, we can extend the above configuration to also spoof responses to website images named “logo”.
![begin greet_html
match ^(GET|POST)
ignore ^GET [^ ?]+\.(?i:jpg|jpeg|gif|png)
response content/greet_html
begin logo_replace
match ^GET [^ ?]logo+\.(?i:jpg|jpeg|gif|png)
option reset
response content/airpwn_logo](Documentation_files/shapeimage_8.png)
The option reset line in the above configuration instructs airpwn to send a TCP reset (RST) packet immediately after injecting the response content. This will cause the connection to terminate immediately, often making the injection work better and/or faster.