企业官网建设流程全解析

简介：《计算机病毒原理与防范（第2版）》实验详细内容是一套面向信息安全专业学生、网络安全从业者及进阶用户的配套实验资源包，旨在通过动手实践掌握病毒分析、传播机制、防护策略、系统安全设置、数据恢复与安全法规等关键环节。压缩包内共514个文件，大小约39.3MB，主要文件类型包括C/C++源码、Visual Studio工程配置、编译生成的库与可执行程序、实验报告文档，并配以大量编译日志与调试记录，便于从源码阅读到编译运行的完整实验流程。目前已有139人学习下载。资源内含PE结构解析、病毒扫描器示例、修改入口表与入口代码等感染方式演示项目，可对照教材逐项复现，理解恶意代码的构造与查杀思路，提升系统防护和数据恢复的实际操作能力。

1. 这门课不是让你背病毒的：实验包打开的姿势决定了你能学到多少

翻开《计算机病毒原理与防范（第2版）》的实验目录，很多人第一反应是找个“实验报告模板”直接抄，等到期末答辩被问一句“这个病毒为什么绕过了你的查杀”就当场卡壳。这门课的实验包真正要训练的不是“运行病毒然后截图”，而是建立一套从样本分析到防御落地的闭环思维——拿到一个来路不明的PE文件，你能说清楚它改了哪些注册表键、写入了哪个启动项、流量发往哪里，然后给出针对性的清除方案。

这套实验内容适合三类人：正在修这门课、需要独立完成实验报告的学生；刚接触恶意代码分析的开发者和运维；以及想系统补上“攻防视角”这一课的安全爱好者。后面的内容全部围绕实验包中常见的实验模块展开，包括实验环境构建、静态与动态分析、查杀对抗、行为取证，一路写到参数怎么调、坑在哪里、结果怎么验证，保证你看完能照着把实验跑通，并且知道自己每一步在做什么。

2. 用虚拟机搭一个“中毒不心疼”的实验台：沙箱隔离与快照回滚

2.1 为什么要坚持在虚拟机里做病毒实验

我在带新人做恶意代码实验时，第一条规定永远是“物理机禁止运行任何样本”。病毒感染不是电影里的视觉特效，它往往静默完成——改写MBR、注入系统进程、释放驱动，等你看到弹窗或文件被加密时，系统已经处于被控制状态。实验包里的样本虽然大多是可公开获取的教学样本，但“教学”不代表“无害”，一旦在物理机触发，重装系统是最轻的代价，内网横向渗透才是真正的灾难。

虚拟机的核心价值在于两层隔离。第一层是CPU级隔离，VMware或VirtualBox的虚拟机监控器将客户机指令限制在独立的内存和CPU上下文中，虚拟机内的进程无法直接访问宿主机内存；第二层是网络隔离，通过NAT或仅主机模式，虚拟机对外部网络的访问完全可控。你可以在虚拟机里放开手脚观察样本行为，同时保证宿主机不暴露在风险中。

实验包要求的环境配置通常不复杂，我一般建议分配2个虚拟CPU、2GB以上内存、40GB动态磁盘，操作系统选用Windows 7 x64或Windows 10 LTSC。选择Windows 7不是因为它先进，而是它的内核结构相对简单，注册表和进程机制的改动能被各类监控工具完整捕获，不会被系统自身的新特性干扰判定。

2.2 快照就是病毒实验的“后悔药”

快照机制是虚拟化平台给恶意代码分析提供的最佳礼物。它记录虚拟机某一时刻的完整磁盘状态和内存状态，恢复时能精确回到该时刻。在运行样本前打一个“干净快照”，实验结束后无论系统被折腾成什么样，一句话就能还原。

我常用的快照策略是“两层快照”：安装好操作系统并完成基础配置后打一个“基础快照”；每次开始一组新的实验前再打一个“实验前快照”。这样如果单个实验做砸了，恢复“实验前快照”即可，不用重新配置系统环境。

VMware和VirtualBox都提供了命令行快照工具，适合批量管理和自动化场景。下面这组命令是VMware Workstation Pro的常用操作：

# 列出当前虚拟机的所有快照 vmrun listSnapshots "D:\VMs\Win7_Lab\Win7_Lab.vmx" # 创建一个名为"lab-before-ransomware"的快照 vmrun snapshot "D:\VMs\Win7_Lab\Win7_Lab.vmx" "lab-before-ransomware" # 恢复到指定快照，-t参数指定恢复到当前快照并幂等处理 vmrun revertToSnapshot "D:\VMs\Win7_Lab\Win7_Lab.vmx" "lab-before-ransomware"

