Dumper-7: generating a usable SDK from an Unreal Engine game at runtime

A DLL injected into a running game, not a static analyser

The usage section is three steps long, which tells you the whole architecture. Compile the DLL in x64-Release configuration, inject the DLL into your target game, and the SDK is written out to the path given by `Settings::SDKGenerationPath`, which defaults to `C:\Dumper-7`. The repository describes itself as an SDK generator for all Unreal Engine games, with all of UE4 and UE5 supported.

Running inside the target process is the interesting constraint and also the point. A static disassembler reasons about the shipped binary and has to infer what a pointer offset means. Dumper-7 asks the engine itself, walking the live object array and name table and emitting what it finds. That is why it copes with obfuscation, custom offsets and heavily modified engines better than a purely static approach, and it is also why it is tied to a specific running instance rather than to a file.

The output is a header only SDK, and there is a dedicated `UsingTheSDK.md` for getting started with it or migrating from an older generated SDK. That file is where the consumption story lives, and the README does not duplicate it.

Three build systems for one C project

The repository supports three build paths, which is unusual for a project this small and mostly means it drops into whatever you already have. There is `CMakeLists.txt`, `CMakePresets.json` and a `cmake/` directory with a `UsingCMake.md` guide. There is `xmake.lua` and `Xmake.md`. There is `Dumper-7.sln` for Visual Studio, plus a `.vscode/` directory for editing.

For most people the Visual Studio solution is the shortest route, since the primary instruction is to produce an x64-Release DLL and injection tooling tends to live in the same Visual Studio world. The CMake and xmake paths exist so the generator can be built in CI or on a machine without Visual Studio installed, which matters more than it sounds once you are generating SDKs across dozens of games.

The source lives in a `Dumper/` directory. The repository is C, with 2291 stars, 520 forks and 40 open issues, and the last push was 2026-09-15. There is no license file in the tree listing, so if you plan to redistribute the generator or the SDKs it produces, the terms are not answered here and you would need to ask.

Every offset override lives in one function

The README is explicit about a rule that saves a lot of confusion: only override an offset if the generator cannot find it, or if what it finds is incorrect. All overrides go in `Generator::InitEngineCore()` inside `Generator.cpp`. Four things get overridden this way, and each has a different trigger.

`GObjects` is initialised through the object array, passing the offset, the chunk size and whether the array is chunked:

ObjectArray::Init(/*GObjectsOffset*/, /*ChunkSize*/, /*bIsChunked*/);

Encrypted object arrays have their decryption function supplied instead, and the comment in the sample warns you to use only types that exist in the generated SDK:

InitObjectArrayDecryption([](void* ObjPtr) -> uint8* { return reinterpret_cast<uint8*>(uint64(ObjPtr) ^ 0x8375); });

`FName` has two separate escape hatches. One forces the use of GNames when the `AppendString` offset is wrong, and the other overrides the offset outright with a type of AppendString, ToString or GNames plus a flag for whether it is a name pool. `ProcessEvent` is handled by `Off::InSDK::InitPE`, which takes an index. Between them these four cover most of the situations where a game ships a modified engine.

Why the same GObjects layout does not fit every engine version

The engine version split is the detail that catches people out, and the README explains it in plain terms. Layout overrides go in roughly line 30 of `ObjectArray.cpp`, and which struct you add to depends on the Unreal version. For UE4.11 through UE4.20 the layout belongs in `FFixedUObjectArrayLayouts`. For UE4.21 and higher it belongs in `FChunkedFixedUObjectArrayLayouts`. Add a new layout only when `GObjects` is not found automatically.

The reason is visible in the two default structs. The fixed layout has three fields, with the objects offset at zero, the max objects offset at 0x8 and the num objects offset at 0xC. The chunked layout has five, since a chunked array also tracks where the chunk metadata lives:

FChunkedFixedUObjectArrayLayout // Default UE4.21 and above
{
    .ObjectsOffset = 0x00,
    .MaxElementsOffset = 0x10,
    .NumElementsOffset = 0x14,
    .MaxChunksOffset = 0x18,
    .NumChunksOffset = 0x1C,
}

