Reverse Engineering a Production Web Application

Let’s imagine (hypothetically for now) that a client's demands require change, and you realize that you no longer have access to the source code or the team that developed a working production application. Should you start over? Reconsider the changes? Maybe not.

Things like this do happen, and here is one example of an actual reverse engineering project that RMCSoft recently completed.

The Challenge

Our customer has been using a web application written in Java. This application provides PDF reports via the Representational State Transfer (REST) protocol. Spring offers the core application framework, while Spring MVC accepts requests over REST from another application and then provides PDF reports generated from data stored in a MySQL database.

The customer would like to continue utilizing, even enhancing, this application, but has no source code. Only a Web Application Resource (WAR) is available and deployed on a production server, so our engineers had to restore the structure of the web application.

Let’s see how this issue can be resolved quickly and effectively.

Priority 1: Get the Source Code of the Application

First, we look at the structure of the WAR deployed on the production server. Our engineers drew the structure of the web application and recovered it in order to develop a skeleton of the web application.

Then we put the source code and the skeleton together to obtain a viable application that could be modified and improved.

Priority 2: WAR Reverse Engineering

Several utility tools are available to get Java source code from a bytecode.

Here are just some of them:

• Bytecode Viewer

• Java Decompiler

• Fernflower 

• Procyon 

To solve our task, we chose Bytecode Viewer. It’s a free tool and has a great GUI which enables the programmer to focus on the structure of the project. As input data, Bytecode Viewer accepts JAR files. Both WAR and JAR files are archives, so we can change an extension from .war to .jar.

Below you can find the result of our reverse engineering:

Priority 3. Restore the web application structure

To restore the application structure, we need to explore the present structure of the web archive. At this stage, we have already renamed our WAR file and we now have a JAR file. Now we can unzip it and examine the structure.

Here is the result:

• WEB-INF
  • web.xml
  • lib
    • *.jar (all the libraries)
  • classes
    • applicationContext.xml
    • log4j.properties
    • config.properties
    • com
      • packages with classes in bytecode (*.class)
• META-INF
  • MANIFEST.MF
  • maven
    • com.app
      • Application
        • pom.properties
        • pom.xml
• images
  • form.png
  • img.png
  • *.png
• templates
  • html templates for reports (*.html)
• index.jsp

As we can see, WAR contains pom.xml, which we can just copy-paste into our project.

All config files which are in the WEB-INF/classes folder should be placed into the src/main/resources folder according to the Maven web project structure. Images, templates, index.jsp will be in the src/main/webapp folder. WEB-INF/web.xml goes into src/main/webapp/WEB-INF.

Destinations for all these artifacts are chosen based on the Maven web project directory layout and web archive packaging rules. Therefore, we’ve got the restored structure of WAR, as follows:

• src
  • main
    • resources
      • applicationContext.xml
      • config.properties
      • log4j.properties
    • webapp
      • WEB-INF
        • web.xml
      • images
        • form.png
        • img.png
        • *.png
      • templates
        • html templates for reports (*.html)
      • index.jsp
• pom.xml

Priority #4. Putting it Together

Now we have the source code as a result of the first and second stages and the project structure as a result of the third stage.

All Java sources obtained will be in src/main/java folder. The web project now contains the following structure:

• src
  • main
    • java (source code from the first stage)
      • com
        • all packages with source code
    • resources
      • applicationContext.xml
      • config.properties
      • log4j.properties
    • webapp
      • WEB-INF
        • web.xml
      • images
        • form.png
        • img.png
        • *.png
      • templates
        • html templates for reports (*.html)
      • index.jsp
• pom.xml

Finally, the project can be packaged with an mvn clean install.

Final Outcome

Our main goal has been achieved; we provided the source code of the web application functioning in the production environment to our customer. The rest of the issues are quite easy to resolve since we now have the source code available. The benefits of our efforts are clear enough: our customer is able to maintain and customize the web application. In this example, we’ve demonstrated one of the ways to extract the sources from WAR and restore the structure of the web project written in Java.

We hope you won’t ever find yourself in the situation described above. However, should it ever happen we hope this information will be of use.