Previous Projects

DroidFax - Dynamic Characterization of Android Applications

A plethora of research on Android has been exclusively focused on security and privacy issues in the Android software ecosystem, especially Android app security, yet there is still very little insight into how Android applications have been commonly built and into the environments in which those applications execute. With the proliferation of its user base and popularity in the mobile and personal computing arena, Android apps need to be dissected and characterized with respect to a general understanding of their programming paradigms and runtime behaviours. Gaining such understandings is critical as it will enable more effective development of both Android apps themselves and better security defense solutions for securing them.

DroidFax is a toolkit dedicated to offering an experimental framework for the dynamic characterization of Android apps. To help deliver a characterization more representative of the latest Android framework features, DroidFax targets the latest release of the Android SDK (version 6.0 / API level 23 / Marshmallow). Its core consists of a lightweight static analysis that mainly instruments the Dalvik bytecode of a given app for call profiling and ICC monitoring, and a lightweight dynamic analysis that collects and then analyzes generated call and ICC traces. It also includes a pre-processing phase taking charge of benchmark apps downloading and ICC-based app pairing based on the ICC resolution results obtained using a third-party tool. The last part of DroidFax computes three categories of metrics from the traces: general metrics, ICC metrics, and security metrics.

Blended Taint Analysis for JavaScript

JavaScript is widely used in Web applications because of its flexibility and dynamic features. However, the latter pose challenges to static analyses aimed at finding security vulnerabilities, (e.g., taint analysis). We present blended taint analysis, an instantiation of our general-purpose analysis framework for JavaScript, to illustrate how a combined dynamic/static analysis approach can deal with dynamic features by collecting generated code and other information at runtime. In empirical comparisons with two pure static taint analyses, we show blended taint analysis to be both more scalable and precise on JavaScript benchmark codes extracted from 12 popular websites at Alexa.


JavaScript Blended Analysis Framework (JSBAF) was built on two exiting infrastructures: TracingSafari and WALA.


Technical Reports

Dila - Dynamic Load-time Instrumentation Library

Dila is a dynamic load-time instrumentation library developed by our group in cooperation with IBM Research. Dila uses customized class loading for instrumenting the byte code of a program before it is executed. During the execution of an instrumented program dynamic program representations, such as call graphs, are created, which can be used for various program analyses. Dila is completely written in Java and uses the byte code manipulation toolkit Shrike from the Wala project. It has been built as a library for online analysis tools with a particular focus on performance. The library is licensed under the Eclipse Public License (EPL).


During program maintenance, a programmer may make changes that enhance program functionality or fix bugs in code. Then, she usually will run regression tests to prevent invalidation of previously tested functionality. If a test fails unexpectedly, she needs to explore her edit to find the failure-inducing changes for that test. Chianti is an Eclipse plug-in that assists the process. Chianti is a tool that performs semantic chance impact analysis to allow the programmer to examine those parts of the edit that may have affected the failing test. Chianti then builds compilable intermediate versions of the program, by adding programmer-selected partial edits to the original code, augmenting the selection as necessary to ensure compilation. The programmer can re-execute the test on the intermediate version in order to locate the exact reasons for failure, by concentrating on the specific changes that were applied.


A blended analysis framework for Java

Analysis-based Process Enforcement for Team-oriented Software Development

The new goal of the next generation of integrated development environments (IDEs) is utilized guidance for development processes. Such IDEs, like IBM's Team Concert, try both to guide developers in each process activity and to enforce a specific result, e.g., all existing tests have to pass before applied changes can be committed to the team repository. In this project, we're going to integrate deep program analysis techniques, such as change impact analysis, with such tool support to identify those changes that do not break any test and, thus can safely committed to the shared repository. Moreover, the analysis will guide developers in finding the root cause in the edit of a subsequent test failure, and in calculating changes left uncovered by the current test suite.

JUnitMX -- A Change-aware Unit Testing Tool

Developers use unit testing to improve the quality of software systems. Current development tools for unit testing help with automating test execution, with reporting results, and with generating test stubs. However, they offer no aid for designing tests aimed specifically at exercising the effects of changes to a program. JUnitMX is an extension to the JUnit plug-in for Eclipse that leverages an atomic change model to assist developers in the creation of new unit tests. In addition to standard information about test runs and results, it provides developers with quantitative feedback and detailed information about change effects, which not only facilitate the writing of more effective tests, but also motivate developers with an achievable coverage goal.

Tool Description

Change-aware tools operate on two versions of a program: an original and an edited version. JUnitMX uses the Chianti tool for selecting these program versions. A special run configuration enables developers to run a JUnit test suite with JUnitMX. This configuration runs the test suite associated with the edited version.

JUnitMX augments the existing JUnit plug-in by showing the following information. The number of behavioral changes that are not covered by any test is shown along with the number of test runs, errors and failures. This number is an upper bound on the changes that should be covered by additional tests.

JUnit's familiar red–green color scheme is extended to red–yellow–green. Intuitively, the green bar is only shown if all tests pass and the all changes are covered by the tests. If all tests pass but some changes are not covered by tests, a yellow bar is shown. Whenever a test fails or crashes, a red bar is shown.

An additional tab lists all changes not tested by the test suite. Changes are classified into groups, Additions and Changes, and further classified into code and structural and behavioral changes. An associated source code comparison view outlines the source code differences that led to the change.

Clicking on such a change will result in opening the source code editor and navigating to the denoted program element. Given this information, a developer can start creating new tests to ensure that as yet not covered changes have no unanticipated effect on the program behavior.

How it works

JUnitMX hooks into the execution of a JUnit test run and adds pre- and post-processing phases. In a pre-processing phase, Chianti is used to compute a coarse-grained representation of the edit as a set of atomic changes with structural dependences and mapping dependences between them.

During execution, JUnitMX uses a custom class loader for instrumenting the target application's classes as they are loaded. This class loader was developed using Dila a library for dynamic load-time instrumentation that we developed as part of the Wala program analysis framework. The instrumented classes contain instrumentation code for constructing a dynamic call graph for every test as it executes.

After the execution of the test suite of the edited program version has completed, the post-processing performs the actual change impact analysis. The dynamic call graphs are correlated with the atomic changes to calculate those changes that are covered by each test. Since changes cannot be applied or tested in isolation, their interdependences have to be considered as well. We say a change is covered by a test if its denoted element is exercised by the test or one of its (transitive) dependences is covered by the test. Once all covered changes are computed, we calculate those remaining uncovered changes that are not covered by any test.


JUnitMX is available under the Eclipse Public License (EPL) and tested with Eclipse 3.3.2. It is available either for download or as update site:

More Details