CopperDroid Logan Horton

Android - Background Android is complicated to analyse due to having 2 places to check for code execution Normally, code is written in Java and executed through the Dalvik virtual machine but some native code execution is possible through the Java Native Interface (JNI) Android utilises inter-process communications (IPC) and remote procedure calls (RPC) which are high-level Android specific semantics - this makes it difficult to reconstruct through system call analysis

Android Issues - the CopperDroid solution All interesting Android application behaviour is characterized by system calls and their parameters Sending a message through the system is done through the Binder using the ioctl system call invoked on the Binder driver, /dev/binder These ioctl calls contain a buffer of marshalled data (the parameters for the call) and the code of the call (numeric representation of the method that is called)

Binder

CopperDroid - What is it? A testing platform to check for malware using an emulator built on QEMU Performs Virtual Machine based dynamic analysis to reconstruct malware behaviour Consists of 2 parts; the emulator component and the analysis component The emulator runs the Android system and the analysis component analyses the emulators gathered data

CopperDroid specifics CopperDroid is not a tool run on something, it is an emulator system that you run and test applications on It is built on the QEMU emulator (an open source processor emulator) which is modified to allow for system calls to be tracked. This is achieved through Virtual Machine Introspection (VMI) Utilises a regular “vanilla” Android emulator for the unmarshalling Oracle The analyses are completed on the machine running the emulator, outside the CopperDroid emulator

CopperDroid The CopperDroid emulator runs the Android system, with unmarshalling of the Binder data done through the Oracle Binder data is the ioctl information from before; the parameters given to the Binder and the numeric representation of the call made to the Binder

CopperDroid - Unmarshalling Oracle The Oracle is the unique part of CopperDroid The unmarshalling part is the deconstruction of the parameters and numeric instruction code into a readable string This string is then reviewable to see what behaviour is being performed There are 3 possible data types that the Oracle can receive: - Primitive (e.g. String) - Class Object - IBinder Object

Oracle - Primitive Primitive data is simple to break down The primitive types are broken down using the corresponding read function provided by the Parcel class. Parcel’s are containers for messages passed through the Binder, both flattened data to be unflattened later or references to live Binder objects For Strings, this would be the readString() method

Oracle - Class Objects To unmarshall class instances, Oracle uses Java reflection. This allows dynamic retrieval of field CREATOR, implementing the Parcelable interface Objects must have a CREATOR field to be able to be written/read from a Parcel Once this is setup, the Oracle begins reading from the class using the createFromParcel() method to unmarshall and read its data Once the type has been unmarshalled, the Oracle creates the string representation using the toString() method which is appended to an output string list and moves onto the next item to be unmarshalled

Oracle - IBinder Objects Some Binder objects are not marshalled, instead a reference is sent When this occurs, if its not primitive, the Oracle verifies if it contains a binder reference object. Here, you parse the first four bytes of the marshalled object looking for reference types Normally, Binder references keep objects from being freed, stopping the extraction of the data from the system. To circumvent this, the CopperDroid emulator keeps references to items created in shared memory and allows retrieval of them as needed for the Oracle

Recap Android is complicated to analyse so CopperDroid uses the ioctl calls to reconstruct the behaviour through the Oracle and analyses that externally to the CopperDroid emulators (sometimes manually) CopperDroid uses 2 emulators; an emulator to run the Android system and an emulator to run the Oracle which breaks down the Binder data to readable information The analyses are done outside the CopperDroid system, run on the machine the emulators are run on

CopperDroid - Success and aims CopperDroid was run on 2900 samples in 3 different sets to test its reliability/success rate in detecting malware CopperDroid detected additional behaviours at a minimum of 60% for the samples with the highest being 73% for one of the sets CopperDroid is not a complete package. The creators make this known through their report in multiple places mentioning this project shows “that a simple, external, stimulation contributes to the discovery of additional behaviors “

Comments and criticism ❖It does analyse malware and does it in a controlled environment which is very preferable. The downside is it is still on an emulator which some types of malware are able to detect this causing issues ❖There is an overhead of 25% compared to regular android running meaning a lot of processing power used to test one application ❖One major upside is that it is not affected by Android version changes. The emulators run will still detect the ioctl calls regardless of Android version (until the baseline behaviour is changed from this) which means it will work on any version. It has been tested on Froyo, Gingerbread, Jelly Bean, KitKat, and Lollipop without issues

Comments and criticism ❖Some unmarshalling must be done manually. Unfortunately, some Bound services such as the ActivityManager do not use AIDL (Android Interface Definition Language) and as such cannot be unmarshalled automatically. This means a person is required to watch over the running of each application on CopperDroid as it could get stuck waiting on manual intervention ❖No static analysis. CopperDroid only uses dynamic analysis, analysis done during runtime of the application to see what it does. This can mean code not always run will get by that would be detected by static analysis so adding another tool to CopperDroid that checks the code would be preferable

Final Remarks The team behind CopperDroid did not set out to create the ultimate malware detection tool, they were mainly wanting to create a tool that did “system-call analysis” to detect malware behaviour This was wanted through an automatic VMI-based dynamic analysis system which would reconstruct the behaviours of Android applications which was achieved to a point All in all, it is good as a tool to try detect behaviour, would be helpful for Android testing such as the Bouncer setup but it does need manual intervention in its current state, does need some static analysis added to it for ease-of-mind and other tools to be run alongside it for effectiveness