这段命令的逻辑是先把当前虚拟机的快照列表打出来确认基准点，然后新建快照，最后在需要回滚时直接恢复。snapshot命令先于样本执行，确保样本运行前系统处于已知良好状态。参数-t在部分版本中用于指定快照类型，无特殊需求时默认即可。

VirtualBox的对应命令稍有不同：

# 创建快照 VBoxManage snapshot "Win7_Lab" take "clean-baseline" --description "系统纯净状态" # 恢复快照 VBoxManage snapshot "Win7_Lab" restore "clean-baseline"

使用快照时有一条血泪经验：一定不要在“样本已运行但尚未分析完”时覆盖快照。快照一旦覆盖，之前记录的系统异常状态就消失了，你只能从头再复现一次样本行为，浪费时间不说，有些样本的行为具有随机性，第二次可能不触发。

2.3 实验网络的三种模式与流量观察窗口

病毒实验的网络配置直接决定两层东西：一是样本能否顺利运行（有些样本需要联网下载第二阶段载荷），二是你能观察到多少网络行为。实验包里的样本按网络行为可分为三类——完全离线型、触发后联网型、常驻通信型，对应不同的网络策略。

从落地角度，我把网络模式按风险和控制粒度做个对比：

默认情况下我推荐NAT模式。虚拟机里的样本发起网络请求时，流量会经过宿主机VMnet8网卡转发，此时在宿主机上用Wireshark抓包，就能看到样本与外部IP的完整通信过程。仅主机模式适合不需要联网的样本——比如只做静态分析或只观察文件系统改动，这时切断外网等于给样本上了锁链。

运行联网型样本前，建议先在虚拟机里打开procmon（Process Monitor）并设置网络过滤条件，然后启动样本，观察它访问了哪些域名和IP。不要急着拦截，第一次运行的目的是“看”，看清楚了再考虑限制。

3. 静态与动态分析的基本功：用文件指纹和行为快照还原样本意图

3.1 静态分析的第一步不是“运行”，而是“别运行”

拿到实验包里的exe或dll样本，新手最容易犯的错误是双击运行。正确顺序是先把样本当“嫌疑犯”审一遍——不做任何执行，只从文件本身提取信息。这个阶段使用的工具未必需要昂贵的商业套件，系统自带的命令和几个开源小工具就能完成大部分工作。

我在静态分析阶段必做的四件事：计算哈希、查看文件类型、提取字符串、解析PE头。这四步层层递进——哈希用于唯一标识样本和查VirusTotal；文件类型用于确认是不是PE文件；字符串能暴露样本的路径、域名、注册表键；PE头则揭示导入函数、节区、数字签名等关键结构。

下面这组命令在Windows的cmd或PowerShell里直接可用：

# 计算SHA-256哈希，用于样本定位和威胁情报查询 Get-FileHash .\sample.bin -Algorithm SHA256 | Format-List # 查看文件头信息，确认真实文件类型 Format-Hex .\sample.bin | Select-Object -First 4 # 提取文件中的ASCII和Unicode字符串 # 需要Sysinternals工具包里的strings64.exe .\strings64.exe -a .\sample.bin > strings_output.txt # 查看PE文件的DOS头和NT头关键字段 # 使用dumpbin（Visual Studio自带）或pefile库 dumpbin /headers .\sample.bin

Get-FileHash输出的SHA-256值是样本的唯一身份证，记录到实验报告中是基本要求。Format-Hex看文件前四个字节——正常PE文件的起始字节为4D 5A（MZ），如果看到其他字节，说明文件可能被处理过或根本不是PE。strings64.exe的-a参数让工具扫描整个文件而不只扫描特定节区，这样可以找出藏在资源段或附加数据中的字符串。

然后是重头戏PE结构解析。这一步建议直接用Python的pefile库写脚本，输出信息比工具默认展示的更容易理解：

