youssefnoob003-SindriKit/docs/domains/primitives/mapping/techniques.md

Mapping Techniques

The mapping subdomain exposes section operations through the snd_mapping_api_t function pointer table. Like memory and process primitives, the framework never hardcodes OpenFileMappingW or NtOpenSection; callers inject the desired backend at initialization time.

Paradigm 1: Win32 Mapping (snd_map_win)

The snd_map_win implementation backs the mapping interface with standard Win32 APIs from kernel32.dll:

• Open: OpenFileMappingW with FILE_MAP_READ
• View: MapViewOfFile followed by VirtualQuery to determine the mapped region size
• Close: CloseHandle

Path Constraints

The Win32 subsystem prepends its own namespace to section names. This backend is suitable for conventional named mappings (Local\..., Global\...) but must not be used for absolute NT Object Manager paths such as \KnownDlls\ntdll.dll. Those paths require snd_map_nt or snd_map_sys.

OpSec Implications

Every call routes through userland hooks in kernel32.dll and ntdll.dll. Use this backend only for diagnostics or environments where EDR instrumentation is absent.

Paradigm 2: NT API (snd_map_nt)

The snd_map_nt implementation resolves NtOpenSection, NtMapViewOfSection, and NtClose from ntdll.dll via PEB walking and hash-based Export Address Table (EAT) parsing. No GetProcAddress or plaintext API strings are required.

• Open: NtOpenSection with SECTION_MAP_READ and case-insensitive object attributes
• View: NtMapViewOfSection into GetCurrentProcess() with PAGE_READONLY
• Close: NtClose

OpSec Implications

This paradigm bypasses kernel32.dll but still executes through in-process ntdll.dll stubs. Inline EDR hooks on those stubs will still fire. It is the typical choice for KnownDlls bootstrapping when the syscall pipeline is not yet configured.

Paradigm 3: Direct Syscalls (snd_map_sys)

The snd_map_sys implementation invokes NtOpenSection, NtMapViewOfSection, and NtClose through the framework's syscall resolution pipeline and custom ASM stubs.

• Open / View / Close: Direct syscalls resolved by compile-time function hashes (SND_HASH_NTOPENSECTION, etc.)

OpSec Implications

Direct syscalls bypass userland EDR hooks placed inside ntdll.dll stubs. This is the preferred backend for stealth KnownDlls mapping once the syscall pipeline is bootstrapped.

Warning

snd_map_sys requires the operator to configure the syscall pipeline (snd_syscall_set_ntdll, snd_syscall_strategy_set, snd_syscall_strategy_add) before invocation. Unconfigured pipelines cause immediate resolution failures.

KnownDlls Bootstrapping

The Object Manager helper snd_om_knowndll_map() wraps a mapping backend to map a clean system DLL from the \KnownDlls (x64) or \KnownDlls32 (x86) directory:

PVOID clean_ntdll = NULL;
snd_status_t status = snd_om_knowndll_map(&snd_map_nt, L"ntdll.dll", &clean_ntdll);
if (SND_FAILED(status)) {
    return status;
}

// Feed the mapped image into the syscall pipeline
snd_syscall_set_ntdll(clean_ntdll);
snd_syscall_strategy_set(snd_syscall_resolve_ssn_scan);
snd_syscall_strategy_add(snd_syscall_resolve_ssn_sort);

The helper builds the full Object Manager path (SND_TARGET_KNOWNDLLS_DIR + DLL name), calls open and view, then closes the section handle. The mapped view remains valid after the handle is closed.

Typical stealth profile (see pocs/inject_pe/main.c):

1. Map clean ntdll.dll from KnownDlls via snd_map_nt
2. Bootstrap the syscall pipeline with the mapped base
3. Switch remaining operations to _sys backends (snd_mem_sys, snd_proc_sys)