Week 12: Android Battery Data

At the beginning of this week, I continued working on the Android development training. I learned about switching between Activities by using Intents, the lifecycle of an Activity, navigating between different XML pages, and dynamically generating UI elements. I began working on collecting sources of entropy with Adam. We plan on eventually combining the data collection code into a unified app, but for right now, I am working on getting battery specifications and status as well as process statistics from the OS such as how many processes are currently running, how much memory each process is using, the network bandwidth of each process, and other system information.

I started out researching a way to get battery information from the Android environment. The android.os API provides the BatteryManager class, which contains several string constants such as EXTRA_TEMPERATURE, EXTRA_VOLTAGE, EXTRA_LEVEL, and EXTRA_STATUS. When I tried to display those constants in TextViews directly, however, they all came up as either 0s or nulls. I did a little more research and discovered that these constants can only be accessed through a BroadcastReceiver. The receiver is registered using this function call:

this.registerReceiver(this.mBatInfoReceiver,

                new IntentFilter(Intent.ACTION_BATTERY_CHANGED));

This registers mBatInfoReceiver, which is declared as follows:

private BroadcastReceiver mBatInfoReceiver = new BroadcastReceiver(){

        @Override

        public void onReceive(Context arg0, Intent intent) {

          temp = intent.getIntExtra(BatteryManager.EXTRA_TEMPERATURE, 0);

          volt = intent.getIntExtra(BatteryManager.EXTRA_VOLTAGE, 0);

          tech = intent.getStringExtra(BatteryManager.EXTRA_TECHNOLOGY);

          stat = intent.getIntExtra(BatteryManager.EXTRA_STATUS, 0);

          level = intent.getIntExtra(BatteryManager.EXTRA_LEVEL, 0);

          scale = intent.getIntExtra(BatteryManager.EXTRA_SCALE, 0);

        }

      };

So that each of the variables assigned in onReceive() is updated whenever the Android system triggers the ACTION_BATTERY_CHANGED intent. All I needed to do once these variables were updated was format some of them (temperature is given in tenths of a degree Celcius and voltage is given in millivolts). This code worked quite nicely, giving me all of the battery information that can be updated in real time by the press of a button. The next step for this unified app will be for me to start working on system process data collection.

Week 11: Getting Started with Android

The first thing I worked on this week was collecting TCP network packet arrival times. Fortunately, the tcpdump command line tool has an extensive list of features that makes it very easy to obtain information on network traffic. It dumps the originating IP, the target IP, the packet size, and other bookkeeping information. If the –tt option is used, the timestamp of the packet with microsecond granularity is recorded as well. Therefore, the command:

sudo tcpdump -nntt | awk '{print $1}' > packets.txt

logs the timestamps of packet arrivals in packets.txt continuously until it is interrupted by the SIGINT or SIGTERM signals. Alternately, the –c 100 option can be appended to print the first 100 packet timestamps and then terminate.

For the rest of the week, I worked on getting up to speed on Android development to work with Adam on identifying sources of entropy and collecting random data from the mobile platform. There is a hefty amount of work to set up the development environment. Once I was finished downloading the Android SDK, the ADT plugin for Eclipse, the latest SDK tools, and the AVD (an emulator for debugging apps), I was ready to start learning about project organization, user interface principles, event listeners, Android Activities and Intents, and a whole list of other basic Android development concepts. Hopefully with a week of preparation, I will at least be able to do some basic tasks on the platform. Fortunately, the Android developer’s site is very well documented, making research for specialized projects easy.

Week 10: Wrapping up the Mouse Logger

I started off this week by trying to investigate device event files in a new Linux virtual machine I obtained. My startup engineering class provided me with an Amazon EC2 remote instance of Ubuntu LTS 12.04 which was intended to be used as a homogenous development environment. Unfortunately, I ran into the same problem as the virtual machine on the Macbook Pro where mouse event information was not being routed properly to the files due to the virtualized interface.

I then went on to research available libraries that abstract away the lower-level details of getting mouse event data. I had already used the Python binding evdev last week but I was unable to find any way to register mouse clicks with that extension. When I did a little more digging, I found that the preferred library for interfacing with any external device is Xlib. However, I quickly discovered that the library is tedious, outdated, and very poorly documented. For example, the only way to obtain the resolution of the screen is:

