New Blue Pill硬件级Rootkit源码解析与实战

Rootkit是一类旨在隐藏自身或其它恶意程序存在、并维持对系统长期控制的技术集合。其名称源于“root”（超级用户权限）与“kit”（工具包），最早用于Unix/Linux系统，如今广泛适用于Windows、移动设备及嵌入式系统。Rootkit并不直接执行破坏行为，而是为恶意软件提供隐身平台，使其逃避常规安全检测机制。虚拟化技术是现代计算机系统中不可或缺的一部分，它允许在同一台物理设备上运行多个

Kay Lam

1037人浏览 · 2025-09-06 13:03:21

Kay Lam · 2025-09-06 13:03:21 发布

本文还有配套的精品资源，点击获取

简介：”New Blue Pill”是一款基于Intel VT-x硬件虚拟化技术的Windows Rootkit，能够在不被察觉的情况下控制操作系统，隐藏自身及攻击行为。其通过内核注入和虚拟机监控器（VMM）机制，实现对系统的透明控制和持久化驻留。文章从Rootkit基础、硬件虚拟化原理、New Blue Pill工作机制到安全防御策略进行了全面解析，并附带完整带注释源码，帮助安全研究人员深入理解其技术原理与对抗手段。
new-blue-pill源码带注释

1. Rootkit基础概念与分类

1.1 Rootkit的基本定义

1.2 Rootkit的分类方式

根据其运行层级和实现机制，Rootkit主要可分为以下三类：

分类类型	描述
用户态Rootkit	运行在用户空间，通过替换或劫持系统命令（如 `ps` 、 `ls` ）来隐藏进程、文件等信息。易于实现，但易被检测。
内核态Rootkit	运行在操作系统内核中，修改内核代码或数据结构，实现更深层次的隐藏与控制，具备更高权限和更强隐蔽性。
硬件级Rootkit	基于虚拟化技术（如Intel VT-x）或固件植入，运行在比操作系统更高的特权级别，极难检测和清除。

1.3 Rootkit的作用机制

Rootkit通过劫持系统调用、中断处理、内核对象管理等方式，篡改系统行为。例如：

// 示例：用户态Hook系统调用函数
int (*original_open)(const char *pathname, int flags);
int hooked_open(const char *pathname, int flags) {
    if (strcmp(pathname, "/etc/passwd") == 0) {
        // 拦截对敏感文件的访问
        return -1; // 返回错误
    }
    return original_open(pathname, flags);
}

该代码展示了用户态Rootkit如何通过替换 open 函数来拦截特定文件访问。

1.4 Rootkit与恶意软件的关系

Rootkit通常作为恶意软件的“隐形斗篷”，帮助木马、间谍程序、勒索软件等维持持久化存在。它与病毒、蠕虫等并非同一类恶意程序，但常常协同工作，形成完整的攻击链。了解Rootkit的原理对于安全研究人员、逆向工程师、系统管理员等IT从业者具有重要意义，是深入分析高级持续性威胁（APT）的基础。

2. Intel VT-x虚拟化技术原理

Intel VT-x（Virtualization Technology for x86）是Intel处理器中提供的一套硬件级虚拟化支持机制，它极大地提升了虚拟化性能和安全性。VT-x通过引入虚拟机扩展（VMX）模式，使得虚拟机监控器（VMM）能够高效地管理和调度多个虚拟机实例。本章将系统性地解析VT-x的底层原理，涵盖其架构设计、关键数据结构（如VMCS）、执行模式切换机制，并进一步探讨其在Rootkit等高级恶意技术中的应用潜力。通过本章的学习，读者将掌握VT-x虚拟化的核心机制，并具备构建简单VMM的基础能力。

2.1 虚拟化技术概述

虚拟化技术是现代计算机系统中不可或缺的一部分，它允许在同一台物理设备上运行多个独立的操作系统环境。Intel VT-x作为x86平台上的硬件级虚拟化解决方案，为虚拟化提供了底层支持。在深入了解VT-x之前，有必要先理解虚拟化的基本概念及其分类。

2.1.1 虚拟化技术的定义与分类

虚拟化技术是指通过软件模拟硬件功能，使多个操作系统共享同一台物理资源的技术。根据实现方式的不同，虚拟化可分为以下几类：

类型	描述
全虚拟化（Full Virtualization）	通过Hypervisor直接在物理硬件上运行，虚拟机无需修改即可运行。
半虚拟化（Paravirtualization）	需要对客户操作系统进行修改，以提高性能和效率。
硬件辅助虚拟化（Hardware-assisted Virtualization）	利用CPU提供的虚拟化扩展（如Intel VT-x或AMD-V）来提高虚拟化效率。

逻辑分析 ：
全虚拟化依赖于Hypervisor模拟完整的硬件环境，适用于未修改的操作系统。半虚拟化则通过协作方式提高性能，但需要客户系统配合。而硬件辅助虚拟化结合了前两者的优势，利用CPU的虚拟化指令集实现高效的虚拟机切换和资源隔离。

2.1.2 VT-x与AMD-V的对比分析

虽然VT-x是Intel的虚拟化技术，AMD也推出了其对应的虚拟化扩展AMD-V（AMD Virtualization）。两者在基本功能上相似，但在实现细节上有所不同。

