Skip to content
一个通过分析字节码进行污点分析的静态代码审计应用(添加了大量代码注释,适合大家进行源码学习)。加入了挖掘Fastjson反序列化gadget chains(曾使用它挖掘到了Fastjson、Jackson通用的gadget chain)和SQLInject(JdbcTemplate、MyBatis、JPA、Hibernate、原生jdbc等)静态检测功能。
Branch: master
Clone or download
Pull request Compare This branch is 16 commits ahead, 1 commit behind JackOfMostTrades:master.


一、加入了Fastjson的gadget chain挖掘


--config fastjson /xxxxx/xxxxx/xxxxx/xxxxx.jar /xxxxx/xxxxx/xxxxx/xxxxx2.jar /xxxxx/xxxxx/xxxxx/xxxxx3.jar



--config sqlinject --boot /xxxxx/xxxx/jdbc-1.0-SNAPSHOT.jar




--config fastjson --boot --NoTaintTrack /xxxxx/xxxxx/xxxxx/xxxxx.jar

注意:Fastjson的非污点分析搜索,暂时只挖掘slink为jndi lookup的链


  1. --config xxx:挖掘什么样的gadget chains(jackson、fastjson、sqlinject、jserial...)
  2. --boot:指定该jar为SpringBoot项目jar包
  3. --NoTaintTrack:不使用污点分析,将会把所有链都搜索出来,好处是不会遗漏,坏处是需要大量的人工审计
  4. --mybatis.xml xxx:当挖掘sqlinject时,若工程使用了Mybatis,则可通过指定mapper xml所在目录,进行挖掘Mybatis的sql注入
  5. --resume:是否项目启动时删除所有dat数据文件,重新搜索
  6. --OpLevel 1:链聚合优化等级,1表示一层优化,默认0不优化
  7. --history:启用历史扫描jar包记录,方便大规模扫描时不重复扫描旧jar包,好处时减少工作时间,坏处是遇到依赖组合的gadget可能扫不出来

Gadget Inspector

This project inspects Java libraries and classpaths for gadget chains. Gadgets chains are used to construct exploits for deserialization vulnerabilities. By automatically discovering possible gadgets chains in an application's classpath penetration testers can quickly construct exploits and application security engineers can assess the impact of a deserialization vulnerability and prioritize its remediation.

This project was presented at Black Hat USA 2018. Learn more about it there! (Links pending)

DISCLAIMER: This project is alpha at best. It needs tests and documentation added. Feel free to help by adding either!


Assuming you have a JDK installed on your system, you should be able to just run ./gradlew shadowJar. You can then run the application with java -jar build/libs/gadget-inspector-all.jar <args>.

How to Use

This application expects as argument(s) either a path to a war file (in which case the war will be exploded and all of its classes and libraries used as a classpath) or else any number of jars.

Note that the analysis can be memory intensive (and so far gadget inspector has not been optimized at all to be less memory greedy). For small libraries you probably want to allocate at least 2GB of heap size (i.e. with the -Xmx2G flag). For larger applications you will want to use as much memory as you can spare.

The toolkit will go through several stages of classpath inspection to build up datasets for use in later stages. These datasets are written to files with a .dat extension and can be discarded after your run (they are written mostly so that earlier stages can be skipped during development).

After the analysis has run the file gadget-chains.txt will be written.


The following is an example from running against commons-collections-3.2.1.jar, e.g. with

java -Xmx2G -jar build/libs/gadget-inspector-all.jar commons-collections-3.2.1.jar

In gadget-chains.txt there is the following chain:

com/sun/corba/se/spi/orbutil/proxy/CompositeInvocationHandlerImpl.invoke(Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;)Ljava/lang/Object; (-1)
  com/sun/corba/se/spi/orbutil/proxy/CompositeInvocationHandlerImpl.invoke(Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;)Ljava/lang/Object; (0)
  org/apache/commons/collections/map/DefaultedMap.get(Ljava/lang/Object;)Ljava/lang/Object; (0)
  org/apache/commons/collections/functors/InvokerTransformer.transform(Ljava/lang/Object;)Ljava/lang/Object; (0)
  java/lang/reflect/Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; (0)

The entry point of this chain is an implementation of the JDK InvocationHandler class. Using the same trick as in the original commons-collections gadget chain, any serializable implementation of this class is reachable in a gadget chain, so the discovered chain starts here. This method invokes classToInvocationHandler.get(). The discovered gadget chain indicates that the classToInvocationHandler can be serialized as a DefaultedMap so that the this invocation jumps to DefaultedMap.get(). The next step in the chain invokes value.transform() from this method. The parameter value in this class can be serialized as a InvokerTransformer. Inside this class's transform method we see that we call cls.getMethodName(iMethodName, ...).invoke(...). Gadget inspector determined that iMethodName is attacker controllable as a serialized member, and thus an attacker can execute an arbitrary method on the class.

This gadget chain is the building block of the full commons-collections gadget chain discovered by Frohoff. In the above case, the gadget inspector happened to discovery entry through CompositeInvocationHandlerImpl and DefaultedMap instead of AnnotationInvocationHandler and LazyMap, but is largely the same.

Other Examples

If you're looking for more examples of what kind of chains this tool can find, the following libraries also have some interesting results:

Don't forget that you can also point gadget inspector at a complete application (packaged as a JAR or WAR). For example, when analyzing the war for the Zksample2 application we get the following gadget chain:

net/sf/jasperreports/charts/design/JRDesignPieDataset.readObject(Ljava/io/ObjectInputStream;)V (1)
  org/apache/commons/collections/FastArrayList.add(Ljava/lang/Object;)Z (0)
  java/util/ArrayList.clone()Ljava/lang/Object; (0)
  org/jfree/data/KeyToGroupMap.clone()Ljava/lang/Object; (0)
  org/jfree/data/KeyToGroupMap.clone(Ljava/lang/Object;)Ljava/lang/Object; (0)
  java/lang/reflect/Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; (0)

As you can see, this utilizes several different libraries contained in the application in order to build up the chain.


Q: If gadget inspector finds a gadget chain, can an exploit be built from it?

A: Not always. The analysis uses some simplifying assumptions and can report false positives (gadget chains that don't actually exist). As a simple example, it doesn't try to solve for the satisfiability of branch conditions. Thus it will report the following as a gadget chain:

public class MySerializableClass implements Serializable {
    public void readObject(ObjectInputStream ois) {
        if (false) System.exit(0);

Furthermore, gadget inspector has pretty broad conditions on those functions it considers interesting. For example, it treats reflection as interesting (i.e. calls to Method.invoke() where an attacker can control the method), but often times overlooked assertions mean that an attacker can influence the method invoked but does not have complete control. For example, an attacker may be able to invoke the "getError()" method in any class, but not any other method name.

Q: If no gadget chains were found, does that mean my application is safe from exploitation?

A: No! For one, the gadget inspector has a very narrow set of "sink" functions which it considers to have "interesting" side effects. This certainly doesn't mean there aren't other interesting or dangerous behaviors not in the list.

Furthermore, there are a number of limitations to static analysis that mean the gadget inspector will always have blindspots. As an example, gadget inspector would presently miss this because it doesn't follow reflection calls.

public class MySerializableClass implements Serializable {
    public void readObject(ObjectInputStream ois) {
        System.class.getMethod("exit", int.class).invoke(null, 0);
You can’t perform that action at this time.