文章作者:r00tk1t 发布时间:2018年01月08日 - 21时56分 最后更新:2020年10月20日 - 21时01分 原始链接:https://r00tk1ts.github.io/2018/01/08/关键的Windows内核数据结构一览(上)/ 近期一直在整理归纳知识体系,译几叠好文,写数篇心得,旨在温故而知新.放眼四壁,一时浩如烟海,月迷津渡.在翻译fuzzySecurity的Windows exploit开发系列教程第十部分时,觅得此文,甚佳,不敢独酌. Windows的内部

3.系统机制 微软提供了一些基本组件让内核模式的组件使用: 1.陷阱分发,包括终端,延迟的过程调用(DPC),异步过程调用(APC),异常分发以及系统服务分发 2.执行体对象管理器 3.同步,包括自旋锁,内核分发器对象,以及等待是如何实现的. 4.系统辅助线程 5.其他的机制,比如Windows全局标记 6.本地过程调用 7.内核事件跟踪 8.Wow64 3.系统机制 3.1陷阱分发 3.1.1 中断分发 3.1.1.1 硬件中断 3.1.1.2 软中断请求级别(IRQL) 3.1.1.3 软中

搞内核研究的经常对中断这个概念肯定不陌生,经常我们会接触很多与中断相关的术语,按照软件和硬件进行分类: 硬件CPU相关: IRQ.IDT.cli&sti 软件操作系统相关: APC.DPC.IRQL 一直以来对中断这一部分内容弄的一知半解,操作系统和CPU之间如何协同工作也是很模糊.最近花了点时间认真把这块知识进行了梳理,不当之处,还请高手指出,先行谢过了! 本文旨在解答下面这些问题: 1.IRQ和IRQL之间是什么关系? 2.Windows是如何在软件层面上虚拟出IRQL这套中断机制的 3.A

