gravitlauncher/gravitguard

Purpose

GravitGuard 2 Pro is a Windows-native protection template for Java applications. It builds a native launcher plus a guard DLL, intended to start or supervise a JVM-based target and apply native checks/hooks. The included Java program is a minimal demonstration target.

Build Outputs and Entry Points

• Native executable entry point: GravitGuard2/GravitGuard2.cpp, built by GravitGuard2/GravitGuard2.vcxproj.

• Guard DLL process entry point: GuardDLL/dllmain.cpp, built by GuardDLL/GuardDLL.vcxproj.

• Java demonstration entry point: demo-application/src/main/java/org/example/Main.java.

• The solution is GravitGuard2.sln; the README specifies separate x86 and x64 Release builds and requires JAVA_HOME.

Native Launcher Stage

GravitGuard2/GravitGuard2.cpp is the top-level native application boundary. Its architectural role is to operate before or alongside the Java target, where it can establish the protected process/JVM environment and coordinate use of the guard DLL. It is the executable artifact expected to be distributed with the protection.

Guard DLL and Protection Core

The DLL contains the core protection implementation:

• GuardDLL/GravitGuard.cpp and GuardDLL/GravitGuard.h define the principal GravitGuard-facing implementation/API.

• GuardDLL/guard.cpp and GuardDLL/include/guard.h contain guard-specific logic and shared declarations.

• GuardDLL/dllmain.cpp attaches this functionality to DLL lifecycle events.

This division makes the launcher/process boundary separate from code that executes inside a guarded process.

Hooking / Interception Boundary

Hooking is a first-class mechanism:

• GuardDLL/hooks.cpp implements hook setup or hook callbacks.

• GuardDLL/GuardDetour.h and GuardDLL/GuardDetourHandler.h define detour abstractions and handling contracts.

• minhook is an external/submodule dependency used for native API detouring.

Hooks form the primary interception boundary between guard policy and Windows/JVM-related runtime behavior. Low-level Windows compatibility definitions are isolated in GuardDLL/WindowsInternalDefines.h.

JVM and Java Target Integration

The native side includes JVM-oriented definitions in GuardDLL/jli_defines.h, indicating direct integration with Java launcher/JLI interfaces rather than only controlling an unrelated child process. The Java application remains a separate Gradle project under demo-application, with its executable application code at demo-application/src/main/java/org/example/Main.java.

The expected flow is native launcher/guard initialization → JVM or Java target startup → native hooks/checks active during target execution.

Diagnostics and Runtime Dependencies

GuardDLL/Logger.cpp and GuardDLL/Logger.h provide diagnostics from the injected/loaded native guard layer. The material runtime dependencies are Windows, a JDK/JVM available through JAVA_HOME, and the MinHook native detouring library. CI is Windows/MSBuild-oriented through .github/workflows/msbuild.yml.