[原创]实现简易ARK工具(1) GDT表-编程技术-看雪安全社区

[原创]实现简易ARK工具(1) GDT表

发表于: 2025-7-10 21:17 7100

[原创]实现简易ARK工具(1) GDT表

X66iaM

2025-7-10 21:17

7100

[TOC]
**前言**

大家好，在下最近打算开个坑写一下ARK工具的笔记。第一次接触windows内核，文中一定有许多错误，恳请指正，谢谢你的时间！

鉴于文末贴了代码，所以设置为点赞或回复可观看，嘿嘿。

# 前置知识

## GDT是什么

GDT (Global Descriptor Table)是告诉CPU"内存怎么分段、每段有什么权限"的一张表，ARK工具通过读取这张表来检查系统有没有被篡改。

GDT数组在内存中，每个元素是8字节的段描述符。每个段描述符用于表述三个关键字段:

+ `Base Address`: 段的基址
+ `Limit`: 段的界限(大小)
+ `Access`: 访问权限

```cpp
struct SegmentDescriptor {
    // ========== 历史字段 (来自80286) ==========
    unsigned Limit1:16;    // 界限低16位 - 从80286继承
    unsigned Base1:16;     // 基址低16位 - 从80286继承  
    unsigned Base2:8;      // 基址中8位 - 从80286继承
    unsigned type:4;       // 段类型 - 从80286继承，但扩展了
    unsigned s:1;          // 系统段标志 - 从80286继承
    unsigned dpl:2;        // 特权级 - 从80286继承
    unsigned p:1;          // 存在位 - 从80286继承
    
    // ========== 80386新增字段 ==========
    unsigned Limit2:4;     // 界限高4位 - 新增，支持32位界限
    unsigned avl:1;        // 软件可用位 - 新增
    unsigned res:1;        // 保留位 - 新增，为未来扩展
    unsigned db:1;         // 操作数大小 - 新增，支持16/32位切换
    unsigned g:1;          // 粒度位 - 新增，突破界限限制
    unsigned Base3:8;      // 基址高8位 - 新增，支持32位基址
};

```

## 段选择子(CS)的16位结构

```plain
15                    3   2   1   0
┌──────────────────────┬───┬───────┐
│      索引 (13位)     │TI │RPL(2位)│
│    (Index 13 bits)   │   │       │
└──────────────────────┴───┴───────┘
- 位 15-3: 索引字段 (13位) = 8192个可能的描述符 
  索引0特殊: 指向NULL描述符(必须为0)
  有效索引: 1-8191
  
- 位 2:    TI位 (1位)      = 表指示器
选择使用哪个段描述符表
TI = 0: 使用GDT (Global Descriptor Table)
TI = 1: 使用LDT (Local Descriptor Table)

- 位 1-0:  RPL字段 (2位)   = 请求特权级
RPL = 0: Ring 0 (内核级)
RPL = 1: Ring 1 (系统服务级，很少用)  
RPL = 2: Ring 2 (设备驱动级，很少用)
RPL = 3: Ring 3 (用户级)
```

## 内存地址类型与转换

1. Logical Address (逻辑地址): 程序中使用的地址 CS:IP 
2. Linear Address (线性地址): 分段后的地址
3. Physical Address (物理地址): 实际的内存地址
4. Virtual Address(虚拟地址):在x86架构中 在没有分页(实模式)的情况下，线性地址就是物理地址。在有分页(保护模式)的情况下，线性地址就是虚拟地址，虚拟地址通过页表转换为物理地址。

所以这是命名角度的问题

从CPU角度: 线性地址 (Linear Address)

+ 强调这是分段后、分页前的地址
+ Intel手册的正式术语

从程序角度: 虚拟地址 (Virtual Address)

+ 强调这是程序看到的"虚拟"地址空间
+ 操作系统和编程中更常用

举例说明有分页的情况

```markdown
程序说: "我要访问 CS:0x1000"  (逻辑地址)
       |
       |CS是段选择子，通过计算转换为索引 TI RPL 
       ↓
CPU查GDT: "GDT[索引] 描述的基址是0x400000" (分段转换)
       ↓  
得到: 0x400000 + 0x1000 = 0x401000 (线性地址/虚拟地址)
       ↓
再查页表: "线性地址0x401000对应物理地址0x800000" (分页转换)
       ↓
最终访问: 物理内存0x800000位置 (物理地址)
```