import pefile pe = pefile.PE("sample.bin") # 展示导入函数表，看样本调用了哪些系统API print("=== Imported DLLs and Functions ===") for entry in pe.DIRECTORY_ENTRY_IMPORT: print(f"[{entry.dll.decode()}]") for imp in entry.imports: print(f" {imp.name.decode() if imp.name else 'ordinal ' + str(imp.ordinal)}") # 展示节区信息，重点关注节区名称和熵值 print("\n=== Sections ===") for section in pe.sections: name = section.Name.rstrip(b'\x00').decode(errors='replace') entropy = section.get_entropy() print(f"{name}: virtual_size={section.Misc_VirtualSize}, entropy={entropy:.2f}")

这个脚本的输出分两部分。导入表列出样本用到的DLL和函数——比如看到CreateRemoteThread和VirtualAllocEx组合，几乎可以断定是注入类行为；看到CryptEncrypt和InternetOpenUrl组合，则很可能指向勒索或数据外传。节区信息中熵值大于7的节区通常指示加密或压缩内容——正常程序编译出来的代码节熵值在5.5到6.5之间，异常高熵节往往是加壳或加密的痕迹。

3.2 动态分析：让样本在监控下“表演”

静态分析能给出“它可能想干什么”，动态分析则是让样本真正跑起来，观察它实际干了什么。实验包中的动态分析模块通常包含注册表监控、进程行为监控、文件系统监控三块，对应的工具组合是procmon + Wireshark + 火绒剑（或Process Explorer）。

在启动样本前，我先给procmon设置好三类过滤规则：操作类型限定为RegSetValue、RegCreateKey、WriteFile、CreateFile、Process Create和Network Operation；路径排除系统正常活动的噪音路径，比如C:\Windows\System32下的部分通用操作；进程名限定为样本自身的进程名。这样procmon记录到的行为日志就不会被系统自身的刷屏操作淹没。

启动样本后，等待2到3分钟让样本完成初始化，然后停止捕获并导出日志。导出为CSV后用Excel做透视表分析，或者用Python脚本提取关键行为链。下面这段脚本能从procmon导出的CSV中快速提炼出高价值行为：

import csv HIGH_VALUE_KEYS = [ r"Software\Microsoft\Windows\CurrentVersion\Run", r"Software\Microsoft\Windows\CurrentVersion\RunOnce", r"System\CurrentControlSet\Services", ] with open("procmon_log.csv", newline="", encoding="utf-8") as f: reader = csv.DictReader(f) for row in reader: operation = row["Operation"] path = row["Path"] # 注册表持久化位置是高危信号 if operation in ("RegSetValue", "RegCreateKey") and any( key.lower() in path.lower() for key in HIGH_VALUE_KEYS ): print(f"[PERSISTENCE] {operation}: {path} = {row['Result']}") # 写入可执行文件到系统目录 if operation == "WriteFile" and path.lower().endswith((".exe", ".dll", ".sys")): print(f"[DROP] WriteFile: {path}") # 进程注入行为，目标进程非系统正常进程 if operation == "Process Create" and "Temp" in path: print(f"[PROCESS] {row['Process Name']} -> {path}")

这段脚本把procmon日志中三类关键信号提出来：写入启动项的注册表操作、在系统目录释放可执行文件、从临时目录创建进程。脚本本身不复杂，但它的价值在于帮你从几十万条噪音记录中快速锁定异常行为——手工翻日志找这些信号会花掉你大量时间，而且容易漏。看到[PERSISTENCE]输出时，实验报告里就该写“样本通过修改Run键实现开机自启”，而不是模糊地写“该样本具有持久化能力”。

3.3 内存分析：动态分析的“最后一层皮”

实验包中进阶一点的实验会要求做内存转储分析。原因是某些样本的恶意行为不落地到磁盘——它们直接在被注入的进程中以内存形式存在。这种情况下磁盘看是干净的，但内存已经沦陷。常见做法是用Mimikatz或DumpIt抓取进程内存镜像，再用Volatility分析。

Volatility的关键命令如下：

# 识别镜像对应的操作系统版本 volatility -f memory.dmp imageinfo # 列出进程列表，查找异常进程 volatility -f memory.dmp --profile=Win7SP1x64 pslist # 检查网络连接，查找可疑外联 volatility -f memory.dmp --profile=Win7SP1x64 netscan # 扫描隐藏进程，对抗进程伪装 volatility -f memory.dmp --profile=Win7SP1x64 psscan

imageinfo是所有后续分析的前提，它的输出会告诉你镜像对应的操作系统版本和profile名称，后续命令必须指定这个profile才能正确解析。netscan输出的TCP或UDP连接列表与Wireshark抓包对照，能确认样本是否还在与外部保持通信。psscan的价值在于检测通过DKOM（直接内核对象操作）隐藏的进程——普通pslist看不到，psscan直接从内存池中扫描进程对象，隐藏的进程也无所遁形。

