Tuesday, August 3, 2010

Patch: airbase-ng.c

I'm trying to use airbase-ng (from aircrack-ng.org) for an "evil-twin" rogue wifi access-point. However, the code has a number of bugs that need to be fixed.

The first bug is in "probe response" packets that response to "probe requests" with a null (empty) SSID field. The code (incorrectly) copies the probe request, adds it's own SSID, then sends the packet as a response. Thus, the response packet contains two SSIDs: the first one is the one airbase added, the second one is the empty one from the probe-request. I fixed this bug by simply changing the 'tag' of the SSID to some unknown value that will be ignored by the receiver.

The second bug is in the handling of "QoS" data packets. These are otherwise identical to data packets, but they have an extra 2 bytes in the header for the QoS field. The existing code doesn't handle this correctly, causing inserting those extra two bytes in the equivelent Ethernet frame, between the address fields and the ethertype. Sniffing at0 shows frames that have an ethertype of 0x0000, followed by "08 00 45 ...". Fixing this is a two line change to test if the packet is QoS, and if so, skip an extra two bytes in the header.

For the probe-response problem I added the following function that mangles the field tag in the incoming packet, changing it from 0 (meaning SSID) to 230 (something else). All other fields are left alone:
void nuke_essid(uchar* packet, int length)
{
    int offset=0;

    while( offset+2 < length )
    {
        int tag_length = packet[offset+1];

        if( packet[offset] == 0 )
            packet[offset] = 230;
        offset += 2 + tag_length;
    }
}
I then call it after it receives the broadcast probe:

    if(opt.verbose)
    {
        PCT; printf("Got broadcast probe request from %02X:%02X:%02X:%02X:%02X:%02X\n",
                smac[0],smac[1],smac[2],smac[3],smac[4],smac[5]);
    }

    //store the tagged parameters and insert the fixed ones
    buffer = (uchar*) malloc(length-z);
    memcpy(buffer, packet+z, length-z);
+   nuke_essid(buffer, length-z);

    memcpy(packet+z, "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00", 12);  //fixed information
    packet[z+8] = (apc->interval) & 0xFF;       //beacon interval
To fix the QoS problem I simply add the following two lines near the beginning of packet_recv():
    pthread_mutex_unlock( &mx_cap );

    z = ( ( packet[1] & 3 ) != 3 ) ? 24 : 30;
+   if(packet[0] == 0x88)
+       z += 2; /* handle QoS field */

    if(length < z)
    {
Tickets

The probe-response issue is open in ticket 714. On one of my WinXP machines, I see the same problem with weird characters in the SSID being displayed.

The QoS issue is described in ticket 760. I have a MacBook Air, which is how I found it. My MacBook Air is running Windows, however. I think it has to do with the driver or hardware, not Mac OS X. I'd bet any 802.11n device will have the same problem, since they prefer to send QoS packets.

2 comments:

  1. Thank you very much! I tracked down the same problem looking at the frames on the TAP interface, then found this patch via google. Cheers

    ReplyDelete
  2. Thank you very much! I Greetings from me. Please visit my website:http:///teknologiprograming.blogspot.com. I await his arrival

    ReplyDelete