December 19, 2014
Hot Topics:

Java Language Integrity & Security: Uncovering Bytecodes

  • March 5, 2007
  • By Matt Weisfeld
  • Send Email »
  • More Articles »

The thought of re-creating the original source code of the statically linked application is far beyond the reach of most any technology. Yet, is it possible to accomplish this task with bytecodes? The answer to this question is, for the most part. There are many technologies that perform the function of recreating source code from bytecodes, and you will explore this in later articles. For now, you can use something much more accessible, a tool provided by the Java SDK itself: javap.exe.



Click here for a larger image.

Figure 7: javap.exe.

The Java documentation identifies javap as the The Java Class File Disassembler. Their definition is as follows:

The javap command disassembles a class file. Its output depends on the options used. If no options are used, javap prints out the package, protected, and public fields and methods of the classes passed to it. javap prints its output to stdout.

http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javap.html

You can take a look at the various options available for javap by calling javap with the -help options as seen in Figure 8.



Click here for a larger image.

Figure 8: The options for javap.exe (using javap - help).

For your examples, you will start with the -private flag to show you all classes and members. The best way to see what javap does is to run the Employee class through it as follows:



Click here for a larger image.

Figure 9: Running Employee.class through javap.exe.

It is interesting to look at the original source code and the disassembled source code right next to each other. Take a look at Listing 4 and study the differences.

Listing 4: The Employee Class (original source code and the disassembled source code)

public class Employee {

   private int employeeNumber;

}

public class Employee extends java.lang.Object{
   private int employeeNumber;
   public Employee();
}

There are two obvious differences between the two versions of the code. First, in the disassembled source code, it is apparent that Employee extends the java.lang.Object class. This is expected, because all objects in Java ultimately extends the Object class. However, here is irrefutable proof. The code was not in the original source code. Yet, the compiler has inserted it into the bytecode version. The second obvious difference is the fact that there is a constructor in the midst of the code.

public Employee();

Again, this is as expected. If no constructor is specified in the original code, a default constructor is supposed to be provided for you—and this is exactly what happened here. You can have some fun and see what happens when you do provide a constructor as seen in Listing 5.

Listing 5: The Employee Class (original source code and the disassembled source code)

public class Performance {

   public static void main(String[] args) {

      System.out.println("Performance Example");

      mployee joe = new Employee(1);

   }
public class Employee {

   private int employeeNumber;

   public Employee (int a) {

   }

}

Running this code through javap produces the output in Figure 10.



Click here for a larger image.

Figure 10: A Non-Default Constructor.

Notice that the default constructor is gone and is replaced by the constructor that you defined. This is exactly what you would have expected. Once again, the value of this exercise is primarily instructional; however, at times it can be a valuable debugging tool. Finally, put in a second constructor.

Listing 6: The Employee Class (original source code and the disassembled source code)

public class Performance {

   public static void main(String[] args) {

      System.out.println("Performance Example");

      Employee joe = new Employee(1);

   }
}
public class Employee {

   private int employeeNumber;

   public Employee (int a) {

   }

   public Employee (float a) {

   }
}

Now, javap produces the output in Figure 11. Notice that the name of the attribute datatype is not included in the method parameter list—they are only listed as int and float. Also note that in the original source code, both of the parameter names are the same. This leads you to an interesting topic that you will cover extensively in a future article as well.



Click here for a larger image.

Figure 11: Two Constructors.





Page 3 of 4



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Sitemap | Contact Us

Rocket Fuel