To use the tool, it is necessary to provide as input a Java program and an appropriately configured properties file. In this file, the user must supply some additional information, such as which are the source and sinks. These determine the flow of confidential data in the program, and which type of analysis will take place. For example, in a timing attack the source is the password and the sinks are the conditionals.

With the inputs provided, the Java program is transformed into Shimple - an intermediate representation of the Soot compiler in Static Single Assignment form (SSA) format - in which all program variables have one definition. From the Shimple code, InspectorJ begins the analysis, creating the dependence graph.

A dependence graph represents the data and control dependences relationships between the variables of the program. Data dependence: if the code has an instruction that defines a variable a and uses a variable b, such as a=b+1. Control dependence: if the code has a conditional branch, such as if p==0 then a=b+1 else a=b-1, the value of the variable a depends on the value of the variable p. The nodes represent the variables of the program and the sinks, and the edges represent the dependences.

To detect a vulnerability, the tool searches the graph looking for paths between the source and the sinks. These paths characterize tainted flows, and whenever these exist, there is a vulnerability in the code. The tool highlights these paths in red to show the user where the problem is in the code. For timing attacks, InspectorJ searches for paths between the password and conditional branches. The variables are represented by squares, the source by an X and the sinks by differents figures, such as triangles and diamonds.

The tool provides as output a rich graph that shows how information flows throughout the program. There are several functionalities: save an image from the graph; generate a video that traverses the graph showing the tainted flow, passing through all the variables that belong to it; zoom in on certain parts of the graph to better visualize them; among other features.

In addition to static analyses, the tool performs a dynamic check. If the code has subtyping polymorphism and dynamic dispatching, the type of the instantiated object can be defined only at execution time. If the static analysis detects that one method of any of the possible types of this object is unsafe, the tool inserts a guard in the Java program in points that unsafe methods could be called. Thus, the tool prevents the execution of unsafe parts of the code through instrumentation.