CODEWITHSUNDEEP
javajvmreverse-engineeringbytecode
meepledemeep
meepledemeep

Reputation: 21

Reverse Engineer Java *.class file to change data type of variable

I have a problem with an old application which runs on a Java Tomcat server and the source code for the application is not fully available, but the .class files are obviously all running on the tomcat server.

Can I somehow manipulate the bytecode of a .class file (used by JVM) so that I can change a variables datatype (because this is what has to be done)? Or even reverse engineer it to its old .java source code?

I have used decompilers and javap command up to now. Can I somehow copy the whole Tomcat application and:

  1. decompile it
  2. do my changes
  3. recompile it?

Upvotes: 2

Views: 952

Answers (3)

Erdogan Kurtur
Erdogan Kurtur

Reputation: 3685

I did that. Not exactly that, but something very similar. Instead of decompiling and recompiling, which is very long, and tedious, I directly edited the byte-code of the class file.

pros

  • You do not need to compile anything at all, you just edit a file
  • no SDK, no IDE, etc is necessary, just a java-byte code editor
  • for small changes you can get away with single method modification

cons

  • very-very error-prone even if you know what you are doing
  • no way to track changes as you do with git
  • will probably require modifying all dependent classes
  • you should have some knowledge about how compiled code looks like, and behaves before even attempting such a thing.
  • you will most likely break a law or two since this will not be for "educational" purposes
  • you will be marked as "the hacker" and every odd job will be forwarded to you

PS: I had to edit licensing class of a product to allow more users. The company writing it ceased to exist, so buying was not an option. We switched to a new product anyway, it was just temporarily.

Upvotes: 0

arcy
arcy

Reputation: 13133

I have a wild and crazy idea; I haven't done this, but as long as we're talking about things that are theoretically possible...

IF you manage to decompile all the code and get a system that you can recompile and run (and I strongly recommend you do that before you make any changes), if you are able to identify where the int is that you want to replace with a long, and then all the direct and indirect references to it, hopefully (because it's just this file size limit that you mention elsewhere) you end up with only a handful of classes.

The decompile should tell you their names. Create new classes with the exact same names, containing (of course) all their decompiled code. Change the methods that you need to change.

Now put those classes in a jar that is searched before the jar containing the application. You're limiting the number of classes for which you're providing new .class files to just those. This makes it easier to see exactly what has been changed, for future programmers, if it doesn't do anything else. It's possible because of the way Java handles its runtime; the step that's equivalent to 'linking' in a traditional compiled non-virtual-machine language happens when the class is loaded, instead of at compile time.

Upvotes: 0

arcy
arcy

Reputation: 13133

Well, if you decompile it to make changes and recompile, then you're not going to need to change the byte code directly.

If you change the type, you'll have to change the type of any methods (like getters and setters) that use the variable. Then you'll need to change the calls of any methods in all classes that CALL those methods, and the types of their variables that hold these values, etc. The good news is that, if you manage to decompile it successfully, your IDE will tell you where all those places are, assuming the new type is incompatible with the old type.

I would evaluate this as "theoretically possible", but problematic. With the little information you've given us, there's no way to know the size of the job AFTER you successfully decompile the entire application.

Upvotes: 3

Related Questions