Reverse engineering android applications (part 1)

I’ve been getting irritated by the number of android applications that want access to everything on my phone despite the function I want to use not really requiring it. I figure it’s time to take these applications apart and figure out what the reason for this problem is.

I figure in most cases the likelihood isn’t that the app wants to do evil, but instead it’s something else that’s causing the need for all the extra permissions. The problem is that there is no way to tell by simply looking at the permissions required because they want to do so much. When you look at a a word search game you have to wonder why it wants to use GPS, wireless and internet.

There appear to be two main schools of android reverse engineering. One is to unzip the .apk and then decode the .dex file into the raw instructions. An alternative is to turn the .dex into a more regular .jar with .class files and then feed it to a java decompiler. See dex2jar and Java Decompiler for that approach.  The first approach is taken by baksmali which is a disassembler for the dex files to essentially an assembly like version of the byte code with annotations.

The de-compiler approach produces much more easier to understand output for most code and at worst essentially produces assembly like output like baksmali for code it can’t de-compile properly.