3

I modified the byte-code of a third party Java desktop application's .class file (and repacked the .jar), only to see that during runtime, my change made no difference, unless my change caused a crash somehow. The most simple experiment I did was to use a hex editor and simply replace a letter in a text string in the .class file. Runtime (of course, after restarting the Java application), the text was still the original text.

Here's an example of the original byte-code:

ldc "Some text."

Using a hex editor, I changed the string, and looked again in the byte-code editor:

ldc "Xome text."

The decompiled code also shows the modified string. There are no more references to the original string in the .class file. Despite this change, the displayed text at runtime is "Some text." rather than "Xome text.".

Is there anything I need to take into consideration, e.g. some sort of cache (outside the scope of the application) that must be cleared? I tried to delete the "Temporary Internet Files" in the Java console, to no avail.

Thank you for any assistance you can provide! :)

Removed: The decompiled code and modified files for the real-world application I was experimenting on, due to their questionable nature (didn't really help anyone anyway).

  • 1
    I didn't get the idea of your question ?!? Could you be a bit more explicit ? – perror Jul 4 '14 at 12:46
  • Are you sure you changed all instances of that static string? And are you sure the string you're seeing at runtime isn't dynamically generated? (Best to decompile the class and find out.) – Jason Geffner Jul 4 '14 at 12:52
  • 2
    The text may have been created by some other .class file. Check how many .class files are within the jar. – 0xec Jul 4 '14 at 15:23
  • Can you post the jar before and after modification? – Antimony Jul 4 '14 at 15:31
  • 2
    If it's a real world application there must be some protection, some sort of obfuscation, encryption etc. So my guess is that string is encrypted and only decrypted on running. So you may never see the string in a static .class file. What you are editing is probably something else. – 0xec Jul 4 '14 at 16:00
3

Firstly, I would mention that instead of using a general purpose hex editor, a dedicated class editor would be much better. There are plenty of them.

You tried editing the class file and to your surprise the changes you made were not reflected. At that point you should be pretty much sure that there must be some other tricks such as generating the strings dynamically, encryption, obfuscation etc.The class files could also be loaded from some other locations such as a cache which you do not expect.

One way to get information about which classes are loaded is to use the following command line switch while starting java.

java -verbose:class -jar <Your jar file>

This way the jvm will notify you when classes are loaded and from which locations. Using this you can know if there is some sort of hidden cache from which it loads class files.

After this option fails, i.e. when you are sure that there is no such hidden cache, you can almost be sure that there is encryption involved or the strings are generated dynamically. Decompiling would help, but of course if there is no obfuscation to hinder decompiling. If everything else fails, you may try inspecting the bytecode of the classfiles as a last resort.

  • Thank you very much for this answer, and for providing even more information! :) – Dimm Jul 5 '14 at 11:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.