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

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

1. 基础知识

1.1 可执行文件与逆向分析

知识点	关键内容	用在哪里
PE 文件格式	Windows EXE 通常采用 PE 格式，文件头能反映机器类型、入口点及节表信息。	我用 PEiD、IDA 检查 RaDa.exe，还从 PE 头读取了 COFF 时间戳。
UPX 加壳	UPX 对程序进行压缩和封装，程序的入口和可读内容会发生变化；遇到改动过的包头时，标准工具可能无法解包。	原始 RaDa 在 PEiD 中呈现 UPX 特征，但 UPX 5.2.1 报错；我改用实验提供的脱壳器。
脱壳结果核对	脱壳后需要观察程序结构是否更容易分析，并核对入口、导入表及字符串。	我比较了文件大小、PEiD 检测结果、字符串数量，并用 IDA 查看 ThunRTMain。
IDA 交叉引用	从字符串位置沿着引用关系找到代码，能够进一步弄清数据用在什么地方。	我追踪 RaDa 的 URL、Run 注册表路径和 C:\RaDa 目录，找到了相应的汇编指令。
VB6 运行时	Visual Basic 程序会借助 MSVBVM60 等运行时例程执行初始化、字符串处理和对象操作。	我在导入表看到 ThunRTMain、__vbaStrCopy 等名称，结合代码理解字符串如何被加载。
Crackme 常用判断	参数比较、条件跳转、文件名检查和简单编码都可能影响程序的成功分支。	Crackme1 通过 strcmp 判断口令；Crackme2 还检查程序名，并用 XOR 0x42 还原提示文本。

1.2 恶意代码与网络取证

知识点	关键内容	用在哪里
后门与远程访问木马	这类程序通常具有远程指令处理、文件操作或维持访问能力。分析时要把潜在功能与已发生的行为区分开。	RaDa 的 CGI 路径、命令解释器及自启动字符串帮助我判断它可能具有的功能。
病毒、蠕虫	病毒往往依靠感染文件复制；蠕虫可以利用网络弱点传播。	我把 RaDa 的程序功能与 PCAP 中的 SQL Slammer 传播流量分别分析，没有混成同一种行为。
PCAP 文件	PCAP 记录已捕获的数据包，时间、协议、源目的地址和负载可以用于还原通信经过。	我用 capinfos 看总体情况，再用 TShark/Wireshark 筛选 IRC、HTTP、UDP 1434 和 SMB。
IRC 通信	IRC 客户端可用 NICK、USER 注册，用 JOIN 加入频道，PRIVMSG 发送消息；常见端口是 TCP 6667。	我追踪到 209.196.44.172:6667 的 IRC 会话，查看了欢迎信息、频道名单与消息正文。
NBNS 与 SMB	NBNS 可查询 NetBIOS 名称；SMB 通过会话请求和共享连接请求访问网络共享。	我把 NBSTAT 查询、响应与 TCP 139 上的 SMB Tree Connect 请求联系起来分析。
证据判断	报文里出现目标路径、命令或错误码，只能先说明对应字段出现过；还要查看双方是否有后续交互。	在 HTTP 和 SMB 部分，我追踪了 TCP 流，再判断现有抓包能说明什么。

2. 实验内容

这次实验分为四个部分。我先识别并脱壳 RaDa，再完成两个 Crackme 的逆向验证；随后围绕 RaDa 回答八个分析问题，最后对给定的蜜罐 PCAP 回答七个取证问题。

部分	已完成内容	主要工具
任务一	识别 RaDa 的文件类型、运行平台和壳，完成脱壳与字符串提取，并找出样本中声明的作者。	PowerShell、PEiD、VMUnpacker、IDA
任务二	找出 Crackme1、Crackme2 输出成功信息所需的条件，说明判断过程并实际运行验证。	IDA、Windows 命令行
任务三	围绕 RaDa 依次分析文件摘要、用途、特性、反分析手段、类别、相似工具、作者和至少五种检测方法。	IDA、文件哈希及公开资料
任务四	分析 Windows 2000 蜜罐的 PCAP，重点回答 IRC、僵尸网络规模、攻击来源、漏洞类型和攻击结果。	Kali、Wireshark、TShark、Python

