Die folgenden Informationen sind nur in englischer Sprache verfügbar.
Over the past few years, the members of the Secure Software Engineering group have developed a range of useful and often even production-stable tools, mostly for static and dynamic program analysis.
It is our group's policy to make our tools available as open source, such as to allow for extensions by other researchers, and to foster collaboration. The graphic on the right shows tools we work with. Boxes show tools we developed or contribute to. Ovals show external dependencies.
Publications about each tool can be found on the respective tool's webpage. For the links see below.
If you have a question about one our tools, please consult the appropriate mailing list, or otherwise just email us.
Developing an Android application in an IDE is very convenient since features like code completion, “Open Declaration“, renaming variables, searching files etc. help the developer a lot. Especially code-debugging is a very important feature in IDEs. Usually, all those features are available for the source code and not for the bytecode, since they support the developer not a reverse-engineer. Well, but all those features would be be also very helpful for reverse-engineering Android or Java applications. This is the reason why we came up with a new reverse-engineering framework that works on the intermediate representation Jimple and supports all the features above and a lot more.
SuSi is a tool for the fully automated classification and categorization of Android sources and sinks.
The overall principle of static, dynamic or hybrid taint-tracking approaches is to check if there is a potential flow between a source and a sink. There exist different kinds of sensitive sources and sinks in the area of Android security. For instance, the user’s location information or address book can be treated as a source, while the network connection or the SMS message sending facilities can be seen as sinks. In general, sources and sinks are accessed through specific API methods (e.g, getLastKnownLocation() for the user’s current location). SuSi is a tool that automatically generates a list of Android sources and sinks by analyzing the complete Android source code. Our approach is version-independent and can simply be run again when a new Android version is released. This relieves security analysts from having to regularly create new lists of sources and sinks by hand. SuSi is based on a supervised machine-learning approach. It first uses a small hand-annotated fraction of the API to train a classifier which is then able to fully-automatically classify all other methods in the whole Android API as a source, sink, or neither. SuSi is highly precise with a recall and precision of more than 92% as evaluated using ten-fold cross validation.
FlowDroid is a context-, flow-, field-, object-sensitive and lifecycle-aware static taint analysis tool for Android applications. Unlike many other static-analysis approaches for Android we aim for an analysis with very high recall and precision. To achieve this goal we had to accomplish two main challenges: To increase precision we needed to build an analysis that is context-, flow-, field- and object-sensitive; to increase recall we had to create a complete model of Android’s app lifecycle.
Our analysis is based on Soot and Heros. FlowDroid uses a very precise callgraph which helps us to ensure flow- and context-sensitivity. Its IFDS-based flow functions guarantee field- and object-sensitivity. Because an accurate and efficient alias search is crucial for context-sensitivity in conjuction with field-sensitivity, we want to highlight this part of our analysis, which is inspired by Andromeda.
Heros: efficient solving of simple-to-define IFDS and IDE problems
Heros is our inter-procedural data-flow solver. Heros is based on the well-known IFDS and IDE frameworks by Reps, Horwitz and Sagiv.
It allows users to define data-flow problems in a very simple template-based manner (see here for example): simply define your flow functions and let the solver take care of the rest. Other implementations of IFDS and IDE exist, for instance WALA has had support for IFDS for quite some time. Heros has a number of unique features, though:
- Its implementation is independent of the programming language being analyzed and the analysis framework’s IR. We provide a connector to Soot but other people can easily integrate Heros with other tools. We ourselves are working on an integration with a C/C++ compiler.
- Heros is multi-threaded and hence highly scalable.
- Heros also provides a relatively simple programming interface.
SPLLift – Transparent and Efficient Reuse of IFDS-based Static Program Analyses for Software Product Lines
A software product line (SPL) encodes a potentially large variety of software products as variants of some common code base. Up until now, re-using traditional static analyses for SPLs was virtually intractable, as it required programmers to generate and analyze all products individually.
With SPLLIFT, however, we show how an important class of existing inter-procedural static analyses can be transparently lifted to SPLs. Our approach automatically converts any analysis formulated for traditional programs within the popular IFDS framework for inter-procedural, finite, distributive, subset problems to an SPL-aware analysis formulated in the IDE framework, a well-known extension to IFDS.
With SPLLIFT, programmers can reuse IFDS-based analyses without changing a single line of code. Through experiments using three static analyses applied to four Java-based product lines, we were able to show that our approach produces correct results and outperforms the traditional approach by several orders of magnitude.
RefaFlex – Safer Refactorings for Reflective Java Programs
Current refactoring tools for modern IDEs do not offer support for reflection, resulting in unintentionally changed program semantics when refactoring reflective code. This is undesired, as such semantic changes can lead to security problems and other pitfalls. RefaFlex aids in this demand by collecting runtime information from previous test runs and providing a constraint generator giving the programmer valuable information where a refactoring may change a program’s behaviour past refactoring. RefaFlex is implemented as an Eclipse plugin. This plugin guarantees that refactorings, once applied in Eclipse, will not alter the semantics of test runs that were executed within the Eclipse IDE prior to invoking the refactoring. RefaFlex builds on top of the successful TamiFlex project (see below).
Join Point Interfaces – Modular type checking of AO programs
Aspects written in aspect-oriented programming languages such as AspectJ are frequently used to implement important security concerns in a modular manner. The aspects are important software assets, as they are often non-trivial to write. Hence, one goal should be to maximize their reuse across multiple applications.
Join Point Interfaces (JPIs for short) are a novel AspectJ language extension allowing programmers to completely de-couple aspect definitions from the base code those aspects advise. For the first time, they therefore do allow easy reuse of aspects. Join Point Interfaces build on the semantics of Closure Join Points, another AspectJ language extension that we developed to allow programmers to expose join points at program locations that cannot (easily) be matched by AspectJ pointcuts.
JPIs are the first mechanism to allow for complete modular type checking of aspect-oriented programs. Our implementation is available as an part of the open-source project AspectBench Compiler.
TamiFlex – Taming Reflection in Java Programs
TamiFlex is our solution to the dreaded “reflection problem” in static program analysis for Java. Using reflection, Java programs can invoke methods and access fields and classes indirectly, by passing a String value to some special methods of the reflection API. Those string values can be generated at runtime, making them impossible to analyze statically.
TamiFlex solves this problem in part, on a best-effort basis: it logs information about reflective calls at runtime and then transforms the program's code to include non-reflective versions of those calls. Static analysis tools can then “see” those calls in the modified program version, thus allowing for a “more sound” analysis of those programs. TamiFlex also integrates with Soot (see below). Results on TamiFlex have been published at ICSE 2011.
Clara – Ahead-of-time evaluation of finite-state runtime monitors
Clara (CompiLe-time Approximation of Runtime Analyses) is our framework for statically evaluating finite-state runtime monitors ahead of time. Clara allows for the static evaluation and optimization of runtime monitors. A runtime monitor is a piece of instrumentation that can be inserted into a program in order to check that the program fulfils certain properties when executed. This is useful for security monitoring or for defining testing oracles.
Clara can handle any runtime monitor formulated as an AspectJ aspect. Through large-scale empirical evaluations we were able to show that in about 80% of all cases Clara's static analyses are able to determine completely statically that a given runtime monitor will never find a violation for a given program. In most other cases, Clara's static analyses lead to drastic performance optimizations. As all our tools, Clara is open source, and we welcome your contributions.
Soot – Static code analysis and transformation for Java
Soot is one of the most widely used analysis and transformation frameworks for Java bytecode and source code. Soot features a wide-range of intermediate representations that make static program analysis as easy as it can be. While Soot is not our own development, we are maintaining the framework at the moment. Many of our existing tools are based on Soot and/or integrate with it.
Further older tools can be found on Eric Bodden's personal web page.