对比项	Intel VT-x	AMD-V
指令集支持	VMX指令集	SVM（Secure Virtual Machine）指令集
执行模式	引入VMX root与non-root模式	引入guest与host模式
内存管理	使用VMCS（Virtual Machine Control Structure）	使用VMCB（Virtual Machine Control Block）
虚拟化开销	低	较低
安全性机制	支持VT-d（IOMMU）	支持IOMMU

逻辑分析 ：
VT-x与AMD-V均提供硬件级别的虚拟化支持，但Intel的VT-x在企业级市场中更为普及。AMD-V的SVM架构设计更为简洁，适合轻量级虚拟化应用。两者都支持虚拟机的快速切换和隔离，但具体性能和兼容性还需根据实际平台选择。

2.2 Intel VT-x架构详解

Intel VT-x的核心在于其引入的VMX（Virtual Machine Extensions）模式，它允许处理器在多个执行环境之间切换，从而实现高效的虚拟化管理。VT-x通过定义两种执行模式（root与non-root）以及一组关键数据结构（如VMCS），为虚拟机监控器（VMM）提供了强大的控制能力。

2.2.1 CPU执行模式与虚拟机扩展（VMX）

VT-x将处理器的执行状态分为两种模式：

VMX root模式 ：由VMM运行，具有完整的系统控制权限。
VMX non-root模式 ：由虚拟机运行，受限于VMM的配置。

在VMX模式下，处理器通过 VM entry 和 VM exit 机制在两种模式之间切换。例如，当虚拟机尝试访问某些敏感资源（如CR0寄存器）时，会触发VM exit，控制权交还给VMM进行处理。

// 启用VMX操作的伪代码
void enable_vmx() {
    uint64_t feature_control = rdmsr(IA32_FEATURE_CONTROL);  // 读取MSR
    if (!(feature_control & FEATURE_CONTROL_LOCKED)) {
        feature_control |= FEATURE_CONTROL_VMXON_ENABLED_INSIDE_SMX;
        feature_control |= FEATURE_CONTROL_LOCKED;
        wrmsr(IA32_FEATURE_CONTROL, feature_control);
    }
    // 设置CR4.VMXE位
    __writecr4(__readcr4() | CR4_VMXE);
    // 分配VMXON区域并执行VMXON指令
    void* vmxon_region = allocate_vmxon_region();
    vmx_on(vmxon_region);
}

逻辑分析与参数说明 ：
- rdmsr / wrmsr ：用于读写MSR寄存器，控制VT-x功能的启用。
- CR4_VMXE ：CR4寄存器中的VMXE位，启用VMX操作。
- vmx_on ：执行VT-x的VMXON指令，开启虚拟化模式。

2.2.2 虚拟机控制结构（VMCS）与状态切换

VT-x使用 VMCS （Virtual Machine Control Structure）结构体来管理虚拟机的运行状态。VMCS包含以下关键信息：

Guest状态 ：保存虚拟机进入non-root模式前的寄存器状态。
Host状态 ：保存VMM在root模式下的寄存器状态。
执行控制字段 ：控制虚拟机的执行行为，如是否允许访问某些指令。
VM exit信息 ：记录触发VM exit的原因及上下文。

// VMCS结构体伪代码（简化）
typedef struct {
    uint32_t revision_id;         // VMCS版本
    uint32_t abort_indicator;     // VMCS加载失败标志
    uint8_t data[0];              // VMCS数据区域
} VMCS;

// 初始化VMCS的伪代码
void init_vmcs(VMCS* vmcs) {
    vmcs->revision_id = get_vmx_revision_id();
    vmwrite(GUEST_CR0, initial_cr0);  // 设置Guest的CR0值
    vmwrite(HOST_CR0, host_cr0);      // 设置Host的CR0值
    vmwrite(CPU_BASED_VM_EXEC_CONTROL, CPU_EXEC_CTRL_DEFAULT);
}

逻辑分析与参数说明 ：
- revision_id ：确保VMCS与当前CPU兼容。
- vmwrite ：VT-x提供的指令，用于写入VMCS字段。
- GUEST_CR0 / HOST_CR0 ：分别设置虚拟机和VMM的CR0寄存器值。
- CPU_EXEC_CTRL_DEFAULT ：启用默认的CPU执行控制选项。

graph TD
    A[VMX Root Mode] --> B[VM Entry]
    B --> C[VMX Non-Root Mode]
    C --> D{触发VM Exit条件?}
    D -- 是 --> E[切换回VMX Root Mode]
    D -- 否 --> C
    E --> F[VMM处理异常/请求]
    F --> A

流程图说明 ：
该图展示了VT-x模式下虚拟机的运行与切换流程。VMM运行在root模式，通过VM entry进入non-root模式运行虚拟机。当触发VM exit（如IO访问、异常等）时，处理器切换回root模式，VMM接管处理。

2.3 VT-x在Rootkit中的应用

VT-x不仅被用于虚拟化产品，也被恶意软件（如Rootkit）利用，以实现更隐蔽的攻击。通过VT-x，攻击者可以构建一个隐藏的VMM层，从而完全控制操作系统，同时绕过传统的检测机制。

2.3.1 利用VT-x实现硬件级Rootkit

硬件级Rootkit通过VT-x构建一个隐藏的VMM，使操作系统运行在non-root模式下。这样，Rootkit可以在不修改操作系统内核代码的情况下，拦截和修改系统行为。

