This is a hands-on blog post describing how to capture and analyze internet traffic of an Android application. You will need a computer with Linux installed, and a wireless adapter that is supported by Kismet (see: 7. Supported capture source types). I assume that you know how to connect your Android device to a wireless network, and that you know how to download and install programming libraries and development packages in your Linux environment. This blog post was written based on my experiences with Ubuntu 10.10 on an IBM Thinkpad T42 using an upgraded Intel 2200ABG wi-fi adapter.

There are four phases to capturing Android traffic:
1. Connect the Android device to a wi-fi network
2. Install and configure Kismet
3. Capture a log with Kismet
4. Analyze the log with Wireshark

1 Connect the Android Device to a Wi-fi Network

I assume that you already know how to connect to a wi-fi network on your Android phone, though the choice of network is important. Because you will be capturing all wireless traffic on that network, you should make sure you have permission to do so - ideally, you'll be doing this at home, so the only people that can complain is your family or room mates. The network security is also a consideration. Wireshark can decrypt WEP and WPA/WPA2 (in personal mode only) traffic if you have the key, though WPA decryption also requires the capture of 4 EAPOL handshake packets. Since I don't know how to guarantee capture of those packets, I will recommend using WEP or no encryption for the purposes of this test.

At the same time, make a note of what channel your adapter is on, and the MAC addresses of your router and Android device.

2 Install and Configure Kismet

Kismet is a powerful, open-source application for capturing and analyzing IEEE 802.11 (wi-fi) traffic. I am new to the tool, and have only begun to scratch the surface of what can be done with it, but some of the uses include discovery of hidden wi-fi networks, passive WEP key cracking, identifying clients connected to a network (and monitoring their network usage), and logging all observed wireless traffic. The traffic logging feature is what we are interested in now, because we want to see what kind of data our Android applications are sending out over the internet.

The version of Kismet available in the Ubuntu repository is over two years old as of this post, so I recommend downloading the latest version from the website and compiling the program from source. Kismet uses the standard ./configure && make && make install pattern, making installation a snap, though it may require installing some libraries such as libpcap-dev and libnl-dev. The only gotcha is that it needs root access to configure the wireless adapter. For a short test in a safe environment, you can install and run the program as root, but it's important to be aware that the packet analysis code and all plugins will run with root privileges. Instructions to install and run Kismet more safely are available in the README file or on the Kismet documentation page.

By default, the Kismet configuration file can be found at /usr/local/etc/kismet.conf, though for this guide there is nothing in the configuration that needs to be changed.

3 Capture a Log with Kismet

Before launching Kismet on Ubuntu 10.10, I needed to manually disable wireless networking by right-clicking on the wi-fi icon on the Panel, and unchecking the "Enable Wireless" option.

Launch Kismet from the command line by running "kismet", or "sudo kismet" if you installed it as root. There will be several dialog boxes when you first run the application. Navigate through the dialogs using tab/enter, or with the mouse. If running as root, the first will warn you that running Kismet as root is unsafe. Next, Kismet will ask if it should automatically start the Kismet Server (choose "Yes", then "Start"). Finally, there should be a warning that no capture sources are configured. Choose "Add Source". Next to "Intf", type the name of the wireless interface (On Ubuntu, the default is eth1). The "Name" field can be anything, but I'd suggest naming it after the manufacturer of your wireless adapter. Next to "Opts", tell Kismet not to hop to different wi-fi channels, then specify what channel it should monitor by writing "hop=false,channel=xx".

On my machine, I eventually received a warning dialog stating that "All packet sources are in error state" - Kismet was unable to identify the type of wireless adapter I had, so I needed to manually specify this as an option when adding it as a source ("type=ipw2200").

Instead of adding the source on start-up, consider adding the source in Kismet's configuration file. Here is an example from my configuration file:

# See the README for full information on the new source format
# ncsource=interface:options
# for example:
# ncsource=wlan0
# ncsource=wifi0:type=madwifi
# ncsource=wlan0:name=intel,hop=false,channel=11
ncsource=eth1:type=ipw2200,name=intel,hop=false,channel=1