目录 . 相关阅读材料 . <加密与解密3> . [经典文章翻译]A_Crash_Course_on_the_Depths_of_Win32_Structured_Exception_Handling.pdf . < DAY安全: 软件漏洞分析技术> 2. 数据结构分析 二. KTHREAD KTHREAD(内核层线程对象).再次重复说明一点: windows内核中的执行体(ETHREAD, EPROCESS) 负责各种与管理和策略相关的功能,而内核层(或微内核)(KTHREAD,

在之前的一篇文章中介绍了替换IDT向量表中的地址来达到Hook的目的 IDT hook KiTrap03 但是这样很容易就可以被检测了.接下来要学习就是通过patch GDT来达到Hook IDT的目的. 首先,我们要了解一下,当触发INT 3号中断之后,CPU是如何找到接下来要执行的指令的地址. CPU 在执行中断的时候,先会得到中断描述符表中该中断的中断例程(InterruptFunc ),然后得到该中断描述符中的段选择符,解析出段选择符对应的GDT(因为中断例程全都是在内核层中)中的地址(

关于idt的基本知识就不进行赘述了,先看一个例子 0 ;------->进入内核,找到中断处理例程KiTrap03 0 这段代码执行,触发3号中断,然后开始执行KiTrap03例程,要知道,执行完中断以后还是要回到原来的程序处继续执行的,也就是我们这的Mov eax, 1的指令,显然,发生中断时的寄存器环境就要被保存,便于之后的恢复程序运行,这里,就出现了一个结构_KTRAP_FRAME,陷阱帧. kd> dt _KTRAP_FRAME nt!_KTRAP_FRAME +0x000 DbgEb

一.前言 在NT中,有两种类型的APCs:用户模式和内核模式.用户APCs运行在用户模式下目标线程当前上下文中,并且需要从目标线程得到许可来运行.特别是,用户模式的APCs需要目标线程处在alertable等待状态才能被成功的调度执行.通过调用下面任意一个函数,都可以让线程进入这种状态.这些函数是:KeWaitForSingleObject, KeWaitForMultipleObjects, KeWaitForMutexObject, KeDelayExecutionThread. 对于用户模

一.前言   对于IDT第一次的认知是int 2e ,在系统调用的时候原来R3进入R0的方式就是通过int 2e自陷进入内核,然后进入KiSystemService函数,在根据系统服务调用号调用系统服务函数.而2e就是IDT(系统中断描述符表)中的索引位2e的项,而KiSystemService就是该项的例程函数,后来为了提升效率,有了系统快速调用,intel的的cpu通过sysenter指令快速进入内核,直接通过kiFastCallEntry函数调用系统服务函数,各种杀软也做了这个地方的Hoo

内核调试入门 内核程序运行在内核态,因此不能像对用户态应用程序那样来调试.关于内核调试方面的知识请参考<软件调试>这本书.目前内核调试主要有以下三种方法. 一是使用硬件调试器,它通过特定的接口(如 JTAG)与 CPU 建立连接并读取它的状态,例如 ITP 调试器. 二是在内核中插入专门用于调试的中断处理函数和驱动程序.当操作系统内核被中断时,这些中断处理函数和驱动程序接管系统的硬件,营造一个可以供调试器运行的简单环境,并用自己的驱动程序来处理用户输入.输出,例如 SoftICE 和 Syse

KTHREAD 线程调度 SDT TEB SEH shellcode中DLL模块机制动态获取 <寒江独钓>内核学习笔记(5)   继续我们的线程相关的数据结构的学习.接下来我们学习 KTHREAD,TEB这两个结构. 1. 相关阅读材料 1. <加密与解密3> 2. [经典文章翻译]A_Crash_Course_on_the_Depths_of_Win32_Structured_Exception_Handling.pdf 3. <0 DAY安全: 软件漏洞分析技术>

-------------------------------------------------------------------------- 前一篇指出 tail_recursivef_factorial() 会递归调用自身来计算某个正整数的阶乘.当要计算的目标数值过大,经历多次调用后, 就会耗尽可用的内核栈,引发一次页错误异常,而转移控制到错误处理程序前再次向无效的内存地址压入"陷阱帧"则会让原本可 以处理的异常升级为"double fault",致使系统

本篇读书笔记主要参考自<深入解析Windows操作系统>和<软件调试>这两本书. IDT是处理异常,实现操作系统与CPU的交互的关口. 系统在初始化阶段会去填写这个结构. IDT的每一个表项都成为门描述符,因为IDT的功能就像大门一样,从一个空间跳到另一个空间去执行. IDT中包含三种门描述符 任务门描述符:用于任务切换 中断门描述符:用于描述中断处理例程 陷阱们描述符:用于描述异常处理例程 CPU如何使用IDT cpu首先根据IDTR找到IDT,再利用向量号码找到门描述符.再去判

0x01 前言 我们知道R3层中,Zw系列函数和Nt系列函数函数是一样的,但是在内核Zw系列函数调用了Nt系列函数,但是为什么要在内核设置一个Zw系列函数而不是直接调用Nt函数呢?Zw系列函数又是怎么调用Nt系列函数的呢?我们利用IDA分析NtosKrnl.exe文件. 0x02 ZwProtectVirtualMemory 我们先看看ZwProtectVirtualMemory的实现 . ; NTSTATUS __stdcall ZwProtectVirtualMemory(HANDLE Pr

Dump 文件分析很大程度上就是分析蓝屏产生的原因.这种系统级的错误算是Windows提示错误中比较严重的一种(更严重的还有启动黑屏等硬件或软件兼容性错误等等).说它是比较严重,是因为毕竟Windows还提供了dump文件给用户分析,至少能比较容易的找到错误的原因.一般蓝屏要么是内核程序中的异常或违规,要么是数据结构的损坏,也有boot或shutdown的时候内核出错.有时候蓝屏是一闪而过,紧接着是系统重启:有时候是蓝屏等待.总之蓝屏的时候都提示了一些停止代码和错误信息,不过这些提示是不全面的,

二.字符串通配符语法 一些调试器命令具有接受各种通配符的字符串参数.这些类型的参数支持以下语法功能: 星号(*)表示零个或多个字符. 问号(?)表示任何单个字符. 包含字符列表的括号([])表示列表中的任何单个字符.列表中只有一个字符匹配.在这些括号中,可以使用连字符(-)指定范围.例如,prog[er-t7]am匹配“progeam”.“program”.“progsam”.“progtam”和“prog7am”. 数字符号(#)表示前面零个或多个字符.例如,lo#p与“lp”.“lop”.“

Windbg里的K*命令显示给定线程的堆栈帧以及相关信息,对于我们调试时,进行调用栈回溯有很大的帮助. 一.K*命令使用方式 在不同平台上,K*命令的使用组合如下 User-Mode, x86 Processor [~Thread] k[b|p|P|v] [c] [n] [f] [L] [M] [FrameCount] [~Thread] k[b|p|P|v] [c] [n] [f] [L] [M] = BasePtr [FrameCount] [~Thread] k[b|p|P|v] [c]

  本篇原文为 X64 Deep Dive,如果有良好的英文基础的能力,可以点击该链接进行阅读.本文为我个人:寂静的羽夏(wingsummer) 中文翻译,非机翻,著作权归原作者所有.   由于原文十分冗长,也十分干货,采用机翻辅助,人工阅读比对修改的方式进行,如有翻译不得当的地方,欢迎批评指正.翻译不易,如有闲钱,欢迎支持.注意在转载文章时注意保留原文的作者链接,我(译者)的相关信息.话不多说,正文开始: 关于 X64 平台执行和调试关键方面的深度教程,例如编译器优化.异常处理.参数传递.堆栈

可变参数函数的实现与函数调用的栈结构密切相关,正常情况下C的函数参数入栈规则为__stdcall, 它是从右到左的,即函数中的最右边的参数最先入栈. 例如,对于函数: void test(char a, int b,double c,char * d){ printf("a:%#p\nb:%#p\nc:%#p\nd:%#p",&a,&b,&c,d); } int main(){ char ch; test(,,&ch); ; } 从各个形参变量的地址可以

入栈规则 可变参数函数的实现与函数调用的栈帧结构是密切相关的.所以在我们实现可变参数之前,先得搞清楚 栈是怎样传参的. 正常情况下,C的函数参数入栈遵照__stdcall规则, 它是从右到左的,即函数中的参数入栈是从右到左的. 例如: void test(char a, int b,double c,char * d){ printf("a:%#p\nb:%#p\nc:%#p\nd:%#p",&a,&b,&c,d); } int main(){ char ch;

本篇内容主要来自Unity官方手册: 一般性能优化 一些地方为本人瞎编杜撰,请酌情参考.如有错误,欢迎指出. Unity里C#编程虽然既简单还很爽,但是性能小陷阱还不少.我总强迫自己让代码最优,因此很留意这些细节.这里我记录了一下最近发现的一下优化点.   协程 别嵌套 协程( Coroutine )固然爽,我用起来可得心应手了,刷刷刷,平滑动画,等待加载,定时启动…… 官方的意见是: 在可能的情况下,最好将一系列操作压缩到尽可能少协程.虽然嵌套协程非常适合代码清晰度和维护,但由于协程跟踪对象,