[](https://microsoft.com)
[](https://isocpp.org)
[](https://learn.microsoft.com/en-us/cpp/assembler/masm/masm-for-x64-ml64-exe)
[](LICENSE)
---
## Overview
Nocturne is a research-oriented Windows x64 shellcode loader built around a single goal: producing **clean, fully backed call stacks** that are indistinguishable from legitimate Windows threads — even under manual forensic inspection with WinDbg.
Modern EDR solutions and manual analysts rely on call stack integrity as a primary detection signal. Unbacked return addresses, misaligned frames, and dynamic function table artifacts are all strong indicators of malicious activity. Traditional stack spoofing techniques address some of these, but they break under **Intel CET (Control-flow Enforcement Technology)** shadow stack validation, where the hardware maintains a separate, read-only copy of return addresses that must match the software stack.
Nocturne solves this by taking a fundamentally different approach: instead of fabricating fake frames, it **injects code into a legitimate module's `.text` section** and registers a `RUNTIME_FUNCTION` entry with **real donor unwind metadata** from that module. The Windows unwinder then walks the stack using genuine unwind info, producing frames that point back to a signed, backed DLL (`windows.storage.dll`). Because the code physically resides within the module's address range and the unwind chain is structurally valid, both software-based stack walks and CET hardware validation see a legitimate call chain.
The loader is built entirely **CRT-free** (`/NODEFAULTLIB`) with a custom entry point, custom `memset`/`memcpy` intrinsics, and `HeapAlloc`/`HeapFree` operator overrides — no C runtime dependency in the final binary. All Win32 and NT API resolution happens at runtime through **compile-time DJB2 hashing** (`constexpr`): the hash values are computed during compilation and embedded as immediate constants, while the actual function pointers are resolved at runtime by walking PEB loader data structures. This means zero API name strings exist in the binary, and the IAT contains only benign camouflage imports.
> [!IMPORTANT]
> The payload exits immediately after execution, so short-lived shellcode (e.g. `calc.exe` launcher) will terminate before you can inspect the call stack. To properly analyze the spoofed stack, use a **persistent payload** such as an `msfvenom` reverse shell or a long-lived beacon — anything that keeps the thread alive long enough for manual inspection with WinDbg or Process Hacker.
---
## Techniques & Why They Were Chosen
### 🔧 API Hash Resolution (DJB2)
All Win32/NT APIs are resolved at runtime by walking the PEB loader data structures and matching export names against precomputed DJB2 hashes. The hashes are generated at **compile time** using `constexpr` evaluation — the compiler computes each hash and embeds it as an immediate constant in the binary. At runtime, the resolver iterates the target module's export table and compares each export name's hash against the embedded constant. This eliminates IAT entries that would otherwise reveal the loader's true capabilities to static analysis tools, and ensures no API name strings are present in the binary.
### 🎭 IAT Camouflage
The Import Address Table is populated exclusively with **benign USER32.dll imports** (`MessageBoxA`, `RegisterClassW`, `IsWindowVisible`, etc.) placed inside an unreachable code branch. Static analysis tools see a harmless GUI application rather than a loader.