Once the source is added, logging should begin automatically. By default, log files are saved in the directory that Kismet was started in, though this can be changed in the configuration file or through command line arguments. Start up the Android app to be tested and generate some traffic. When enough data has been captured, quit Kismet and kill the Kismet Server.

4 Analyze the Log with Wireshark

Install Wireshark if it isn't on your machine. On Ubuntu, the version in the repository is mostly up-to-date, so that building from source isn't necessary.

Start Wireshark, click File -> Open, then navigate to the directory where Kismet saved the log files. Find and select the log ending with the extension ".pcapdump" - this is dump of the raw 802.11 packets captured by your wireless adapter. If the traffic was captured from a WEP-protected network, the hex decryption key can be sent under Edit -> Preferences -> IEEE 802.11 (see The Wireshark Wiki - HowToDecrypt802.11).

To find the specific packets for the application you're interested in, try using Wireshark's display filters. The filter "wlan.addr == xx:xx:xx:xx:xx:xx" will limit the displayed packets to only those that were sent by or sent to the specified MAC address (note that the filter for wired MAC "eth.addr" is different from the filter for wireless MAC!). The traffic you're looking for would likely be TCP, so the filter "tcp" can narrow things down further. Eventually, you should be able to find the IP address of the server that the app is communicating with, so the filter "ip.addr == xxx.xxx.xxx.xxx" would give you only packets between the Android phone and the destination.

Happy hacking!

Tamagotchis can have three possibile interactions: visits, presents and games. Starting with the simplest, visits, I recorded a number of interactions. I noted that each visit involved either singing, playing ball or chatting. Below is a sample visit.

Singing visit between JANIE and HELEN

JANIE: ac 0 24 d6 a 1 e 9 5 0 4 88 0 0 20 80 9 0 0 ff 1 ff ff 0 (request)

HELEN: ac 1 1f 96 8 5 c 5 e 0 4 88 20 5 10 0 1 0 0 ff 1 ff ff 4e (response)

JANIE: ac 1c 24 d6 a 1 20 1f c (request confirmation)

HELEN: ac 1d 1f 96 8 5 20 24 cf (response confirmation)

Based on this (and several other samples)I theorize the following protocol:

Request and response:

Confirmations

When the Tamagotchis play a game instead of just visit, the request and response are the same, but the confirmations are different:

Likewise, when they give a present, only the confirmation is different.

So that's a ten second guide to the protocol!

Up next:

• Set up IR to send stuff to Tamagotchi
• Put a Tamagatchi into debug mode to better understand the physical attributes portion of the protocol
• Play with the protocol :)

At first I attempted to do this using the Python script from Part I, but this means that the entire signal must be sent over serial, which is slow and can miss events.

Instead, I implemented decoding directly on the Arduino board. I used a simple state machine that polls the output of the IR receiver and changes state based on the amount of time the signal was one or zero before it changed. The Arduino has an internal timer (call millis or micros) that was used for timing.

Serial output is not printed until decoding is complete as to not interfere with timing.

I had to do some manual timing of signals to get the decoder to work correctly, but now it decodes both sides of the IR conversation quite cleanly.

Example output:

ac 00 0e d6 01 0c 05 18 00 00 03 88 00 00 10 00 02 00 00 ff 1 ff ff 55

From a Tamagotchi named "Alex" (01 0c 05 18 in IR).

To start, I set up a liteon IR module to listen in on the transmission, and recorded the ouput with some help from DW and his digital signal analyser.

Plotting the signal, you can see a request and a response:

Looking more closely at the request:

Googling a bit, this appears to be similar to NEC encoding, athough the periods of the bits are stretched out (in normal NEC encoding, 0 is a cycle of equal size, 1 is a cycle that is low twice as long as it is high. In this case, 0 is marked by a cycle that is low twice as much as it is high and 1 is marked by a cycle that is low four times as much as it is high. Note that the graph above has 1 and 0 inverted, a feature of the IR receiver.) The main point is that if you look at the graph, there are some waveforms that are squished together, and those are zeros. The ones that are spaced out at ones.

Assuming this, it is easy enough to write a Python script that extracts the bytes of the request, which are:

ac 00 26 d6 0e 01 0e 01 00 01 33 87 00 00 33 c0 0b 00 00 ff 01 ff ff 7d

Looking at this, there are bytes in the same pattern as my Tamagotchi's name (Nana):

ac 00 26 d6 0e 01 0e 01 00 01 33 87 00 00 33 c0 0b 00 00 ff 01 ff ff 7d`

Note that 0x0e = 14 and 'N' is the fourteenth letter of the alphabet. So 1, 14, 1, 14 could represent the name Nana.

Update

Trying this with a Tamagotchi named Anna gives the following output:

ac 00 39 d6 01 0e 0e 01 00 00 34 87 00 00 20 80 8 00

so this is almost certainly the case.

The following parts were used:

Basic Setup

The menu Tools --> Board --> Arduino Deumilanove w/ ATmega328 was selected. The menu Tools --> Serial Post --> (appropriate port) was selected. Note the port needs to be selected each time a different Arduino is connected to USB. One automatically binds to COM3 and the other to COM4; there is most likely a setting somewhere to have these on the same COM port, but that would later preclude connecting both at the same time.

Testing the XBee

The shield and wireless module were assembled onto the Arduino. The jumpers on the XBee shield were put into the outward position. The Arduino was plugged into USB. The following sketch was uploaded:

Sketch: XBee_diagnostics

void setup()
{
    Serial.begin(9600);
}

void loop()
{
    Serial.println("+++");
    delay(2000);
    echo();
    Serial.println("ATID");
    echo();
}

void echo() {
    byte incomingByte;

    // see if there's incoming serial data:
    delay(50);
    while (Serial.available() > 0) {
        // read the oldest byte in the serial buffer:
        incomingByte = Serial.read();
        Serial.write(incomingByte);
        if(incomingByte != '\r') {
            Serial.write(' ');
        }
        delay(100);
    }
}

The Arduino was unplugged from USB, the jumpers switched to the inward position, then the serial monitor activated. The XBee should be responding with 234 as the ID (for Series 2).

Configuring

Use X-CTU to configure. Alternatively, any serial terminal will do. Note that the ATmega328 must be removed and the XBee shield pins placed in the outward position for this to work.

It may be preferred to configure the XBee module as part of a sketch and avoid removing the processor or finding a terminal program. The diagnostic sketch may be modified to with the following:

void loop()
{
    delay(2000);
    Serial.println("+++");
    delay(2000);
    echo();
    Serial.println("ATDL FFFF");
    echo();
    Serial.println("ATWR");
    echo();
    delay(10000);
}

After configuring, the Arduino was unplugged fro USB.

Transmitter

The jumpers on the XBee shield were put into the outward position. The Arduino was plugged into USB. The following sketch was uploaded:

Sketch: Send_physical_pixel

const int ledPin = 13;

void setup()
{
    Serial.begin(9600);
    pinMode(ledPin, OUTPUT);
}

void loop()
{
    digitalWrite(ledPin, HIGH);
    Serial.print('H');
    delay(1000);

    digitalWrite(ledPin, LOW);
    Serial.print('L');
    delay(1000);
}

The Arduino was unplugged from USB, the jumpers switched to the inward position. Then the Arduino was plugged into USB and the serial monitor activated. The serial monitor showed a string of HLHL… The LED was flashing at 0.5 Hz.

The Arduino was unplugged from USB, and the plugged this into the power adapter. The LED continued to flash at 0.5 Hz.

Receiver

Now for the second Arduino with XBee shield. The jumpers on the XBee shield were put into the outward position. The Arduino was plugged into USB and the following sketch Sketchbook --> Examples --> Communication --> PhysicalPixel was uploaded (unchanged).

The LED on the receiver is observed going on and off. However, not at regular 1 second intervals – the XBee sometimes groups the H and L sends together so these will be read at irregular intervals.

More Details

Note if you are in an area with ore XBee modules, then more configuration will be required to prevent all pairs from interfering with others.

Jumper meanings

When loading the Arduino while the XBee shield is attached, ensure the pins are in the USB position. Here’s a table of the explanation of jumper settings: