GSoC 2016

[honeynet]

GSoC 2016

[yuanchun-li]

Progress on 0. Testing up to 10 Apps:

I tested DroidBox4.1.1 with 10 apps from DroidBench test suite, and found that DroidBox4.1.1 is able to detect the data leakages correctly.
However DroidBench is not enough for demonstrating the effectiveness of DroidBox, because:

1. Data leakage is just one of the sensitive behaviors monitored by DroidBox, and there are many other behaviors should be tested (such as cryptousage, servicestart etc.).
2. DroidBench uses the device IMEI as the source and sending SMS as the sink, thus many other forms of sources and sinks are not tested. For example, location data as source and sending to internet as sink.

[yuanchun-li]

About 7 Anti-Sandbox-Detection Techniques

I found a paper about Sandbox Detection techniques.
https://users.ece.cmu.edu/~tvidas/papers/ASIACCS14.pdf

[yuanchun-li]

Progress on 1. Remove False LogMessages:

DroidBox log contains the pid, for example:
W/dalvikvm( 150): DroidBox: { "FdAccess": { "path": "706970653a5b343833345d", "id": "1529432564" } }
means the log is produced by process with pid 150.

We can connect the pid with app using Linux ps command.
If we maintain a pid-app mapping at runtime, we will be able to connect each log message to the corresponding app.

[yuanchun-li]

Finished: 1. Remove False LogMessages:

DroidBot can connect DroidBox log messages to corresponding process names now!
For example,
A sensitive behavior produced by the target app has the package name in its process field:

        {
            "detail": {
                "data": "3c3f786d6c2076657273696f6e3d27312e302720656e636f64696e673d277574662d3827207374616e64616c6f6e653d2779657327203f3e0a3c6d61703e0a3c737472696e67206e616d653d22696e6974223e623d333537323432303433323337353131", 
                "id": "1790189246", 
                "operation": "write", 
                "path": "/data/data/com.gnom.anton/shared_prefs/trom.xml", 
                "sink": "File", 
                "tag": [
                    "TAINT_PHONE_NUMBER", 
                    "TAINT_IMEI"
                ]
            }, 
            "process": "/init->zygote->com.gnom.anton", 
            "time": 7.67, 
            "type": "DataLeak"
        }, 

The following log is produced by system, not by the target app:

        {
            "detail": {
                "data": "636f6d2e676e6f6d2e616e746f6e3a7a707274000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000676e6f6d2e616e746f6e2e53686f72740076697479330000", 
                "id": "1981810222", 
                "operation": "read", 
                "path": "/proc/13763/cmdline"
            }, 
            "process": "/init->zygote->system_server", 
            "time": 9.341, 
            "type": "FileRW"
        }, 

The method of connecting DroidBox logs to process names is continuously calling ps command and maintaining a pid-to-process mapping.

[yuanchun-li]

Progress on 2. Measure the Coverage of Dyn.Analysis:

Take method coverage as an example, the steps to measure the method coverage of dyn. analysis are as follows:

1. Analyze the app and get a list of all methods in the app.
2. Instrument the app to print log messages when it reaches a method.
3. Run the app and collect the log messages.
4. Get the list of reached methods.
5. Calculate the coverage (i.e. the percentage of reached methods).

Because it is a separated module and it's not easy to instrument app using python, I started a new project androcov to do the coverage-related stuffs.

[yuanchun-li]

Progress on 2. Measure the Coverage of Dyn.Analysis:

I finished the instrumentation module (androcov) this week, see https://github.com/ylimit/androcov.
androcov extract all methods defined in an Android app and rewrites the app by add a logging line in each method, so that the reached methods will be logged at runtime.

The coverage can be calculated at runtime by dividing the number of reached methods by the number of all methods.

[yuanchun-li]

Finished: 2. Measure the Coverage of Dyn.Analysis

I added a script named CoverageEvaluator.py which can be used to evaluate DroidBot by measuring the method coverage.

[yuanchun-li]

Progress on having a scripting language / Make analysis reproducible

I decided to use json as the scripting language in DroidBot, and here is a description of the script syntax:

The DroidBot script contains three basic objects:

1. View selector, which can be used to select a view (aka. a UI component);
2. State selector, which can be used to select a state (such as a login state);
3. Operation object, which defines a set of events to be sent to device (such as screen-touching events);

DroidBot script also has a main method, which defines which operations to take in certain states.

An example of the DroidBot script is as follows:

{
    'views': {
        'login_email': {
            'id': '*email*',
            'class': 'EditText'
        },
        'login_password': {
            'id': '*password*',
            'class': 'EditText'
        },
        'login_button': {
            'id': '*login*',
            'class': 'Button'
        }
    }
    'states': {
        'login_state': {
            'activity': 'LoginActivity',
            'views': ['login_email', 'login_password', 'login_button']
        }
    }
    'operations': {
        'login_operation': {
            'operation_type': 'custom',
            'events': [
                {
                    'event_type': 'text_input',
                    'target_view': 'login_email',
                    'text_content': '[email protected]'
                }
                {
                    'event_type': 'text_input',
                    'target_view': 'login_password',
                    'text_content': 'yuanchun's password'
                }
                {
                    'event_type': 'touch',
                    'target_view': 'login_button'
                }
            ]
        }
        'normal_operation': {
            'operation_type': 'policy',
            'event_policy': 'dynamic'
        }
    }
    'main': {
        'login_state': 'login_operation',
        'default': 'normal_operation'
    }
}

Explanation of the example:

• In views, we define the view selectors which will be used to select the views we are interested in.
  In this example, we define three views which are the email input view, password input view a the login button.
• In states, we define the states in which we want DroidBot to take different operations.
  In this example, we define a login_state which is a login screen waiting for users to input email and password.
  The login_state can be recognized by checking the foreground activity name and the view on the screen.
• In operations, we define the operations which will be used in different states.
  In this example, we define a login_operation which is simply typing email, typing password and press login button.
• In main, we connect the states to corresponding operations.
  In this example, we let DroidBot to take login_operation in Login state, and use dynamic event policy in other states.

[yuanchun-li]

Progress on 4. Improving DroidBot

1. A new exploration policy "utg_dynamic" is added. I guess it may be better than "dynamic" policy, but need more testing.
2. DroidBot will push some dummy documents to device sdcard before testing, also need more testing.

[yuanchun-li]

GSoC 2016 finished!

[yuanchun-li]

For what I have done in GSoC 2016, please refer to http://honeynet.github.io/droidbot/2016/08/20/GSoC_2016.html