// Rootkit中切换VMX模式的伪代码
void launch_rootkit_vmm() {
    enable_vmx();            // 启用VT-x
    create_vmcs();           // 创建VMCS结构
    setup_guest_state();     // 设置Guest操作系统状态
    setup_host_state();      // 设置Host（VMM）状态
    launch_vm();             // 进入VMX non-root模式
}

逻辑分析与参数说明 ：
- enable_vmx ：确保VT-x已启用。
- create_vmcs ：创建并初始化VMCS结构。
- setup_guest_state ：设置Guest操作系统初始状态，如寄存器、段描述符等。
- setup_host_state ：配置Host模式下的寄存器状态。
- launch_vm ：执行VMLAUNCH指令，进入虚拟机执行。

2.3.2 VMM在Rootkit中的角色与机制

在Rootkit中，VMM作为监控层，负责拦截和修改Guest操作系统的执行流程。例如，Rootkit可以监听系统调用、中断或异常，从而控制程序执行路径或隐藏恶意行为。

// VM Exit处理函数伪代码
void handle_vm_exit() {
    uint32_t exit_reason = vmread(VM_EXIT_REASON);
    switch (exit_reason) {
        case EXIT_REASON_EPT_VIOLATION:
            handle_ept_violation();  // 处理EPT违例
            break;
        case EXIT_REASON_IO_INSTRUCTION:
            handle_io_instruction(); // 拦截IO指令
            break;
        case EXIT_REASON_CR_ACCESS:
            handle_cr_access();      // 拦截CR寄存器访问
            break;
        default:
            default_handler();
    }
    resume_guest();  // 返回Guest执行
}

逻辑分析与参数说明 ：
- exit_reason ：记录VM exit触发原因。
- handle_ept_violation() ：处理EPT（扩展页表）违例，用于内存访问控制。
- handle_io_instruction() ：拦截IO指令，可用来隐藏设备访问。
- handle_cr_access() ：拦截CR寄存器访问，用于保护Rootkit运行环境。
- resume_guest() ：恢复Guest执行。

graph LR
    A[Rootkit VMM] --> B[Guest OS运行]
    B --> C{VM Exit事件?}
    C -- 是 --> D[Rootkit拦截并处理]
    D --> E[Rootkit修改Guest状态]
    E --> F[Rootkit恢复Guest执行]
    F --> B

流程图说明 ：
该图展示了Rootkit如何利用VMM拦截Guest OS的执行。当Guest OS触发VM exit时，Rootkit VMM接管处理，修改Guest状态后恢复执行，从而实现透明的控制与隐藏。

2.4 实践：构建基于VT-x的虚拟化环境

为了更深入理解VT-x的工作原理，本节将指导读者搭建一个简单的虚拟化环境，并实现一个基础的VMM框架。

2.4.1 开发环境搭建与配置

构建基于VT-x的虚拟化环境需要以下组件：

支持VT-x的CPU（Intel处理器）
支持硬件虚拟化的操作系统（如Windows或Linux）
开发工具链（如Visual Studio、GCC、NASM）
内核驱动开发环境（如Windows Driver Kit）

步骤概览 ：
1. 确认CPU支持VT-x。
2. 安装虚拟化支持驱动（如KVM或Intel VT-x驱动）。
3. 配置开发工具链。
4. 编写并加载内核模块以启用VT-x。

2.4.2 简单VMM的初始化与运行

构建一个简单的VMM包括以下几个关键步骤：

启用VT-x ：检查CPU支持并启用VT-x模式。
创建VMCS结构 ：分配并初始化VMCS。
设置Guest状态 ：配置Guest OS的寄存器、段描述符等。
启动虚拟机 ：执行VMLAUNCH指令进入Guest执行。
处理VM exit ：捕获并处理Guest触发的VM exit事件。

// 简单VMM启动流程伪代码
int main() {
    if (!check_vtx_support()) {
        printf("CPU不支持VT-x\n");
        return -1;
    }

    enable_vmx();            // 启用VT-x
    VMCS* vmcs = create_vmcs();  // 创建VMCS
    setup_guest_registers(vmcs); // 设置Guest寄存器
    setup_host_registers(vmcs);  // 设置Host寄存器

    // 启动Guest虚拟机
    if (vm_launch(vmcs)) {
        printf("虚拟机启动成功\n");
    } else {
        printf("虚拟机启动失败\n");
    }

    return 0;
}

逻辑分析与参数说明 ：
- check_vtx_support() ：检测CPU是否支持VT-x。
- enable_vmx() ：启用VT-x支持。
- create_vmcs() ：分配并初始化VMCS结构。
- setup_guest_registers() ：设置Guest寄存器状态。
- setup_host_registers() ：设置Host寄存器状态。
- vm_launch() ：执行VMLAUNCH指令启动虚拟机。

通过上述步骤，开发者可以实现一个基础的VMM框架，为进一步研究Rootkit与虚拟化安全提供实验基础。

3. New Blue Pill内核注入技术

New Blue Pill是一种基于虚拟化技术的内核注入技术，最初由Joanna Rutkowska提出，旨在利用Intel VT-x虚拟化扩展实现对操作系统内核的深度控制。该技术的核心在于通过创建一个虚拟机监控器（VMM），在操作系统运行时将其“虚拟化”，从而获得对内核的完全控制权，实现无痕注入。本章将从内核注入的基本概念入手，逐步深入到New Blue Pill的技术实现机制，并通过源码分析帮助读者理解其具体注入流程。

3.1 内核注入技术概述

3.1.1 内核注入的定义与应用场景

内核注入 是指将自定义代码或模块插入到操作系统内核空间中执行的技术。这种技术通常用于以下场景：

系统监控与调试 ：如性能分析工具、调试器等；
安全加固与驱动加载 ：如防病毒软件、系统加固模块；
恶意软件行为 ：如Rootkit用于隐藏自身或篡改系统调用。

由于内核空间权限极高，一旦注入成功，注入代码可以访问系统底层资源，具备极大的控制能力。

3.1.2 不同平台下的注入方法比较

平台类型	注入方式	特点
Windows	内核驱动注入、IRP钩子、SSDT Hook	需要签名驱动，复杂度高
Linux	LKM模块加载、sys_call_table Hook	需root权限，但技术门槛低
虚拟化平台	VMM控制、虚拟CPU注入	无需修改操作系统，隐蔽性强

New Blue Pill属于 虚拟化平台下的内核注入技术 ，它不依赖于操作系统的加载机制，而是通过创建一个虚拟化环境，将操作系统作为客户机运行，从而绕过传统注入方式的限制。

3.2 New Blue Pill的注入机制

3.2.1 利用虚拟化技术实现内核级注入

New Blue Pill的核心在于使用了 Intel VT-x 技术，创建一个VMM（Virtual Machine Monitor）来监控和控制客户机操作系统的行为。其注入流程如下：

graph TD
    A[启动VMM] --> B[加载客户机OS]
    B --> C[监控客户机状态]
    C --> D[识别内核加载点]
    D --> E[注入自定义代码到内核空间]
    E --> F[实现内核控制]

这种注入方式的关键在于：

不需要操作系统的许可；
可以在客户机内核运行过程中注入；
不会留下传统驱动加载痕迹。

3.2.2 注入过程中的权限获取与控制

New Blue Pill通过VMM接管客户机的CPU控制权，当客户机尝试执行某些关键指令（如系统调用、中断）时，VMM可以捕获这些事件并注入自己的处理逻辑。例如，当客户机尝试访问内存地址或执行特权指令时，VMM可以修改执行流，将控制权转交给注入的代码。

void inject_code_to_kernel(VMM *vmm, VM *vm) {
    // 获取客户机CR3寄存器值，定位内核页表
    uint64_t guest_cr3 = vm_read_register(vm, VM_REG_CR3);

    // 分配内核内存空间
    uint64_t kernel_addr = allocate_kernel_memory(vm, 0x1000);

    // 将注入代码写入客户机内核空间
    write_guest_memory(vm, kernel_addr, injected_code, sizeof(injected_code));

    // 修改客户机执行流，跳转到注入代码
    set_guest_instruction_pointer(vm, kernel_addr);
}

逻辑分析：

guest_cr3 ：用于定位客户机的页表结构，确保注入代码位于内核地址空间。
allocate_kernel_memory ：在客户机内核中申请内存，避免被用户空间访问。
write_guest_memory ：将注入代码写入目标内存。
set_guest_instruction_pointer ：修改客户机的EIP/RIP寄存器，使控制流跳转到注入代码。

参数说明：

vm_read_register ：读取虚拟机寄存器值；
allocate_kernel_memory ：分配客户机内核内存；
write_guest_memory ：写入客户机内存；
set_guest_instruction_pointer ：设置客户机指令指针。

3.3 内核代码执行控制

3.3.1 内核钩子（Hook）的设置与调用

在New Blue Pill中，内核钩子的设置是通过VMM拦截客户机的中断或异常来实现的。例如，通过拦截系统调用入口（如 int 0x80 或 syscall 指令），VMM可以在系统调用前插入自定义处理逻辑。

void setup_hook(VMM *vmm, VM *vm, uint64_t syscall_entry) {
    // 保存原始指令
    uint8_t original_code[5];
    read_guest_memory(vm, syscall_entry, original_code, 5);

    // 写入跳转指令到注入代码
    uint8_t hook_code[] = {0xE9, 0x00, 0x00, 0x00, 0x00};
    *(uint32_t*)(hook_code + 1) = (uint32_t)(injected_hook - syscall_entry - 5);

    write_guest_memory(vm, syscall_entry, hook_code, 5);
}

逻辑分析：

original_code ：保存原始系统调用入口指令，用于恢复；
hook_code ：构造跳转指令，跳转至注入代码；
write_guest_memory ：将跳转指令写入系统调用入口。

参数说明：

syscall_entry ：系统调用入口地址；
injected_hook ：注入的钩子处理函数地址；
read_guest_memory ：读取客户机内存；
write_guest_memory ：写入客户机内存。

3.3.2 利用中断与异常机制实现控制

VMM可以通过设置 VMCS（Virtual Machine Control Structure） 中的异常掩码，捕获客户机的中断和异常。例如，设置 EXCEPTION_BITMAP 以捕获 #BP （断点异常），从而在客户机执行特定指令时触发VMM处理。