内存分析属于进阶操作，实验包里未必每个实验都要求，但如果你打算在答辩时秀一手“我不仅做了行为分析还做了内存取证”，这组命令值得提前跑通。

4. 查杀对抗与免杀实验：从“被杀”到“理解杀”的过程

4.1 免杀实验的本质不是攻击，是理解查杀的盲区

实验包里有一类实验让不少人困惑：为什么要求我们做“免杀”？如果目标是防范病毒，为什么还要教如何让病毒躲过查杀？我的理解是——不了解查杀引擎的判定逻辑，就无法真正写好查杀规则或加固主机。一个只知道“用杀软扫描”的人，面对杀软报不了毒的样本时束手无策；而做过免杀实验的人知道，特征码定位、加壳混淆、行为拆分这些技术正对应了查杀引擎的三个弱环：静态特征匹配、文件结构扫描、行为序列关联。

实验包里的免杀实验通常限定在“修改样本特征以规避特征码查杀”这一层面，不涉及真正的漏洞利用或持久化对抗。你可以把它理解成一个“白帽走查”——通过修改样本的字节内容，让病毒查杀引擎无法将文件与已知病毒库中的特征匹配。

4.2 特征码定位：找到那个让杀软“认脸”的字节区间

特征码是杀软比对文件时使用的唯一标识片段，它可能是一个字符串、一段汇编指令序列或者某个特定结构。定位特征码的常见手段是“二分法”——把样本切成若干段，逐段测试哪一段被查杀，然后缩小范围。手工做这件事很痛苦，我一般用Python写一个自动替换脚本来完成粗定位：

import hashlib import os # 读取样本并做切分 with open("sample.bin", "rb") as f: data = f.read() chunk_size = 512 chunks = [data[i:i+chunk_size] for i in range(0, len(data), chunk_size)] # 将每块数据替换为0x00，然后计算哈希用于识别 for idx, chunk in enumerate(chunks): temp_data = bytearray(data) start = idx * chunk_size temp_data[start:start+chunk_size] = b"\x00" * len(chunk) temp_path = f"patched_{idx}.bin" with open(temp_path, "wb") as f: f.write(temp_data) # 这里不直接调用杀软，而是记录每个变体的哈希供自动化测试 sha = hashlib.sha256(temp_data).hexdigest() print(f"Chunk {idx:03d}: offset={start:#010x}, sha256={sha[:16]}...")

这个脚本的逻辑是将样本按512字节切块，逐一将某一块用零字节替换，生成一个变体文件，并计算哈希。实际检测时需要你把每个patched_*.bin放到装有杀软的测试机上扫描，记录哪些变体不再被查杀。如果一个变体的第N块被替换后杀软不再报警，说明特征码就在这一块中。

定位到特征码后，修改方式因特征类型而异。如果是字符串特征，直接改字母大小写或用等价同义词替换；如果是汇编指令特征，用功能等效的指令序列替换——比如把mov eax, 0改成xor eax, eax，效果相同但字节不同。这里有一条实操经验：不要只改一处，至少改三处以上，否则杀软升级特征后很快会重新检出。

4.3 加壳与脱壳：为什么实验报告里必须写清“壳”的类型

加壳实验是另一个高频模块。壳的本质是用一段解密程序包裹原始代码，运行时先解密再执行。加壳后的样本静态分析几乎看不到有效字符串和导入表，动态分析也需要先等自解密完成。实验包里通常要求你用UPX、VMP或Themida给样本加壳，再观察杀软和工具的反应。

我在指导学生做加壳实验时经常强调一个点：加壳不是给样本“穿上隐身衣”，而是把恶意逻辑从一个显式的文件内容变成一个动态的解密过程。杀软对加壳样本的处理方式有两种：直接报“可疑”或尝试脱壳后再报毒。因此实验报告若只写“加壳后杀软不查杀了”是不够的——你需要说明杀软是不查杀了，还是报为Heuristic（启发式）类型，还是脱壳后依然杀。

UPX加壳的命令极简单，适合教学演示：

# 对样本进行UPX压缩/加密处理 upx -9 -o packed_sample.exe sample.bin # 验证壳信息 upx -t packed_sample.exe

