jedanzig/hyperv-memproc-dll-injection-poc
GitHub: jedanzig/hyperv-memproc-dll-injection-poc
一个基于MemProcFS和Hyper-V的DMA注入概念验证工具，从宿主机直接向客户机进程映射并执行DLL载荷，无需在客户机内部调用任何注入API或触发内核回调。
Stars: 0 | Forks: 0
# InjectorBridge (PoC)
这是一个概念验证（PoC）Windows C++ 注入桥接工具，它利用基于 DMA 的内存访问（通过 Hyper-V 的 MemProcFS/LeechCore）在客户机 VM 进程中映射并执行 DLL —— 无需触及客户机内核或在客户机内部使用标准的 Windows 注入 API。
此代码库旨在用于演示和学习。并未经过生产环境的强化。
## 工作原理
InjectorBridge 完全从**宿主机**运行，通过 DMA 访问 Hyper-V 客户机的物理内存：
1. **连接** — 使用 `hvmm://` 设备初始化 MemProcFS，以便通过 LiveCloudKd/hvmm.sys 访问客户机物理内存。
2. **定位** — 遍历客户机的进程列表以按名称查找目标进程，并解析客户机内部的模块基址/导出。
3. **阶段 1（分配）** — 在现有的客户机模块中查找代码洞，写入调用 `VirtualAlloc` 的 shellcode，并在一个频繁调用的函数（`PeekMessageW`）上安装临时的内联 Hook，以便当客户机应用程序下次调用该函数时，shellcode 能在上下文中执行。该 shellcode 通过一个共享内存标志将分配地址回传给宿主机，然后循环等待，直到宿主机恢复原始函数字节。
4. **映射** — 在宿主机上解析 Payload DLL，将其映射为平面镜像，根据客户机已加载的模块解析导入，应用基址重定位，并将最终镜像逐页写入新分配的客户机内存（针对 MemProcFS 尚无法虚拟寻址的页面，使用物理地址回退机制）。
5. **阶段 2（执行）** — 第二个 shellcode + 内联 Hook 周期在映射的镜像上调用 `DllMain(DLL_PROCESS_ATTACH)`，完成注入。
所有的 Hook 安装都是临时的 —— 一旦每个阶段发出完成信号，原始字节就会被恢复。
## 代码库结构
**Main**（当前构建路径）：
- `main/bridge.cpp` — CLI 入口点和 VMM 生命周期
- `main/injection.h` — 主注入流水线（Staging、映射、重定位、信令）
- `main/pe_mapper.h` — PE 解析、镜像映射、导入/重定位辅助函数
- `main/shellcode.h` — 注入阶段使用的 Shellcode 构建器/常量
- `main/test_dll.cpp` — 测试 Payload DLL（`DllMain` 写入 `C:\injected_test.txt` 作为执行证明）
**Ideas**（当前未接入 `injector_bridge`）：
- `Ideas/hook_manager.h` — Hook 注册/状态模型和验证辅助函数
- `Ideas/code_cave_finder.h` — 多模块代码洞扫描辅助函数
- `Ideas/relocation_tracker.h` — 重定位解析/跟踪工具
- `Ideas/hook_shellcode.h` — 全上下文 Hook Shellcode 原型
## 依赖项
本项目依赖于 [MemProcFS](https://github.com/ufrisk/MemProcFS)、[LeechCore](https://github.com/ufrisk/LeechCore) 和 [LiveCloudKd](https://github.com/gerhart01/LiveCloudKd)（用于 Hyper-V DMA 驱动）。这些**不包含**在此代码库中 —— 您必须单独下载它们。
### 设置
1. 下载最新的 [MemProcFS 版本](https://github.com/ufrisk/MemProcFS/releases)（或从源代码构建）。
2. 将所需的**头文件**复制到 `main/dependencies/`：
main/dependencies/
├── vmmdll.h
└── leechcore.h
3. 将所需的**库文件**复制到 `libs/`：
libs/
├── vmm.lib
└── leechcore.lib
4. 下载 [LiveCloudKd](https://github.com/gerhart01/LiveCloudKd/releases) 并将以下**运行时文件**放置在构建的可执行文件旁边：
build-vs2022/Release/
├── hvmm.sys # Hyper-V 内存访问驱动
├── hvlib.dll # LiveCloudKd 库
├── leechcore_device_hvmm.dll # LeechCore HVMM 设备插件
├── vmm.dll # MemProcFS 核心
├── leechcore.dll # LeechCore 核心
├── dbghelp.dll # 符号支持
└── symsrv.dll # 符号服务器支持
这些仅在运行时需要 —— 没有它们项目也能编译。
## 构建
要求：
- Windows
- Visual Studio 2022（或兼容 CMake 的 MSVC 工具链）
- CMake 3.20+
- MemProcFS 头文件和库（见 [依赖项](#dependencies)）
```
cmake -S . -B build-vs2022 -G "Visual Studio 17 2022" -A x64
cmake --build build-vs2022 --config Release
```
## 用法
```
# 在 Hyper-V 主机上从提升的（管理员）提示符运行
injector_bridge.exe
# 示例
injector_bridge.exe notepad.exe test_payload.dll
```
注入器将等待目标进程在客户机 VM 中出现，最多等待 120 秒。一旦找到，它就会映射并执行 Payload。测试 DLL 会在客户机内写入 `C:\injected_test.txt` 作为执行证明。
## 检测面
理解这种技术为何隐蔽 —— 以及在何处不隐蔽 —— 与实现本身同样重要。
### 客户机端工具看不到什么
| Vector | Why it's blind |
|--------|---------------|
| Guest kernel (SSDT hooks, PatchGuard) | The injector runs entirely on the **host**. No syscalls are made from within the guest. |
| Guest ETW / kernel callbacks | `PsSetCreateThreadNotifyRoutine`, `PsSetLoadImageNotifyRoutine` — none are triggered because no new thread is created and the DLL is never loaded through the Windows loader. |
| Guest AV / EDR user-mode hooks | NTDLL is not used for the allocation or mapping. `VirtualAlloc` is called via inline hook shellcode executing in the context of an existing thread — the EDR's IAT/inline hooks on `NtAllocateVirtualMemory` are bypassed because the call originates from shellcode in a code cave, not from a monitored call stack. |
| PE loader telemetry | The DLL is mapped manually. It never appears in `InMemoryOrderModuleList` (PEB module list) or triggers `LdrLoadDll` notifications. |
| Standard memory scanners (scanning for MZ headers) | Headers can be zeroed post-mapping trivially. |
### 什么仍然可以检测到
| Vector | Notes |
|--------|-------|
| Host-side hypervisor introspection | A VMI (Virtual Machine Introspection) solution running at the hypervisor level would see the DMA writes. This is the same layer this tool operates on. |
| Anomalous `PeekMessageW` return values | The hook causes `PeekMessageW` to return 0 for 1–2 calls during shellcode execution. A behaviour-based rule watching for unexpected message pump failures could flag this. |
| Executable memory not backed by a file | The allocated region is `PAGE_EXECUTE_READWRITE` with no mapped file backing. Tools like PE-sieve or Moneta that scan for unbacked executable memory regions will find it. |
| Physical memory forensics | The DLL image exists in guest physical memory and is visible to any tool that can read raw RAM (including MemProcFS itself). |
核心隐蔽属性在于**信任边界**：所有的写入都源于宿主机，因此任何仅依赖客户机 OS 可见性的检测机制在结构上都无法检测到此类攻击。
## 许可证
本项目采用 [MIT 许可证](LICENSE) 授权。
MemProcFS、LeechCore 和 LiveCloudKd 是拥有各自许可的第三方项目 —— 请参阅其各自的代码库以了解条款。
## 免责声明
此代码仅用于**教育和授权安全研究目的**。请勿对您不拥有或未获得明确测试许可的系统使用它。
标签：0day挖掘, Bash脚本, C++, DLL注入, DMA攻击, Hyper-V, MemProcFS, pdftotext, PoC, SecList, Shellcode, SSH蜜罐, 内存取证, 内核安全, 内联Hook, 恶意软件研究, 技术调研, 数据展示, 数据擦除, 暴力破解, 流量审计, 物理内存访问, 端口监听, 红队, 网络安全, 虚拟化安全, 规避防御, 进程注入, 逃逸技术, 隐私保护