## 内存访问段机制的流程

```cpp
步骤1: 解析段选择子CS
CS = 0x0020 (假设)
实际不是直接取第20项，而是：
1. 索引 = 0x20 >> 3 = 4 (指向GDT第4项)
2. TI = (0x20 >> 2) & 1 = 0 (使用GDT)
3. RPL = 0x20 & 3 = 0 (请求特权级0)

步骤2: 从GDT获取段描述符
1. 根据索引4，从GDT[4]读取8字节段描述符
2. 解析出基址、界限、权限等信息
    
步骤3: 地址计算
1. 存在位检查: if (P位 == 0) → 段不存在 异常
2. 特权级检查: if (max(CPL,RPL) > DPL) → 特权级违例
3. 类型检查: 执行/读取/写入权限是否匹配
4. 界限检查: if (偏移 > 段界限) → 段界限违例

步骤4: 页表转换
1. 线性地址 = 段基址 + 偏移地址
2. 如果基址=0 (平坦模式)，则线性地址=偏移地址
```

## 获取GDT

+ `GDTR`寄存器: CPU内部的寄存器，指向当前使用的GDT表。
+ `SGDT`指令: 这是x86的特权指令，把GDTR寄存器的内容读出来。
+ 在R3使用`sgdt`指令获取`GDTR`寄存器值是可以的。但是不能读写GDT表。（只能知道它在哪
+ 涉及的API组合:
 - R3的:`GetySystemInfo(&systemInfo) `拿到`systemInfo.dwNuberOfProcessors`即核心数。`SetProcessAffinityMask(GetCurrentProcess(),mask)` 确定在哪个核心上跑，注意mask数值是按位的 。
 - R0的:`KeQueryActiveProcessors()`获取活跃核心的Mask;`KeSetSystemAffinityThread(Mask)`强制线程在指定核心运行;
 - 注意这个API的说明，我的XP虚拟机是会卡死的，不理解 <a href="elink@65cK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6D9k6h3q4J5L8W2)9J5k6h3#2A6j5%4u0G2M7$3!0X3N6q4)9J5k6h3y4G2L8g2)9J5c8Y4A6Z5i4K6u0V1j5$3&6Q4x3V1k6%4K9h3&6V1L8%4N6K6i4K6u0V1K9r3q4J5k6s2N6S2M7X3g2Q4x3V1k6V1M7X3W2$3k6i4u0K6i4K6u0r3k6r3c8A6i4K6u0r3N6$3c8E0i4K6u0r3L8X3k6Q4x3X3c8%4k6r3#2Q4x3X3c8C8k6i4y4W2N6s2y4&6M7%4c8W2L8h3q4X3k6X3W2F1K9i4c8&6N6r3S2J5k6h3q4V1">KeSetSystemAffinityThread 函数 （wdm.h） - Windows drivers</a>![](upload/attach/202507/1003898_ARQXTAXY36S7ZFS.png)

**每个CPU核心都有自己的**`**GDTR**`**寄存器，指向各自的GDT表，进程在哪个核心上跑，指向的就是哪个核心的GDT表，可所有核心的GDT表内容是一样的。**

测试：给win7 sp1 32位虚拟机设置为2处理器2内核数量，跑一下遍历的程序，发现GDT的四个基址不同，大小相同。

![](upload/attach/202507/1003898_NMK43C2XHGGZ64J.png)

```cpp
int main()
{
 GDTR gdtr;
 SYSTEM_INFO SystemInfo;
 GetSystemInfo(&SystemInfo);
 int Mask = 1;
 printf("GDT dwNumberOfProcessors:%d\n", SystemInfo.dwNumberOfProcessors);
 for (int i = 0; i < SystemInfo.dwNumberOfProcessors; i++) {
 SetProcessAffinityMask(GetCurrentProcess(), Mask);
 __asm {
 sgdt gdtr
 //lgdt GDT
 }

printf("GDT Base:%08x Limit:%08x\n", gdtr.Base, gdtr.Limit);
 Mask <<= 1;
 }
 
 system("pause");
 return 0;
}
```