3. 实验过程

3.1 任务一：RaDa 文件识别、脱壳与字符串提取

（1）先确认样本和文件信息

我先把 RaDa 文件解压到 Windows 10 虚拟机中，之后将这一部分的工作目录统一放在 C:\lab4\samples\rada。最开始做 Crackme 时用过 C:\lab3，所以前几张界面的目录与后面的不同；后续分析都围绕同一组实验样本进行。

我在 PowerShell 中查看 RaDa.exe 的文件大小、MD5 和 SHA256，并保存输出。原文件为 20,992 字节，MD5 是 CAAA6985A43225A0B3ADD54F44A0D4C7。再用 PEiD 打开它，工具检测到 UPX 壳特征，入口点落在 JDR1 段。结合 Windows PE 文件结构，可以得出它是一个面向 Windows 的 32 位可执行程序。

cd C:\lab4\samples\rada

Get-Item .\RaDa.exe | Select-Object Name,Length,LastWriteTime

Get-FileHash .\RaDa.exe -Algorithm MD5 | Format-List

Get-FileHash .\RaDa.exe -Algorithm SHA256 | Format-List

图1 RaDa 样本大小与哈希校验

图2 PEiD 检测原始 RaDa 的 UPX 特征

（2）尝试解包，改用 VMUnpacker

看到 UPX 标识后，我先尝试直接用 UPX 5.2.1 解包。程序却返回 CantUnpackException，还提示文件可能被修改或保护。我又核对了输入路径，错误仍然出现。考虑到样本可能经过了额外处理，我改用实验提供的“超级巡警之虚拟机自动脱壳器 V1.3”。

VMUnpacker 识别出了壳类型，并提示“脱壳成功”，最后生成 RaDa_unpacked.exe。新文件大小为 71,680 字节，MD5 为 847C2A1DCFE8347AFD8CF76D99217C5B。我再次检查发现：UPX 已无法将新文件识别为 UPX 压缩文件；PEiD 则显示 Microsoft Visual Basic 5.0 / 6.0，入口点 000018A4、EP 段 JDR0。这些变化让我能够继续做静态分析。

图3 使用 Test-Path 核对 UPX 程序和 RaDa 文件路径

图4 VMUnpacker 提示脱壳成功及输出路径

图5 脱壳后 PEiD 识别到 Visual Basic 特征

（3）提取字符串，确认样本中的作者署名

我先用 PowerShell 提取连续至少五个可打印 ASCII 字符。原始文件得到 1,071 行，脱壳后得到 2,507 行。这两个数字是同一提取方法下的统计结果，能够直观看到脱壳后可读内容增加了许多。

图6 原文件与脱壳后 ASCII 字符串行数对比

随后我在 IDA 的 Strings 设置中勾选 Unicode，找到了 RaDa、v0.22、RaDa Usage 等内容，其中最重要的是 Copyright (C) 2004 Raul Siles & David Perez。根据样本内部的版权声明，我记录的作者为 Raul Siles 和 David Perez。

图7 IDA 中提取到 RaDa 的版权声明

3.2 任务二：Crackme1、Crackme2 逆向分析

（1）Crackme1：从错误提示找到正确输入

我先直接运行 Crackme1，看到 I think you are missing something.；给出错误参数时，提示变为 Pardon? What did you say?。因此我重点查看了程序接收参数之后的判断逻辑。在 IDA 中找到 strcmp，沿着比较结果查看 test eax,eax 和后面的 jz 条件跳转，再回头核对字符串 I know the secret。

图8 Crackme1 参数数量检查与 strcmp 比较

图9 Crackme1 中成功与失败分支的控制流

