当前位置:主页 > 网络安全 >

ddos防护_ddos防火墙源码_怎么办

时间:2021-07-16 16:21来源:E度网络 作者:E度网络 点击:

ddos防护_ddos防火墙源码_怎么办

今天我们开始一个旅程来回答一个问题:在WoW64下,64位ntdll是如何加载到32位进程中的?这个旅程将带我们进入Windows内核逻辑的未知领域,我们将发现32位进程的内存地址空间是如何初始化的。什么是WoW64?来自MSDN:|WOW64是x86仿真器,允许基于32位Windows的应用程序在64位Windows上无缝运行。换言之,随着64位版本Windows的推出,公安备案ddos防御,微软需要拿出一个解决方案,让在32位Windows时代编写的应用程序能够与64位Windows的新底层组件无缝交互。具体来说,64位内存寻址和直接与新内核通信的组件两个NT层,一个内核在32位Windows中,调用WindowsAPI的应用程序通过一系列动态链接库(DLL)进行路由。但是,所有系统调用最终都路由到ntdll.dll,这是Usermode中将用户模式api的执行传递到内核的最高层。一个例子是调用CreateFileW。此API调用在用户模式下从kernel32.dll发出;然后将其作为NtCreateFile传输到ntdll,然后NtCreateFile通过系统调用调度器将控制权转移到内核。在32位Windows下,这是非常简单的-但是,在WoW64下必须采取额外的步骤。32位ntdll无法直接将控制权传递给内核,因为内核现在是64位可执行文件,只接受64位ABI之后的类型。由于这个原因,一个翻译层被添加到64位窗口中,以几个dll的形式被规范地命名为wow64.dll wow64cpu.dll和wow64win.dll. 这些DLL负责将32位发起的调用转换为64位调用。这些调用最终通过映射到每个32位进程的64位ntdll进行路由。有很多关于32位系统调用到64位调用的神奇转换的信息(1),所以我们就不在这里讨论了。我们主要关注的是内核如何以及何时将64位版本的ntdll映射到32位进程。这看起来像:特别是,我们对倒数第二的条目感兴趣。我们可以观察到ntdll映射到的地址是一个64位地址范围(7FFFFED40000-7FFFFEF1FFFF),它的位置在Windows的64位系统文件所在的System32\目录中。但是,我们知道32位进程不能访问或在64位内存空间中工作。为了理解上面的输出,我们必须首先讨论VAD(虚拟地址描述符)是什么,以及它将如何帮助我们理解将64位ntdll加载到32位进程中的机制什么是虚拟地址描述符?VAD是Windows操作系统跟踪系统中可用物理内存的多种方法之一。VAD专门跟踪每个进程在Usermode范围内的保留和提交的地址。每当一个进程请求一些内存时,都会创建一个新的VAD实例来跟踪它。VAD结构为自平衡树,其中每个节点(VAD实例)描述一个内存范围。每个节点最多可以包含两个子节点;左边是低地址,右边是高地址。每个进程都分配了一个VadRoot,然后可以遍历它来标识描述保留或提交的虚拟地址范围的其他节点。的输出!来自WinDBG的vad命令值得注意,因为这是我们主要用来跟踪64位Windows中32位进程映射的输出。并不是所有的领域对我们来说都特别有趣。让我们考虑一下测试应用程序的输出HelloWorld.exe. 我们首先通过!process ProcessObject命令。一旦我们确定了VadRoot,我们就把这个地址输入到!vad命令。(为便于分析,输出已被截断)。我们看到五个列标题:"VAD"、"Level"、"Start"、"End"和"Commit"。这个!vad命令本身接受vad实例的地址;在我们的例子中,我们向它提供了使用!此进程的进程命令。VAD地址是当前VAD结构或实例的地址:级别描述了此VAD实例(节点)所在的树中的级别。级别0是从中获得的VadRoot!上述过程输出。起始地址和结束地址值用VPN(虚拟页码)表示。这些地址可以通过乘以页面大小(4kb)来转换为它们的虚拟地址,或者左移3。结束VPN将添加额外的0xFFF以扩展到页面的结尾。在上面的例子中,D20->D20000和DD2->dd2ff。Commit是此VAD实例描述的范围内提交的页数。分配的类型是next,它告诉我们特定的范围是映射的还是进程私有的访问类型描述范围的允许访问,局域网ddos防御方法,last是与映射区域关联的任何名称。VAD实例可以通过多种方式创建;通过使用映射API(CreateFileMapping/MapViewOfFile)或内存分配(如VirtualAlloc函数)。内存可以保留或提交(或释放),也可以保留并部分提交。无论是哪种情况,VAD条目都映射到进程的VAD树中,以让内存管理器知道该进程的当前内存分配。我们对VAD的研究将揭示在WoW64下运行的32位进程的初始设置映射NT子系统DLL在进程初始化的早期,Windows在映射和初始化主可执行文件之前确定并保留特定区域的特定地址范围。其中一些包含初始进程地址空间、共享系统空间(KUSER_shared_DATA)、控制流保护位图区域和NT本机子系统(ntdll)。由于进程初始化的总体复杂性,我们只对最后一部分感兴趣,它包含将32位ntdll和64位ntdll加载到32位进程地址空间的逻辑。我们将通过跟踪一系列API调用并密切关注描述每个点的内存区域的虚拟地址描述符(vad)来进行观察。为了让内核区分如何映射新进程,它需要知道这是否是一个WoW64进程。它通过读取名为_EPROCESS.WOW64流程最初创建流程对象时。如果此值为真,则会相应地映射内存。PspAllocateProcess是我们旅程的起点,但更具体地说,我们将从MmInitializeProcessAddressSpace()开始。MmInitializeProcessAddressSpace()负责与新进程的地址空间相关的许多初始化。它调用MiMapProc essExecutable,创建定义初始进程的可寻址内存空间的VAD条目,然后将新创建的进程映射到其基虚拟地址。其中一个特别有趣的函数是PspMapSystemDlls。让我们看看在调用PspMapSystemDlls之前进程的地址空间是什么样子的。在WinDBG中,我们确保当前处于测试应用程序(.process)的上下文中,并查找当前的Vad根目录(!vad输出)。我们可以观察到,到目前为止,我们的进程已经在32位地址空间中映射并分配了一个基址(1200),内核共享内存(0x7FFE0000-0x7FFE0FFF)和64KB保留内存(0x7FFE1000-0x7ffffff)区域也被映射到各自的虚拟地址。PspMapSystemDlls遍历包含多个平台子系统模块信息的全局指针。对于x86和x64 Windows,这些是ntdll.dll分别位于C:\Windows\SysWow64和C:\Windows\System目录中。一旦PspMapSystemDlls找到要加载的相关dll,它就会调用PspMapSystemDll将它们映射到进程的地址空间中。这个函数非常简短和直接,下面显示了一个代码片段。为了使它映射正确的本机子系统dll,需要满足某些条件。PspMapSystemDll通过调用MmMapViewOfSection执行本机dll的实际映射,并保存捕获的基址。映射这两个DLL并初始化它们的VAD项之后,我们的32位进程地址空间如下所示:现在,我们的进程已经被映射(0xc40000-0xcf2ff)、共享内核内存空间(0x7ffe0000-0x7ffe0fff)、32位地址空间的有效结束区域(0x7ffe1000-0x7ffffff)和两个NT子系统dll。锁定地址空间要完成32位进程的映射,c语言做ddos防御,app如何防御cc,必须执行最后一步。我们知道一个32位进程最多只能寻址2GB的虚拟内存*所以Windows需要为这个进程屏蔽剩余的地址空间。对于32位进程,30g高防能防御多少ddos攻击,这发生在0x7FFF0000-0x7FFFFFFF范围之后;但是,不能在0x7ffffff之后映射任何内容。因此,需要保留(或屏蔽)与64位NTDLL相邻的内存区域。为了实现这一点,内核将剩余的64位地址空间标记为私有。它通过遍历当前进程的VAD树并找到最后一个可用的虚拟地址来创建这个VAD条目,然后追加并预置一个新的VAD条目。完成此任务的API是MiInitializeUserNoAccess。此函数接收当前进程句柄和虚拟地址。传递的虚拟地址是0x7FFF0000,它是32位进程的最后一个可寻址范围的开始。然后,它继续遍历当前的VAD条目,并执行一个新范围的插入,该范围覆盖32位进程的剩余地址空间。在这个调用之后,进程的地址空间现在看起来像:我们现在可以看到,我们的32位进程已经被映射

推荐文章
最近更新