-9表示最高压缩级别，-o指定输出文件名。注意UPX加壳并不会改变文件的入口点指向解密代码的方式，但upx -t能验证壳是否完整——测试失败说明壳被破坏或样本本身不支持加壳。实验报告里应该同时记录加壳前后文件大小、入口点偏移、节区数量这三个指标，它们能直观反映壳的加壳强度。

加壳对抗的是静态查杀，但现代杀软早已加入动态行为查杀层——样本运行时一旦出现文件遍历、注册表写入和网络外联等行为序列，即便没有任何静态特征也会触发拦截。这就解释了为什么免杀实验越做越深入后，结论会落回“行为检测才是查杀的终局手段”。

4.4 免杀实验中的伦理边界

写到这里必须停下来说清楚一条红线：免杀实验的全部意义在于理解查杀引擎的工作原理、掌握特征提取方法，用于提升防御方能力——比如给杀软补充特征、给EDR调优检测规则、给蓝队做攻防演练。如果读者学完这套内容后去改造真实恶意样本、绕过企业安全防护，那不仅偏离了课程设计意图，还可能触犯法律。我的个人习惯是，做完免杀实验后立即重启虚拟机并恢复快照，样本分析产生的临时文件一律不进宿主机目录。

5. 避坑指南：五类实验翻车现场与排查思路

5.1 虚拟机和宿主机之间“文件传不出来”

现象：在虚拟机里分析完样本，导出报告或日志时发现共享文件夹无法访问，提示权限不足，或者直接找不到共享路径。

原因：共享文件夹功能依赖VMware Tools或VirtualBox Guest Additions。如果虚拟机内的安全软件把Tools的某些组件禁用了，或者系统更新后Tools版本与虚拟机监控器不匹配，共享就会失效。

解决：不用共享文件夹，改用HTTP服务或FTP中转。在宿主机上起一个临时HTTP服务，虚拟机内用curl或浏览器下载所需文件。反向传输时，在虚拟机里起服务、宿主机来取。这种方法不依赖Tools，兼容性最好。或者尝试重装Tools，但有时安全策略会再次干扰。

5.2 样本一运行，系统直接蓝屏

现象：双击样本后，虚拟机瞬间蓝屏，重启后系统异常或直接无法引导。

原因：样本触发了内核级行为——加载恶意驱动或修改关键内核结构，超出了虚拟机的容错能力，导致系统崩溃。这种情况在小内存配置（小于1GB）或精简系统镜像上更常见。

解决：第一步不要慌，从“基础快照”恢复即可。第二步调整虚拟机内存到2GB以上，并关闭虚拟机的“内存预留”选项。第三步改用安全的内存转储配置——在系统属性中设置“小内存转储（256KB）”，蓝屏时生成的minidump文件可以交给调试分析。如果反复蓝屏且无法分析行为，可以考虑换一台配置更高的机器做动态分析，或者改用“仅主机模式”减少外部干扰。

5.3 杀软把实验工具和样本一起杀了

现象：准备分析工具的阶段，procmon或Wireshark突然被系统自带的安全中心查杀；复现实验时，刚拷贝进来的样本还没运行就被隔离了。

原因：默认安全策略过于激进，将“可疑文件”和“黑客工具”等同处理。这与样本本身的恶意性无关，是安全产品的“宁可错杀”策略在起作用。

解决：在虚拟机内明确添加排除项——把实验工具安装目录和样本存放目录都加入Windows Defender的排除列表。具体操作是“设置—更新和安全—Windows安全中心—病毒和威胁防护—管理设置—排除项”。如果你用的是第三方安全软件，同样在其白名单中添加排除路径。这是实验环境的正常配置，不需要在实验报告中掩盖。

5.4 快照恢复后网络不通

现象：从快照恢复后，虚拟机内显示“未识别的网络”或网络适配器没有分配到IP，但快照创建前网络是正常的。

原因：快照恢复改变了虚拟机的MAC地址——某些虚拟化平台在恢复快照时重新分配MAC，Windows会把新MAC对应的网络视为陌生网络并重置防火墙配置。同时NAT网络服务可能在快照恢复过程中被宿主机重置。

解决：先确认VMware NAT服务是否在运行——Windows服务管理器里找VMware NAT Service，未运行则手动启动。再删除并重建虚拟机的网络适配器，重新设置为NAT模式。以上两步能解决九成问题。剩下的一成是Windows防火墙需要重新允许相关协议——保险起见，直接在虚拟机内关闭防火墙（仅限实验环境）。