最后我在命令行执行 crackme1.exe "I know the secret"，程序输出 You know how to speak to programs, Mr. Reverse-Engineer，与我在汇编中找到的成功分支一致。这一步让我第一次把参数比较、跳转条件和真正的运行输出连了起来。

图10 Crackme1 正确输入后的成功信息

（2）Crackme2：为什么口令正确仍然失败

Crackme2 更容易让人误判。我照着第一题输入正确口令，程序却显示 I have an identity problem.。我回到 IDA 查看，发现它在检查输入之前还比较了自身文件名，期望名称为 crackmeplease.exe。于是我复制并改名后再次运行，使用相同口令，最终看到 We have a little secret: Chocolate。

图11 Crackme2 在代码中进行文件名检查

图12 Crackme2 改名并输入正确口令后的输出

我又继续查看成功字符串的生成方式，找到循环中对编码字节执行 XOR 0x42、再通过 putchar 输出字符的过程。这题让我意识到，遇到提示与输入看起来不匹配时，还要考虑程序有没有检查运行环境或自身属性。

图13 Crackme2 的 XOR 0x42 解码循环

3.3 任务三：RaDa 深度分析（Q1—Q8）

Q1：二进制文件摘要

我用同一套工具记录了 RaDa 的文件信息，便于之后核对样本有没有发生变化。RaDa.exe 大小 20,992 字节，MD5 为 CAAA6985A43225A0B3ADD54F44A0D4C7；脱壳文件大小 71,680 字节，MD5 为 847C2A1DCFE8347AFD8CF76D99217C5B。原文件有 UPX 特征，处理后的文件呈现 VB5/6 特征。

用 PowerShell 按 PE 文件头结构读取了 COFF TimeDateStamp，转换得到 UTC 2004-10-29 23:59:58。它与文件系统显示的修改时间并不相同，所以我在摘要中分别记录，未把这个时间直接当作已经查实的真实编译时间。

图14 通过 PowerShell 读取 PE 头中的时间戳

Q2：这个程序想完成什么功能

在 IDA 的 Unicode 字符串里，我发现了 http://10.10.10.10/RaDa、RaDa_commands.html、cgi-bin、download.cgi、upload.cgi。一开始我只是把它们看作网络地址和路径；后来进一步沿着交叉引用找到了代码。地址 0040538D 附近先把 URL 的地址载入寄存器，再调用 __vbaStrCopy 进行字符串复制，说明这个 URL 确实进入了程序的处理逻辑。

图15 RaDa 中的 URL 与 CGI 接口字符串

图16 IDA 中引用 RaDa URL 并调用字符串复制例程

结合这些地址和命令页面的名称，我认为程序可能设计了远程命令收发、文件上传下载等功能。

Q3：程序有哪些值得关注的特性

我继续向下查找，发现 C:\RaDa\tmp、C:\RaDa\bin、RaDa.exe 这些路径，以及 HKLM\Software\Microsoft\Windows\CurrentVersion\Run 和 REG_SZ。Windows 的 Run 项经常用于登录后启动程序，我因此重点检查这一处引用。在 0040504F 一带可以看到程序加载注册表路径，在 00405083 和 00405043 附近又分别处理 bin、tmp 路径。

图17 安装目录、临时目录及注册表路径字符串

图18 Run 注册表路径对应的汇编引用

图19 bin 目录与 RaDa.exe 文件名拼接相关代码

我另外找到了 COMSPEC、/C、multipart/form-data、Content-Disposition、AppendChunk 和 GetChunk。这些内容把命令解释器、文件处理、HTTP 表单传输几条线索连到了一起。到目前为止，我确认的是代码中存在并引用这些路径和字符串；目录创建、注册表修改或上传行为是否发生，还需要动态行为记录才能回答。

Q4：有哪些影响分析或逆向的做法

