Reverse Engineering in Java

Question

I know that the same question has been asked many times on SO and I have gone through most of the threads. However, I still dot not have a satisfactory answer, so I thought of asking from community.

I am being assigned the work to do reverse engineering to a module and have the following issues:

1. The team has no idea what exactly is in the underlying component (Module is a third party solution)
2. Team was only working on testing part so they can only provide me information about the flow, but what is the starting point and which is where they have no idea.

Now they want me to dig through the code base and come up with class diagrams as well as sequence flow etc.

I have never worked in my professional life in this kind of situation where there is no idea where to start and how to do this work. The only thing I have is source code.

I have two questions where I want the help:

1. Is there any plugin for Eclipse which can generate class diagrams automatically from the source code?
2. What should the approach be when one is in this kind of situation?

Update: I will have access to the source code. So I am more inclined towards the best approach to accomplish the task

Solution 1

There are several Java decompilers that will help you, such as JD-Core, and there's an Eclipse version of it.

Solution 2

I'd start with decompiling the module and making sure that the decompiled code can be reassembled into a working library. You can use JD for example. I can see now that you've got the source code already.

Getting a compilable source code first is important, because you will have to add comments and javadoc as you explore it. You don't have to work with the original binary anymore, just treat the decompiled source code as a very badly documented normal code. It is also a good idea to rename local variables and method parameters to make the code easier to read.

Generating class diagrams from .java files should be easy then.

Understanding the flow can be done in two ways, manually or using a profiler. For both methods you need to find the entry points first, but if you're already using the library, these should be fairly obvious. Then you just invoke the API method and step through the code. Always make notes of anything interesting you encounter. (In many ways, exploring unknown code is similar to exploring a dungeon in a good old adventure game.) Convert these notes into javadoc comments so you can generate more informative javadocs as you go along.

The profiler method is more about discovering the general patterns of calls, but every profiler should have a call stack view you can use.

Comments

[Eric Giguere]

Understanding a new code base is always a daunting task, even with documentation and class diagrams. I find it always helps to start small. You're obviously using a small part of the library already, so I would start with that API. Get the list of classes that you're using already and try to understand them first. Class libraries are usually written by the same person or team of persons, so gaining some insight into how they structure their code will help with understanding the whole library. This is true whether or not you use tools.