width = Display().screen().root.query_pointer().root_x

height = Display().screen().root.query_pointer().root_y

Fortunately, I was able to find a Python library called PyUserInput that abstracts away the complexity of Xlib. I created a class ClickRecorder that inherits PyMouseEvent. This way, I could change the code for the click() and move() functions so they would call WriteInfoLine(), a function I wrote that appends a line containing the timestamp, delta since last move or click, and x and y coordinates to the log file. The function ended up looking like this:

def writeInfoLine(x, y, isClick):

    global MIN_DELTA, lastClick, lastX, lastY, lastMove

    currTime = time.time()

    line = str(currTime) + " (delta "

    if isClick:

        delta = currTime - lastClick

        line += str(delta) + "):\t"

        line += "[" + str(x) + "," + str(y) + "] click\n"

        f.write(line)

        lastClick = currTime

    else:

        delta = currTime - lastMove

        if delta < MIN_DELTA:

            return

        if x == lastX and y == lastY:

            return

       

        line += str(delta) + "):\t"

        line += "[" + str(x) + "," + str(y) + "]\n"

        f.write(line)

        lastX = x

        lastY = y

        lastMove = currTime

I set MIN_DELTA to 0.25 so that mouse movements that are within 250 milliseconds of each other do not get recorded. To finish up my program, I wrapped the import statement for PyUserInput in a try clause that would run a setup.sh script and install the module if an ImportError is caught. With this program completed, we finally have a fully functional robust application for logging mouse events, and the log file formatting will make it easy to extract certain parameters for entropy.

Week 9: Java and Fireworks

For this shortened Fourth of July week, I turned to Java to develop a program capable of logging mouse events. One advantage of using Java is that it is intrinsically platform-independent since each Java application is compiled into bytecode that is then executed in the Java Runtime Environment. I used the java.awt.MouseInfo class to sample the x and y coordinates of the mouse ten times per second. If the position of the mouse has not changed since the last sample, it is not logged again. The code ended up looking like this:

while(true){

            Point mousePt = MouseInfo.getPointerInfo().getLocation();

            mouseX = Math.max(0, mousePt.x);

            mouseY = Math.max(0, mousePt.y);

            if (mouseX != prevX || mouseY != prevY){

                unixTime = System.currentTimeMillis();

                delta = unixTime - prevTime;

                String content = unixTime + " " + delta +

                    " [" + mouseX + "," + mouseY + "]\n";

                writeToFile(filename, content);

            }

            try { Thread.sleep(100); }

            catch (InterruptedException exception){

                exception.printStackTrace();

                throw exception;

            }

            prevX = mouseX;

            prevY = mouseY;

            prevTime = unixTime;

}

The log file I create also includes the timestamp with millisecond granularity as well as the delta since the last different pair of x and y coordinates. This program should work for all three of the platforms we have targeted for this project.

Week 8: Mouse Event Logging

The first thing I did this week was research Linux keyloggers. While there are many online, there are few open source solutions that offer the flexibility required for our project. In fact, I only found one source that provides a timestamp for each individual key pressed. I changed the script to store the data in a local log file that can be parsed later on.

For the rest of the week, I did a lot of research on Linux device event files in order to work on capturing mouse events. Unfortunately, the protocol for this OS service varies wildly depending on the Linux distro in question and I was unable to find a truly reliable source for working with the Ubuntu VM. I also refrained from investigating rootkits because I did not want to put my personal machine at risk. So far, my understanding is that a new input_event struct is written to the event file every time the given hardware device has a new event to report. The struct has the following format:

struct input_event {

struct timeval time;

__u16 type;

__u16 code;

__s32 value;

};

However, when I use programs that try to exploit this data formatting, the only field that ever changes is the timeval struct while the type, code, and value remain constant. The best option I could find for logging mouse events was the python bindings for evdev. Using this package to read /dev/input/event3, the mouse event file for Ubuntu 12.04 LTS, I am able to record mouse clicks with extremely precise timestamps. None of the deltas get recorded and the coordinates of the mouse when it is clicked are not logged either.