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.

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.