我真正遇到的困难首先来自加壳：PEiD 能看到 UPX 特征，标准 UPX 却报 CantUnpackException。换用 VMUnpacker 后，IDA 可以继续识别 VB6 运行时，但初次加载还出现了虚拟地址映射警告。程序使用较多 VB6 运行库调用，单看反汇编入口时很难直接读出业务功能，我只好转而结合 Unicode 字符串与交叉引用查找。加壳、运行库间接调用和字符串的存储方式确实提高了分析难度。

Q5：我如何判断恶意软件类别

我倾向于把 RaDa 归入后门/远程访问木马（Backdoor/RAT）。主要理由来自两组线索：一组是远程 URL、命令页面和文件收发接口；另一组是 Run 自启动项、安装目录及命令解释器相关字符串。它们共同指向远程访问、维持运行和文件操作等功能。

在查找过程中，我没有取得 RaDa 主动感染其他可执行文件或通过漏洞复制传播的证据，so没有把它归为文件感染型病毒或网络蠕虫。

Q6：有哪些功能相近的程序

我查阅了公开的 RAT/后门软件资料，主要比较远程控制、文件操作和持久化三个方面。以下是我整理的对照，目的是说明相似功能，不代表这些程序出自同一个家族。

程序	可以比较的功能	我关注的区别
Poison Ivy	远程控制、主机操作、持久化手段	MITRE 有其行为资料；与 RaDa 的实现方式仍需分别分析。
njRAT	远程指令、主机信息获取、网络通信	共同点在远程访问能力，具体协议与指令格式不能直接类推。
DarkComet	远程管理与文件操作	公开资料将其列为 RAT；RaDa 这里依据的是本次静态分析。
Sub7、Gh0st RAT、灰鸽子	均可作为远程控制类工具的对照实例	我没有实际获取这些程序的样本做二进制逐项对照，故只作类别举例。

Q7：能否调查到开发作者

我在脱壳文件的 Unicode Strings 中找到了 Copyright (C) 2004 Raul Siles & David Perez。这条版权信息的地址与内容已有截图，可以回答样本自带声明的作者为 Raul Siles、David Perez。我的调查条件限于当前样本及公开资料；文件内部文字可以改写，要进一步核对开发者身份，还得结合可信发布来源和样本哈希。

Q8：至少五种恶意软件检测方法

我按“原理、在本样本上能查什么、适用与局限”整理了五种方法。其中哈希和静态检查是我实际做过的；沙箱、网络监控和 EDR 部分属于根据 RaDa 线索设计的验证方案。

方法	工作原理与操作思路	结合 RaDa 的分析及局限
1. 哈希、特征码与 YARA	对文件计算 SHA256/MD5；对已知样本进行精确匹配，也可以把多个具有辨识度的字符串写成 YARA 组合规则。	我已计算原始文件和脱壳文件哈希。以后制作规则可考虑 RaDa_commands.html、特定 URL 和目录组合；单一哈希容易因文件改动失效，宽泛字符串容易误报。
2. PE 静态启发式分析	检查入口、节表、导入表、加壳特征、字符串及潜在敏感 API，结合多个异常点判断风险。	PEiD 与 IDA 是我本次真正使用的方法。UPX 标签本身不说明文件一定恶意，VB6 运行时也有大量正常用途。
3. 隔离沙箱动态行为	在断开外网且保留快照的虚拟机内监控进程、文件、注册表与网络活动，前后对比变化。	如果进一步验证 RaDa，我会看 C:\RaDa 目录、Run 项和网络地址。考虑到样本风险，本轮没有执行这一步，所以没有动态日志。
4. 网络流量与 IDS 检测	用 Wireshark/TShark 或 Snort/Suricata 观察异常会话、协议字段和通信频率，结合规则识别可疑行为。	PCAP 取证证明我使用过网络侧分析方法，但那份抓包来自另一台蜜罐，并非 RaDa 运行时采集的流量。加密和数据采集位置都会影响检测效果。
5. 主机日志与 EDR 检测	结合进程创建、网络连接、文件写入、注册表修改等事件，按时间线还原可疑活动。	RaDa 的 Run 路径和目录字符串提示了监测重点。要真正实施还需提前开启 Sysmon 或其他日志采集，本实验没有相应的运行记录。