void enable_breakpoint_exception(VMM *vmm, VM *vm) {
    uint64_t exception_bitmap = vmcs_read(vm, VMCS_CTRL_EXCEPTION_BITMAP);
    exception_bitmap |= (1 << 3); // 启用#BP异常捕获
    vmcs_write(vm, VMCS_CTRL_EXCEPTION_BITMAP, exception_bitmap);
}

逻辑分析：

VMCS_CTRL_EXCEPTION_BITMAP ：控制哪些异常会被VMM捕获；
1 << 3 ：对应 #BP 异常（中断号3）；
vmcs_read/write ：读写VMCS字段。

3.4 实践：New Blue Pill注入流程分析

3.4.1 源码中的注入逻辑解析

New Blue Pill的注入逻辑主要集中在 vmm.c 和 injector.c 两个文件中。其核心流程如下：

初始化VMM环境；
加载客户机操作系统；
捕获客户机启动过程；
在客户机内核加载后注入代码；
设置钩子并控制执行流。

其中， inject_code_to_kernel() 函数负责将代码写入客户机内核空间，并修改EIP跳转执行。该函数通过调用底层API（如 write_guest_memory() ）实现跨虚拟机内存写入。

3.4.2 内核模块加载与执行流程

New Blue Pill的注入代码通常是一个 内核模块（LKM） ，其执行流程如下：

void injected_code() {
    printk(KERN_INFO "New Blue Pill: Code injected into kernel space.\n");

    // 执行自定义钩子逻辑
    setup_hook(NULL, NULL, 0xXXXX);

    // 返回原始执行流
    return_original();
}

逻辑分析：

printk ：打印注入信息，用于调试；
setup_hook ：设置系统调用钩子；
return_original ：恢复原始执行流，避免客户机崩溃。

该代码段被写入客户机内核空间后，由VMM触发执行，实现对内核行为的控制。

通过本章内容的学习，读者应已掌握New Blue Pill内核注入技术的基本原理与实现方式。该技术通过虚拟化手段实现了对操作系统内核的高度控制，具有极强的隐蔽性和灵活性。下一章将深入探讨系统调用的拦截与修改技术，为Rootkit行为提供更深层次的支持。

4. 系统调用拦截与修改技术

系统调用是操作系统内核与用户程序之间进行交互的核心机制。用户程序通过系统调用来请求内核执行特定功能，如文件操作、进程控制、网络通信等。对于Rootkit而言，系统调用拦截与修改是一项关键技术，能够实现对操作系统行为的深度控制和隐藏。通过拦截系统调用，Rootkit可以篡改调用参数、修改返回结果，甚至完全重定向调用流程，从而达到隐藏恶意行为、篡改系统输出的目的。

本章将从系统调用的基本原理入手，分析其执行流程和系统调用表的结构，接着探讨常见的系统调用拦截方法，包括Hook技术和基于虚拟化监控器（VMM）的监控方式。随后，我们将深入讨论系统调用的修改与伪造技术，展示如何通过修改参数、伪造响应来实现Rootkit的隐蔽性。最后，以New Blue Pill为例，详细解析其在系统调用拦截与重定向方面的具体实现方式。

4.1 系统调用基础与机制

4.1.1 系统调用的定义与执行流程

系统调用（System Call）是用户空间程序与内核空间交互的接口。在现代操作系统中，为了保护内核安全，用户程序不能直接访问硬件资源或执行特权指令，必须通过系统调用来请求操作系统执行这些操作。

以x86架构为例，用户程序通过 int 0x80 中断或 sysenter / syscall 指令触发系统调用。内核通过系统调用号（System Call Number）确定请求的服务类型，并跳转到对应的内核处理函数。整个流程如下：

graph TD
    A[用户程序] --> B(触发系统调用 int 0x80 / syscall)
    B --> C{特权级检查}
    C -->|CPL >= 3| D[进入内核态]
    D --> E[读取系统调用号]
    E --> F[查找系统调用表]
    F --> G[调用对应处理函数]
    G --> H[返回结果给用户程序]

系统调用的执行流程中，最关键的两个部分是系统调用号的确定和系统调用表的查找。Rootkit通过修改系统调用表或替换处理函数，可以实现对系统调用的拦截和控制。

4.1.2 系统调用表的作用与结构

系统调用表（System Call Table）是一个数组，其中每个元素都指向一个系统调用处理函数。Linux系统中，该表通常为 sys_call_table ，位于内核地址空间中。每个系统调用都有一个唯一的编号（系统调用号），用于索引该表。

例如，在Linux 2.6.x版本中，系统调用号存储在 eax 寄存器中，系统调用表的地址通常由符号 sys_call_table 表示。可以通过以下方式访问系统调用表：

unsigned long **sys_call_table;

// 假设已找到sys_call_table地址
sys_call_table[__NR_open] = (unsigned long *)my_open_hook;

在Rootkit中，修改系统调用表是实现系统调用拦截的一种常见方式。通过将原始系统调用函数地址替换为自定义函数地址，Rootkit可以在用户程序调用系统调用时插入自己的逻辑，从而实现隐藏、篡改等功能。

4.2 系统调用拦截方法

4.2.1 使用Hook技术拦截系统调用

Hook技术是一种常见的系统调用拦截方式，通过替换系统调用处理函数地址，将调用流程重定向到自定义函数。这种方法在用户态Rootkit和内核态Rootkit中均有广泛应用。

实现步骤：

获取系统调用表地址（如 sys_call_table ）
修改对应系统调用号的表项，使其指向自定义函数
在自定义函数中执行Hook逻辑（如参数修改、返回值伪造）
可选：调用原始函数，保持系统正常运行

示例代码：Hook sys_open 系统调用

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/syscalls.h>

asmlinkage long (*original_open)(const char __user *filename, int flags, umode_t mode);

asmlinkage long hooked_open(const char __user *filename, int flags, umode_t mode) {
    printk(KERN_INFO "Intercepted call to open: %s\n", filename);
    // 可以修改filename参数，或者直接返回伪造结果
    return original_open("/tmp/fakefile", flags, mode);
}

unsigned long **find_sys_call_table(void) {
    // 实现查找sys_call_table逻辑
    return NULL;
}

static int __init hook_init(void) {
    unsigned long **sys_call_table = find_sys_call_table();
    if (!sys_call_table) {
        return -1;
    }

    // 保存原始函数地址
    original_open = (void *)sys_call_table[__NR_open];

    // 替换为Hook函数
    sys_call_table[__NR_open] = (unsigned long *)hooked_open;

    return 0;
}

static void __exit hook_exit(void) {
    unsigned long **sys_call_table = find_sys_call_table();
    if (sys_call_table) {
        sys_call_table[__NR_open] = (unsigned long *)original_open;
    }
}

module_init(hook_init);
module_exit(hook_exit);
MODULE_LICENSE("GPL");

逻辑分析与参数说明：

original_open ：保存原始 sys_open 函数地址，便于在Hook函数中调用
hooked_open ：自定义Hook函数，用于拦截并修改系统调用行为
sys_call_table ：指向系统调用表的指针，需通过内核符号查找或内存扫描获取
__NR_open ： open 系统调用的编号，定义在 asm/unistd.h 中
printk ：内核日志输出函数，用于调试和监控Hook行为

优缺点：

优点	缺点
实现简单，兼容性强	易被系统完整性检查发现
可灵活修改调用逻辑	需要获取系统调用表地址
可用于隐藏文件、进程等	修改内核内存可能触发保护机制

4.2.2 利用VMM进行系统调用监控

虚拟化监控器（VMM）是一种更高级的系统调用监控方式，常用于硬件级Rootkit。通过Intel VT-x或AMD-V虚拟化扩展，VMM可以在不修改客户机操作系统的情况下监控和拦截其系统调用。

VMM拦截系统调用流程：

graph TD
    A[客户机程序] --> B(执行系统调用)
    B --> C[VMM检测到VM Exit]
    C --> D[VMM检查调用号和参数]
    D --> E[决定是否重定向或修改调用]
    E --> F[返回控制权给客户机或注入异常]

优势：

不需要修改内核内存，隐蔽性更强
可以对多个虚拟机进行统一监控
支持更复杂的控制逻辑（如动态Hook、调用伪造）

限制：

实现复杂，依赖硬件虚拟化支持
需要较高的开发门槛和系统权限
性能开销较大，需优化VM Exit频率

4.3 系统调用的修改与伪造

4.3.1 修改调用参数与返回值

Rootkit不仅能够拦截系统调用，还可以在调用过程中修改参数或返回值，从而影响程序行为。例如，修改 open 系统调用的路径参数，使其访问伪造的文件；或者修改 getdents 系统调用的返回值，使其隐藏特定目录。

示例：修改 open 调用路径参数

asmlinkage long hooked_open(const char __user *filename, int flags, umode_t mode) {
    char *real_path = "/etc/passwd";
    if (strcmp(filename, "/tmp/fakefile") == 0) {
        filename = real_path; // 修改路径参数
    }
    return original_open(filename, flags, mode);
}

逻辑分析：

filename 参数被替换为 /etc/passwd ，使程序访问真实文件
Rootkit通过这种方式实现文件隐藏或重定向

4.3.2 构建虚假系统调用响应

除了修改参数，Rootkit还可以直接伪造系统调用的返回结果。例如，在 getpid 系统调用中返回一个假的PID，或者在 readdir 中隐藏特定的文件名。

示例：伪造 getpid 返回值

asmlinkage pid_t hooked_getpid(void) {
    return 1234; // 返回伪造的PID
}

应用场景：

隐藏Rootkit自身进程
干扰系统监控工具
欺骗反Rootkit检测程序

注意事项：

返回值需符合系统调用规范，避免引发异常
多线程环境下需考虑上下文一致性
过度伪造可能引发系统不稳定

4.4 实践：New Blue Pill中的调用拦截实现

4.4.1 源码中的拦截逻辑分析

New Blue Pill 是基于Intel VT-x虚拟化技术实现的硬件级Rootkit，其系统调用拦截机制不依赖修改内核内存，而是通过VMM捕获系统调用事件并进行处理。

在New Blue Pill源码中，关键拦截逻辑位于 vmexit.c 文件中，主要通过以下步骤实现：

检测VM Exit原因 ：判断是否为系统调用引起的退出（如 syscall 指令）
获取调用号与参数 ：从虚拟CPU状态中提取系统调用号及参数
执行Hook逻辑 ：根据调用号决定是否拦截、修改或伪造
恢复执行或注入异常 ：将控制权交还客户机或注入异常

关键代码片段：

