20242418 2026-2027-1 《网络与系统攻防技术》实验三实验报告

20242418 2026-2027-1 《网络与系统攻防技术》实验三实验报告

1 基础知识

1.1 核心术语与基本概念

术语	基本定义	本实验中的对应含义
恶意代码	用于实施未授权访问、破坏、控制或其他有害行为的软件或代码。	本实验以远程控制类样本为观察对象，关注安全软件的检测与处置。
Payload（载荷）	程序执行后实现特定功能的一段代码或模块。	工具生成的测试载荷用于比较文件结构和安全产品的检测表现。
Shellcode	通常指可由特定处理器架构直接执行的指令序列。	需区分原始指令、编码后的字节数据与外层可执行文件。
反向连接	目标程序主动发起到监听端的网络连接。	监听器运行、网络连接建立和会话交互成功属于不同验证阶段。
会话（Session）	双方通信建立后形成的逻辑交互通道。	需结合会话列表和系统信息输出核实，不以监听启动替代成功判据。
PE 文件	Windows 平台常用的可执行文件格式，包含文件头、节区和导入等结构。	可对比原始、编译与 UPX 压缩样本的体积和结构。
哈希（SHA-256）	将文件映射为固定长度摘要以识别文件内容是否一致。	用于样本身份核对；文件一旦变化，其摘要通常随之改变。

1.2 恶意代码的主要检测机制

检测类别	检测依据与原理	特点及局限
静态特征匹配	扫描文件字节序列、签名、导入表和已知特征。	速度较快，适于已知样本；样本变化可能影响固定签名匹配。
静态启发式分析	检查异常节区、可疑 API 组合、文件结构和程序特征。	无需依赖单个固定签名，但可能存在误报。
机器学习检测	利用训练模型对样本结构与统计特征进行综合判别。	可识别部分未知样本；判断依赖模型与输入特征。
行为检测	监控实际运行中的文件、进程、内存及网络活动。	可以识别静态层面不明显的行为；依赖运行上下文。
内存与解包分析	检查运行时内存内容，并识别压缩壳或封装特征。	UPX 压缩不等于免于检测；是否解包须依据具体日志判断。
云信誉与安全情报	综合文件信誉、威胁情报和安全服务反馈。	检测结果可能随联网状态、信誉与情报更新而变化。
多引擎检测	同一样本由多个防护引擎分别进行判定。	检出数并非“危险程度”分数，也不直接证明本机能否执行。

1.3 常见对抗技术及其检测局限

技术类别	基本概念	实验观察与局限
编码	对字节表达方式进行变换，运行时可能需要还原。	编码改变文件特征，但不能据此断言可规避动态检测。
数据加密	将数据转换为需经指定操作恢复的表示形式。	简单可逆变换与强加密不同，不能仅凭加密认定样本安全。
加壳与压缩	对可执行文件进行封装或压缩，改变文件组织形式。	UPX 改变大小和结构，安全软件仍可能识别壳类型或载荷行为。
代码混淆	改变代码呈现形式，同时尽量保持预期功能。	可增加分析成本，但不能消除实际的恶意行为。
模块分离	把程序功能或数据拆分到不同的文件或模块。	单文件静态结果不能替代对整体运行链路的检测。
运行时行为变化	程序在实际运行时产生不同的内存、进程或网络活动。	运行结果必须结合防护状态、时间与告警日志综合判断。

1.4 实验工具与平台

工具或平台	主要作用	本实验中的记录要点
Kali Linux	安全测试与分析操作系统。	用于命令执行、文件信息检查与网络连通性验证。
Metasploit / msfvenom	安全测试框架与样本生成组件。	记录工具输出、参数对应的样本形式及会话信息。
Veil-Evasion	用于研究不同样本封装形式的安全测试工具。	记录版本 3.1.14、生成文件和多引擎检测结果。
C / mingw-w64	C 语言开发与面向 Windows 的交叉编译工具链。	保留源文件、编译输出与文件格式信息。
UPX	通用可执行文件压缩工具。	记录打包前后体积变化及 PE 类型。
VirSCAN	多引擎文件扫描服务。	登记扫描时间、SHA-256、检出引擎数和参与引擎数。
Microsoft Defender	Windows 安全防护产品。	核对实时保护、引擎版本、特征库及告警处置。
火绒安全软件	安全防护产品，提供文件和网络等防护功能。	记录软件版本、病毒库时间、实时监控与告警日志。
EICAR	无害的标准杀毒软件测试字符串。	可辅助验证防护响应；文件不存在不单独证明具体处置方式。

