I'm currently working on a university project that involves debugging JVM bytecode from production applications. The catch is that I'm focusing on cases where the bytecode has been stripped of debugging information—like the LineNumberTable, LocalVariableTable, and StackMapTable—and I don't have access to the original source code. I'm looking for insights into manual dynamic analysis of this kind of bytecode. How often do you find yourselves in this situation? What specific use cases can you share? What tools do you recommend for this? Are you using anything publicly available or developed in-house? It's common for release JARs to go through these processes, often after being optimized or obfuscated by tools like ProGuard. I know traditional Java debugging provides certain insights with debug info, but I'm curious about how to handle scenarios where that data is missing. Also, legally, I understand there are permissible reasons to analyze and modify licensed software—such as fixing bugs or creating compatible products—but I'd love to get your thoughts on all this!
4 Answers
I once had to recompile a legacy JAR when the source code was lost after 20 years. It was a small but crucial application, and we were only able to understand its logic after analyzing the bytecode. After matching the data processes, we managed to migrate the system into a modern solution without issues. It's wild looking back to see how everything came together without any documentation!
I’ve had some experience debugging native libraries, but I haven’t dealt much with obfuscated JARs. It’s tricky when you do get into unknown bytecode territory! You often have to rely on examining the state at method entry and then hooking calls to validate what’s going on.
Have you tried JDBG? It’s a Windows-only tool. You might be able to somewhat reconstruct the LineNumberTable and LocalVariableTable through careful analysis of method instructions, though getting line numbers right can be tricky. If you can track how instructions are built into the final AST model, you might be able to insert line number entries back in. Some decompilers, like FernFlower, might offer similar capabilities, but they have limitations too.
I tried some static analysis too, but you’re right—it can often be inaccurate, especially when dealing with complex bytecode.
I faced a similar challenge while working on my dissertation. I had to reverse-engineer an Android app to add a feature that wasn’t originally there. Instead of decompiling everything, I focused on extracting specific functions, getting them to a compilable state, and then recompiling them as if they were external dependencies. This let me make targeted changes without having to fix the app as a whole. Later, I used the Xposed Framework to hook into my banking app’s authentication mechanism to build a custom dashboard. By analyzing the bytecode, I could set hooks to capture and understand the data flow. Java Agents could also help with this kind of debugging, as tools like ByteBuddy let you modify bytecode at runtime.
That's interesting! But isn’t Android now using DEX instead of JVM bytecode? I’ve heard ART handles the execution differently now. How does that affect reverse engineering tools?
You’re right! The hooking methods can be similar because of their shared background, but I think Java Agents have a lot of potential for traditional JVM work, too.
Yeah, I downloaded JDBG but couldn't get it to work even for applications with debug info. Did you have any luck with it?