对我来说，这五种方法可以互相补充：静态分析先找出要观察的线索，动态日志与网络抓包再验证运行过程中发生了哪些操作。

3.4 任务四：蜜罐 PCAP 取证分析（Q1—Q7）

（1）获取文件并确认抓包内容

我先在 Windows 宿主机下载 botnet_pcap_file.dat，通过 VMware 共享目录传到 Kali。Kali 最初能识别共享名称，却在 /mnt/hgfs 下看不到文件；重新挂载后，把证据复制到 /home/kali/lab4_forensics/evidence/，后面一直读取这份本地副本。

sudo vmhgfs-fuse .host:/ /mnt/hgfs -o allow_other

cp /mnt/hgfs/shared_folder/botnet_pcap_file.dat ~/lab4_forensics/evidence/

cd ~/lab4_forensics/evidence

file botnet_pcap_file.dat

sha256sum botnet_pcap_file.dat

capinfos botnet_pcap_file.dat

文件名虽以 .dat 结尾，file 和 capinfos 都能识别出其实际为 PCAP，链路层为 Ethernet、时间戳精度为微秒。文件的 SHA256 为 d8a282fbedb5ac64ed52e1eec54ff7703f13555d508b853e21e0344918314a73。

图20 Kali 本地 PCAP 类型与 SHA256 校验

图21 capinfos 的数据包数和抓包时间统计

capinfos 显示共有 54,536 个数据包，时间范围为 2003-03-01 04:08:09.525204 至 2003-03-06 03:27:57.867166，跨度约 4.97 天。TShark 统计 TCP 54,350 包、UDP 186 包；应用层还能看到 IRC 9,594、HTTP 1,443 等协议分支。蜜罐 IP 为 172.16.134.191，后续筛选都以它为中心。

Q1：IRC 是什么？加入网络需要发送什么？常见端口是什么？

我先在 Wireshark 中筛选 IRC，并找到一条有完整注册过程的会话。IRC 是 Internet Relay Chat，客户端与服务器通过 TCP 交换文本命令。我在该流中看到客户端发出 NICK、USER 进行注册，加入频道时发出 JOIN，还出现 MODE、WHO；常见服务端口为 TCP 6667，这条会话也确实使用了 6667。

图22 IRC 会话1539中可见 NICK、USER、JOIN 等命令

Q2：僵尸网络是什么？一般用来做什么？

我理解的僵尸网络是被控制者集中操纵的一批计算机或设备。控制消息可以借助 IRC 频道、HTTP 等渠道传递，被控设备可能参与 DDoS、扫描、垃圾邮件和其他滥用活动。在分析这份 PCAP 时，我先把 IRC 看作通信协议，再依据消息正文与前后行为判断其中哪些内容值得怀疑。

Q3：蜜罐与哪些 IRC 服务器通信？

我在 Kali 中筛选蜜罐向 TCP 6667 发出的 SYN，去重得到 5 个目标 IP：209.126.161.29、209.196.44.172、217.199.175.10、63.241.174.144、66.33.65.58。

图23 蜜罐主动连接 TCP 6667 的五个目标 IP

为了避免把发起连接和实际交互混在一起，我又检查服务器返回的 SYN-ACK。能确认的有 3 个：209.196.44.172、217.199.175.10、63.241.174.144；此前用 TShark 检查 IRC 应用层时，也见到了它们发来的消息。对于其余两个目标，当前记录仅支持“蜜罐曾尝试连接”。

图24 对 SYN-ACK 服务器来源去重，得到三个 IP

Q4：观察期间有多少不同主机访问该 IRC 网络？