1.5 检测指标及实验结果判读

记录要素	记录方法	判读原则
样本身份	文件名、大小、格式、SHA-256。	相同文件名不必然代表相同内容；优先使用哈希核验。
多引擎检出结果	按“检出数/参与引擎数”记录，如 6/48。	同一平台的不同时间和引擎数量可能不同，不直接等同于防护通过率。
安全软件状态	版本、病毒库时间、实时保护与相关模块开关。	只有与会话截图对应的当时状态，才能支撑该次测试结论。
检测阶段	区分浏览器拦截、文件扫描、运行时监控与隔离处置。	文件下载成功不代表安全软件放行，扫描未检出不代表运行时安全。
会话验证	会话列表、连接信息与目标系统信息。	会话建立与交互成功是独立于监听启动的验证结果。
环境与网络	虚拟网段、默认网关、DNS 解析与连通性。	DNS 故障与网关不可达需分层排查；网站错误不必然是平台故障。
实验局限	记录测试时间、条件差异、失败现象及未验证事项。	不能由检出数量差异推出单一技术的因果效果，也不能由一次成功得出长期稳定结论。

2 实验内容

我首先搭建并核对 Kali Linux、Windows 10 及虚拟网络环境，记录安全软件的版本与保护状态；随后使用 msfvenom、Veil-Evasion、C 语言和 UPX 构建不同形式的实验样本，观察编码、文件封装与组合处理后的文件类型、体积和多引擎检测情况。

在结果验证阶段，我通过 VirSCAN 记录样本扫描结果，并在 Windows Defender 与火绒环境下分别保留文件传输、检测告警及会话状态截图。对实验中出现的工具安装失败、网络解析异常、在线上传校验失败以及样本被隔离等现象，我结合错误输出和恢复后的验证结果进行归纳。

 

3 实验过程

3.1 实验环境与工具说明

本次实验中，我使用 Kali Linux 作为攻击机，Windows 10 虚拟机作为受测主机，并分别在 Microsoft Defender 与火绒环境下进行了样本检测与实测。为了保证分析可靠，我不仅记录了样本运行结果，还保留了安全软件状态、版本信息、网络故障排查、VirSCAN 检测以及 Meterpreter 会话信息。

项目	配置/版本	作用	说明
攻击机	Kali Linux 2025.4	样本生成、MSF 监听、VirSCAN 检测	终端提示符可见 kali@weiqihang
受测主机	Windows 10 22H2 (10.0 Build 19045)	运行样本并观察杀软行为	通过 sysinfo 验证
免杀相关工具	Veil 3.1.14、msfvenom、mingw-w64、UPX 4.2.4	生成、封装与编译样本	均有截图证据
安全软件 1	Microsoft Defender	对样本进行本地检测与拦截	已记录产品版本、引擎版本与特征库版本
安全软件 2	火绒 6.0.12.3	在第二轮实测中作为主防护软件	已记录版本号、病毒库时间和实时监控状态
检测平台	VirSCAN	统计多引擎检测结果	共记录多个样本的检测比率

3.2 具体实验步骤与结果

3.2.1 前期排障：网络、环境及工具检查

我在实验中遇到的第一个问题不是样本本身，而是网络环境。由于 VirSCAN 上传时经常报错，我反复上传后也失败，于是先从“网络是否通”“DNS 是否能解析”“本机能否访问目标站点”三个角度检查。这样做是为了避免把网络问题误判成平台问题，浪费时间。

图1 VirSCAN 上传失败时，我先在 Kali 终端中定位问题。图中可以看到 getent 与 curl 都无法正常解析 www.virscan.org。

从上图可以看到，getent 与 curl 都无法完成域名解析，说明问题不是浏览器上传按钮本身，而是 Kali 的网络访问链路存在异常。于是我继续检查本机到网关和外部地址的连通性，并重启网络相关服务。

图2 排查并重启网络相关服务后，局域网连通性与 DNS 解析恢复正常，Kali 已经能够解析出 www.virscan.org 的地址。

恢复后，Kali 可以成功 ping 通 192.168.153.2，并且 getent hosts 已经能够解析出 www.virscan.org 的 IP 地址。这个细节在报告里非常重要，因为它说明后续 VirSCAN 结果是建立在“网络恢复正常”的前提下得到的，而不是偶然刷新出来的。

