Writing Your Own Wireless Software

Other than using preexisting tools that are already written and published by someone else, attackers might also need to write their own customized tools. The following sections highlight some important pointers to look out for when writing wireless tools.

Libpcap When developing a wireless tool, one of the most important code libraries to be familiar with is the Libpcap library. Originally developed at the Lawrence Berkeley Laboratory, it is currently maintained by the same group of people who maintain Tcpdump, the command-line packet capture utility (http://tcpdump.org). The use of the Libpcap library in a sniffing tool simplifies a lot of coding from a programmer's perspective, making it something of a necessity when coding a tool.

To illustrate, take a look at the following segment of Probemapper's code, which is written in C:

pcap_handl = pcap_open_live(interface,65536,1,1000000,errbuf); // When an error has happened if(pcap_handl == NULL) {

fprintf(stderr,"Error in pcap open live(): %s\n",errbuf);

This code shows the Probemapper tool opening up a pcap interface that will be used subsequently for purposes of getting packets from that wireless interface.

The following code uses the handle that is created via pcap_open_live and the pcap_next function call to extract the data received by that wireless interface. The subsequent three lines check for and report an error if nothing is received.

packet = pcap next(pcap handl,&hdr);

fprintf(stderr,"No packets: %s\n", errbuf);

The next important thing to understand when it comes to sniffing a wireless interface is that the wireless interface needs to be placed in RFMON mode for it to sniff wireless traffic, be it data, management, or control frames. Prepended to each of the wireless frames, collected via the wireless driver, is a special header that reports information about signal level, noise level, frequency, and rate, at the point where the frame is received by the WNIC. Different headers are prepended depending on the wireless driver/ firmware combination in use, as well as the settings on those drivers/firmware in some cases. Identifying the type of header information that has been prepended is very important because the sniffer being coded needs to know the structure of packet headers captured and how to process them accordingly thereafter.

Generally three types of headers are prepended: the Radiotap header, the WLAN-ng PRISM header, and the WLAN-ng PRISM AVS header. To be able to differentiate programmatically among these headers being prepended to each wireless packet, you can use the pcap_datalink function call, which is summarized next:

#define DLT_PRISM_HEADER 119 #define DLT_IEEE802_11_RADIO_AVS 163 #define DLT_IEEE802_11_RADIO 127 // Identify PRISM Header if (pcap_datalink (pcap_handl) == DLT_ PRISM_HEADER) {

..process PRISM header code here }

// Identify AVS Header if (pcap_datalink (pcap_handl) == DLT_IEEE802_11_RADIO_AVS) {

..process PRISM AVS header code here }

// Identify Radio Tap Header if (pcap_datalink (pcap_handl) == DLT_IEEE802_11_RADIO) {

..process Radio Tap header code here }

Since the structure definitions of the various headers are different, the codes used to process these headers also have to vary. The data structures defined for the three headers are documented here for inclusion when coding a wireless application:

PRISM Header

p80211item uint32 t hosttime attribute ((packed)), p80211item uint32 t mactime attribute ((packed)); p80211item uint32 t channel attribute ((packed)); p80211item uint32 t rssi attribute ((packed)); p80211item uint32 t sq attribute ((packed)); p80211item uint32 t signal attribute ((packed)); p80211item uint32 t noise attribute ((packed)); p80211item uint32 t rate attribute ((packed)); p80211item uint32 t istx attribute ((packed)); p80211item uint32 t frmlen attribute ((packed)); };

PRISM AVS Header struct avs 80211 1 header { uint32_t version; uint32_t length; uint64 t mactime; uint64_t hosttime; uint32_t phytype; uint32 t channel; uint32_t datarate; uint32_t antenna; uint32_t priority; uint32_t ssi_type; int32 t ssi signal; int32 t ssi noise; uint32 t preamble;

uint32_t encoding; };

RadioTap Header struct ieee80211_radiotap_header { u8 it version; u8 it_pad; u16 it len;












The structure of the Radiotap capture header differs from the other two headers in that it is a variable length header with the field it_present. This indicates, by its bitmap setting, which field is present and which field is not.

After the capture header has been taken care of, the sniffer code will then have to process the rest of the wireless frame as a wireless frame with its structure. In this code, the frame received (after taking away the capture header) is being cast to a management header structure:

#define T_MGMT 0x0

#define ST_AUTH 0xB

#define FC SUBTYPE(fc) (((fc) >\> 4) & 0xF)

struct mgmt header t { u int16 t fc; u int16 t duration; u_int8_t da[6]; u_int8_t sa[6]; u_int8_t bssid[6]; u int16 t seq ctrl; };

// Get the management header out of the packet mgmt header = (struct mgmt header t *) packet;

.. code to process management wireless frame }

.. code to process authentication request frame }

LORCON LORCON is an acronym for Loss of Radio Connectivity. It is a set of libraries written by Joshua Wright and Dragorn. These libraries make a programmer's job much simpler when it comes to writing a packet injection tool as they eliminate the complexities and intricacies of having to deal with multiple wireless chipsets and having to write code for every single WNIC you want to support in your application, since each WNIC's code is written and functions differently.

LORCON can be downloaded from http://802.11ninja.net/code/LORCON-current.tgz. After installing LORCON, if you want to code an application that makes use of the LORCON libraries, you need to compile it using an additional library flag of -lorcon.

LORCON exposes a series of function calls that any application that compiles the LORCON library into its code can use. By making use of the LORCON library, the application developer does not have to write driver-specific codes to take care of the differences in making different drivers/chipsets inject packets. The code structure/ format presented here illustrates the capability of the library, from showing how an interface can be established up to how a wireless frame can be transmitted:

#include <tx80211.h> #include <tx80211 packet.h> /* Initialize the interface */

if (tx80211 init(&in tx, iface, drivertype) < 0) .. code to handle error /* Set monitor mode */

if (tx80211_setmode(&in_tx, IW_MODE_MONITOR) < 0) { .. code to handle error

if (tx80211 setchannel(&in tx, channel) < 0) {

.. code to handle error

/* Open the interface to get a socket */ if (tx80211_open(&in_tx) < 0) { .. code to handle error

/* Send the packet if (tx80211 txpacket(&in tx, &in packet) < 0) .. code to handle error

Included with this book is Probemapper, a GPL'ed wireless-client-detection and wireless-profile-identification program that makes use of the LORCON libraries. Probemapper is also available from http://securitystartshere.org/page-downloads.htm (which also houses a copy of the LORCON libraries that work with Probemapper).

Was this article helpful?

0 0
The Ultimate Computer Repair Guide

The Ultimate Computer Repair Guide

Read how to maintain and repair any desktop and laptop computer. This Ebook has articles with photos and videos that show detailed step by step pc repair and maintenance procedures. There are many links to online videos that explain how you can build, maintain, speed up, clean, and repair your computer yourself. Put the money that you were going to pay the PC Tech in your own pocket.

Get My Free Ebook

Post a comment