Working on Java

There are a few things you should know before working on Java games:

• Don't attach to the launcher, attach to Java itself: The launcher usually just starts the real game process and exits or sits in the background. Look for a java process that appears after starting the game. That's usually the one you want.
• Don't assume Java values are big endian in process memory: Java class files and some Java APIs use big endian, but normal heap values in a running JVM on x86/x64 are usually stored in the machine's native byte order, so Host or Little is normally correct.
  • Use Big only if you know the data itself is big endian. For example a custom buffer, network data, save data, emulator memory or something the game manually stores in that format.
  • If your scan results make no sense, try the other endianness once. But don't start with Big just because the target is Java.
• SIGSEGV should usually be ignored for Java processes: Java uses SIGSEGV internally for memory management and runtime tricks. If GDB stops on every SIGSEGV, Java targets become almost unusable.
  • By default, Settings -> Java -> Ignore SIGSEGV for Java processes should be enabled.
  • PINCE's Java detection is simple: it checks whether the attached process name starts with java.
  • If the option does not work because the process has a different name, set SIGSEGV to only Pass to Program manually in Signal Behaviour.
  • You can also read more about Java and SIGSEGV here.
• Raw addresses can be less stable than in native games: The JVM can move objects around during garbage collection. If you find a value and it later disappears or points to nonsense, it might have moved.
  • Static fields, long-lived objects and values owned by native libraries tend to be more stable.
  • Pointer paths may break more often than they do in simple native games, especially for ordinary heap objects.
• Java is not Mono/IL2CPP: The Mono/IL2CPP Dissector is for .NET/Unity runtimes. It won't understand a normal Java JVM.