在工具环境方面，我又进一步检查了 Veil 是否正确安装、配置文件是否生成，以及环境初始化是否完成。

图3 用 dpkg-query 确认 Veil 3.1.14 已正确安装，并检查到 /etc/veil/settings.py 已存在。

图4 Veil 环境初始化完成。该截图能够证明我不是直接套用别人结果，而是自己完成了 Veil 的配置与环境检查。

3.2.2 方法一：Veil-Evasion 样本实验

根据实验要求，我首先使用 Veil-Evasion 生成样本。之所以先做这一部分，是因为 Veil 属于比较典型、比较成熟的“免杀工具”路线，适合作为基准方案。与此同时，我也想用它和后面自己编写的 loader 方案做横向比较。

开始前，我先记录了 Defender 的版本信息和实时保护状态，以便把后续样本运行现象和当时的安全环境对应起来。

图5 先记录了 Microsoft Defender 的基础版本与签名版本，并确认实时保护处于开启状态。

图6 Veil 主界面加载了 41 个 payload，可用命令包括 list、use、checkvt 等。

图7 我通过 list 查看具体载荷列表，为后续选择 C 语言反向 TCP 载荷做准备。

浏览 payload 列表后，我选择了 c/meterpreter/rev_tcp。这样既能完成 Veil 样本生成，也便于我将现成工具生成的样本与后续自写 loader 方案进行对照，分析不同实现方式下的检测结果。

图8 在 Veil 中选择 c/meterpreter/rev_tcp，该 payload 属于纯 C 语言反向 TCP stager。

图9 Veil 成功生成 20242418_veil_c.exe，保留对应源码与 handler 资源文件。

图10 把 Veil 生成的可执行文件复制到实验目录，并统一整理生成的各类样本，便于后续检测与对比。

Veil 成功生成 20242418_veil_c.exe 后，我把样本复制到实验目录.接着，我将该样本上传到 VirSCAN，记录其多引擎检测结果。

图11 VirSCAN 显示 20242418_veil_c.exe 的检测结果为 9/48，这一结果说明样本仍能被部分引擎识别。

VirSCAN 的结果为 9/48。这个结果其实很有启发：它说明像 Veil 这种成熟工具虽然能够降低一部分静态检测率，但并不能让我“理所当然地认为已经完全免杀成功”。

3.2.3 方法二：msfvenom、C Loader 与 UPX

第二种方法中，使用 msfvenom 生成 shellcode，再把 shellcode 融入到 C 语言 loader 中进行编译。这样做的目的，是观察“自己控制加载过程”是否比直接用 Veil 更容易降低检测率。

图12 使用 msfvenom 生成 payload，并通过 x86/shikata_ga_nai 进行了 10 次编码，然后把 shellcode 组合到自己编写的 C loader 中。

从截图可以看到，我指定 windows/meterpreter/reverse_tcp 载荷，并使用 x86/shikata_ga_nai 做了 10 次编码。编码不是“万能免杀”，但它可以改变字节分布与特征表达，因此我把它作为本轮对比的一个变量。随后，我用 mingw-w64 把 loader_20242418.c 编译成 loader_20242418.exe。

图13 用 file 和 sha256sum 对三个样本进行文件类型与哈希值比对，确保后续 VirSCAN 上传的是准确样本。

为了保证后续检测对应的是正确样本，我又使用 file 与 sha256sum 对 veil 样本、loader 样本和 UPX 样本进行了文件类型与哈希校验。这个步骤虽然不复杂，但很必要，因为它能够避免“文件名相似却上传错样本”的低级失误。

图14 UPX 打包后，loader_20242418_upx.exe 的体积从 106490 字节压缩到 59386 字节，目录中能够看到打包前后的样本。

在此基础上，我又进一步使用 UPX 对 loader_20242418.exe 进行加壳压缩，得到 loader_20242418_upx.exe。这里我关注的不是简单“压缩体积”，而是通过改变文件结构、节区和壳特征，观察多引擎检测比率是否发生变化。

图15 VirSCAN 显示 loader_20242418.exe 的检测结果为 7/48。

图16 VirSCAN 显示 UPX 打包后的 loader_20242418_upx.exe 检测结果为 6/48，相比未打包版本略有下降。

