Grr. 2560x1600 still don't work

Running BackTrack in VMware I still can't get to 2560x1600, although 1600x1200 works fine. I edited /etc/X11/xorg.conf correctly, but still don't work.

Patch: airbase-ng timestamp bug

I'm diagnosing another major bug with airbase-ng. Every so often, about 1% of the time, things stop working for no apparent reason. I pulled out Wireshark to see what what was going on. I noticed a minor flood of packets that looked like the following:

As you can see, the "Timestamp" field is obviously bogus, having gone negative. Just by looking at the field, the cause of this is intuitively obvious. It must be some sort of 32-bit to 64-bit integer promotion bug (the field is 64-bits wide, the code runs on a 32-bit version of Linux).

Hunting this down was quick, such search for "gettimeofday", "timestamp", or "tv1". The offending code looks like this:

struct timeval tv1;
uint64_t timestamp;
...
gettimeofday( &tv1, NULL );
timestamp=tv1.tv_sec*1000000 + tv1.tv_usec;

Yep, that's obviously a 32-to-64 promotion (tv_sec is defined as an int). Multiplying by a million causes the value to fill out the full 32-bits, setting the high-order bit, meaning the number is now negative. When the 32-bit result gets assigned to a 64-bit integer, it is "sign-extended", filling out all the high-order bits.

There are many possible fixes, but the simplest is just to change the constant from a 32-bit value to a 64-bit value. In C, appending the letter "L" to a number makes it 64-bits, so whereas the number "1" is 32-bits, "1L" is 64-bits. Appending the letter "U" makes it unsigned, preventing sign extension. Thus, "1UL" is a 64-bit unsigned number with the value of "1".

This can easily be tested with the following program:

#include <stdio.h>
#include <stdint.h>
#include <sys/time.h>
int main()
{
    struct timeval tv1;
    uint64_t timestamp;
    for (;;) 
    {
        gettimeofday(&tv1, NULL);
        timestamp = tv1.tv_sec * 1000000 + tv1.tv_usec;
        printf("+%llx\n", timestamp);
        timestamp = tv1.tv_sec * 1000000UL + tv1.tv_usec;
        printf(" %llx\n", timestamp);
        sleep(1);
    }
}

If you let it run during the time that the expression goes negative, you'll get the following result (hex numbers starting with 89ABCDEF are negative):

+ffffffffe78b00d5
 e78b00d5
+ffffffffe79a6a3d
 e79a6a3d
+ffffffffe7a9d355
 e7a9d355
+ffffffffe7b932e0
 e7b932e0
+ffffffffe7c87784
 e7c87784
+ffffffffe7d7c11a
 e7d7c11a
+ffffffffe7e70493
 e7e70493
+ffffffffe7f65dc1
 e7f65dc1

The expression exists in several places in airbase-ng.c. The solution is to go through the source and added the 'L' to the end of each constant:

-    timestamp=tv1.tv_sec*1000000 + tv1.tv_usec;
+    timestamp=tv1.tv_sec*1000000UL + tv1.tv_usec;

After I do that, this problem goes away.

Note that this isn't the best fix -- it's just the one that fixes the problem with the least amount of fuss.

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.

VMware configuration on my desktop

While I use the non-persistent live-cd version on netbooks for pentests, I have a persistent copy running in VMware on my desktop. Here are the things I do each time I need to reinstall it.

Download the VMware version

Go to the downloads page and grab the saved VMware virtual machine. It comes with the VMware tools already installed. I use VMware workstation, but I think this will work in VMware player.

Edit VM settings

Since I'm running on my desktop machine, and not a netbook, I need to bump up the settings a bit.

• Memory: bump up to to 2-gigs (I have 12-gigs on desktop)
  
• Processor: bump up to 2-cores (I have 4 hyperthreaded cores on dekstop).
  
• Network: change to "bridged" with "replicated state"
  
• Display: change to "accelerate 3D graphics"
  
• Shared folders: enable, all my development is done in the shared folders
  

fix-vesa

After booting the first time, run the fix-vesa command. This enables it to run at 1280x1024 full-screen on one of my monitors, rather than 1024x768.

automate networking

I edit /etc/networking/interfaces so that just eth0 is listed. I then run the following script to auto-start networking at startup.

update-rc.d networking defaults

change hostname

Change /etc/hostname to something more descriptive than just "bt", something like "vmpwnsauce". In the past, I used to name my home machines something unrelated to what they were, like "playstation3" for a Windows machine. That confused me too much, so now I rename everything according to what they are. (Like most geeks, I've got 20 different machines on my home network).

SSH daemon configuration

sshd-generate
update-rc.d ssh defaults

auto logon to the desktop

Start networking and install "rungetty":

apt-get install rungetty

Edit /etc/event.d/tty1 and change last line:

#exec /sbin/getty 38400 tty1
exec /sbin/rungetty tty1 --autologin root

Edit /root/.bash_profile:

startx

update package list

apt-get update
apt-get install aircrack-ng

References: http://www.question-defense.com/2010/01/14/backtrack-4-final-installation-in-vmware-with-vmware-tools

Gateway IP address

I'm building an 'evil-twin' script. It needs to find out which adapter (like eth0 or wlan0) I'm going to use as my upstream side, that will connect to the Internet. It also needs the gateway IP address.

The way to do that is with the route -n command (netstat -rn also works), then extract the data with grep and awk:

gatewayip=`route -n | grep 'UG[ \t]' | awk '{print $2}'`

notes: http://www.cyberciti.biz/faq/how-to-find-gateway-ip-address/

Networking

Older versions of Backtrack would automatically bring up networking and mount drives. This annoyed pentesters, because we don't want such automatic things to happen, especially automounting the primary drive when we boot from a live CD. So, you have to do it manually.

For Ethernet, I type in something like the following:

ifconfig eth0 up
dhclient eth0

For WiFi, I do something like:

ifconfig wlan0 up
iwconfig wlan0 mode managed essid "linksys"
dhclient wlan0

There are easier ways of doing this. For example, I can just use the "ifup" thingy:

ifup eth0

Changing the screen resolution

Fixing the screen resolution on Backtrack 4 is a pain. It assumes a laptop with 800x600 or 1024x736 resolution.

I recently installed the VMware version on my desktop, which has multiple monitors. I wanted to full-screen it on one monitor, which is 1280x1024. This is really cool because I can simply mouse over the window to change the focus.

The solution to the problem was to simply exit the desktop back to the command-line, type "fix-vesa", then type "startx" to bring up the desktop again. Voila, it was now 1280x1024. I hit full-screen button on VMware, and everything worked as I wanted it.

I'm not sure what fix-vesa does. I typed "xrandr" to find out what settings had been changed, it appeared to only add an entry for 1280x1024.