System Architecture

The launcher executable starts with a native GUI and begins scanning for Minecraft's GLFW window handle. Once found, it resolves the process ID and waits for the JVM to fully initialize before proceeding.

• Scans for GLFW30 window class via FindWindow
• Resolves target PID from the window handle
• Extracts the embedded loader DLL to a uniquely-named temp file using GetTickCount() to avoid file-lock collisions on re-injection

A remote thread is created inside the target process to call LoadLibrary on the extracted DLL. This causes Windows to map our loader into Minecraft's address space and execute DllMain.

• Opens the target process with PROCESS_ALL_ACCESS
• Allocates memory in the remote process via VirtualAllocEx
• Writes the DLL path string into remote memory
• Creates a remote thread targeting LoadLibraryA

Once inside the game process, the loader DLL spawns a background thread. It enumerates all loaded modules to locate the JVM's exported JNI_GetCreatedJavaVMs function, then attaches the current thread to the Java runtime.

• EnumProcessModules scans all loaded DLLs in the process
• GetProcAddress searches each module for JNI_GetCreatedJavaVMs
• The discovered function returns the active JavaVM pointer
• AttachCurrentThread binds the native thread to JNI, yielding a JNIEnv

The loader locates the JVM's instrument.dll and calls its Agent_OnAttach function with the path to the embedded JAR. This loads the JAR as a Java agent, triggering agentmain() which captures the Instrumentation instance for later bytecode transformation.

• Locates instrument.dll in the JVM's bin directory via GetModuleHandle
• Resolves the Agent_OnAttach export from instrument.dll
• Calls Agent_OnAttach with the temp JAR path as argument
• agentmain() stores the Instrumentation instance and registers it via System.getProperties()
• No JVMTI needed — uses the standard Java Instrumentation API

The Java agent JAR is embedded inside the loader DLL as a compiled byte array. It is extracted to a temp file before agent loading. After load, the temp JAR is immediately deleted from disk as an anti-detection measure.

• JAR binary is compiled into the DLL at build time via jar_to_array.py
• Written to %TEMP% with a tick-count-based unique filename
• Agent loading makes classes available through the app classloader
• Temp JAR is erased from disk after successful load
• DLL PE headers are zeroed in memory to reduce forensic footprint

The native loader finds and invokes Bootstrap.init() via JNI. This initializes the module system, registers classloader-safe callbacks via System.getProperties(), installs bytecode transformers, and starts the IPC pipe server.

• Class.forName loads Bootstrap through the app classloader
• Callbacks registered in System.getProperties() as Consumer/Function objects
• ModuleManager.init() registers all combat, movement, and utility modules
• TransformerRegistry receives RenderTransformer and KeepAliveTransformer
• PipeServer opens a named pipe for communication with the injector GUI

Bootstrap registers a ClassFileTransformer with the Instrumentation API, then calls retransformClasses on the target Minecraft classes. The transformer intercepts each class and uses ASM to inject callback hooks that route through System.getProperties() — avoiding classloader conflicts entirely.

• Instrumentation.addTransformer() registers the ClassFileTransformer
• retransformClasses() is called on MinecraftClient, InGameHud, and ClientConnection
• ASM ClassWriter + MethodVisitor inject hooks into render, HUD, and packet methods
• Hooks call System.getProperties().get(key) to retrieve Consumer/Function callbacks
• This bridge design avoids LinkageError from classloader mismatches
• Transformer is retained for later cleanup/retransformation

With bytecode transformed, the injected callbacks fire every game tick. The render hook drives the module system and key handler. The packet hook enables network interception. All module logic executes within these entry points.

• Bootstrap.onRender() — called every render frame, ticks all enabled modules
• Bootstrap.onHudDraw() — called during HUD rendering for overlay drawing
• Bootstrap.onPacketReceive() — intercepts inbound packets, can cancel processing
• MCReflect initializes on first render call, caching Minecraft field/method handles

Shutdown is triggered via an IPC UNINJECT command from the launcher. Bootstrap.shutdown() disables all modules, clears transformer state, and calls Instrumentation.retransformClasses() with an empty transformer — restoring original bytecode. System properties are cleaned and all traces are removed.

• UNINJECT command received via named pipe IPC
• Bootstrap.shutdown() disables all active modules
• TransformerRegistry cleared, retransformClasses() restores original bytecode
• System.getProperties() entries for callbacks are removed
• DLL PE headers already zeroed; temp JAR already deleted
• Launcher GUI shows uninject confirmation popup