检测结果表明，未加壳的 loader_20242418.exe 为 7/48，而 UPX 加壳后的 loader_20242418_upx.exe 为 6/48。这个结果说明 UPX 的确使检测率略有下降，但下降幅度有限。我由此得到的认识是：单独加壳的效果很有限，尤其面对会自动脱壳的主流引擎时，单一手段很难支撑“稳定免杀”。

3.2.4 方法三：组合技术实验

为了进一步满足“通过组合应用各种技术实现恶意代码免杀”的要求，我的第三种方案：把原始 shellcode 与执行逻辑分离，载荷主体不直接写入 exe，而是以 bin 文件形式单独存储，同时对 bin 做简单字节变换，再由 loader 在运行时恢复并执行，最后再对 loader 本体进行 UPX 打包。

之所以这样设计，是因为在前两轮实验里我已经观察到：如果恶意代码完整地落在 exe 中，很容易被静态特征直接命中。因此通过“落地文件不直接包含明文 shellcode”的方式，减少静态扫描压力。

图17 在组合技术阶段，先生成原始 shell_20242418.raw，再把其中每个字节加 3，得到加密后的 encrypted_20242418.bin。

我首先生成原始 shell_20242418.raw，大小为 354 字节，然后利用 Python 把每个字节加 3，生成 encrypted_20242418.bin。这样做虽然不是复杂加密，但可以验证“落地数据与真实 payload 脱钩”的思路。

图18 分离加载 loader 核心代码。

接着，编写 loader_sep_20242418.c：程序先打开 encrypted_20242418.bin，读取完整内容，逐字节减 3 恢复，然后申请可执行内存，复制解密后的 shellcode，再通过函数指针跳转执行。这个加载过程是本次实验最想强调的“组合思路”之一。

图19 用 mingw-w64 编译分离加载器，再通过 UPX 对 loader_sep_20242418.exe 进行打包，生成 loader_sep_upx_20242418.exe。

图20 打包完成后，实验目录中同时保留了 encrypted_20242418.bin、loader_sep_20242418.exe 和 loader_sep_upx_20242418.exe。

随后我用 mingw-w64 编译 loader_sep_20242418.exe，并通过 UPX 进一步打包，得到 loader_sep_upx_20242418.exe。最终实验目录中保留了三个关键文件：加密 bin、未打包分离加载器、UPX 打包后的分离加载器。

图21 VirSCAN 显示组合样本 loader_sep_upx_20242418.exe 的检测结果为 2/48，是本次实验中检测率最低的样本。

VirSCAN 结果显示，组合样本 loader_sep_upx_20242418.exe 的检测率为 2/48，是本次实验中记录到的最低静态检出数。但我没有把这一数字直接等同于实机验证成功，而是继续观察本地防护软件的拦截记录和运行现象，因为静态平台的检测结果不能替代真实环境中的验证。

3.2.5 防护软件环境实测与对比

3.2.5.1 Microsoft Defender 环境

在 Defender 环境里，我记录到了一个很有代表性的现象：同一类样本在不同时间点的命运并不完全相同。2026-10-21 当天，在实时保护、云保护、自动提交样本和篡改防护都开启的情况下，样本曾经建立过会话；但到 2026-10-22 上午，Defender 已经能够识别并拦截新的组合样本。这一现象使我真正理解了“免杀结果具有时效性”这句话。

图22 在 2026-10-21 的实验中，记录到 Defender 实时保护、云保护、自动提交样本和篡改防护都开启，而样本仍然建立过会话。这组证据说明结论具有“时间点”属性。

图23 重启后我再次验证，PowerShell 中 RealTimeProtectionEnabled 与 BehaviorMonitorEnabled 都为 True，同时 Meterpreter 会话仍然出现过，进一步说明测试现象是真实发生的。

从以上两张图可以看出，并不是在完全关闭 Defender 的情况下得出前一天的回连结果，而是在多个核心防护项开启的前提下观察到了真实会话现象。

但是到了第二天，Defender 又把组合样本标记为Behavior:Win32/Meterpreter.gen!D

3.2.5.2 火绒环境

为补充不同防护产品下的对照，我继续在火绒环境中记录测试现象，并核实防护开关、版本信息和实时监控状态。这样可以把 Defender 与火绒环境中的观察结果分开分析，避免将不同产品的表现混为一谈。

