Fix & Finalize C++ Java Loader (JNI/JVMTI) for In-Memory Bytecode Transformation

Job ID: 40128672

Budget: $30 – $100 USD

I have a nearly finished C++ project that acts as a custom Java Virtual Machine (JVM) loader. The application's purpose is to load an encrypted JAR file from memory, initialize it, and use the JVMTI (JVM Tool Interface) to intercept and transform class bytecodes at runtime.

The core logic for JVM initialization, JAR decryption, and memory loading is already implemented. However, I am facing stability issues—specifically Access Violations (0xC0000005) during the early stages of class loading when the JVMTI agent starts interacting with the Java-side Transformer.

Technical Stack:

Language: C++ (Visual Studio / MSVC)

API: JNI (Java Native Interface), JVMTI (JVM Tool Interface)

Java Version: 1.8 (Targeting Minecraft/Game environments)

Goal: Dynamic bytecode retransformation via ClassFileLoadHook.

Tasks to Complete:

Debugging Access Violations: Fix the crash occurring at CallObjectMethod inside the ClassFileLoadHook. This involves ensuring correct thread attachment and pointer validation.

Global Reference Management: Ensure all JNI objects (like the Transformer instance) are properly stored as NewGlobalRef to prevent Garbage Collection issues.

Refining the Hook: Implement a robust filtering system to ensure only target classes are processed, avoiding overhead and recursion crashes.

Stability & Thread Safety: Ensure the loader works correctly when injected or started alongside a multi-threaded Java application.

Requirements:

Proven experience with JNI and JVMTI.

Expert-level C++ skills (pointer arithmetic, memory management, debugging).

Understanding of Java ClassLoaders and how JVM handles class definitions.

Ability to work with existing code and refactor it for stability.

What I provide:

Complete C++ Source Code.

The Java Transformer JAR (source or binary).

Testing environment/setup instructions.

Technical Requirements (Add this as a Note or File):
The loader must stay entirely in-memory (no temporary files).

Must handle classes being loaded before the Transformer is fully initialized.

Code must be compatible with x64 architecture.