This is for the usage of TRUE one class at a time. For Javaagent development, we can only access one class per round, while Soot was designed to read all classes before follow-up processes. So Soot will not handle dependency classes' info at once, letting work-lists to load these classes later. As a result, incomplete resolving causes wrong generated codes. For example, an InterfaceMethodref could be changed to a Methodref, which cannot run on JVM.
LocalVariableTable(&LocalVariableTypeTable), MethodParameters and parameter-annotations are significant for Spring applications. Original Soot only resolves parameter names from LocalVariableTable. As start_pc and length in LVT may be invalid after the class being transformed, LVT is only resolved without writing back to class. For MethodParameters, both are supported. More details at Wiki.
In December 2022, we have officially released SootUp, a version of Soot with a completely overhauled, more modular, testable, maintainable and usable architecture. Please check this out in case you wish to start a new program-analysis project.
Since there has been some confusion: SootUp is not yet feature-complete. Therefore, the "old" Soot needs to live on for the time being, especially for projects that require instrumentation capabilities or robust Android support. The "old" Soot is still being maintained until it can safely be dropped for a feature-complete successor.
We are regularly applying for funding to help us maintain Soot. You can help us immensely by letting us know about projects that use Soot, both commercially or in the form of research tools.
Also many thanks to 
... for supporting the further Development of Soot!
Amazon Web Services is a Gold Sponsor.
Read more here about how to become a sponsor on your own.
Try and get involved in Soot's Java 9 bleeding edge developement.
- Automatic modules (modules automatically created from jars in the module-path)
- Named modules
- Exploded modules
- Modular jar files
- Resolving modules in Soot's
ModuleScene - Spark
- Anonymous modules (mixing module- and class-path)
- Multi-module jar files
Soot is a Java optimization framework. It provides four intermediate representations for analyzing and transforming Java bytecode:
- Baf: a streamlined representation of bytecode which is simple to manipulate.
- Jimple: a typed 3-address intermediate representation suitable for optimization.
- Shimple: an SSA variation of Jimple.
- Grimp: an aggregated version of Jimple suitable for decompilation and code inspection.
See https://soot-oss.github.io/soot for details.
We have some documentation on Soot in the wiki and also a large range of tutorials on Soot.
For detailed information please also consider the Soot's JavaDoc and Options Documentations.
A Soot release is currently built for each commit to the master branch. You can include Soot as
a dependency via Maven, Gradle, SBT, etc using the following coordinates:
<dependencies>
<dependency>
<groupId>org.soot-oss</groupId>
<artifactId>soot</artifactId>
<version>4.5.0</version>
</dependency>
</dependencies>You can also obtain older builds of the master branch. A complete listing of builds can be found on Maven Central.
A Soot SNAPSHOT is currently built for each commit to the develop branch. You can include Soot as
a dependency via Maven, Gradle, SBT, etc using the following coordinates:
<dependencies>
<dependency>
<groupId>org.soot-oss</groupId>
<artifactId>soot</artifactId>
<version>4.6.0-SNAPSHOT</version>
</dependency>
</dependencies>
<repositories>
<repository>
<id>sonatype-snapshots</id>
<url>https://oss.sonatype.org/content/repositories/snapshots</url>
<releases>
<enabled>false</enabled>
</releases>
</repository>
</repositories> You can also obtain older builds of the develop branch. A complete listing of builds can be found on Maven Central.
We recommend using Soot with Maven You can obtain the latest release build of Soot directly. You can obtain the latest SNAPSHOT build of Soot directly.
The soot-<RELEASE>-jar-with-dependencies.jar file is an all-in-one file that also contains all the required libraries.
The soot-<RELEASE>.jar file contains only Soot, allowing you to manually pick dependencies as you need them. If you do not want to bother with dependencies, we recommend using the former.
If you cannot work with the prebuild versions and need to build Soot on your own, please consider the wiki for further steps.
Soot follows the git-flow convention. Releases and hotfixes are maintained in the master branch. Development happens in the develop branch. To catch the bleeding edge of Soot, check out the latter. In case of any questions, please consult the Soot mailing list at: http://www.sable.mcgill.ca/mailman/listinfo/soot-list/
We are happy to accept arbitrary improvements to Soot in form of GitHub pull requests. Please read our contribution guidelines before setting up a pull request.
You are using Soot and would like to help us support it in the future? Then please support us by filling out this little web form.
That way you can help us in two ways:
- By letting us know how we can improve Soot you can directly help us prioritize newly planned features.
- By stating your name and affiliation you help us showcasing Soot’s large user base. Thanks!
If you want to run Soot with Java > 8, you are done. Just run it as usal. If you want to execute Soot with Java 8 but analyze Java >8 Projects or vice versa, see below.
To load modules in Soot's ModuleScene from java:
// configure Soot's options, refer to example configurations below
Options.v().set_soot_modulepath(modulePath);
// load classes from modules into Soot
// Here, getClassUnderModulePath() expects the module path to be set using the Options class as seen above
Map<String, List<String>> map = ModulePathSourceLocator.v().getClassUnderModulePath(modulePath);
for (String module : map.keySet()) {
for (String klass : map.get(module)) {
logger.info("Loaded Class: " + klass + "\n");
loadClass(klass, false, module);
// the loadClass() method is defined below
}
}
//this must be called after all classes are loaded
Scene.v().loadNecessaryClasses();
public static SootClass loadClass(String name, boolean main, String module) {
SootClass c = ModuleScene.v().loadClassAndSupport(name, Optional.of(module));
c.setApplicationClass();
if (main)
Scene.v().setMainClass(c);
return c;
}ModuleUtil.module_mode() helps you check whether you have modules enabled in Soot. This is done based on whether the module path is set using the Options class.
if(java < 9 ) { // when you have a target benchmark with Java < 9 and hence no modules
Options.v().set_prepend_classpath(true);
Options.v().set_process_dir(Arrays.asList(applicationClassPath().split(File.pathSeparator)));
Options.v().set_soot_classpath(sootClassPath());
}
if(java >= 9 && USE_CLASSPATH) { // when you have a target benchmark with Java >= 9 and do not want module support
Options.v().set_soot_classpath("VIRTUAL_FS_FOR_JDK" + File.pathSeparator + sootClassPath());
Options.v().set_process_dir(Arrays.asList(applicationClassPath().split(File.pathSeparator)));
}
if(java>=9 && USE_MODULEPATH) { // when you have a target benchmark with Java >= 9 and want module support
Options.v().set_prepend_classpath(true);
Options.v().set_soot_modulepath(sootClassPath());
Options.v().set_process_dir(Arrays.asList(applicationClassPath().split(File.pathSeparator)));
}In the above examples, applicationClassPath() should be replaced with the path to the application classes for analysis by Soot and sootClassPath() should be replaced with the Soot classpath.
To execute Soot using Java 1.9, but analyzing a classpath run, just as before:
java -cp soot-trunk.jar soot.Main --process-dir directoryToAnalyse
if you want to specify the classpath explicitly run:
java -cp soot-trunk.jar soot.Main -cp VIRTUAL_FS_FOR_JDK --process-dir directoryToAnalyse
the value VIRTUAL_FS_FOR_JDK indicates that Soot should search Java's (>9) virtual filesystem jrt:/ for classes, too, although Soot is not executed in module mode.
To load modules and classes in Soot using java 1.8 run:
java -cp PATH_TO_JAVA9/jrt-fs.jar:soot-trunk.jar soot.Main -pp -soot-modulepath modules/
Please replace PATH_TO_JAVA9 with the path to your local installation of java 9.
The jrt-fs.jar is a built-in NIO FileSystem provider for the jrt:// filesystem java 9 uses that replaces rt.jar.