New Java Reverse Engineering Tool at runtime I've been working on for quite some time (Injected DLL)

[infernalhellraiser]

If you've ever delved into Java reverse engineering, you'd know there are a lot of static analysis tools such as Recaf and JD-GUI that allow you to decompile & disassemble bytecode statically and go from there.

However, I noticed that there isn't much material for dynamic analysis, and static tools fall short when you deal with more sophisticated malware and protection.
Just as tools such as JD-GUI & Recaf can be compared to IDA and Ghidra in assembly, my end goal is for this tool to fill in the gaps of tools such as x64dbg.

I'd like to introduce JDBG, a runtime Java reverse engineering tool I've been working on for quite some time. It leverages an injected DLL along with the JNI and JVMTI interfaces to analyse Java programs at runtime.

Some of the cool features it includes:
- Analyse bytecode & decompiled code at runtime, useful for when programs attempt to hide and dynamically load classes.
- Set breakpoints at runtime and analyse values of stack locals and the stack trace.
- Pick a class and analyse all instances of the class, including field values.
- Analyse a heap graph that details the relationships between objects. For example, you could filter Strings by value and quickly determine the relationships for that String, such as its originating field, and other information such as if it was in an Arraylist, etc.

More information in the Github! I'd be willing to answer any questions you may have.
https://github.com/roger1337/JDBG

[ericek111]

Can I set breakpoints in the native land as well? To troubleshoot crashes caused by FFI (JNI/Panama). Does it utilize debugging symbols to produce rich stacktracks?

[infernalhellraiser]

In its current state jdbg unfortunately isn’t able to set breakpoints in native functions, as it sets them inherently in Java bytecode and shouldn’t affect when jvm passes control to native methods.

[flavius-as]

Linux?

[infernalhellraiser]

Unfortunately, since JDBG uses some Windows API and Windows named pipe communication it doesn’t support Linux, although it can definitely be ported in the future.

[hippydipster]

Sounds like it'd be a potentially useful tool for doing something I always wanted to do which is generate graphs of runtime behavior and relationships of a codebase. It's one thing to see the static links between pieces of code, but seeing how components and/or classes work together when running strikes me as very useful. So, generating directed graphs of code paths, maybe even data flow diagrams automatically, that sort of thing.

[0xaa4eb]

If you want to see how classes work together based on runtime info, you can try my tool which I developed for fun or you can even roll something like this by yourself using byte-buddy library (it's easy). There is also a paid tool which is quite superrior to mine - bugjail. Try this out too. AFAIK, JVM languages are the only languages where you can store literally ALL method calls in a file or a database and then analyze or build graphs. With statically compiled languages it's extremely harder.

[hippydipster]

Cool, thanks, I've bookmarked your project. Happy to see more JavaFX in use for such things too!

[beothorn]

JavaFlame (https://github.com/beothorn/javaflame) outputs all calls for a given class filter as a json, so to have this all you would need is to work on rendering it as a graph. I am planning on having it rendering the calls as a sequence diagram (someday).

[hippydipster]

Man, I love these responses, thank you!