Android Application Assessment
In this article we’ll discuss about steps involved in performing security assessment of an Android based application. We will see use of various tools and methodologies. There are various other
methods and tools but steps are very common in nature.
There are various tools/ methods to do this kind of assessments. We shall discuss the general and popular approach. Our assessment revolves around the following two methodologies:
• Black Box approach
• White Box approach
First we need to set up the test bed for which we need to download the Andriod SDK. Download
the Android SDK tool from http://developer.android. com/sdk/index.html. It includes SDK and
AVD (Android Virtual Device). They are necessary for creating the VM and installing emulator.
Setting up the AVD and emulator is out of scope for this article but it’s very easy, once you follow the
above link. Once the AVD is setup it appears as in the following Figure 1. We have named our AVD
as ‘Security’ as you can see in the Figure 1. Once launce we can start the emulator which will act as
a virtual Andriod device, on which we can install our various applications to test. Click on ‘Start’ to
launch the emulator, which appears shortly Figure 2.
Once, emulator started, install the android app’s .apk file on it.
Go to <path-to-andriod installation>/tools, run the command: adb install <path-to-.apk file>.
In some latest AVDs the adb tool has moved to platform-tools/. If you don’t see this directory in
your SDK, launch the SDK and AVD Manager (execute the android tool) and install “Android SDK
Platform-tools”.
Once the above command runs successfully, you can see our installed application on the emulator
Figure 3.
Black Box Approach
This approach deals with doing penetration testing of the app without actually knowing the internal
structure of the app. We may capture the communication between the client and server and edit and modify it observe the server’s response.
Once the app is installed, we are ready to capture the traffic using our regular web proxies such as Burp/ Paros. This is applicable to the clients which use browser based communication.
For native apps we can use other approach like, ITR etc.
Configure local web proxies, eg Burp, Paros to intercept the traffic by modifying the Internet setting
in Android by clicking on Settings->Wireless & Network Settings-> Mobile Networks -> Access
Point Names-> Proxy Name (PC’s IP address) & Port (Figure 4). The communication of our sample
application SecureBank, which communicates over HTTP can be captured using a web proxy
such as Paros or Burp (Figure 5). Here onwards we can perform the assessment as we do for normal
web application.
White Box Approach
This is useful in the cases, where you can’t capture the traffic, such as native application, which
don’t communicate over HTTP. Also, decompiling the app into source code gives you more insight into the configuration related issues. It involves decompiling the application to get the source code
and configuration files.
Methods to decompile the app into source code:
• Change the .apk file into .zip file
• Extract the zipped file
• You can see the classe.dex file along with other files (Figure 6)
• Now the classes.dex file (Android files are in dex format, which is Dalvik Executable), can
be converted to JAR files using a tool called dex2jar (http://code.google.com/p/dex2jar/).
Run the command as dex2jar classes.dex, which converts the classes.dex to classes.dex.
dex2jar.jar (Figure 7).
• Now use any Java Decompiler such as JD (http://java.decompiler.free.fr/?q=jdgui) to open
the JAR file [Figure-8]. Now you can review the Java Source Code. Also, you can save the
source files as File> Save All Sources
Reviewing the AndroidManifest file for Permissions
The AndroidManifest.xml resides into the same folder where classes.dex is available. The XML file
can’t be read directly as it is in binary format. You need to convert the xml file into a readable text file using a tool called AXMLPrinter2.jar:
java -jar AXMLPrinter2.jar AndroidManifest.xml>
AndroidManifest.txt
Now the AndroidManifest.txt file can be reviewed for various permissions and settings (Figure 9).
Go to http://developer.android.com/guide/topics/ manifest/manifest-intro.html for info on reviewing
permissions contained in AndroidManifest.xml file. Carefully review the permissions which the
application is requesting and other permissions which this application is granting to other applications
on the Android device. Also, see the intentfilter tag, which specifies the types of intents that
an activity, service, or broadcast receiver can respond to. There are many other settings and depends
on application to application.
Android app sign check
To check if the application is signed or not you may use a java tool, found in the bin directory of Java
installation, called jarsigner:
jarsigner -verify TargetApp.apk
If the .apk is signed properly, Jarsigner prints “jar verified”.
A more detailed command will give you more information about the components signed (Figure 10).
jarsigner -verify -verbose -certs TargetApp.apk>details.txt
To see the information about the certificate used to sign, such as issuer, validity, algorithms etc
(Figure-11), run the following command against the certificate. The certificate can be found under
‘Meta-INF’ file, see Figure 7.
keytool -printcert -file MyCert.cer > CertDetails.txt
Apart from all these methods, few others also exist, such as using some android based tools- adb
etc. All these will be covered in next issue of the article.
In this article we’ll discuss about steps involved in performing security assessment of an Android based application. We will see use of various tools and methodologies. There are various other
methods and tools but steps are very common in nature.
There are various tools/ methods to do this kind of assessments. We shall discuss the general and popular approach. Our assessment revolves around the following two methodologies:
• Black Box approach
• White Box approach
First we need to set up the test bed for which we need to download the Andriod SDK. Download
the Android SDK tool from http://developer.android. com/sdk/index.html. It includes SDK and
AVD (Android Virtual Device). They are necessary for creating the VM and installing emulator.
Setting up the AVD and emulator is out of scope for this article but it’s very easy, once you follow the
above link. Once the AVD is setup it appears as in the following Figure 1. We have named our AVD
as ‘Security’ as you can see in the Figure 1. Once launce we can start the emulator which will act as
a virtual Andriod device, on which we can install our various applications to test. Click on ‘Start’ to
launch the emulator, which appears shortly Figure 2.
Once, emulator started, install the android app’s .apk file on it.
Go to <path-to-andriod installation>/tools, run the command: adb install <path-to-.apk file>.
In some latest AVDs the adb tool has moved to platform-tools/. If you don’t see this directory in
your SDK, launch the SDK and AVD Manager (execute the android tool) and install “Android SDK
Platform-tools”.
Once the above command runs successfully, you can see our installed application on the emulator
Figure 3.
Black Box Approach
This approach deals with doing penetration testing of the app without actually knowing the internal
structure of the app. We may capture the communication between the client and server and edit and modify it observe the server’s response.
Once the app is installed, we are ready to capture the traffic using our regular web proxies such as Burp/ Paros. This is applicable to the clients which use browser based communication.
For native apps we can use other approach like, ITR etc.
Configure local web proxies, eg Burp, Paros to intercept the traffic by modifying the Internet setting
in Android by clicking on Settings->Wireless & Network Settings-> Mobile Networks -> Access
Point Names-> Proxy Name (PC’s IP address) & Port (Figure 4). The communication of our sample
application SecureBank, which communicates over HTTP can be captured using a web proxy
such as Paros or Burp (Figure 5). Here onwards we can perform the assessment as we do for normal
web application.
White Box Approach
This is useful in the cases, where you can’t capture the traffic, such as native application, which
don’t communicate over HTTP. Also, decompiling the app into source code gives you more insight into the configuration related issues. It involves decompiling the application to get the source code
and configuration files.
Methods to decompile the app into source code:
• Change the .apk file into .zip file
• Extract the zipped file
• You can see the classe.dex file along with other files (Figure 6)
• Now the classes.dex file (Android files are in dex format, which is Dalvik Executable), can
be converted to JAR files using a tool called dex2jar (http://code.google.com/p/dex2jar/).
Run the command as dex2jar classes.dex, which converts the classes.dex to classes.dex.
dex2jar.jar (Figure 7).
• Now use any Java Decompiler such as JD (http://java.decompiler.free.fr/?q=jdgui) to open
the JAR file [Figure-8]. Now you can review the Java Source Code. Also, you can save the
source files as File> Save All Sources
Reviewing the AndroidManifest file for Permissions
The AndroidManifest.xml resides into the same folder where classes.dex is available. The XML file
can’t be read directly as it is in binary format. You need to convert the xml file into a readable text file using a tool called AXMLPrinter2.jar:
java -jar AXMLPrinter2.jar AndroidManifest.xml>
AndroidManifest.txt
Now the AndroidManifest.txt file can be reviewed for various permissions and settings (Figure 9).
Go to http://developer.android.com/guide/topics/ manifest/manifest-intro.html for info on reviewing
permissions contained in AndroidManifest.xml file. Carefully review the permissions which the
application is requesting and other permissions which this application is granting to other applications
on the Android device. Also, see the intentfilter tag, which specifies the types of intents that
an activity, service, or broadcast receiver can respond to. There are many other settings and depends
on application to application.
Android app sign check
To check if the application is signed or not you may use a java tool, found in the bin directory of Java
installation, called jarsigner:
jarsigner -verify TargetApp.apk
If the .apk is signed properly, Jarsigner prints “jar verified”.
A more detailed command will give you more information about the components signed (Figure 10).
jarsigner -verify -verbose -certs TargetApp.apk>details.txt
To see the information about the certificate used to sign, such as issuer, validity, algorithms etc
(Figure-11), run the following command against the certificate. The certificate can be found under
‘Meta-INF’ file, see Figure 7.
keytool -printcert -file MyCert.cer > CertDetails.txt
Apart from all these methods, few others also exist, such as using some android based tools- adb
etc. All these will be covered in next issue of the article.