General Usage of SootUp
This page walks you through the core data structures, as well as shows how to get started with SootUp.
The core datastructures
Before you get started with the SootUp library, it helps to learn about the following core data structures:
-
Project
: defines the outlines of an analysis. SootUp users should first create aProject
instance. It is the starting point for all operations. You can define multiple instances ofProject
at the same time and there are no information shared between them. All caches are always at the project level. -
Language
: represents the programming language of the analyzed code. -
AnalysisInputLocation
: points to the target code to be analyzed.
Soot Equivalent
It corresponds to the cp
option, which specifies the classpath for Soot to find classes to be analyzed.
View
: presents the code/classes under analysis.
Soot Equivalent
It corresponds to the Scene
class, but it is not a singleton. So it is possible to instantiate multiple views simultaneously.
-
Scope
: defines the scope of theView
. By default, theView
is created with all code found on theAnalysisInputLocation
specified for theProject
instance. -
SootClass
: represents a class loaded into theView
. -
SootMethod
: represents a method of a class. -
SootField
: represents a field of a class. -
Body
: represents a method body in Jimpe. -
StmtGraph
: represents the control flow graph of a method body in Jimple statements.
Creating a Project
You can use bytecode analysis typically when you do not have access to the source code of the target program. Following example shows how to create project for analyzing Java bytecode.
Create a project to analyze Java bytecode
1 2 3 4 5 6 7 |
|
If you have access to the source code, it is also possible to create a project for analyzing source code. Following example shows how to create project for analyzing Java source code.
Experimental
The source code frontend is experimental and should only be used for testing purposes. You should compile the code for analysis first and use the bytecode frontend instead.
Create a project to analyze Java source code
1 2 3 4 5 6 7 |
|
If you have a Jimple file, you can create a project for analyzing jimple code directly. Following example shows how to create project for analyzing jimple code.
Create a project to analyze jimple code
1 2 3 4 5 6 |
|
Creating a View
To create an analysis view, you can call the createView()
method on the project
object:
1 |
|
By default, whenever a class is retrieved, it will be permanently stored in a cache.
If you do not want retrieved classes to be stored indefinetly, you can instead provide a different CacheProvider
to the created view.
To for example use an LRUCache
instead, which stores at most 50 classes, and always replaces the least recently used class by a newly retrieved one, use the following call:
1 |
|
Retrieving a Class
Each class is identified with a unique signature adhering to Java identifier rules, therefore you first need to specify the class signature (ClassType
) as shown below.
Let's say the following is the target program that we want to analyze:
Target Program
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
|
Then, we could define the ClassType
of the HelloWorld
class as follows:
Defining a ClassType
1 2 |
|
Once we have a ClassType
that identifies the HelloWorld
class, we can use it to retrieve the corresponding SootClass
object from the view
as shown below:
Retrieving a SootClass
1 2 |
|
Retrieving a Method
Like the classes, methods also have an identifier which we call MethodSignature
. For instance, we can define the method signature for identifying the main
method of the HelloWorld
class as follows:
Defining a MethodSignature
1 2 3 4 5 6 7 8 |
|
Once we have a MethodSignature
that identifies the main
method of the HelloWorld
class, we can use it to retrieve the corresponding SootMethod
object from the view
as shown below:
Retrieving a SootMethod from the View
1 2 3 4 5 |
|
Alternatively, we can also retrieve a SootMethod
from SootClass
that contains it.
Retrieving a SootMethod from a SootClass
1 2 3 4 5 |
|
Retrieving the Control-Flow Graph of a Method
Each SootMethod
contains a Control-Flow Graph (CFG) which is represented via the StmtGraph
. This structure is usually used for program analysis. You can retrieve the CFG of a SootMethod
as follows:
Retrieving the CFG of a SootMethod
1 |
|
Access or Download all of the code used above
SootUp vs Soot
Below we show a comparison of the code so far with the same functionality in sootup.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 |
|