Offensive C development has a structural flaw: the tooling is embarrassing.

Not the techniques. The techniques are sophisticated, well-researched, constantly evolving. The people building them are sharp. But the infrastructure they build on? It’s a pile of decade-old GitHub PoCs, abandoned loaders with no documentation, and the kind of copy-paste archaeology that would make a software engineer physically recoil.

You want to implement a reflective loader? You hit GitHub, rip a chunk of code from a five-year-old PoC that hasn’t seen a commit since the original author got a real job, and try to make it fit your implant. Cue the next six hours of your life evaporating in a debugger, chasing arbitrary access violations, wondering why you chose this career path.

We’ve collectively accepted a standard of tooling that the rest of the industry moved past years ago. And we’ve accepted it because the assumption has always been that low-level offensive code is inherently unmaintainable. That you can have clean architecture or operational effectiveness, but not both. That the “opsec” build will always be an unreadable nightmare of inline assembly and opaque macros, and that’s just the cost of doing business.

That assumption is wrong. While offensive tooling has long embraced reusable techniques, it has rarely treated execution mechanics as a first-class engineering boundary. SindriKit applies Dependency Injection to that boundary, allowing capabilities to remain stable while execution profiles evolve independently.

You can explore the source code, view the architecture, and contribute to the project over on GitHub at SindriKit.

The Problem Is Structural

Let’s be specific about what’s broken, because “the tooling is bad” isn’t an argument, it’s a complaint.

The real problem is that offensive tools couple two things that should never be coupled: the logic of a technique and the mechanics of its execution. Your reflective loader doesn’t just load a PE image. It loads a PE image using VirtualAlloc, using LoadLibrary, using whatever Win32 calls you hardcoded three months ago. The technique and its execution profile are fused together at the source code level.

This creates the nightmare every offensive developer knows intimately. You build something. It works. Then you need to evade an EDR and those Win32 calls are glowing red flares. So you rewrite. Now you have two codebases: the “clean” one for testing, and the “opsec” one that nobody wants to touch. The EDR changes. You rewrite again. The target is CrowdStrike instead of SentinelOne. You rewrite again.

You are not fighting the problem. You are fighting your own architecture.

The solution isn’t a new technique. It’s a new structure. One the rest of software engineering figured out decades ago.

And this is the point worth being precise about: SindriKit is not a loader. The loader is the first module that proves the architecture works. What SindriKit actually is is a framework for composing offensive capabilities around interchangeable execution mechanics. That distinction matters, because there are already many loaders. There are not many frameworks built around the insight that technique and execution profile should be decoupled at the design level.

The Architecture

SindriKit is built on a single premise: isolate the intent of an offensive technique from its underlying execution mechanics.

Everything flows from this. Rather than hardcoding APIs, execution is orchestrated through stateful context objects. The loader module provides the first proof of this architecture in action, using snd_loader_ctx_t to orchestrate a payload:

typedef struct {
  const snd_buffer_t *raw_source;
  snd_pe_parser_t pe;
  snd_pe_target_t target;
  snd_loader_stage_t stage;
} snd_loader_ctx_t;

As the payload moves through the pipeline, ctx.stage tracks its lifecycle to ensure teardown and cleanup are deterministic. By centering everything on this context object and its state, the framework offers a strictly layered API:

            +-----------------------------------------------------------+
            |                      Chains (High-Level)                  |
            |  snd_prepare_reflective_image(&ctx)                       |
            +-----------------------------------------------------------+
                                          |
                                          v
            +-----------------------------------------------------------+
            |                      Engine (Low-Level)                   |
            |  snd_apply_relocations / snd_resolve_imports              |
            +-----------------------------------------------------------+
                                          |
                                          v
            +-----------------------------------------------------------+
            |                     Universal Modules                     |
            |  snd_pe_parse (parsers/pe)                                |
            +-----------------------------------------------------------+

Operators get fire-and-forget chains at the top. Developers who need granular control drop down to the engine level.

The framework is structured around clear layers, but the real innovation isn’t the context struct itself. It’s what the context object allows you to do next.

Dependency Injection

This is where the design pays off. In a traditional loader, execution mechanics are fused directly to the logic. Your code looks like this:

// Traditional: Hardcoded execution mechanics
pMemory = VirtualAlloc(NULL, size, MEM_COMMIT, PAGE_READWRITE);
pModule = LoadLibraryA("ntdll.dll");
pFunc = GetProcAddress(pModule, "NtProtectVirtualMemory");

When that gets flagged by an EDR, you have to rewrite the capability. SindriKit removes the hardcoded APIs. Before starting the loading chain, you populate your context with an execution profile:

// SindriKit: Injected execution mechanics
ctx.mem_api = &snd_mem_win;
ctx.mod_api = &snd_mod_win;

When you need to evade an EDR and shift to direct syscalls, you don’t rewrite the loader. You don’t touch the core algorithm at all. You change two lines:

ctx.mem_api = &snd_mem_native;
ctx.mod_api = &snd_mod_native;

The technique never changes. Its operational footprint does. The same capability can move from Win32 APIs to native syscalls without modifying the underlying implementation.

This is Dependency Injection. It’s a foundational pattern in mainstream software engineering, used everywhere from web frameworks to game engines. While many frameworks expose pluggable components, execution mechanics themselves are rarely modeled as a primary architectural boundary.

The consequence is that capabilities become portable across execution profiles. Any capability built on SindriKit can change its entire operational character by swapping a profile, not rewriting a codebase.

Native execution profiles require syscall resolution, but no single extraction technique works everywhere. SindriKit treats syscall resolution as another injectable execution mechanic:

snd_set_syscall_strategy(...)

If one strategy fails, the framework falls through to the next. The capability remains unchanged because syscall resolution is not part of the capability itself; it is simply another execution detail that can be replaced.

The same architectural principle applies throughout the framework: capabilities remain stable while execution mechanics evolve independently.

Debugging Without Going Blind

There’s a fair objection to low-level abstraction: when something breaks deep inside a 3000-line codebase and you can’t use printf or GetLastError, you’re flying blind.

SindriKit answers this with the snd_status_t system. Every function returns a status object that propagates subsystem, failure location, and failure reason up the call chain:

status = snd_execute_reflective_image(&ctx);
if (status.code != SND_SUCCESS) {
    snd_status_print(status);
    return status.code;
}

During development, this tells you exactly what broke and where. When you deploy, flip SND_ENABLE_DEBUG=OFF at build time and the entire status system collapses to silent integer codes with absolutely zero debug strings. The rich developer experience doesn’t cost you anything operationally.

Composability in Practice

The framework earns its keep at the moment of integration when you’re dropping SindriKit into a real, ongoing exploit chain.

When your exploit gains execution, you need to load a post-exploitation module cleanly, without fumbling the fragile context you just earned, and without cluttering your vulnerability logic with loading mechanics.

Two lines in your CMakeLists.txt:

add_subdirectory(libs/SindriKit)
target_link_libraries(exploit_common PUBLIC Advapi32 sindri::engine)

Your exploit just inherited a full loading engine, a PE parser, and dynamic syscall resolution strategies. The moment SYSTEM is confirmed, the transition looks like this:

// Resolve NTDLL via PEB walk
PVOID ntdll;
snd_peb_get_module_base_by_hash(SND_HASH_NTDLL_DLL, &ntdll);
snd_set_ntdll(ntdll);

// Native execution profile
ctx.mem_api = &snd_mem_native;
ctx.mod_api = &snd_mod_native;

// Load and execute
snd_buffer_load_from_disk("admin.exe", &file_buf);
ctx.raw_source = &file_buf;
snd_prepare_reflective_image(&ctx);
snd_execute_reflective_image(&ctx);

No extra functions or boilerplate. And if your threat model demands something the built-in profiles don’t cover, a topology-aware allocator, a custom memory primitive the EDR isn’t watching, you write one function, copy the base profile, and swap the mechanic. You bring the mechanics. SindriKit brings the architecture that makes them composable with everything else.

The Point

Offensive development has been operating under a false constraint: that operational effectiveness requires sacrificing engineering discipline. That the two-codebase problem, one clean build for testing, one unreadable build for deployment, is just how it works.

It isn’t. It is just the consequence of coupling technique to execution mechanics at the source level.

SindriKit exists to end the cycle where every change in an EDR’s detection strategy forces you to rewrite working capabilities.

Detection logic will constantly evolve. Execution mechanics will constantly evolve. Those changes are inevitable.

What should not be inevitable is rewriting working capabilities every time they do.

Architecture should absorb those changes, not operators.