First Steps with SootUp
Before you get started with the SootUp library, it helps to learn about the following core data structures:
-
AnalysisInputLocation
: points to the target code that shall be loaded into theView
. -
View
: handles the representation of the code you configured it to analyze. -
SootClass
: represents a class. Can be loaded from the View via aClassType
identifier. SootMethod
: represents a method of a class - loaded from the View via aMethodSignature
identifier.SootField
: represents a field of a class - loaded from the View via aFieldSignature
identifier.Body
: represents a method body of aSootMethod
.StmtGraph
: represents the control flow graph of aBody
.Stmt
's represent actual Instructions.
Creating a View
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 a view for analyzing Java bytecode.
Create a view to analyze Java bytecode
1 2 3 4 |
|
If you have access to the source code, it is also possible to create a view for analyzing source code. Following example shows how to create view for analyzing Java source code.
Experimental! - Create a view to analyze Java source code
The source code frontend is experimental and should only be used for testing purposes. Usually you should compile the code for analysis first and use the bytecode frontend instead (see above).
1 2 3 4 |
|
If you have a Jimple file, you can create a view for analyzing jimple code directly. Following example shows how to create a view for analyzing jimple code.
Create a view to analyze jimple code
1 2 3 4 5 6 |
|
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 e.g. 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 |
|
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 |
|
1 2 3 4 5 |
|
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 6 7 |
|
Alternatively, we can also retrieve a SootMethod
from SootClass
that contains it.
Retrieving a SootMethod from a SootClass
1 2 3 4 5 6 |
|
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 |
|
Using the StmtGraph
1 2 3 4 5 6 7 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
|
1 2 |
|
Access a complete example of the code used above
Download BasicSetup.java