最开始追踪 209.196.44.172 所在的 IRC 会话时，服务器欢迎消息显示 Current global users: 4752，我以为可以直接用这个数。再仔细看才发现，它表示那一时刻服务器报告的全局在线用户数，题目问的是观察期间的不同主机，统计口径并不一样。

我用 Wireshark 的 Follow TCP Stream 把 tcp.stream == 1539 导出为 irc_1539.txt，共 15,995 行、约 1.1 MB。随后用 Python 从 353 用户列表以及 JOIN/QUIT/PART、WHO 信息中提取昵称和主机标识并去重，得到：

统计项目	本次计算结果
353 用户列表中的去重昵称	3,457
JOIN/QUIT/PART 中去重昵称	6,538
JOIN/QUIT/PART 中去重主机标识	5,573
WHO 中去重主机标识	1
合并后的去重主机标识	5,573
JOIN / QUIT 事件数	7,976 / 7,662

图25 IRC 会话文本提取后的去重统计结果

图26 保存的主机标识清单与部分实际名称

图27 IRC 服务器欢迎信息中的 4752 个全局在线用户

因此把 5,573 作为从这条 IRC 会话中观察到的不同主机标识数量写进结果，它来自单条会话文本，有些主机可能反复连接、使用多个名称或被代理隐藏。

Q5：哪些 IP 地址被用于攻击蜜罐？

我先提取所有发往 172.16.134.191 的 IPv4 数据包源地址，去掉端口后用 sort -u 得到 165 个不同来源 IP。接下来我结合具体报文筛出有明显攻击或探测特征的例子。

图28 tcpdump/awk/sort 统计出165个不同入站源 IP

源 IP 示例	观察到的行为	判断
68.37.54.69（另有多源）	向 UDP 1434 发送 376 字节有效载荷	高度疑似 SQL Slammer 传播/利用流量
210.22.204.101	多次 GET /NULL.IDA?CCCC...	疑似针对 IIS Indexing Service 的利用尝试
218.163.9.89	UDP 137 发送 NBSTAT 查询	主机名称和服务信息探测
219.118.31.42	TCP 139 上的 NBSS 与 SMB Tree Connect 请求	共享资源连接尝试

其他地址保存在 Kali 的 inbound_ips.txt 中。在这里列出有报文依据的代表性来源，避免单凭“向蜜罐发过包”就给所有来源贴上同一种标签。

Q6：攻击者尝试利用了哪些漏洞或服务弱点？

第一类：SQL Slammer / UDP 1434。 在第 33 帧看到源地址 68.37.54.69:1034 向蜜罐 UDP 1434 发包：以太网帧 418 B、IPv4 长 404 B、UDP 总长 384 B、有效载荷 376 B，负载开头为 04 01 01 01...。我发现这些特征与公开资料中 SQL Slammer/Sapphire 的传播报文高度一致，将其判为高度可疑的传播或利用尝试。

图29 第33帧 UDP1434 的长度与十六进制内容

第二类：IIS / HTTP 异常请求。 210.22.204.101 向蜜罐重复发送 GET /NULL.IDA?CCCC...，请求中的长串字符十分醒目。我查阅微软 MS01-033 后发现，这与 IIS Indexing Service 的 .ida/.idq 处理弱点及相关历史攻击流量相符。

图30 多次出现的 HTTP /NULL.IDA 异常请求

第三类：NetBIOS 信息探测。 第 11 帧向蜜罐发出 UDP137 节点状态查询，第 12 帧收到相同事务 ID 0x0100 的响应，里面共有 10 个 NetBIOS 名称，包括 PC0191<00>、PC0191<20>、SBM<1e>。至少从这组报文看，请求方收到了蜜罐提供的名称和服务信息。

图31 NBSTAT 响应包含 PC0191 等十个名称

第四类：SMB 共享探测。 对 219.118.31.42 的报文，依次找到 NBNS 查询、TCP 139 连接、NBSS Session Request 和 SMB Tree Connect AndX Request。第 8 帧里请求的共享路径为 \\PC0191\C，服务类型是 A:（磁盘共享），表明客户端已经尝试连接具体共享。