图25 在转入火绒环境实测时，我首先记录火绒版本号为 6.0.12.3，病毒库时间为 2026-10-21 19:18。

图26 为了避免双引擎相互影响，我确认 Microsoft Defender 在该轮火绒测试中已经处于未运行状态。

图27 火绒网络防护界面显示多项防护开关已经开启，包括网络入侵拦截、对外攻击拦截、僵尸网络防护和恶意网址拦截等。

首先，我记录了火绒版本号与病毒库时间，并确认 Defender 在本轮测试中未运行，避免双引擎并存导致结果难以解释。然后查看火绒网络防护界面，确保其核心网络防护项处于开启状态。

图28 在 Windows 端，我用 curl 分别下载了 loader_sep_upx_20242418.exe 和 encrypted_20242418.bin，两个文件都能够成功落地。

接着，在 Windows 端使用 curl 下载组合方案所需的两个文件：loader_sep_upx_20242418.exe 与 encrypted_20242418.bin。这里我刻意保留下载过程与目录列表，为了证明样本的确完成了“文件落地”，而不是只在共享目录里存在。

图29 在火绒环境中，session 4 已经建立，并显示了回连主机信息。

图30 进入 session 4 后，执行 sysinfo，确认目标主机为 Windows 10 22H2（10.0 Build 19045），Meterpreter 类型为 x86/windows。

在监听端，我观察到 session 4 已成功建立；随后进入会话执行 sysinfo，确认目标主机为 Windows 10 22H2，Meterpreter 类型为 x86/windows。

图32 用 EICAR 标准测试串检验火绒实时防护。PowerShell 在等待 3 秒后 Test-Path 返回 False，说明测试文件已被及时处理。

我又专门用 EICAR 标准测试串验证了火绒的实时监控功能。截图显示文件实时监控开关已打开，且写入 eicar_test.com 后等待 3 秒，Test-Path 结果为 False，说明测试文件已经被及时处理。这一组证据能增强报告的可信度。

3.3 检测结果汇总与分析

为了更清晰地比较三类主要方案的效果，我把本次实验中保留了截图证据的关键样本整理如下。这里的重点不是简单比较数字高低，而是把“用了什么技术”“检测率如何变化”“实机结果如何”同时放在一张表里。

样本名称	主要技术	关键文件信息	VirSCAN 结果	实机观察
20242418_veil_c.exe	Veil 生成的 C 语言反向 TCP 样本	PE32，约 109.59 KB	9/48	在实验过程中作为第一类基准样本使用，说明直接使用成熟工具仍会被多引擎识别
loader_20242418.exe	msfvenom 编码 + 自写 C loader	PE32，106490 B	7/48	比 Veil 样本检测率略低，说明自己控制载荷组织方式有一定作用
loader_20242418_upx.exe	前一方案基础上增加 UPX 加壳	UPX 压缩，59386 B	6/48	检测率继续下降，但降幅有限，说明单独加壳不是决定性因素
loader_sep_upx_20242418.exe + encrypted_20242418.bin	分离加载 + 简单加密 + UPX	exe 59374 B，bin 354 B	2/48	静态检测率最低；Defender 次日能拦截，火绒环境下可建立 session 4

从结果上看，我认为本次实验最重要的结论有三点。第一，静态检测率确实会受到编码、加壳、分离加载等技术影响，且“组合技术”优于“单一技术”。第二，静态平台的低检出率并不等于实机稳定通过，动态行为和特征库更新仍然会改变最终结果。第三，任何关于“免杀成功”的结论都必须附带时间、样本版本、杀软名称和防护状态，否则结论就容易失真。

4 问题及解决方案

4.1 网络与 DNS 异常导致软件源、工具安装和在线检测受阻。我先后遇到 apt update 无法解析软件源、apt install -y veil 提示无法定位软件包，以及浏览器访问 VirSCAN 失败的情况。进一步检查时，Kali 对网关 192.168.153.2 的 ping 返回 Destination Host Unreachable，curl 也报告无法解析 www.virscan.org。这些现象说明当时的问题不只是某个网站打不开。

处理与验证：我先检查 VMware 的 VMnet8 NAT 配置，确认实验网段为192.168.153.0/24；随后重新激活 Kali 网络连接，并重启 VMware NAT、DHCP 与 DNS 相关服务。恢复后我按“网关连通性—域名解析—目标网站访问”的顺序复核，而不是只看浏览器是否能打开页面。这次排查让我认识到，安装失败的报错有时只是上游网络故障的结果。我应先验证 IP 连通性，再验证 DNS，最后验证应用层服务；每一步都保留输出，才能把真正的原因和表面现象区分开。

