Version
1.8.9 ▼
1.8.9
26.2 (coming soon)

Injection

Grave ships with two injectors per platform: a friendly one for everyday use, and a raw one for users who want stealth.

Windows macOS

macOS

You must disable System Integrity Protection (SIP) before Grave will run.

macOS blocks unsigned binaries from attaching to other processes. With SIP enabled, both the bundled .app and the standalone Unix executable will fail silently the moment they try to inject into the Minecraft Java process. Grave is not notarized by Apple, so the only way to give it the privileges it needs is to turn SIP off.

How to disable SIP:

  1. Boot into Recovery Mode: shut down, then press and hold the power button until you see “Loading startup options”. Choose Options → Continue.
  2. From the menu bar, open Utilities → Terminal.
  3. Run csrutil disable and confirm with your admin password if prompted.
  4. Reboot normally.

Once SIP is off, you're free to use Grave with no issues.

On macOS, Grave ships with two injectors that target any java processes.

GraveInjector.app (bundled application)

Download the .dmg, run and drag the .app to your Applications folder, double-click it and the bundled GUI handles everything: locating Minecraft, attaching, and loading the client.

GraveInjector (Unix executable)

A standalone command-line binary you can run from a terminal or wire into your own scripts. Same payload, no GUI, no logo.

How macOS injection works

Injection is fully fileless. The injector pushes both the Mach-O loader dylib and the client .dylib bytes through POSIX shared memory, then reflectively maps the loader into Minecraft in-process. The loader pulls the client out of shared memory and maps it the same way. Nothing touches disk.

The reflective loader is a shellcode-style, position-independent Mach-O blob that maps itself into fresh MAP_JIT memory and walks its own load commands, resolves every import through dlopen and dlsym, and applies its chained fixup table, everything dyld would normally do but done in-process with no dyld involvement. Once the loader is live it opens the POSIX shared memory segment holding the client, loads it the same way, and unlinks the segment immediately after. By the time injection completes there are no mapped files, no shared memory names, and no kernel objects left behind.

The shellcode loader component is based on outflanknl/macho-loader. The in-memory dylib loader that handles the client payload is a separate piece built on Apple's open-source dyld internals.

Once you're injected, browse modules in the sidebar to see what's available.