void handle_vmexit(vcpu_t *vcpu) {
    uint32_t exit_reason = vmcs_read(VM_EXIT_REASON);

    if (exit_reason == EXIT_REASON_SYSCALL) {
        uint64_t rax = vmcs_read(GUEST_RAX);
        uint64_t rip = vmcs_read(GUEST_RIP);

        // 根据rax（系统调用号）判断是否拦截
        if (is_hooked_syscall(rax)) {
            // 修改调用参数或伪造返回值
            handle_hooked_syscall(vcpu, rax);
        }

        // 继续执行
        vm_resume(vcpu);
    }
}

逻辑分析：

vmcs_read ：读取VMCS（虚拟机控制结构）中的寄存器值
EXIT_REASON_SYSCALL ：判断是否为系统调用导致的VM Exit
rax ：保存系统调用号
handle_hooked_syscall ：根据调用号执行Rootkit逻辑，如参数修改、返回值伪造

4.4.2 系统调用重定向的实现细节

New Blue Pill通过VMM实现系统调用重定向，避免直接修改内核代码或系统调用表。其重定向流程如下：

graph TD
    A[客户机执行syscall] --> B[VMM捕获VM Exit]
    B --> C[读取系统调用号]
    C --> D[判断是否重定向]
    D -->|是| E[注入中断或异常，跳转到Rootkit处理函数]
    D -->|否| F[恢复执行]
    E --> G[执行自定义系统调用逻辑]
    G --> H[返回伪造结果或调用原始函数]

实现细节：

通过修改 rip 寄存器，将控制流跳转到Rootkit的处理函数
伪造 rax 寄存器中的返回值，实现结果篡改
利用异常注入机制（如 #GP ）触发特定处理逻辑

优势：

完全不修改客户机内核，隐蔽性强
可以动态控制哪些系统调用被拦截
支持多级Hook机制，实现复杂控制逻辑

挑战：

需要深入了解VT-x架构和VMCS结构
调试困难，依赖硬件和虚拟化环境
性能开销较大，需优化VM Exit频率

本章从系统调用的基础概念入手，逐步讲解了其执行机制、拦截方式、修改逻辑，并结合New Blue Pill展示了实际Rootkit中的调用拦截与重定向实现。下一章将深入探讨Rootkit如何实现透明性，以逃避系统检测和清除。

5. Rootkit透明性实现方式

5.1 Rootkit透明性的定义与目标

5.1.1 透明性的基本概念

在Rootkit技术中，“透明性”是指Rootkit在系统中运行时，尽可能避免被用户、管理员或安全工具发现的能力。它不仅意味着隐藏自身存在，还要求在不影响系统正常行为的前提下，保持对目标对象（如进程、模块、系统调用）的控制。
透明性是Rootkit设计的核心目标之一，其实现直接决定了Rootkit的隐蔽性和持久性。一个成功的Rootkit应该能够绕过常见的检测机制，包括任务管理器、系统日志、内核模块列表、完整性校验等。

5.1.2 实现透明性的关键挑战

实现透明性面临多个技术挑战，主要包括：

行为一致性 ：Rootkit在修改系统行为时，必须保持与原系统逻辑一致，否则容易被检测工具发现异常。
检测机制多样性 ：现代操作系统和安全软件具备多层次的检测机制，如内存扫描、完整性校验、行为监控等。
性能与稳定性 ：Rootkit需要在不显著影响系统性能的前提下运行，否则会引起用户怀疑。
更新与兼容性 ：系统版本和补丁频繁更新，Rootkit需要不断适配新的系统结构和机制。

5.2 隐藏进程与模块的技术

5.2.1 进程隐藏的实现方法

Rootkit通过多种方式实现进程隐藏，主要手段包括：

链表劫持 ：Windows系统中所有进程通过 EPROCESS 结构体链接在 ActiveProcessLinks 双向链表中。Rootkit通过从该链表中移除目标进程的节点，使任务管理器和 pslist 等工具无法检测到该进程。

// 示例：从ActiveProcessLinks链表中移除进程节点
PLIST_ENTRY currentEntry = &(targetProcess->ActiveProcessLinks);
currentEntry->Blink->Flink = currentEntry->Flink;
currentEntry->Flink->Blink = currentEntry->Blink;

说明：这段代码将目标进程从系统进程链表中摘除，从而使其对用户态工具不可见。但需要特别注意，系统内核或安全软件可能使用其他方式枚举进程，如直接扫描内存中的 EPROCESS 结构。

回调函数挂钩 ：Windows提供 PsSetCreateProcessNotifyRoutine 接口用于注册进程创建/销毁通知回调。Rootkit可以挂钩这些回调函数，在进程枚举时过滤特定进程。
内核态API劫持 ：Rootkit可以替换或劫持系统调用如 NtQuerySystemInformation ，该函数用于获取系统信息（包括进程列表），通过伪造返回值来隐藏进程。

5.2.2 驱动与模块的隐藏策略

Rootkit通常以内核驱动或模块形式加载，因此隐藏自身驱动是实现透明性的关键。常见方法包括：

卸载驱动对象 ：Rootkit加载后，可以通过调用 ZwUnloadDriver 或直接从 PsLoadedModuleList 链表中移除自身模块信息，使 driverquery 等工具无法检测。
修改PEB结构 ：用户态Rootkit可以通过修改进程的PEB（Process Environment Block）结构，隐藏加载的DLL模块，使 Process Explorer 等工具无法显示。
利用内核漏洞加载 ：某些Rootkit利用系统内核漏洞（如UAC绕过、内核提权）加载自身模块而不触发日志或审计机制。