图32 第8帧 SMB Tree Connect 指向 PC0191 上的 C 共享

Q7：哪些攻击成功？如何成功？

在本次抓包中，我确认 NetBIOS 节点状态信息探测取得了响应。为了判断探测过程是否完成，我把外部主机发送的查询请求和蜜罐返回的应答放在一起核对。首先，我在 UDP 137 流量中找到第 11 帧：外部主机 218.163.9.89 从 UDP 1025 端口向蜜罐 172.16.134.191 的 UDP 137 端口发送 NetBIOS 查询请求。报文事务 ID 为 0x0100，问题数为 1；结合查询字段，可以确认其意图是获取目标的节点状态信息。

接着，我查看紧随其后的第 12 帧。该报文由蜜罐返回给 218.163.9.89，事务 ID 同样为 0x0100。Wireshark 显示响应标志 0x8400、回复码 No error，Answers 中包含 1 条 NBSTAT 应答记录，其内部列出了 10 个 NetBIOS 名称及相关服务标识。

我对照两帧的事务 ID、通信方向和应答内容，确认这次查询得到了有效返回。名称表中能够看到 PC0191<00>（工作站服务）、PC0191<20>（服务器服务）、SBM<00> 和 SBM<1E> 等字段。攻击者采用节点状态查询的方式获取目标名称和服务线索，信息探测这一环节取得了效果。

4. 问题及解决方案

这一部分写的是我实际遇到、并留有错误界面的情况。我把最能说明故障的图片放在问题后面，再写解决过程，方便复查。

4.1 原始 RaDa 无法用 UPX 直接解包

问题一： PEiD 明明检出了 UPX 特征，我在 PowerShell 中调用 UPX 5.2.1 却得到 CantUnpackException: file is modified/hacked/protected。我最初以为是工具路径写错了，核对文件存在后重新执行，还是相同的错误。

图37 UPX 对 RaDa.exe 返回 CantUnpackException 的原始报错

解决一：我改用 VMUnpacker V1.3。新文件生成后，再通过文件大小、PEiD、导入项和字符串数量做交叉检查。这样我才有足够依据继续分析脱壳文件。

4.2 IDA 加载脱壳文件时出现地址映射警告

问题二：IDA 弹出 Can't find translation for virtual address 00011028, continue?。当时我担心脱壳文件损坏，无法继续反汇编。

图38 IDA 加载 RaDa_unpacked.exe 时的虚拟地址映射提示

解决二： 我选择继续加载，观察到入口 004018A4、ThunRTMain、导入函数以及 Unicode 字符串都能够解析。后面分析 URL 和目录引用也有实际结果。因此我继续完成能够核验的静态部分，对 PE 结构未完全修复的可能性作了备注。

4.3 Kali 重启后找不到 VMware 共享文件夹

问题三： vmware-hgfsclient 能显示 shared_folder，但我执行 ls /mnt/hgfs 只看到空目录，复制 PCAP 时还报 No such file or directory。

图39 共享名称能识别但尚未挂载，cp 提示文件不存在

解决三：我重新运行 sudo vmhgfs-fuse .host:/ /mnt/hgfs -o allow_other，共享目录随即正常出现。接着将 PCAP 复制到本地 ~/lab4_forensics/evidence，用 file 和 sha256sum 校验，后续只分析本地副本。这次也提醒我，重启虚拟机后应先检查挂载状态。

4.4 TShark 解析时卡在第 44144 帧附近

问题四： 我提取 IRC 信息时，终端提示 TCP dissector 的内部状态超出限制，告警指向第 44144 帧。命令运行变得很慢，我当时不知道是数据文件出了问题，还是软件本身的问题。

图40 TShark 在第 44144 帧附近出现 TCP dissector 警告