··	疑问:如果在64位系统上跑，给出的也是32位大小的GDT表地址，不合理，难道给的是假的？

那么我们拿表的时候就要考虑多核问题，精确的拿到每个核心的GDT表。

# 通过R0和R3通信遍历GDT表

模仿一下PCHunter拿的信息

1. **Cpu序号** - 这个是我们在遍历多核CPU时自己维护的，不是从GDT表本身来的
2. **段选择子** - 这个是段描述符在GDT表中的索引，我们遍历时的i值
3. **基址** - 段的起始线性地址。		 `SegmentDescriptor`结构体中，由`Base1`、`Base2`、`Base3`拼接而成
4. **界限** - 段的大小。				 `SegmentDescriptor`结构体中，由`Limit1`、`Limit2`拼接而成
5. **段粒度** - 界限的单位(字节或4KB)。    `SegmentDescriptor`结构体中的`g`字段
6. **段特权级** - 0=内核级，3=用户级。    `SegmentDescriptor`结构体中的`dpl`字段
7. **类型** - 段的具体类型和权限。		 `SegmentDescriptor`结构体中的`type`字段

**思路**

秉持着在R3能干的活不要在R0干的理念。

R3遍历核心读GDT地址->发送每个核心的GDTR给R0->R0读表数据发给R3->R3解析数据。

```cpp
R3(用户态)                    R0(内核态驱动)
│                           │
├─1. sgdt获取GDTR──────────┤
├─2. 计算GDT大小(Limit+1)─┤
├─3. malloc申请缓冲区─────┤
├─4. 发送[CPU索引+GDTR+缓冲区]──►│
│                           ├─5. KeSetSystemAffinityThread切换到对应核心
│                           ├─6. 直接从GDT基址复制数据
│◄─7. 返回[完整GDT数据]─────┤
├─8. 解析段描述符数据───────┤
├─9. 转换为GDT_INFO格式───┤
├─10. 显示在UI界面────────┤
├─11. free释放缓冲区──────┤
```

**原始的段描述符转换成UI数据的解析方法**

![](upload/attach/202507/1003898_76WTVXJQ4XE9QGB.png)

上面这张图片出自<a href="elink@5aaK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6K6k6h3N6E0k6h3&6@1k6X3q4#2L8s2c8Q4x3X3g2U0L8$3#2Q4x3V1k6S2i4K6u0r3x3e0p5&6x3o6l9H3x3o6l9@1x3o6p5^5y4K6x3H3y4l9`.`.">244K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6K6k6h3N6E0k6h3&6@1k6X3q4#2L8s2c8Q4x3X3g2U0L8$3#2Q4x3V1k6S2i4K6u0r3x3e0p5&6x3o6l9H3x3o6l9@1x3o6p5^5y4K6x3H3y4l9`.`.</a>

```plain
Base字段重组:
Base3(8位) Base2(8位) Base1(16位)
字节7 字节4 字节3-2
┌──────────┬──────────┬────────────────┐
│63......56│39......32│31.............16│ ← 段描述符中的原始位置
└──────────┴──────────┴────────────────┘
 ↓ ↓ ↓
 << 24 << 16 不移位
 ↓ ↓ ↓
┌──────────┬──────────┬────────────────┐
│31......24│23......16│15.............0│ ← 32位完整基址
└──────────┴──────────┴────────────────┘

Limit字段重组:
Limit2(4位) Limit1(16位)
字节6低4位 字节1-0 
┌──────────────┬────────────────────┐
│51..........48│15................0│ ← 段描述符中的原始位置
└──────────────┴────────────────────┘
 ↓ ↓
 << 16 不移位
 ↓ ↓
┌──────────────┬────────────────────┐
│19..........16│15................0│ ← 20位完整界限
└──────────────┴────────────────────┘

段粒度转换:
G=0 (字节粒度):
  界限值直接使用: 假设limit = 0x12345 → 段大小 = 0x12345 字节

G=1 (页粒度): 
 界限值需要转换: 假设limit = 0x123 → 段大小 = (0x123 << 12) | 0xFFF
 
 转换过程:
 原始limit: 0x00000123 (20位)
 ↓ << 12 (左移12位,乘以4KB)
 扩展后: 0x00123000 (32位)
 ↓ | 0xFFF (低12位置1)
 最终: 0x00123FFF (段可用到页尾)
```

