- 博客(111)
- 收藏
- 关注
RSS订阅原创 WaitForSingleObject分析（二）
先看 kernel32!这个函数本身几乎没有什么实质逻辑，它只是一个很薄的封装层。hHandlebAlertable所以这里可以先得到一个很重要的结论：WaitForSingleObject 本质上只是 WaitForSingleObjectEx 的一个简化包装版本，区别在于它把 bAlertable 固定为了 FALSE。
2026-04-09 23:36:28
418
原创 等待块（一）
在windows内核中，凡是头部以开始的对象都是被等待对象_DISPATCHER_HEADER = 内核等待对象的公共头Windows 等待机制里，线程是唯一的等待者；而带 _DISPATCHER_HEADER 的对象是可被等待的 dispatcher object，其中线程对象本身也属于可被等待对象。等待者永远是线程；被等待者是 dispatcher object；线程对象本身既能等待别人，也能被别人等待。就是干这个的。它本质上是 线程 和 等待对象 之间的一条“挂接记录”。
2026-04-09 23:33:01
207
原创 DebugActiveProcess 调试流程分析（二）
DbgUiDebugActiveProcess 本身并不负责完成复杂的附加逻辑，它首先只是把目标进程句柄和调试对象句柄传给 NtDebugActiveProcess，由内核去建立真正的调试关系。接下来，DebugActiveProcess 会继续调用 DbgUiDebugActiveProcess，开始真正的“附加目标进程”流程。在内核里完成“目标进程 ↔ 调试对象”的正式绑定，并为附加调试准备好第一批初始调试事件。让调试器在附加到一个已经运行中的进程后，能够尽快收到一个调试事件，从而接管该进程。
2026-04-05 15:41:12
366
原创 DebugActiveProcess 调试流程分析（一）
到这里，这条链路就已经比较清楚了。本身并不直接完成全部调试附加逻辑。它的第一步，是调用 DbgUiConnectToDbg，先检查当前线程是否已经保存了调试对象句柄；如果没有，就进入内核调用 NtCreateDebugObject。而 NtCreateDebugObject 的职责也非常明确：测试用户输出参数 DebugHandle合法性先把输出句柄清零校验 Flags，只允许 0 或 DEBUG_KILL_ON_CLOSE。
2026-03-22 15:17:55
424
1
原创 Win7 x64 下 32 位程序系统调用全过程解析（一）
32 位程序↓↓API - MS↓↓↓wow64cpu!↓↓↓↓syscall↓ 64 位内核。
2026-03-21 13:14:41
424
原创 SEH：局部展开（八）
之所以能保证“离开 try 前一定执行 finally”，并不是因为编译器偷偷把 finally 插到 return 前面那么简单，而是因为运行时提供了 __local_unwind4 这样一套真正的“局部展开”机制：它会按照 ``ScopeTable +TryLevel的关系，把当前函数里沿途该执行的 __finally 一层层跑完，然后控制流才能真正离开当前 try。
2026-03-20 21:51:09
225
原创 用户态异常处理：SEH 调用链分析（五）
到这里，的 SEH 分发部分就基本清楚了。它的后半段核心逻辑可以概括为：先获取当前线程的栈边界和 SEH 链表头根据决定采用哪种异常链校验模式要么先整链预扫要么在主循环中逐节点校验对每个 SEH 节点做合法性检查节点必须位于当前线程栈上节点必须对齐handler 不能落在当前线程栈区间内handler 还要通过通过真正调用异常处理函数根据handler返回的决定后续动作：恢复执行：继续找下一层 SEH：记录嵌套异常状态其它返回值：抛出退出前统一调用VEH 进程级分发↓。
2026-03-18 19:08:27
387
原创 SEH详解（七）
这里，我们先不展开的具体结构，而是先借助简化结构体，建立一个最重要的认识：对于来说，编译器并不是给每一个 try 都单独往 FS:[0] 挂一个新的异常节点。更常见的做法是：在函数入口只挂一次异常注册结构，然后配合 scopetable 和 trylevel 来描述当前函数内部多个 try 的关系。从这段反汇编中，我们已经能清楚看到：next 对应原来的 fs:[0]_except_handler4 是真正挂到异常链上的统一入口scopetable 保存当前函数所有异常作用域的信息。
2026-03-17 11:25:07
377
原创 __try / __except 和 __try / __finally 用法（六）
是微软编译器提供的语法扩展，属于 SEH（Structured Exception Handling，结构化异常处理），不是 ISO 标准 C/C++ 语法。__try/__except 的本质，是 MSVC 基于 Windows SEH 机制提供的一套非标准编译器扩展语法。
2026-03-12 13:25:32
277
原创 用户态异常处理：VEH 调用链分析（四）
这个函数的作用可以概括为一句话：根据 vehIndex 选择 VEH 或 VCH 链表，检查 PEB 标志位，构造，然后依次遍历链表中的处理函数，直到某个处理函数返回，或者遍历完整个链表为止。│▼│ 根据 vehIndex 计算目标链表 ││▼│ 读取 PEB . CrossProcessFlags ││ 检查 ProcessUsingVeh / ProcessUsingVch 标志位 │││ 对应标志位是否置 1?││否 │是▼ ▼。
2026-03-07 01:32:09
448
原创 什么是VEH（三）
做了五件事：分配一个节点编码 handler 指针选择 VEH 链表加锁插入链表一句话概括：VEH 本质就是一个带锁的全局双向链表。它是被保存在 ntdll 内部的一个全局链表中。
2026-03-06 18:46:50
295
原创 异常的派发（二）
│▼│ 1) 入口：SEH Prolog + KeExceptionDispatchCount++ ││ 选择 ContextFlags (是否保存 FPU/XMM/XState) ││▼│ 2) 内核栈分配 Extended CONTEXT ││▼│▼│ 4) 异常码“修正/特判” ││ - UserMode 下可能 KiCheckForAtlThunk ││▼│▼ ▼。
2026-03-05 21:13:20
464
原创 异常的登记（一）
我们从一个最简单、最典型的 CPU 异常 #DE（Divide Error） 入手，当逆向 Windows 7 x86 内核对异常的处理路径，并以此为入口分析 nt!表示 ExceptionInformation[] 数组中 有效参数的个数（0~15）。存放异常的 附加参数，具体每个参数的含义取决于 ExceptionCode。0x80000003 → 断点异常（INT3）异常嵌套（异常在异常处理过程中再次发生）处理器/内核在构造异常记录时会填它。发生异常的指令地址（EIP）。指向“前一个异常记录”。
2026-03-05 14:15:48
258
原创 Win7 x64 分页机制（9-9-9-9-12）完整解析
在 Win7 x64 下，处理器运行于 Long Mode（IA-32e paging）。这不是 Windows 的设计，而是 Intel IA-32e 架构规定的分页模式。Windows 只是运行在这个硬件机制之上。
2026-02-21 05:37:12
562
2
原创 Win7 x64 内存管理（一）
本质：描述一段连续虚拟地址区间的内核数据结构换句话说：VAD 用来描述进程地址空间中一段连续的虚拟地址区间，以及该区间的类型、保护、提交和映射信息。
2026-02-15 18:59:16
815
原创 x64——long-mode下的段描述符（四）
64bit-mode和。64bit-mode的执行环境和执行环境在compatibility-mode下，处理器的行为与legacy模式一般无异。在64位模式下，处理器可使用的物理资源得到扩展。—— 《x86/x64体系探索及编程》
2026-02-07 09:28:13
558
原创 x64——Long-mode（三）
Windows x64 启动后，CPU 永远运行在 Long Mode。64 位代码执行于 64-bit Mode，32 位代码执行于 Compatibility Mode。两种模式共享同一套 64 位分页机制，但执行语义不同。
2026-02-05 11:34:03
385
原创 x64之调用约定（二）
Windows x64 ABI 规定：前 4 个参数槽位固定存在，每个槽位同时绑定一个 GPR 和一个 XMM参数序号整型使用浮点使用1RCXXMM02RDXXMM13R8XMM24R9XMM3因此在 add3 的调用点可以看到：它们不会相互抢寄存器。Shadow Space 是 Windows x64 ABI 规定的 32 字节栈空间，由调用者分配，供被调用函数使用。[rsp+08h] 参数1[rsp+10h] 参数2[rsp+18h] 参数3。
2026-01-27 11:15:48
318
原创 x64（一)
在 VS2019 的 x64 项目中，写汇编只能使用“独立汇编文件 + MASM”从 Intel SDM 的角度来看，x64 虚拟地址并不是完整使用 64 位。在反汇编工具中，x64 下对全局变量的访问表面上看起来和 x86 几乎一致，默认情况下，VS2019 的 C/C++ 项目并不会编译 .asm 文件，x64 处理器真的使用了完整的 64 位虚拟地址空间。x64 不只是“加寄存器”，还补全了子寄存器体系。x64 的通用寄存器已经全部扩展到了 64 位。事实上，x64 的地址是“受限制的 64 位”。
2026-01-26 14:10:32
664
原创 二进制转反汇编
E: 操作码后跟一个 ModR/M 字节，用于指定操作数。当操作数大小为 32 位或 64 位 时表示 doubleword。ModR/M 字节的第 5、4、3 位（即 reg/opcode 字段）用作操作码扩展。v:字 / 双字 / 四字（64 位模式），取决于操作数大小属性。参见 A.4 节《一字节与两字节操作码的操作码扩展》。（如果存在 SIB 字节，则位于 SIB 字节之后），I:立即数：操作数的值直接编码在指令的后续字节中。运行模式：32 位保护模式（IA-32）默认操作数大小：32 位。
2026-01-25 20:33:02
430
原创 intel白皮书卷2 第二章（AI翻译）
有效的操作码表达式附录 A附录 B在64 位模式下，ModR/M 的 Disp32（32 位偏移量）编码而不再表示仅由偏移量构成的绝对地址。有关该重新定义的具体细节，请参见表 2-7。RIP 相对寻址所使用的ModR/M 编码并不依赖任何前缀的使用。具体而言，用于选择RIP 相对寻址的r/m 位字段编码 101B不会受到 REX 前缀的影响。当REX.B = 1且r/m = 101B（即试图选择 R13）并且mod = 00B此时，编码结果仍然表示 RIP 相对寻址。
2026-01-25 17:06:53
1223
原创 用户 APC 的执行过程（下）
本文分析了Windows用户APC在Ring3中的执行流程。当线程从内核返回用户态时，KiUserApcDispatcher接管执行，首先建立专用的SEH异常处理机制保护APC回调。随后调用用户注册的NormalRoutine执行实际回调。回调完成后，通过恢复原始异常链并调用ZwContinue再次进入内核，将执行环境恢复至APC发生前的状态，确保线程透明地继续原有执行流。整个过程体现了Windows APC机制对线程执行流的巧妙控制。
2026-01-13 18:21:44
630
原创 用户 APC 的执行过程（上）
文章摘要： 本文深入分析了Windows内核中用户APC的执行机制，重点剖析了KiInitializeUserApc函数的关键作用。研究发现，用户APC并非在KiDeliverApc中直接执行，而是通过KiInitializeUserApc为返回用户态时执行APC做好准备。该函数主要完成以下工作：1)检查执行环境是否允许用户APC；2)从TrapFrame/ExceptionFrame提取用户态上下文；3)在用户栈构造APC执行环境；4)拷贝CONTEXT到用户栈；5)修正TrapFrame使其符合Ring
2026-01-13 13:53:52
696
原创 API函数的调用过程（下）(ring0部分)
系统调用返回流程解析 本文详细分析了Windows内核在系统调用返回时的完整处理流程，指出内核函数返回并不等于系统调用结束。关键点包括： 返回前校验：检查调用来源（Ring0/Ring3）、当前IRQL级别、线程挂靠状态等 APC处理：验证线程APC状态，确保满足返回用户模式条件 TrapFrame回收：恢复线程的TrapFrame指针，完成调用栈清理 安全性检查：包括虚拟8086模式检测、性能统计等额外验证 中断处理：返回前关闭中断以确保现场恢复的原子性 整个过程展现了Windows内核严谨的系统调用退出
2026-01-12 16:28:47
730
原创 内核 APC 的执行过程
本文分析了Windows 7 x86系统中的KiDeliverApc函数，这是APC(异步过程调用)机制的核心执行函数。文章将其汇编代码转换为C伪代码，详细解析了四个关键执行阶段：首先检查线程的APC总开关SpecialApcDisable；然后进行TrapFrame切换和状态初始化；接着循环处理内核APC队列，执行KernelRoutine并在条件满足时执行NormalRoutine；最后处理用户APC队列，仅执行KernelRoutine并为返回用户态准备执行环境。该函数实际上是一个完整的APC调度分发
2026-01-11 09:05:14
801
原创 插入APC
摘要 本文分析了Windows内核函数KeInsertQueueApc的反汇编代码。该函数用于将APC(异步过程调用)插入目标线程的APC队列。主要流程包括：提升IRQL到DPC级别，获取线程APC队列自旋锁，检查线程是否允许APC入队(ApcQueueable标志)和APC是否已插入(Inserted标志)。若条件满足，则调用KiInsertQueueApc完成插入操作。代码展示了内核同步机制(自旋锁)和APC队列管理的关键细节。
2026-01-11 00:15:56
897
原创 初始化APC
摘要：本文分析了 Windows 内核函数 KeInitializeApc 的实现机制。该函数用于初始化异步过程调用(APC)对象，主要完成三项工作：1) 设置 APC 所属线程和环境；2) 指定要执行的内核/普通例程；3) 配置执行上下文。通过反汇编分析可见，函数会初始化 KAPC 结构体中的 Type、Size 等字段，并根据参数设置线程指针、例程指针和执行模式等信息。特别处理了不同环境(Original/Attached)下的 ApcStateIndex 值，并确保未使用的 NormalRoutine
2026-01-08 06:43:12
305
原创 APC的结构
APC（Asynchronous Procedure Call）是一种机制，用于让内核或用户代码在指定线程的上下文中，延迟执行一段函数。可以把 APC 理解为：“有人往线程的待办事项里塞了一件事，但线程什么时候做，取决于线程什么时候看待办事项。就像是对线程说：“等你有空了，帮我顺便执行一下这段代码”，而不是“立刻中断你现在的工作”
2026-01-08 05:46:32
816
原创 全局句柄表（cid表）
本文解析了Windows内核中的CID表机制，指出PID/TID本质上是全局句柄表中的特殊句柄值。通过Win7 x86实验验证，PID通过CID表可直接定位到EPROCESS对象体，而无需遍历进程链表。文章详细展示了从PID计算句柄索引、解析二级句柄表、定位对象体的完整过程，揭示了CID表与私有句柄表的关键差异：CID表存储EPROCESS/ETHREAD对象体，而非对象头。这一机制解释了PsLookupProcessByProcessId等API的高效实现原理。
2026-01-04 11:47:39
961
原创 私有句柄表
本文摘要： Windows句柄机制解析：句柄本质上是进程句柄表中的一个索引值，而非对象指针或内核地址。每个进程拥有独立的句柄表（_HANDLE_TABLE），管理对象引用关系。句柄表采用可变层级结构（1-3级），通过TableCode字段标识层级。句柄表项（_HANDLE_TABLE_ENTRY）存储对象头指针（OBJECT_HEADER）和访问权限等信息，其中对象指针的低3位被复用为标志位。OBJECT_HEADER作为对象的身份证，包含类型信息、引用计数等元数据。通过分析OBJECT_HEADER可确定
2026-01-02 08:50:42
531
1
原创 API函数的调用过程（上）(ring0部分)
到这里为止，我们已经完整走完了：从用户态 sysenter到 KiFastCallEntry到 KTRAP_FRAME 构造到 SSDT 查表再到真正的内核函数 NtOpenProcess也就是说：系统调用的“进入阶段”已经全部完成。从这一刻开始，CPU 已经不再执行系统调用框架代码，而是正式进入了具体内核服务的实现逻辑。sysenter 没有返回指令，Windows 又是如何回到 Ring3？下一篇将从 call ebx 之后开始，继续跟踪。
2025-12-25 14:44:13
936
原创 什么是SSDT
本文介绍了Windows系统中的系统服务号(SSN)和服务描述符表(SSDT)机制。系统服务号是用户态调用内核函数的标识，通过EAX寄存器传递，包含12位索引和1位表选择位。内核通过SSDT（函数指针数组）将服务号映射到具体函数，包括KeServiceDescriptorTable（NT服务）和KeServiceDescriptorTableShadow（GUI服务）。当执行sysenter指令时，内核根据EAX值从对应SSDT中获取函数地址完成调用，实现了用户态到内核态的安全跳转。
2025-12-25 12:09:36
332
原创 重写 OpenProcess：绕过 Win32 API，直接进入 NT 内核（Win7 x86）
本文探讨了在Windows 7 x86环境下绕过常规API调用链直接通过sysenter进入内核的方法。通过分析kernelbase.dll中的OpenProcess函数实现，展示了如何手动构造OBJECT_ATTRIBUTES和CLIENT_ID结构体，并直接调用NtOpenProcess系统调用。文章重点在于理解系统调用机制，包括参数整理、栈布局以及sysenter指令的使用，为深入研究Windows系统调用提供了技术参考。
2025-12-24 17:49:09
300
原创 API函数的调用过程(ring3部分)
本文以Win7 x86环境为例，通过IDA静态分析跟踪OpenProcess API的完整调用链。从kernel32.dll的导出表开始，发现其仅作为跳板函数，通过IAT跳转至API-MS转发层。随后调用进入kernelbase.dll实现层，该层负责参数整理并转换为NT调用格式，最终通过NtOpenProcess进入ntdll.dll。整个过程展示了Win32 API从用户态到内核态的系统调用路径，揭示了Windows API调用的多层次转发机制。
2025-12-22 07:22:27
667
原创 ring0与ring3通信
设备对象是驱动在内核中创建的、用于接收 I/O 请求的内核对象。在 Windows 中，驱动程序本身并不能直接接收 IRP，真正接收 IRP 的，是驱动创建的 设备对象（DEVICE_OBJECT）。创建成功后，系统会为该驱动生成一个设备对象，之后所有发往该设备的 IRP，都会被派遣到这个设备对象所属的驱动中。这个设备并不对应真实硬件，而是一个“纯软件设备”，用来承载用户态与驱动之间的通信。
2025-12-14 03:13:23
399
原创 驱动开发之遍历驱动
摘要 本文介绍了Windows内核驱动遍历的实现原理和方法。通过分析_LDR_DATA_TABLE_ENTRY结构体，说明了每个加载的驱动模块都会通过链表相互连接。遍历过程包括三个步骤：获取当前驱动的链表节点、通过链表指针找到下一个节点、还原出下一个驱动模块信息。文章提供了完整的代码示例，展示了如何通过DriverSection指针遍历系统所有已加载驱动，并输出每个驱动的名称、基址和大小等信息。该技术可用于内核模块监控和分析。
2025-12-13 03:27:21
266
原创 驱动开发之字符串操作
摘要：本文介绍了Windows内核驱动中字符串操作的关键注意事项。相比用户态，内核态字符串操作错误会直接导致蓝屏。主要内容包括：1) UNICODE_STRING和ANSI_STRING结构体定义及初始化；2) 安全拷贝字符串的方法；3) 字符串比较函数的使用；4) Unicode与ANSI字符串相互转换的实现。特别强调内存管理和边界检查的重要性，提供了Rtl系列API（如RtlCopyUnicodeString、RtlCompareString等）的实用示例，并指出需要释放系统分配的内存缓冲区。
2025-12-12 14:18:32
235
原创 第一个驱动程序
本文介绍了Windows驱动程序开发的基本流程和跨版本兼容性调试技巧。主要内容包括：1) 创建空驱动项目并配置开发环境；2) 编写简单的驱动入口函数和卸载函数；3) 使用WinDbg调试技巧；4) 重点分析了Win10驱动在Win7系统蓝屏的原因，发现是安全Cookie机制差异导致；5) 通过修改__security_cookie值并修复PE校验和，成功实现Win10驱动在Win7系统运行。文章提供了详细的逆向分析和解决方案，对Windows驱动开发人员具有实用参考价值。
2025-12-11 23:13:38
390
原创 TLB实验
TLB实验验证摘要 TLB(Translation Lookaside Buffer)是处理器用于缓存页表转换结果的专用缓存，可避免每次访问内存时逐级查询页表。通过实验验证：修改页表后若未刷新TLB，CPU仍会使用缓存的旧映射；而执行mov cr3指令或设置PTE的G位(全局页)可控制TLB刷新行为。实验代码动态修改虚拟地址0的页表项，分别映射到不同物理页，对比TLB刷新前后的内存访问结果，证实了TLB的工作机制及其与CR3寄存器、PTE属性的关联性。
2025-12-10 19:47:43
593
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人