In my paper, I have detailed a simple but dangerous exploit of the Android framework that allows arbitrary applications to spoof sensitive activities of other applications in order to collect private data without user’s knowledge.  This can be accomplished because of an inability to tell what app a given activity belongs to.   Without this information, there is no way of knowing if the foreground activity is the same activity that was expected to be displayed when the app was launched.  I have demonstrated a simple method for constructing spoof activities and integrating them into stand alone or existing code.  The danger of this exploit lies in the simplicity of engineering a spoofed activity for any service that provides a native app for Android, and the ease of collecting the harvested data from user devices.  Future work includes implementing a practical defense to this class of attacks, and doing comprehensive case studies to further demonstrate the need to fix this exploit.

So, when I stopped my research at the end of week five (weeks six and seven were completed right before school started), my idea that I had worked on for the entire summer had been recently published by a group at another university.  I had begun to look for another idea that I could bring to completion in two weeks, but I hadn’t found much.  Exploits in security are somewhat unpredictable, it can take two minutes or two years to find one.  Whether it was luck or something else however, I came up with something that I thought might just work.  By connecting a few dots, I realized that I might have a real exploit on my hands.  The bad news that came with this discovery was that it had very little to nothing to do with my previous topic, and I would basically have to start over on the code I had written.  However, I spent a fair amount of time at the beginning of my research reading other works and building some background knowledge.  It was this that gave me the ability to quickly code up the new exploit with minimum delay.

I had an idea, two weeks, and some idea of where to start the code.  What I didn’t have was a guarantee that this idea would even be feasible.  However, I really didn’t have any other options, so I took my chances and devoted my full time to fleshing out my idea.  After stumbling over a few roadblocks, I began to see that my idea was indeed working, in some ways better than I had expected.  I also saw about 15 different ways that I could make it even better, but I knew I didn’t have time for most of them.  That’s not a problem, since I knew if I delivered on this project, I would have the opportunity to continue to work on it once the school year started.  So, I kept going on what I had, and finished the code during the hurricane (the threat of losing power was a good motivator).  Now, I’m rushing to finish the paper in time for the deadline, and setting up a schedule to improve upon my initial results with my advisor.  It was a bit crazy at times, but the seven weeks I spend on this project were seven weeks well spent.

After my first couple weeks of reading, I was more than ready to jump in and start coding.  A couple papers that I had read about two different topics gave me a pretty good idea of what I wanted to start working on.  I won’t go into too many details, but by basic goal for the summer was to find a security flaw in the Android operating system, exploit it, and then write about it.  So, I began to look for a way to apply the two ideas I had found from the previously mentioned articles.  Some careful reading and a lot of thinking later, and I saw a loophole that could be used to re-apply a proven technique in an improved way.

Now, it’s a long way from conceptualizing a flaw to writing the code that actively exploits it.  My first step was to write some code that did something harmless, but would function as the basis for my exploit.  This would serve two purposes, the first being to familiarize myself with the Android API, and secondly to get me some information that I needed for the exploit.  As it is with any new domain, the first 100 lines of code took much longer than the next 500.  By the middle of week 4, I had most of the information I needed to move on, when I hit a snag.  I realized that in order to execute the second part of my idea, I would need the source code to some popular applications.

Many apps for Android are available online, source code and all.  However, some aren’t, and the ones I needed the source code for weren’t.  As it turns out, there are some tools available to recover the source code from the app itself (a task not normally possible without complex tools like these).  So, I evaluated the time I had left (less than week at this point, then I would be stopping research for a month to get married and move, picking up the last two weeks before school started), and decided I would continue on, narrowing my focus a bit, and work on getting one strong application of my exploit.  Then trouble came.  In browsing for some prior articles, I stumbled upon a paper that was going to be presented in early August…about the exact same topic I had just spent over half of my summer research on.  Not only had they worked on the same topic, but being a group of two professors and a handful of grad students at one of the nation’s top computer science graduate programs, the paper was <em>slightly</em> more thorough than mine was (and more rigorous, better organized, explained, had more breadth and depth, etc.).

I was at a loss for what to do, and this led to the rest of my last week before taking a break to be a bit unproductive.  I began searching for a new idea, but I wasn’t coming up with much.  It seemed like a lost cause at the time.  After all, I had roughly two weeks to do what I hadn’t finished in five.  The rest of the story will be in my final post, but the background knowledge that I had built up in the first couple weeks ended up saving me in the last two.