A game on UE4.25 therefore needs the chunked form, and pasting the fixed one is a mistake that presents as a generator that starts and then dumps nothing. Note also that the default offsets in these samples are placeholders at zero rather than real values, so they describe the shape of the structure rather than working values for any particular build.

The ini file that configures a dump without a rebuild

Settings can be changed at runtime through a `Dumper-7.ini` file rather than by editing `Settings.h`. It can be per game, placed in the same directory as the game's executable, or global, placed under the default output directory. One rule is easy to get wrong: profiles do not merge, so a global profile does not change your default settings.

Four settings exist. `SleepTimeout` delays the dump when non-zero, and the unit is the confusing part, because values under 1000 are assumed to be seconds and anything else is milliseconds. `DumpKey` starts the dump on a keypress, given as a hex or decimal virtual keycode, with hex values starting at `0x`. If both are set, whichever fires first triggers the dump. `SDKNamespaceName` changes the namespace in the generated files. `SDKGenerationPath` changes the output directory instead of the default, where paths are relative to the game executable unless absolute with a drive letter, `..` reaches parent directories, and no quotes should be included.

The README's own example combines all four:

[Settings]
SleepTimeout=30
SDKNamespaceName=MyOwnSDKNamespace
DumpKey=0x77
SDKGenerationPath=./

Those settings generate the SDK in the same folder as the game and start after 30 seconds or on pressing F8, since 0x77 is that key's virtual keycode. For scripted work the key setting is usually dropped and a timeout used instead, and for anything where the game lives somewhere awkward an absolute path is less fragile than `./`.

What the issue tracker expects from you

The README closes with a detailed triage guide, and it is unusually specific about what makes an issue actionable. For a game that crashes while dumping, attach the Visual Studio debugger to the game and inject a debug configuration build of the DLL, then include a screenshot of the exception, a screenshot of the callstack and the console output.

For compiler errors in the generated SDK, the first instruction is to verify you followed `UsingTheSDK.md`, then send a screenshot from the error window with `Build Only` selected rather than `Build + Intellisense`, since Intellisense often reports false positives. You also need a screenshot of the first error in the output window rather than the error window, plus the code location causing it. Fixes are welcome alongside reports, with missing padding in a predefined struct and incorrect macro use given as examples. If the SDK will not compile and you cannot resolve it, the request is to upload the entire generated folder rather than just the CppSDK output.

The last line of the README is a warning worth repeating back to yourself before filing: if your own DLL project crashes, verify your code carefully, because the error most likely lies within the generated SDK rather than in the generator.

Two releases are on record. v7.0.0 on 2026-07-18 introduced IDA Mappings V2 and points at a separate tool, IDAExecFunctionsImporter by Fischsalat, as the consumer of that format. v7.0.1 on 2026-07-26 added two `UClass::GetFunction` overloads and removed a duplicate `Struct.GetProperties()` call in `DumpEditorOnlyMetadata()`.

Editorial conclusion

Dumper-7 is aimed at one job, and it is a job most static analysers cannot do: reading the engine structures out of a live process so the SDK reflects the exact build you are sitting in front of. The three steps are compile in x64-Release, inject into the target, read the output from the configured path, and everything else in the README exists to handle games where autodetection guesses wrong. Reach for `Generator::InitEngineCore()` when GObjects or FName cannot be found, and the two layout structs in `ObjectArray.cpp` when the engine version falls on the wrong side of the UE4.21 boundary. v7.0.0 moved to IDA Mappings V2 and v7.0.1 added two `UClass::GetFunction` overloads, with the repository pushed on 2026-09-15. Worth knowing before you build on it: no LICENSE file appears in the tree listing, so the licensing terms are not something this repository settles.

Frequently asked questions

Official sources

1. Encryqed/Dumper-7 on GitHub
2. Issues
3. README
4. Releases