解决四： 我停止该次解析，先把读取范围限制在前 40000 帧，完成 IRC 会话的初步定位。之后改用 Wireshark 图形界面查看后面的报文，包括 45696 等含 PRIVMSG 的帧。这个调整让我能够继续分析，同时注意在统计时标清数据范围。

4.5 tcpflow 下载失败，改用 Wireshark 导出会话

问题五： 做 Q4 时我想安装 tcpflow 来重组 IRC 文本，apt 却反复提示无法连接 192.168.153.1:7897，软件包下载中断。

图41 Kali 安装 tcpflow 时出现代理连接超时

解决五： 我发现 Wireshark 已经能够打开所需会话，于是没有继续折腾软件源，而是用 Follow TCP Stream → Save As 导出 irc_1539.txt，再通过 Python 统计不同昵称和主机标识。最终拿到了 Q4 的具体数量，并生成了可复查的 q4_hosts.txt 和 q4_statistics.txt。

5. 学习感悟、思考等

做完实验四，我印象最深的不是某一条命令，而是自己几次改变判断的过程。

最开始我以为 RaDa 被 PEiD 识别为 UPX，就能直接运行 UPX 解包。真正动手后，工具先报错，换用 VMUnpacker 又遇到 IDA 地址映射警告。我没有把“脱壳成功”四个字当作终点，而是继续核对文件大小、入口和字符串，并从 URL、注册表路径一步步跟到代码。以前看 IDA 中一大页汇编，我很容易迷失；现在至少知道可以先抓住有意义的字符串，再通过引用关系进入对应的处理位置。

Crackme2 也让我记得很清楚。口令已经对了，程序还是报身份错误，我起初只盯着输入内容，后来看出它还检查程序名。找到 crackmeplease.exe 这个条件并完成验证后，我才真正理解：一道逆向题的关键条件可能分散在不同位置，不能凭一条提示就急着下结论。

PCAP 取证的工作量更大。面对五万多个数据包，我一开始只是试着切换过滤器，结果越看越乱。后来先统计总体信息，再按 IRC、UDP1434、NBNS、HTTP、SMB 分开检查，思路才清晰起来。第 33 帧的 376 字节载荷、第 12 帧的 NBSTAT 响应、第 8 帧的 SMB 共享路径，都是我一步步展开协议字段才找到的。尤其是 Q4 的 4752 和 5573，我曾经以为选一个数字就能回答题目，真正做去重后才意识到，统计方法本身就决定了这个数字能说明什么。

我还学会了处理工具故障：挂载失效要检查共享目录，TShark 告警要先缩小范围，安装工具失败时也能考虑现成工具的其他功能。这些排障过程花费了不少时间，但正因为留下了错误界面和修复后的结果，后来整理报告时才有完整的操作经过。

参考资料

[1] Oikarinen J., Reed D. Internet Relay Chat Protocol. RFC 1459, 1993. https://www.rfc-editor.org/rfc/rfc1459.html

[2] CAIDA. Analysis of the Sapphire Worm. https://www.caida.org/archive/sapphire/

[3] Moore D., Paxson V., Savage S., et al. The Spread of the Sapphire/Slammer Worm. CAIDA, 2003. https://www.caida.org/catalog/papers/2003_sapphire/

[4] Microsoft. MS01-033: Unchecked Buffer in Index Server ISAPI Extension. https://learn.microsoft.com/en-us/security-updates/securitybulletins/2001/ms01-033

[5] MITRE ATT&CK. PoisonIvy (S0012). https://attack.mitre.org/software/S0012/

[6] MITRE ATT&CK. njRAT (S0385). https://attack.mitre.org/software/S0385/

[7] MITRE ATT&CK. DarkComet (S0334). https://attack.mitre.org/software/S0334/

[8] Wireshark. User's Guide: Following Protocol Streams. https://www.wireshark.org/docs/wsug_html_chunked/ChAdvFollowStreamSection.html