MQP:More on Soot

MQP Navigation ▼ MQP ► MQP-Design ► MQP-Prototypes ► MQP-Research   Main   Project Overview

Overview

Soot is a useful tool for static analysis mentioned in the static analysis tools section. Some of its features are covered in more detail here.

What Soot Does

Soot takes Java source code, bytecode, or classfiles as input and converts them into different representations or models of the code. These representations simplify the process of performing many tasks, including several types of static analysis. For this project in particular, we will be especially interested in Soot's ability to make call graphs and operate on them. Some of the other types of static analysis that Soot facilitates may also factor in to this project.

Intermediate Representations

There are four different models that Soot uses for representing Java Code, each with different uses. We're still learning what each of these does exactly (working from http://www.brics.dk/SootGuide/).

1. Baf - This representation allows for inspection of Java bytecode as "stack code." Still learning about this and what it means.
2. Jimple - This representation is the most commonly used intermediate model. It breaks complicated statements down into more basic ones (for example, i = x + y + z could become i0 = x + y; i = i0 + z), to simplify statement by statement analysis.
3. Shimple - This model is similar to Jimple, but has the ability to remember different values for variables dependent on branching in the program (if two branches set a variable x in different ways, then at the end Shimple may have two variables, x0 and x1, that represent two possible values of x). This can lead to simplifications if it is found that the branches yield identical results for some identifiers.
4. Grimp - This model looks the most like "normal" Java code, and has the least simplifications of the four models.

Analyses and Data Models

From these intermediate representations, Soot creates several different abstract models of the code, and can perform a few types of analyses on these models.

1. Call Graph - Creating a call graph is necessary for any type of interprocedural analysis (one that handles control flow that changes via method invocations). The call graph in Soot is based on a class hierarchy model, so the Method objects represented by Soot have information about what class they belong to and what fields they have access to. Soot also provides different methods for traversing the call graph and finding methods reachable from others.
2. Data Flow Analyses - Soot also has tools that allow the user to specify specific data flow analyses to perform on the model. The user can specify if it is a forward or backward analysis, a may or must analysis, and several other options.
3. Points-to Analysis - Soot has specific tools for performing a points-to analysis, which can be used to determine what values pointers (Java references) could be referring to at a given program point. This could be useful in this project in determining the arguments to Permission objects to refine the knowledge of which permissions are needed.

More to Come

There will likely be more information available on Soot the more it and its uses are investigated. UPDATE: Got Soot up and running on the command line, and can build and run it from eclipse. Next is to work on our own tools to utilize the API and classes that are already there.

References

Soot Survival Guide - http://www.brics.dk/SootGuide/