5.5 样本怎么等都“不出事”，实验做不下去

现象：按实验指导书操作，运行样本后等了十分钟，procmon里一个异常行为都没有，网络连接也干干净净，实验没法收尾。

原因：两根常见原因。第一是样本存在“环境检测”机制——它检测到虚拟机环境（VMware Tools进程、虚拟网卡MAC、特定CPU指令）后主动进入睡眠或退出，这是恶意软件规避分析环境的常见手段。第二是运行缺少参数——部分样本需要配置特定的命令行参数或运行条件才能触发恶意行为。

解决：先说环境检测的应对——安装VMware Tools时选择“不自动运行”，让样本难以通过进程名检测到虚拟化；或者改用“影子服务”工具隐藏虚拟环境特征。再说参数问题——观察样本导入表中的GetCommandLineA函数，如果存在说明样本可能依赖命令行参数；用cmd.exe带不同参数运行样本，配合procmon观察行为差异。如果以上都试了依然无行为，去查样本的编译时间和数字签名——可能是准备阶段的下载器样本，需要配合特定时间或远程服务器响应才能激活。

6. 行为日志的验证闭环：用时间轴还原“查杀结论”是否站得住

做完实验不等于实验报告成立。我见过大量报告写着“样本会通过Run键持久化”，但对应的procmon时间戳和行为序列截图对不上。要避免这种逻辑漏洞，最后一步必须做行为日志的时间轴重建——把进程创建、文件写入、注册表修改、网络外联四类事件按时间排列，验证它们构成一条有逻辑链条的攻击序列。

实操方法是用Python解析procmon导出的CSV，按进程PID和时间戳聚合事件，生成带时间轴的执行摘要：

import csv from collections import defaultdict timeline = [] with open("procmon_full.csv", newline="", encoding="utf-8") as f: reader = csv.DictReader(f) for row in reader: # 过滤掉系统进程的刷屏记录，只保留样本及其子进程 if row["Process Name"] in ("sample.exe", "cmd.exe", "powershell.exe"): timeline.append({ "time": row["Time of Day"], "pid": row["PID"], "operation": row["Operation"], "path": row["Path"], "result": row["Result"], }) # 按时间排序并输出关键行为 timeline.sort(key=lambda x: x["time"]) print("=== 关键行为时间轴 ===") for event in timeline: if event["operation"] in ( "Process Create", "RegSetValue", "WriteFile", "TCP Connect", "UDP Send" ): print(f"{event['time']} | PID {event['pid']} | {event['operation']} | {event['path']} | {event['result']}")

脚本做的事情是过滤出样本及其子进程的事件，并且只保留五类关键操作——进程创建、注册表写入、文件写入、TCP连接、UDP发送。输出结果就是一个时间轴，你能直观看到“进程启动→写入文件→修改注册表→发起外联”这一完整链路。实验报告里贴出这段时间轴再配合分析结论，说服力远大于单张截图。

有了时间轴，还需要做一件事：验证查杀结论的“可复现性”。恢复快照到干净状态，至少再跑一次样本，对比两次时间轴是否一致。如果两次启动的时间轴差异很大，说明样本存在反分析的时间延迟或随机化行为，这种情况要在实验报告中明确标注“样本行为存在不稳定性”，而不是强行下结论。

时间轴重建也是后续做防御方案的基础。当你清楚了样本的行为顺序，你就能针对第一个触发点做针对性拦截——不需要等样本完成全部行为链，在第一步写入文件或修改注册表时就阻断，这也是EDR这类产品“终端检测响应”的核心思路：不依赖特征识别，而是依赖行为链命中。

最后说一个我自己的教训：早年做实验中招过“样本确实被查杀了，但分析结论全部跑偏”的情况。原因是没有把杀软的查杀记录纳入同一时间轴——杀软可能在样本运行后第10秒才检测并阻断，而我的procmon记录的只是样本前10秒的行为，后面的行为全部没有发生。后来我习惯在启动样本的同时记录杀软的日志，两边的时标对齐，分析结论才真正站得住。做实验做到这份上，答辩时被问到“你的结论凭什么成立”，心里才有底。希望你能在实验清单之外，也把这份严谨的验证习惯一起带走，做技术的路才能越走越扎实。

本文还有配套的精品资源，点击获取