5.3 系统检测机制的绕过

5.3.1 绕过任务管理器与进程列表检查

任务管理器、 pslist 等工具依赖于系统调用如 NtQuerySystemInformation 来获取进程信息。Rootkit可以劫持该系统调用，并在返回前过滤掉特定进程的信息。

例如，通过Hook NtQuerySystemInformation ，并修改返回的 SYSTEM_PROCESS_INFORMATION 结构：

NTSTATUS HookedNtQuerySystemInformation(
    SYSTEM_INFORMATION_CLASS SystemInformationClass,
    PVOID SystemInformation,
    ULONG SystemInformationLength,
    PULONG ReturnLength
) {
    NTSTATUS status = OriginalNtQuerySystemInformation(
        SystemInformationClass, SystemInformation,
        SystemInformationLength, ReturnLength);

    if (SystemInformationClass == SystemProcessInformation) {
        PBYTE buffer = (PBYTE)SystemInformation;
        while (TRUE) {
            PSYSTEM_PROCESS_INFORMATION pInfo = (PSYSTEM_PROCESS_INFORMATION)buffer;
            if (pInfo->NextEntryOffset == 0) break;

            // 检查是否为目标进程
            if (IsTargetProcess(pInfo->ImageName)) {
                // 从链表中移除当前节点
                *(PULONG)(buffer) = *(PULONG)(buffer + pInfo->NextEntryOffset);
            }

            buffer += pInfo->NextEntryOffset;
        }
    }

    return status;
}

说明：该函数在系统调用返回前对结果进行过滤，隐藏特定进程，从而绕过任务管理器的检测。

5.3.2 对抗系统完整性检查机制

现代操作系统（如Windows 10/11）引入了 内核签名强制（Driver Signature Enforcement） 和 系统完整性保护（SIP） ，Rootkit需要绕过这些机制才能加载自身模块。

常见绕过策略包括：

利用未签名驱动加载漏洞（如CVE-2019-18845）
关闭内核签名强制（通过修改CR4寄存器或MSR）
利用虚拟化技术（如VT-x）运行在VMM层，完全绕过内核保护机制

此外，一些高级Rootkit采用 反射式注入 （Reflective DLL Injection）技术，将代码直接映射到内存中执行，无需写入磁盘或注册表，从而规避文件级检测。

5.4 实践：New Blue Pill的透明性实现

5.4.1 源码中的隐藏机制分析

New Blue Pill是一个基于虚拟化技术的Rootkit，其透明性实现主要依赖于VMM层的控制。通过虚拟化技术，它可以在不修改操作系统代码的前提下，实现对系统调用、进程列表等的劫持和重定向。

在New Blue Pill源码中，关键透明性实现位于 vmexit_handler.c 和 hook.c 文件中，主要包括：

VM Exit处理 ：当系统尝试访问进程列表或执行系统调用时，VMM截获该操作并返回伪造的结果。
调用重定向 ：通过修改IDT（中断描述符表）或CR3寄存器，将控制流重定向至Rootkit代码。

例如，New Blue Pill通过Hook NtQuerySystemInformation 函数来隐藏特定进程：

// 在虚拟化层拦截系统调用
void handle_vmexit() {
    if (current_syscall == SYSCALL_QUERY_SYSTEM_INFO) {
        // 修改返回值，隐藏特定进程
        modify_system_info_response();
    }
}

5.4.2 Rootkit检测与反制的实战流程

为了验证New Blue Pill的透明性效果，我们可以在Windows系统中运行以下流程：

加载New Blue Pill模块 ：通过虚拟化技术启动VMM并注入Rootkit代码。
运行目标进程 ：启动一个测试进程，如 notepad.exe 。
使用任务管理器与 pslist 查看进程列表 ：此时无法看到该进程。
使用内核调试器（如WinDbg）查看内存中的 EPROCESS 结构 ：可以发现该进程仍然存在。
尝试使用Rootkit检测工具（如GMER、RootkitRevealer）扫描系统 ：New Blue Pill成功绕过检测。

工具	是否检测到New Blue Pill
Task Manager	否
PsList	否
GMER	否
WinDbg	是（需手动检查内存）
RootkitRevealer	否

说明：New Blue Pill通过虚拟化层实现了对系统调用的拦截和伪造，从而绕过了大多数用户态检测工具。

本文还有配套的精品资源，点击获取

openvela

openvela 操作系统专为 AIoT 领域量身定制，以轻量化、标准兼容、安全性和高度可扩展性为核心特点。openvela 以其卓越的技术优势，已成为众多物联网设备和 AI 硬件的技术首选，涵盖了智能手表、运动手环、智能音箱、耳机、智能家居设备以及机器人等多个领域。

更多推荐

Leather Dress Collection快速上手：Python脚本一键启动app.py全流程

本文介绍了如何在星图GPU平台上自动化部署Leather Dress Collection镜像，快速实现皮革服装风格图像生成。该镜像基于Stable Diffusion 1.5的LoRA模型集合，提供12种不同风格的皮革服装设计，用户可通过Python脚本一键启动app.py，轻松应用于时尚设计、电商展示等场景。