# 部分代码和效果图

![](upload/attach/202507/1003898_KBCRVHYRKNYSNDR.png)

在下常常被自己的函数解耦能力感动(破防，真是献丑了

Imgui的UI代码就不贴了，贴点功能代码

```c++
//R3  
//单个段描述符信息在UI上展示的信息
typedef struct _GDT_INFO {
    UINT    cpuIndex;       // CPU序号
    USHORT  selector;       // 段选择子（在GDT中的索引 * 8）
    ULONG64 base;           // 基址（Base1+Base2+Base3拼接）
    ULONG   limit;          // 界限（Limit1+Limit2拼接）
    UCHAR   g;              // 段粒度（0=字节，1=4KB）
    UCHAR   dpl;            // 段特权级（0=内核，3=用户）
    UCHAR   type;           // 段类型
    UCHAR   system;         // 系统段标志
    BOOL    p;              // 段存在位
} GDT_INFO, * PGDT_INFO;

typedef struct SegmentDescriptor {
    // ========== 历史字段 (来自80286) ==========
    unsigned Limit1 : 16;    // 界限低16位 - 从80286继承
    unsigned Base1 : 16;     // 基址低16位 - 从80286继承  
    unsigned Base2 : 8;      // 基址中8位 - 从80286继承
    unsigned type : 4;       // 段类型 - 从80286继承，但扩展了
    unsigned s : 1;          // 系统段标志 - 从80286继承
    unsigned dpl : 2;        // 特权级 - 从80286继承
    unsigned p : 1;          // 存在位 - 从80286继承

// ========== 80386新增字段 ==========
    unsigned Limit2 : 4;     // 界限高4位 - 新增，支持32位界限
    unsigned avl : 1;        // 软件可用位 - 新增
    unsigned res : 1;        // 保留位 - 新增，为未来扩展
    unsigned db : 1;         // 操作数大小 - 新增，支持16/32位切换
    unsigned g : 1;          // 粒度位 - 新增，突破界限限制
    unsigned Base3 : 8;      // 基址高8位 - 新增，支持32位基址
}*PSEGDESC;

#pragma pack(push, 1)
typedef struct GDTR {
  unsigned short Limit;
  unsigned int   Base;
}*PGDTR;
#pragma pack(pop)

typedef struct GDT_DATA_REQ {
    unsigned CpuIndex;
    GDTR Gdtr;
}*PGDT_DATA_REQ;

std::vector<GDT_INFO> _gdtVec;
PSEGDESC ArkR3::GetSingeGDT(UINT cpuIndex, PGDTR pGdtr); //获得单核GDT表数据指针
std::vector<GDT_INFO> GetGDTVec(); //返回所有核心GDT数组_gdtVec

```

```c++
//R3
PSEGDESC ArkR3::GetSingeGDT(UINT cpuIndex, PGDTR pGdtr)
{
    DWORD gdtSize = pGdtr->Limit + 1;
    PSEGDESC pBuffer = (PSEGDESC)malloc(gdtSize);
    if (!pBuffer) {
        LogErr("GetSingeGDT malloc err");
        return nullptr;
    }

GDT_DATA_REQ req = { 0 };
    req.CpuIndex = cpuIndex;
    req.Gdtr = *pGdtr;

DWORD dwRetBytes = 0;
    DeviceIoControl(m_hDriver, CTL_GET_GDT_DATA, &req, sizeof(GDT_DATA_REQ),
        pBuffer, gdtSize, &dwRetBytes, NULL);

return pBuffer;
}

std::vector<GDT_INFO> ArkR3::GetGDTVec()
{
 _gdtVec.clear();

GDTR gdtr = { 0 };
    SYSTEM_INFO SystemInfo;
    GetSystemInfo(&SystemInfo);
    Log("GetGDTVec GDT dwNumberOfProcessors:%d\n", SystemInfo.dwNumberOfProcessors);

for (UINT i = 0; i < SystemInfo.dwNumberOfProcessors; i++) {
 DWORD_PTR mask = 1UL << i; //Mask按位 和 i 一致 
 SetProcessAffinityMask(GetCurrentProcess(), mask);
 __asm {
 sgdt gdtr
 }

Log("GetGDTVec CPU %d: GDTR Base=%p, Limit=%X\n", i, (void*)gdtr.Base, gdtr.Limit);
        PSEGDESC pGdtData = GetSingeGDT(i, &gdtr);
        if (pGdtData) {
            DWORD descCount = (gdtr.Limit + 1) / 8;  // 段描述符数量
            Log("GetGDTVec CPU %d: 解析 %d 个段描述符\n", i, descCount);

for (UINT index = 0; index < descCount; index++) {
 //pDesc是段描述符指针 下面将原始数据转换成UI上显示的数据格式 
 PSEGDESC pDesc = (PSEGDESC)((PUCHAR)pGdtData + index * sizeof(SegmentDescriptor));

// 解析成GDT_INFO
                GDT_INFO gdtInfo = { 0 };
                gdtInfo.cpuIndex = i;
                gdtInfo.selector = index * sizeof(SegmentDescriptor);

// 基址重组 32bit = Base1(16) + Base2(8) + Base3(8)
 gdtInfo.base = pDesc->Base1 |(pDesc->Base2 << 16) |(pDesc->Base3 << 24);

// 界限重组：Limit1(16) + Limit2(4)
 gdtInfo.limit = pDesc->Limit1 | (pDesc->Limit2 << 16);

// 段粒度 
 gdtInfo.g = pDesc->g;
 if (gdtInfo.g) {
 gdtInfo.limit = (gdtInfo.limit << 12) | 0xFFF; // 低12bit置1 = 4K
 }

gdtInfo.dpl = pDesc->dpl;           // 段特权级
                gdtInfo.type = pDesc->type;         // 段类型
                gdtInfo.system = pDesc->s;          // 系统段标志
                gdtInfo.p = pDesc->p;               // 存在位

_gdtVec.emplace_back(gdtInfo);
                Log("GetGDTVec  [%02d] Sel:0x%04X Base:0x%08X Limit:0x%08X DPL:%d Type:0x%X %s\n",
                    index, gdtInfo.selector, (DWORD)gdtInfo.base, gdtInfo.limit,
                    gdtInfo.dpl, gdtInfo.type, gdtInfo.p ? "P" : "NP");
            }

free(pGdtData);

}
        else {
            Log("GetGDTVec CPU %d: pGdtData nullptr\n", i);
        }

}

Log("GetGDTVec成功获取 %zu 个段描述符信息\n", _gdtVec.size());
    return _gdtVec;
}

```

```cpp
//R0
NTSTATUS DispatchDeviceControl( 
  _In_ struct _DEVICE_OBJECT* DeviceObject, _Inout_ struct _IRP* Irp)
{
   UNREFERENCED_PARAMETER(DeviceObject);
    KdPrint(("[test] %s\n", __FUNCTION__));

PIO_STACK_LOCATION stack = IoGetCurrentIrpStackLocation(Irp);
    ULONG code = stack->Parameters.DeviceIoControl.IoControlCode;
    NTSTATUS status = STATUS_INVALID_DEVICE_REQUEST;
    ULONG_PTR info = 0;

switch (code) {
 case CTL_GET_GDT_DATA:
 __try{
 PGDT_DATA_REQ gdtReq = (PGDT_DATA_REQ)Irp->AssociatedIrp.SystemBuffer;
 ULONG cpuIndex = gdtReq->CpuIndex;
 GDTR gdtr = gdtReq->Gdtr;
 ULONG gdtSize = gdtr.Limit + 1;
 KdPrint(("[test] CpuIndex: %d GdtBase: %08x GdtLimit: %08x, Size: %d\n",
 cpuIndex, gdtr.Base, gdtr.Limit, gdtSize));
 
 KAFFINITY affinity = 1UL << cpuIndex; // 将CPU索引转换为位掩码
 KeSetSystemAffinityThread(affinity);
 RtlCopyMemory(Irp->AssociatedIrp.SystemBuffer, (PVOID)gdtr.Base, gdtSize);

info = gdtSize;
            status = STATUS_SUCCESS;
            KdPrint(("[test] CTL_GET_GDT_DATA finish"));
        }
        __except (EXCEPTION_EXECUTE_HANDLER) {
            status = STATUS_UNSUCCESSFUL;
            KdPrint(("[test] CTL_GET_GDT_DATA exception\n"));
        }
        break;
    }
}
```

# 补充1：系统段解析

增加了对系统段的解析，涉及系统调用和各种门。

原来GDT（全局描述符表）中既可以存放段描述符（代码段、数据段），也可以存放门描述符（调用门、陷阱门、中断门）。

在GDT表中，段描述符的`s`字段决定了段的类型：

- `s = 1`：代码段或数据段
- `s = 0`：系统段

### 系统段类型（s=0时）

系统段的`type`字段含义：

| Type | 描述                                            |
| ---- | ----------------------------------------------- |
| 1    | 16-bit TSS (Available) - 16位任务状态段（可用） |
| 2    | LDT - 局部描述符表                              |
| 3    | 16-bit TSS (Busy) - 16位任务状态段（忙碌）      |
| 4    | 16-bit Call Gate - 16位调用门                   |
| 5    | Task Gate - 任务门                              |
| 6    | 16-bit Interrupt Gate - 16位中断门              |
| 7    | 16-bit Trap Gate - 16位陷阱门                   |
| 9    | 32-bit TSS (Available) - 32位任务状态段（可用） |
| 11   | 32-bit TSS (Busy) - 32位任务状态段（忙碌）      |
| 12   | 32-bit Call Gate - 32位调用门                   |
| 14   | 32-bit Interrupt Gate - 32位中断门              |
| 15   | 32-bit Trap Gate - 32位陷阱门                   |

### 应用段类型（s=1时）

- `type & 8 = 1`：代码段
- `type & 8 = 0`：数据段

**代码段权限**：

- `type & 2 = 1`：可读可执行
- `type & 2 = 0`：仅可执行

**数据段权限**：

- `type & 2 = 1`：可读可写
- `type & 2 = 0`：仅可读

```
//系统段解析
const char* segmentType = " ";
if (gdtInfo.system == 0) {          // 系统段
    switch (gdtInfo.type) {
    case 1: segmentType = "16-bit TSS (Available)"; break;
    case 2: segmentType = "LDT"; break;
    case 3: segmentType = "16-bit TSS (Busy)"; break;
    case 4: segmentType = "16-bit Call Gate"; break;
    case 5: segmentType = "Task Gate"; break;
    case 6: segmentType = "16-bit Interrupt Gate"; break;
    case 7: segmentType = "16-bit Trap Gate"; break;
    case 9: segmentType = "32-bit TSS (Available)"; break;
    case 11: segmentType = "32-bit TSS (Busy)"; break;
    case 12: segmentType = "32-bit Call Gate"; break;
    case 14: segmentType = "32-bit Interrupt Gate"; break;
    case 15: segmentType = "32-bit Trap Gate"; break;
    }
}
else {
    if (gdtInfo.type & 8) {  // 代码段
        segmentType = (gdtInfo.type & 2) ? "Code (R E)" : "Code (E)";
    }
    else {  // 数据段
        segmentType = (gdtInfo.type & 2) ? "Data (R W E)" : "Data (R E)";
    }
}
strcpy_s(gdtInfo.typeDesc, sizeof(gdtInfo.typeDesc), segmentType);
```

UI显示的过滤条件自定
 ![图片描述](upload/attach/202507/1003898_QCBFR4KXY3F58NT.webp)

回复或点赞可查看完整内容

冰与火的战歌：Windows内核攻防实战高级班！从零到实战，融合AI与Windows内核攻防全技术栈，打造具备自动化能力的内核开发高手。

最后于 2025-7-18 00:56 被X66iaM编辑，原因：勘误

#基础知识 #系统内核 #驱动开发

收藏・5

点赞・42

打赏

赞赏记录

参与人

雪币

留言

时间

git_51951meggadf3df

非常支持你的观点！

4天前

像个假号

期待更多优质内容的分享，论坛有你更精彩！

2026-9-8 16:21

1k0ct

为你点赞！

2026-8-28 11:02

TnT柠檬茶

非常支持你的观点！

2026-8-24 11:55

mb_lthgjpwj

为你点赞！

2026-8-21 08:54

晨曦。

为你点赞！

2026-8-17 06:22

TheLuckyOne

你的帖子非常有用，感谢分享！

2026-7-17 01:44

wx_晨梦

感谢你的积极参与，期待更多精彩内容！

2026-7-16 10:52

npc0vo

感谢你分享这么好的资源！

2026-4-26 01:46

ink1

期待更多优质内容的分享，论坛有你更精彩！

2026-3-12 14:43

星辰无大海

你的分享对大家帮助很大，非常感谢！

2026-1-26 11:52

小柯南

你的帖子非常有用，感谢分享！

2025-11-20 23:14

BS10

这个讨论对我很有帮助，谢谢！

2025-9-23 13:45

CreateFile

期待更多优质内容的分享，论坛有你更精彩！

2025-9-7 14:34

会逆向的萝卜

感谢你的积极参与，期待更多精彩内容！

2025-9-4 21:54

我不是深渊

你的帖子非常有用，感谢分享！

2025-8-24 09:12

Editor

这个讨论对我很有帮助，谢谢！

2025-8-18 11:06

mb_kkryygzw

为你点赞！

2025-8-7 17:21

coreofthesun

感谢你的积极参与，期待更多精彩内容！

2025-7-29 16:41

Elice

为你点赞！

2025-7-18 09:58

outed

感谢你的积极参与，期待更多精彩内容！

2025-7-16 22:16

0x指纹

谢谢你的细致分析，受益匪浅！

2025-7-16 08:52

git_46183EBalloon

为你点赞！

2025-7-16 05:25

ONewTach

这个讨论对我很有帮助，谢谢！

2025-7-15 09:14

DIO-HOHO

你的分享对大家帮助很大，非常感谢！

2025-7-14 14:38

mb_dzntuqwg

谢谢你的细致分析，受益匪浅！

2025-7-14 13:48

CRoot

这个讨论对我很有帮助，谢谢！

2025-7-13 16:14

Fyw0o

你的分享对大家帮助很大，非常感谢！

2025-7-12 23:14

mb_nzdjqktf

为你点赞！

2025-7-12 20:02

appview

为你点赞！

2025-7-12 00:54

马来

感谢你的贡献，论坛因你而更加精彩！

2025-7-11 19:50

wx_月亮经过

这个讨论对我很有帮助，谢谢！

2025-7-11 16:40

ldljlzw

你的分享对大家帮助很大，非常感谢！

2025-7-11 11:32

mb_hzfcelhs

谢谢你的细致分析，受益匪浅！

2025-7-11 10:45

道友请留步

这个讨论对我很有帮助，谢谢！

2025-7-11 10:20

令狐双

期待更多优质内容的分享，论坛有你更精彩！

2025-7-11 10:14

周旋久

谢谢你的细致分析，受益匪浅！

2025-7-11 09:15

UserXCh

为你点赞！

2025-7-11 08:10

我的小拇指啊

你的帖子非常有用，感谢分享！

2025-7-11 01:52

顽劣

非常支持你的观点！

2025-7-11 00:33

huangyalei

你的分享对大家帮助很大，非常感谢！

2025-7-11 00:04

TkBinary

谢谢你的细致分析，受益匪浅！

2025-7-10 21:29

最新回复 (14)
五德转移雪币： 9464 活跃值： (5892) 能力值： ( LV2，RANK：10 ) 在线值：发帖 6 回帖 92 粉丝 0 关注私信	五德转移 2 楼为你点赞！ 2025-7-12 08:59 0
mb_heqvlbnm 雪币： 234 活跃值： (3220) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 32 粉丝 0 关注私信	mb_heqvlbnm 3 楼 1 2025-7-12 20:59 0
Deice 雪币： 113 活跃值： (2095) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 23 粉丝 0 关注私信	Deice 4 楼如果在64位系统上跑，给出的也是32位大小的GDT表地址，不合理，难道给的是假的？ 2025-7-13 16:38 0
mb_shzsxtje 雪币： 1148 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 35 粉丝 0 关注私信	mb_shzsxtje 5 楼支持，感谢分享 2025-7-14 09:54 0
盗才生雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 28 粉丝 1 关注私信	盗才生 6 楼支持，感谢分享 2025-7-14 10:40 0
CCTV9 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 3 回帖 53 粉丝 2 关注私信	CCTV9 7 楼 6666 2025-7-14 15:44 0
边缘雪币： 3916 活跃值： (3974) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 55 粉丝 1 关注私信	边缘 8 楼支持，感谢分享 2025-7-14 20:36 0
李翔_702165 雪币： 0 活跃值： (903) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 14 粉丝 0 关注私信	李翔_702165 9 楼感谢分享 2025-7-14 21:39 0
paranioa 雪币： 754 活跃值： (1797) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 12 粉丝 0 关注私信	paranioa 10 楼感谢分享 2025-7-15 06:32 0
chipower 雪币： 239 活跃值： (313) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 23 粉丝 0 关注私信	chipower 11 楼感谢分享 2025-8-28 18:54 0
mb_vfttriqb 雪币： 201 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 8 粉丝 0 关注私信	mb_vfttriqb 12 楼 111111111111111 2025-9-4 21:37 0
byhk 雪币： 2646 活跃值： (8785) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 186 粉丝 1 关注私信	byhk 13 楼感谢分享 2025-9-19 07:49 0
mb_dmpagumk 雪币： 205 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 6 粉丝 0 关注私信	mb_dmpagumk 14 楼谢谢分享 2025-12-24 16:28 0
Fzzz 雪币： 3584 活跃值： (265) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 62 粉丝 0 关注私信	Fzzz 15 楼多核场景下的GDT读取思路很清晰 2026-8-26 14:56 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复

X66iaM

发帖

回帖

RANK

关注

私信

他的文章

关于我们

联系我们

企业服务

看雪公众号

最新回复 (14)
五德转移雪币： 9464 活跃值： (5892) 能力值： ( LV2，RANK：10 ) 在线值：发帖 6 回帖 92 粉丝 0 关注私信	五德转移 2 楼为你点赞！ 2025-7-12 08:59 0
mb_heqvlbnm 雪币： 234 活跃值： (3220) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 32 粉丝 0 关注私信	mb_heqvlbnm 3 楼 1 2025-7-12 20:59 0
Deice 雪币： 113 活跃值： (2095) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 23 粉丝 0 关注私信	Deice 4 楼如果在64位系统上跑，给出的也是32位大小的GDT表地址，不合理，难道给的是假的？ 2025-7-13 16:38 0
mb_shzsxtje 雪币： 1148 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 35 粉丝 0 关注私信	mb_shzsxtje 5 楼支持，感谢分享 2025-7-14 09:54 0
盗才生雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 28 粉丝 1 关注私信	盗才生 6 楼支持，感谢分享 2025-7-14 10:40 0
CCTV9 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 3 回帖 53 粉丝 2 关注私信	CCTV9 7 楼 6666 2025-7-14 15:44 0
边缘雪币： 3916 活跃值： (3974) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 55 粉丝 1 关注私信	边缘 8 楼支持，感谢分享 2025-7-14 20:36 0
李翔_702165 雪币： 0 活跃值： (903) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 14 粉丝 0 关注私信	李翔_702165 9 楼感谢分享 2025-7-14 21:39 0
paranioa 雪币： 754 活跃值： (1797) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 12 粉丝 0 关注私信	paranioa 10 楼感谢分享 2025-7-15 06:32 0
chipower 雪币： 239 活跃值： (313) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 23 粉丝 0 关注私信	chipower 11 楼感谢分享 2025-8-28 18:54 0
mb_vfttriqb 雪币： 201 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 8 粉丝 0 关注私信	mb_vfttriqb 12 楼 111111111111111 2025-9-4 21:37 0
byhk 雪币： 2646 活跃值： (8785) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 186 粉丝 1 关注私信	byhk 13 楼感谢分享 2025-9-19 07:49 0
mb_dmpagumk 雪币： 205 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 6 粉丝 0 关注私信	mb_dmpagumk 14 楼谢谢分享 2025-12-24 16:28 0
Fzzz 雪币： 3584 活跃值： (265) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 62 粉丝 0 关注私信	Fzzz 15 楼多核场景下的GDT读取思路很清晰 2026-8-26 14:56 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复