NocturneLdr - A CET-compatible Windows x64 loader that produces

项目说明

<di="center">

<img src="docs/banner.svg" alt="Nocturne Banner" width="100%"/>

<br/>

![Windows]()
![C++20]()
![MASM]()

</div>

---

O

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 — e 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 , 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 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 o — 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 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-li (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-li — 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 e — the compiler computes each hash and embeds it as an immediate constant in the binary. At runtime, the resol 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, IsWindow, etc.) placed inside an unreachable code branch. Static analysis tools see a harmless GUI application rather than a loader.

<di="center">
<img src="docs/screenshots/IatCamouflage.png" alt="IAT Camouflage — Only benign imports " width="900"/>
<br/>
<em>Clean IAT — only benign USER32.dll imports and heap management functions</em>
</div>

🛡️ CET-Compatible Stack Spoofing (RTFI + JIT)

This is Nocturne's core technique. The stack spoofing pipeline:

1. Sacrificial DLL Loading — windows.storage.dll is loaded as the donor module
2. Code Ca — Payload + ShadowGate stub are injected into .text section slack space
3. Dynamic Function Table Registration — RtlAddFunctionTable registers a RUNTIME_FUNCTION entry pointing to donor unwind info, making the injected code appear as a legitimate function within the module
4. In Function Table Collapse — The internal RtlpIn entry for the donor module is collapsed so the dynamic table takes priority during unwinding
5. Cache In — Both the function table cache and function entry cache are flushed to force the unwinder through the manipulated lookup path
6. Type=0 WinDbg Bypass — The dynamic function table entry type is patched from RF_CALLBACK to RF_SORTED, pre WinDbg from resolving it as dynamic
7. .pdata Suppression — The donor module's .pdata section protection is set to PAGE_NOACCESS, forcing all unwind lookups through the controlled dynamic table

The result: every frame in the call stack resolves to windows_storage!<function> — a legitimate, backed module.

<di="center">
<img src="docs/screenshots/ProcessHacker.png" alt="Process Hacker — Clean call stack with windows.storage frames" width="900"/>
<br/>
<em>Process Hacker call stack — all frames resolve to windows.storage.dll</em>
</div>

<br/>

<di="center">
<img src="docs/screenshots/WinDbg.png" alt="WinDbg — Spoofed stack trace" width="900"/>
<br/>
<em>WinDbg stack trace showing legitimate windows_storage frames</em>
</div>

🔍 WinDbg Bypass

The dynamic function table entry is in to WinDbg's forensic commands. Type patching and .pdata suppression ensure that debugger analysis cannot distinguish the spoofed frames from real ones.

<di="center">
<img src="docs/screenshots/BypassWinDbg.png" alt="WinDbg Bypass — Dynamic table hidden from debugger" width="900"/>
<br/>
<em>WinDbg bypass — .fnent shows donor unwind info, no dynamic table artifacts</em>
</div>

😴 Zilean Sleep Obfuscation with Stack Duplication

While the payload sleeps, the loader's entire image is encrypted in memory using a ROP chain built from RtlRegisterWait and NtContinue. The chain is executed on a dedicated worker thread and follows this sequence:

1. WaitForSingleObjectEx — Gate: waits for the trigger event
2. — Changes the image to PAGE_READWRITE
3. SystemFunction040 — Encrypts the image in-place (RtlEncryptMemory)
4. NtGetContextThread — Backs up the current thread's context
5. NtSetContextThread — Replaces it with a spoofed context captured from a legitimate thread (stack duplication)
6. WaitForSingleObjectEx — Sleeps for the configured timeout
7. NtSetContextThread — Restores the original context from backup
8. SystemFunction041 — Decrypts the image back (RtlDecryptMemory)
9. — Restores PAGE_EXECUTE_READ
10. SetEvent — Signals completion

During sleep, if an EDR calls GetThreadContext, it sees the duplicated stack of a legitimate Windows thread — not the loader's real context. Combined with BYOUD stack spoofing during execution, the thread appears clean both while running and while sleeping.

🔐 Heap Masking

Before the image is encrypted, all busy heap allocations across every process heap (except the default process heap) are XOR-encrypted with a per-cycle random key. This prevents EDR memory scanners from finding decrypted strings, shellcode fragments, or configuration data in heap memory while the loader sleeps. The same key is used to decrypt after wakeup — the operation is fully symmetric.

🛡️ EAF Bypass (ShieldedRead)

Export Address Filtering (EAF) uses hardware breakpoints to detect when untrusted code reads the export tables of critical modules like ntdll.dll and kernel32.dll. Nocturne bypasses this using a gadget-based read primitive: instead of directly dereferencing export table pointers, all reads are routed through a MOV RAX, [RAX]; RET gadget found inside ntdll.dll itself. Since the actual memory read occurs within a signed Microsoft module, EAF's hardware breakpoints see a legitimate caller and do not trigger.

The ShieldedRead assembly stub accepts a target address and an optional gadget pointer. If a gadget is provided, it jumps to the gadget to perform the read; otherwise it falls back to a normal dereference. The LdrShieldedSymbolResol resolver uses this for every export table access — PE header parsing, name array iteration, ordinal lookup, and function address resolution all go through the gadget.

🔒 CRT-Free Build

The entire project compiles with /NODEFAULTLIB and a custom entry point. Memory management uses HeapAlloc/HeapFree through operator o. memset and memcpy are implemented as custom intrinsics. This eliminates CRT dependencies that would inflate the binary and add unnecessary attack surface.

🐚 Payload Execution

Shellcode is XOR-decrypted at runtime and executed through the ShadowGate assembly stub, which sets up the spoofed stack frame before transferring control.

<di="center">
<img src="docs/screenshots/Re.png" alt="Reverse Shell — Payload executing with spoofed stack" width="900"/>
<br/>
<em>Reverse shell established with fully spoofed call stack</em>
</div>

---

Build

Open Nocturne.sln in Studio and build for x64 Release or x64 Debug.

| Configuration | Description |
|---|---|
| Debug x64 | Console output enabled, DEBUG preprocessor defined |
| Release x64 | Silent execution, no debug output |

> Both configurations use /NODEFAULTLIB, static CRT (/MT), no buffer security checks, and no C++ exceptions.

> [!NOTE]
> For production use, make sure the DEBUG preprocessor definition is removed from your build configuration. The Debug x64 preset defines it by default — switch to Release x64 or manually remove _DEBUG and DEBUG from Project Properties → C/C++ → Preprocessor Definitions to disable all console output.

---

Project Structure

---

References

---

Disclaimer

This project is intended for authorized security research and educational purposes only. The author is not responsible for any misuse. Always obtain proper authorization before testing on systems you do not own.

---

<di="center">

If you find this project useful or interesting, consider leaving a ⭐

Your support motivates further research and de.

</div>

项目信息

开发语言：C++

Star 数：133

技术要点

该项目属于红蓝攻防方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕A CET-compatible Windows x64 loader that produces fully backed call stacks through runtime function table manipulation, code cave injection, and inverted function table collapse.展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。