软件源域名解析失败，安装工具时无法定位软件包

4.2 浏览器拦截与 Defender 后续隔离：不能把一次运行结果当成长期结论

处理与验证：我将浏览器下载拦截、VirSCAN 静态扫描结果、Windows Defender 告警和实际运行结果分开记录，并核对告警对应的文件名与时间。对已隔离文件，我不把“文件被删除”当作程序本身故障，也不把此前的会话建立当作长期免检的证明；后续测试均限定在隔离实验环境中。

4.3 火绒开启实时监控时，EICAR 测试文件写入后很快不可见

处理与验证：我没有通过关闭防护来让测试文件留存，而是保留实时监控开启状态，记录写入时间、等待时间和检查结果，并检查安全软件界面及日志。EICAR 仅用于验证杀毒软件响应，不是真实恶意程序，因此这一验证可以在不运行真实恶意样本的情况下观察防护是否介入。

4.4 实验思考题

4.6.1 杀毒软件是如何检测出恶意代码的？

杀毒软件主要通过特征码匹配、启发式分析、机器学习、行为监控和云端检测等方式识别恶意代码。静态检测主要分析文件特征，动态检测则关注程序运行过程中的可疑行为。

本次实验中，VirSCAN 可以检测出不同样本的恶意特征；Windows Defender 则曾将组合样本识别为 Behavior:Win32/Meterpreter.gen!D 并进行拦截，说明杀毒软件不仅能够检测文件特征，还能通过运行时行为发现威胁。

4.6.2 免杀是做什么的？

免杀是指通过改变程序的代码特征、文件结构或运行方式，降低其被杀毒软件识别和拦截的概率，使程序在特定检测环境下能够运行。

本次实验中，我尝试了编码、加壳和组合技术，发现部分样本的检出数量有所下降，但后续仍被 Defender 识别。这说明免杀并非永久有效，其效果受到杀毒软件版本、检测策略和测试环境等因素影响。

4.6.3 免杀的基本方法有哪些？

常见的免杀方法包括：

1. 编码与加密： 改变代码或数据的字节特征，降低直接匹配的可能性。

2. 加壳技术： 通过 UPX 等工具改变可执行文件结构。

3. 代码混淆： 调整代码表示形式，增加静态分析难度。

4. 分离加载： 将程序数据与加载逻辑分开组织，改变文件特征。

5. 组合技术： 综合使用多种方法，研究不同检测机制下的表现。

5 学习感悟与思考

5.1 对检测机制与实验条件的认识

通过这次实验，我对“免杀”有了比以前更立体的理解。以前我对免杀的印象比较简单，总觉得只要换个工具、加个壳、改几个字节，就有机会完全绕过杀软。但真正动手之后，我发现现实远比想象复杂。一个样本能不能通过，不仅取决于代码本身，还取决于检测引擎类型、特征库版本、云端策略、行为监控、运行时环境，甚至取决于测试发生的时间点。

5.2 对检测时效性与复现性的认识

我印象最深的一件事，是同一类样本在 10 月 21 日曾建立会话，到了 10 月 22 日却被 Defender 标记和拦截。这让我意识到，实验中的“成功”不是绝对结论，而是与测试时间、样本版本和防护状态相关的阶段性结果。因此，我在火绒环境补充验证时，也同步记录了产品版本、防护开关、EICAR 测试和会话信息，使不同测试结果能够相互对照。

5.3 对组合技术及分析方法的认识

另一个收获是，我对“组合技术”的理解变得更清楚了。前两种方案里，不管是 Veil 还是普通 loader，本质上都还是把主要恶意内容放在单个 exe 中；而分离加载方案把落地文件拆成了 loader 和加密 bin 两部分，既减少了静态暴露，也让我更容易分析每一步究竟改变了什么。这种“先拆问题，再做组合”的思路，不仅适用于免杀实验，也适用于我今后做其他安全实验。

6 参考资料

[1] 博客园实验参考资料：https://www.cnblogs.com/zjhzbyc/p/19153096

[2] 博客园实验参考资料：https://www.cnblogs.com/jasmine-fancy/p/23377807