The Australian Government and Tesltra sponsored the 2014 Cyber Security Challenge Australia competition.  They posted the virtual machine, which hosts most of the challenges, here.  I followed the setup instructions for VirtualBox.  This is another short writeup, that will use the memory forensics tool, Volatility, to recover data from an Android memory dump.

Lab setup:

Volatility is a Python tool that analyzes RAM dumps from 32 and 63 bit windows, linux, mac, and android systems.  –https://code.google.com/p/volatility/wiki/VolatilityIntroduction 

It comes preloaded on Kali Linux, so if you already have it, you can skip to step 2.  Volatility requires a some additional setup for what we want to do, the screencap below summarizes the setup, but I will go more in depth:

1
((Found in “x.x.x.x/release/challenges.html”))

  1. Download Volatility using ‘svn checkout http://volatility.googlecode.com/svn/trunk/ volatility-read-only’
  2. Download and unzip the file, 99de51b8da4623ddc2fcc18b9063f81e.7z, it is found under the Android Forensics category in the Challenges page of the VM.  It should create a file, ‘memory.dmp’, when unzipped.  This is the memory dump of the Android device:
      1. Run: ‘7z x 99de51b8da4623ddc2fcc18b9063f81e.7z’
  3. Download the archive, goldfish-2.6.29.zip, it is also located in the same location as the .7z file above. This is the “profile” to use with Volatility.  Volatility requires a different profile depending on what operating system/architecture is being analyzed.  Copy the zipped archive into the the list of available linux profiles for Volatility:
      1. Run: ‘cp goldfish-2.6.29.zip ~/volatility-read-only/volatility/plugins/overlays/linux/’
  4. Download and unzip the file, system_framework.7z:
      1. Run: ‘7z x system_framework.7z’

Depending on where you extracted the above files, the workspace should look similar to this (yellow = extracted files):

2

3

To see the help menu for Volatility, cd into volatility-read-only and run the vol.py script with the -h argument (“python vol.py -h”).

To list your available Linux profiles, you can run: ‘python vol.py –info | grep Linux’.  Note that the new profile is now available:

4

Everything should be good to go now.  See the Volatility Introduction for more help.  The challenge is described below:

5

 

Inspecting the Memory Dump:

Now that Volatility is setup, we can run some of its plugins on the memory dump.  You can get the description of the available plugins by running ‘python vol.py –info | grep -i linux_’

Some of the interesting plugins that I used were: linux_pslist

‘python vol.py -f ~/memory.dmp –profile=Linuxgoldfish-2_6_29ARM linux_pslist’ gives a list of all process pids and uids.

7

One of the suspicious processes is 1185 (org.jtb.httpmon).  Its uid is 10061. Using this uid, we can see what other resources are being generated from PID 1185.  Using the linux_pstree module, we can get a more organized view:

6

 

Most of this stuff seems ok, except for the bash shell (PID 1255). What files is the process touching?  Take a look at the linux_lsof -p 1185 plugin to list all files that the process has opened.   Some of the interesting files are below:

8

 

I used another forensics tool, Autopsy, to search for some keywords in the memory.dmp file, and discovered that org.jtb.httpmon was attempting to create an asynchronous socket and connect to some remote server.  Autopsy comes preloaded on Kali Linux:

9Capture

This is enough evidence to warrant a deeper look at the application.

Extracting and reversing the application:

After some research, I found the plugin, linux_find_file can be used to extract file contents from memory.  This means, that since we know where the apk is located (above, we found that it was in /data/data/), we can extract it and do some static analysis.  The extraction can be seen below, I first found the Inode number for the .apk file, and extracted it based on that:

apkextracted

 

For decompiling, we just need to unzip the .apk file (since .apk files are just archives), extract the classes.dex, convert it to a jar file, then read the code using jd-gui.  These steps are below:

11
(unzip and extract to httpmon_out directory)

12
(convert classes.dex to jar, dex2jar is built into Kali Linux)

13
(jd-gui is available here, we can use it to get a decent decompile of the jar file)

There are quite a few classes to look at.  Below is my evidence for and against the application being malicious.

Evidence for:

A BroadcastReceiver is being used to listen for the device to boot up (see BootReceiver.java).  This allows the app to start whenever the phone is booted up.  This is not something you would want an application to do.  The application also establishes a BroadcastReceiver for SMS messages (sent and delivered).  The manifest file also contains the following permission requests:

  • BOOT_COMPLETED
  • INTERNET
  • WAKE_LOCK
  • VIBRATE
  • RECEIVE_BOOT_COMPLETED
  • READ_LOGS
  • ACCESS_NETWORK_STATE

Evidence against:

The first thing that I noticed was the abundance of logcat entries.  The logcat entries are used by the application developer to send output to the console (a way for them to print to the console).  This would be unusual for malware, because it would leave a trail of output that leads back to the application.

Conclusion:

I would have to conclude that the application is only suspicious.  The decompiled code doesn’t seem to be obfuscated or trying to hide what it is doing.  But there is a bit of networking being done along side with some suspicious permissions.  I confirmed that this application is indeed the suspicious application that is requested to be identified in the challenge.

 

Notes:

Plugins for Volatility – https://code.google.com/p/volatility/wiki/LinuxCommandReference23
Presentation on Android Memory Forensics – http://www.ucd.ie/cci/cync/Acquisition%20and%20Analysis%20of%20Android%20Memory.pdf
Manual decompiling APKs – https://stackoverflow.com/questions/1249973/decompiling-dex-into-java-sourcecode