Minecraft C++ Jarloader (Injection)

[xCrawl]

Hi, I have a C++ Jarload project, it works smoothly, but we can't change the classcount in the getloadedclasses hook in the update to the server I am doing right now
Our current code is as follows

jvmtiError detourGetLoadedClasses(jvmtiEnv* enva, jint* class_count_ptr, jclass** classes_ptr) {
    return orginalJvmtiGetLoadedClasses(enva, class_count_ptr, classes_ptr);
}

But here's how we do it

typedef jvmtiError(__stdcall* p_hook)(jvmtiEnv* env, jint* class_count_ptr, jclass** classes_ptr);
p_hook original_GetLoadedClasses = nullptr;

jint originalClassCount = 0;
jclass* originalClassArray = nullptr;
bool firstCall = false;
bool jarLoadingInProgress = false;
bool jarLoadingCompleted = false;

jvmtiError GetLoadedClasses(jvmtiEnv* env, jint* class_count_ptr, jclass** classes_ptr) {
    if (!firstCall) {
        firstCall = true;
        jarLoadingInProgress = true;
        auto result = original_GetLoadedClasses(env, class_count_ptr, classes_ptr);
        originalClassCount = *class_count_ptr;
        originalClassArray = *classes_ptr;
        return result;
    }
    else {
        auto result = original_GetLoadedClasses(env, class_count_ptr, classes_ptr);
        *class_count_ptr = originalClassCount;
        return result;
    }
}

im how to fix this (I don't know about JVM Bytecode Manipulation)

 

[Kriteax]

I have never worked with either C++ or the JVMTI, but here you have a free claude sonnet reponse because I couldn't care less:

Let me help analyze this code and explain what's happening. The post appears to be about manipulating the JVM's class loading behavior through the JVMTI (JVM Tool Interface) API.

// JVMTI function pointer type for GetLoadedClasses
typedef jvmtiError(__stdcall* p_GetLoadedClasses)(jvmtiEnv* env, jint* class_count_ptr, jclass** classes_ptr);
p_GetLoadedClasses original_GetLoadedClasses = nullptr;

// Cache for original classes
struct ClassCache {
    jint count = 0;
    jclass* classes = nullptr;
    bool initialized = false;
};

static ClassCache gClassCache;

jvmtiError GetLoadedClasses(jvmtiEnv* env, jint* class_count_ptr, jclass** classes_ptr) {
    // Always get the current state first
    jvmtiError result = original_GetLoadedClasses(env, class_count_ptr, classes_ptr);
    if (result != JVMTI_ERROR_NONE) {
        return result;
    }

    // Cache the first legitimate class list we see
    if (!gClassCache.initialized && *class_count_ptr > 0) {
        gClassCache.count = *class_count_ptr;
        
        // Allocate memory for the cached classes
        gClassCache.classes = (jclass*)malloc(sizeof(jclass) * gClassCache.count);
        if (gClassCache.classes) {
            // Copy the class references
            memcpy(gClassCache.classes, *classes_ptr, sizeof(jclass) * gClassCache.count);
            gClassCache.initialized = true;
        }
    }

    // If we have a cached state, use it
    if (gClassCache.initialized) {
        *class_count_ptr = gClassCache.count;
        *classes_ptr = gClassCache.classes;
    }

    return JVMTI_ERROR_NONE;
}

// Cleanup function to be called when shutting down
void CleanupClassCache() {
    if (gClassCache.classes) {
        free(gClassCache.classes);
        gClassCache.classes = nullptr;
    }
    gClassCache.count = 0;
    gClassCache.initialized = false;
}

The issue in the original code has several problems:

1. Memory Management: The original code doesn't properly manage memory for the cached class array, which could lead to memory leaks or crashes.
2. Race Conditions: The use of global boolean flags (firstCall, jarLoadingInProgress, etc.) isn't thread-safe and could cause issues in a multi-threaded environment.
3. Incomplete Implementation: The original code always returns the first class count it sees, which might not be what you want if you're trying to hide newly loaded classes.

The improved implementation I provided:

1. Uses a proper structure to cache the class information
2. Properly manages memory allocation for the cached classes
3. Provides a cleanup function to prevent memory leaks
4. Is more robust in handling errors
5. Still maintains the ability to "freeze" the class count at a certain point

To use this improved version:

1. Initialize your hook:

jvmtiEnv* jvmti;
// ... get your JVMTI environment ...

// Store the original function pointer
original_GetLoadedClasses = (p_GetLoadedClasses)original_function_pointer;

// Set up your hook
// The exact method depends on your hooking mechanism

1. Make sure to call CleanupClassCache() when you're done.

A few important notes:

1. This code still "freezes" the class count at the first non-zero value it sees. If you need different behavior (like updating the cache at specific times), you'll need to modify the caching logic.
2. Remember that manipulating JVMTI responses can have serious implications for the JVM's operation. Make sure this is really what you want to do.
3. Consider adding thread synchronization if your environment is multi-threaded.