题目：https://ks.wjx.top/vj/rX5h1WB.aspx

难难难，不多说了，直接开始

火眼仿真创建虚拟机

要创建虚拟机，必须要有VMware环境

创建虚拟机 -> 添加镜像 -> 选择镜像文件之后在上面勾选对应镜像 -> 点击确定

选择生成位置（虚拟机位置） -> 开始创建

创建完成之后会给出账号密码，可以记忆一下，或者重置为空（推荐）

part1

1.检材1的操作系统版本是

创建完虚拟机后，就会自动识别出系统版本：

CentOS Linux release 7.6.1810(Core)

2.检材1中，操作系统的内核版本是

找半天不知道检材1怎么登录的root账号，结果最后试出来了密码……：

root/123456

后面才知道这是火眼帮我改的，我们也可以手动设置

创建虚拟机 -> 高级设置：

这里就可以设置各种内容

纯命令行界面还是太难操作了，使用Xterminal连接一下

systemctl start sshd打开服务，看一下监听端口，是7001：

在Xterminal连接后，查看内核版本：

uname -r

3.10.0-957.el7.x86_64

3.检材1磁盘包含一个LVM逻辑卷，该LVM开始的逻辑区块地址（LBA）是

查看磁盘分区：

fdisk -l

根据System字段类型里的LVM判断/dev/sda2是我们要找的分区

2099200

4.检材1中网站"www.kkzjc.com"对应的Web服务对外开放的端口是

尝试使用nmap扫描服务器端口，但没有给出什么有用的信息

使用grep命令直接在服务器上搜索"www.kkzjc.com"

因为是网站的配置文件通常在 /etc目录下，现在/etc下搜索更快一点：

32000

5.检材1所在的服务器共绑定了几个对外开放的域名

既然/etc下有配置文件，就把nginx和apache的都搜一遍：

看来只有nginx，一共开放了三个域名

3

6.检材1所在的服务器的原始IP地址是

看不明白这一题问的是什么，跟着wp做一遍

见第九题

7.嫌疑人曾经远程登录过检材1所在的服务器，分析并找出其登录使用的IP地址是 (并使用该地址解压检材2)

使用last命令查看，发现有两个ip登陆过该服务器（192.168.204.1是我使用Xterminal连接的）：

正确的ip可以解压检材2，检材2是分卷压缩，使用winrar解压缩

192.168.99.222

8.检材1所在的服务器，其主要功能之一为反向代理。找出"www.kkzjc.com"转发的后台网站所使用的IP地址是

首先查看命令行history，发现该服务器有docker镜像：

开启docker服务，看一眼镜像和容器都有哪些

systemctl start docker
systemctl status docker
docker images
docker ps

这里发现一个正在运行的nginx服务器，而且他的映射到本机的端口号是8091，和第四题配置文件中的一样：

进入docker的交互式终端，查看该终端里运行过的命令：

docker exec -it 08f64376a2e3 /bin/bash
history

可以看到曾经多次查看过配置文件/etc/nginx/conf.d/hl.conf：

我们也打开这个配置文件看看，发现了反向代理的ip：

192.168.1.176

9.嫌疑人曾经从题7的IP地址，通过WEB方式远程访问过网站，统计出检材1中该IP出现的次数为

查看docker容器日志，统计其中的ip出现次数，-c参数可输出统计总数：

docker logs 08f6437 | grep -c "192.168.99.222"

18

同时在日志还能发现这个ip在访问服务器的时候是由ip192.168.99.3接受的，且端口号就是之前的8091：

这样就发现了题6的答案：

192.168.99.3

part2

10.检材 2 的原始磁盘 SHA256 值为

2D926D5E1CFE27553AE59B6152E038560D64E7837ECCAD30F2FBAD5052FABF37

11.检材2 所在计算机的OS内部版本号是

18363.1082

12.检材2所在计算机最后一次正常关机的时间为（精确到秒）

2020-09-22 13:15:34

13. 检材2中，VMware 程序的安装时间为（精确到分钟）

2020-09-18 17:57

14.检材2中，Vmware.exe程序总计启动过几次

8

15.嫌疑人通过 Web 方式，从检材2访问检材1所在的服务器上的网站时，连接的目标端口是

在chrome浏览器中发现代理登录的记录：

登录的端口和之前看到的代理端口一致

8091

16.接15题，该端口上运行的进程的程序名称（Program name）为

docker-proxy

17.嫌疑人从检材2上访问该网站时，所使用的域名为

下面就是对应域名（同样是代理登录8091端口）：

 www.sdhj.com

18.检材2 中，嫌疑人所使用的微信ID是

检材二的电脑里面并没有安装微信

但在检材二嵌套证据识别部分能看见一个ios手机备份，查看路径能发现是在分区三下

把当前文件夹下的所有文件导出作为文件集合作为新检材分析，发现里面有微信号：

sstt119999

19.分析检材2，嫌疑人为推广其网站，与广告位供应商沟通时使用的通联工具的名称为

接上一步，创建出来的ios镜像不完整，找不到题目要求的信息

真正的做法是使用同样位于分区三下的另一个镜像：

这样就能发现沟通工具：

telegram

20.分析检材2，嫌疑人使用虚拟货币与供应商进行交易，该虚拟货币的名称是

在上题聊天记录中找到一张收款码图片，用的是狗狗币DOGE

DOGE

21.上述交易中，对方的收款地址是

见上图

DPBEgbwap7VW5HbNdGi9TyKJbqTLWYYkvf

22.上述交易中，嫌疑人和供应商的交易时间是

这里不知道怎么写，wp说可以通过Dogecoin浏览器使用交易地址搜索到交易： https://explorer.coinex.com/doge

2020-09-20 12:19:46

23.上述交易中，嫌疑人支付货币的数量为

见上题图

4000

24.检材2中，嫌疑人使用的虚拟机的虚拟磁盘被加密，其密码为

虚拟机在嵌套证据识别中就已经见过，导出备用，这里以防万一我导出了整个存放虚拟机的文件夹：

微信聊天记录里说他忘记了密码，要去github上找办法：

之前翻看浏览器的时候就看见了github网页，我们也看看那个破解工具网站：

-v指定虚拟机，-d指定字典，就使用它演示使用的这条命令：

python3 pyvmx-cracker.py -v Windows10x64.vmx -d wordlist.txt

得到密码：

zzzxxx

25.检材2中，嫌疑人发送给广告商的邮件中的图片附件的 SHA256值为(忽略邮件状态)

下面的步骤建议直接导入火眼证据分析，使用虚拟机反而徒增麻烦

打开虚拟机，发现有密码：

办法是使用火眼仿真，仿真完毕就会给出密码

不过在此之前，我们要先给虚拟机的加密给取消：

再次使用火眼仿真就能得到密码：

之前聊天记录提到广告使用邮件发送，在桌面的邮箱软件的草稿箱找到广告图片：

保存到桌面，使用certutil计算sha256（这个版本的powershell没有getfilehash）：

cc7ea3ab90ab6b28417e08c715c243ce58ea76d71fd141b93f055a58e9ba561a

26.检材2中，嫌疑人给广告商发送广告图片邮件的发送时间是(忽略邮件状态)

2020-09-20 12:53

27.检材2中，嫌疑人的邮箱密码是

把.vmdk文件作为镜像文件导入成新检材（早知道能导入我就不那么别扭使用虚拟机了气死我了）：

honglian7001

28.检材2中，嫌疑人使用了什么远程管理工具，登录了检材1所在的服务器？

Xshell不是全称，具体名称在安装软件中看，或者虚拟机里面也能看见：

Xshell6

29.检材2中，嫌疑人使用上述工具连接服务器时，使用的登录密码为

qwer1234!@#$

part3

30.检材3 的原始磁盘 SHA256 值为

FF593FCCB3770B8845A3334631F8E80807638EE722C5AA7B34E877589857C3BA

31.检材3 所在的计算机的操作系统版本是

Windows Server 2008 HPC Edition x64

32.检材3中，部署的网站名称是

火眼仿真检材三（一定记得把密码重置成空！！！）

登录server账号，打开服务器管理器：角色 -> web服务器 -> internet信息服务 -> win -> 网站

可以看到有一个托管的网站：

card

33.检材3中，部署的网站对应的网站根目录是

高级设置：

C:\inetpub\wwwroot\v7w

34.检材3中，部署的网站绑定的端口是

同上图：

80

35.检材3中，具备登陆功能的代码页，对应的文件名为

右侧导航栏浏览，发现一个名为web的配置文件：

使用记事本打开，可以看见里面有两条疑似与login相关的配置：

分别查看两个文件，发现都跟登录有关：

本地访问一下，发现竟然都是登录界面：

分不清，真的分不清啊，都写上去吧：

glogin.aspx
dllogin.aspx

不过其实是有办法分开的，具体看下面一题

36.检材3中，请对网站代码进行分析，网站登录过程中，代码中对输入的明文密码作了追加什么字符串处理

再次检索前面两个文件，发现只有dllogin.aspx涉及到了对密码字符串的处理：

OvO

同时也知道了35题的正确答案：

dllogin.aspx

37.检材3中，请对网站代码进行分析，

既然是找动态链接库，那么在dllogin.aspx里面搜索一下dll：

虽然没有找到，不过也给了点启发，问问ai：

为了保险起见，我们直接去检材三里面搜索一下是否有这个文件：

 App_Web_dllogin.aspx.7d7c2f33.dll

38.检材3中，网站登录过程中，后台接收到明文密码后进行加密处理，首先使用的算法是 Encryption 中的什么函数

dll文件编译后无法查看，没有头绪，原来是需要逆向dll

下载net反编译工具dnspy：https://github.com/dnSpy/dnSpy/releases

导出上题找到的dll文件，拖入dnspy寻找：

AESEncrypt

39.检材3中，分析该网站连接的数据库地址为（并使用该地址解压检材4）

多少沾点玄学在这里了

在逆向出来的.net中发现引用了一个数据库有关的库DBManager：

搜索发现这个库也在检材三中：

导出分析，在最底部看见数据库地址：

192.168.1.174

40.检材3中，网站连接数据库使用的密码为

在DBManager里面找到下面这一段：

private void Open()
{
    if (this.Conn == null)
    {
        this.Conn = new SqlConnection(this.ConnStr);  
    }
}

只在this.Conn为null时使用ConnStr，也就是上一题得到的密码

如果不为空，那么优先使用的是AESDecrypt解密出来的连接串，所以我们要想法解密：

Mcyj19i/VubvqSM21YPjWnnGzk8G/GG6x9+qwdcOJd9bTEyprEOxs8TD9Ma1Lz1Ct72xlK/g8DDRAQ+X0GtJ8w==

因为这是Encryption类下面的方法，并且都是windows系统，我们也可以在本机调用解密：

Add-Type -Path <Path/to/DBManager.dll>
[DBManager.Encryption]::AESDecrypt( "Mcyj19i/VubvqSM21YPjWnnGzk8G/GG6x9+qwdcOJd9bTEyprEOxs8TD9Ma1Lz1Ct72xlK/g8DDRAQ+X0GtJ8w==",  "HL",  "forensix" )

再次印证了39题答案是正确的，并且给出了真正的密码：

c4f2737e88

41.检材3中，网站连接数据库服务器的端口是

见上题，ip后就是端口：

1433

part4

做好准备，接下来的路不是一般的难走

42.检材 4 的原始磁盘SHA256 值为

E5E548CCAECD02608A0E053A5C7DCDBFBDD4BE5B0E743EB9DC8E318C369BEBC8

43.重构该网站，分析嫌疑用户的推广链接中参数里包含的 ID 是

现在的目标是连接检材3（服务器）和检材4（数据库）

登录检材4，看一眼history：

看来是先尝试了在本机安装数据库，后面还是选择使用docker了

启动docker，查看现在的docker容器，启动sql1：

检材3能知道连接数据库的地址是192.168.1.174，所以要修改检材4的ip

先在编辑 -> 虚拟网络编辑器中关闭DHCP，防止使用DHCP分配的地址

应用并确定后，进入检材4，修改网卡配置文件：

vi /etc/sysconfig/network-scripts/ifcfg-ens33

改成下面这样：

重启网络，用ip a命令查看配置是否成功：

再次登录检材3，ping一下检材4，看看是否能通：

说明他们在同一个网段了，我们之前的配置是成功的

由于检材三没有数据库应用，接下来我们要在本机连接数据库，那就要让本机和他们也在同一网段

打开vmware -> 编辑 -> 虚拟网络编辑器，把使用的，然后更改子网IP和NAT网关为192.168.1.0/24网段：

点击应用和确定，在本机ipconfig一下

可以看见net8，也就是nat模式，ipv4地址是192.168.1.1，配置成功：

使用40题的解密结果测试连接，结果报错了：

需要下载SQL SERVER驱动程序：

https://learn.microsoft.com/zh-cn/sql/connect/odbc/download-odbc-driver-for-sql-server?view=sql-server-ver16

安装后再次测试连接，成功！

接下来回到App_Web_dllogin.aspx.7d7c2f33.dll中

在登录部分我们可以看到调用了DUserLogin函数，而这个函数又是来自WDUser类：

这个类来自哪里呢？看不出来，问一下ai吧

不嫌麻烦保险起见也可以全部导出using了的dll，这个操作其实是最正确的，后面也会用上

不过这里就取个巧先：

既然不是系统库，那么我们照样能在检材3里面找到这个dll，老样子导出用dnspy分析

dnspy很方便，如果有对应函数，点击即可跳转至对应位置，果然是在WBus里面：

在DUserLogin函数里使用了PD_UserLogin这个数据库函数，我们在数据库里面找到它：

函数说明登录方式分两种，由TD_Webs表的DW_Type决定：

• DW_Type = 0：只允许指定的DW_DU_Id用户登录
• DW_Type = 1：允许任意用户登录（只验证用户名和密码）

并且在之前反编译出来的dll登录逻辑中，我们知道了用户名密码是经过加密的，存放在表里的是加密过的值：

text2 = Encryption.AESEncrypt(text2, "forensix", "HL");
text2 = FormsAuthentication.HashPasswordForStoringInConfigFile(text2, "MD5");

二者结合，如果要让某个用户能登录，就要确保他的DU_Id =TD_Webs.DW_DU_Id，并且将他的密码改为指定值加密后的结果写入DU_Pwd

我们先找到用户表：

在检材二中的chrome浏览器的表单记录中，我们能找到liwente1314520的登录记录：

liwente1314520对应的DU_Id 是1001，也对应TD_Webs表里面的aaaa.bbbb，相应DW_Type是0

在检材3的登录页面逻辑中我们知道，登录方式是"密码"+“OvO”

我们用这种方式制作一个密码，先AESEncrypt加密，再MD5加密（这一步我做错了，先别急着复制，往下看）：

Add-Type -Path <Path/to/DBManager.dll>
[DBManager.Encryption]::AESEncrypt( "111OvO",  "HL",  "forensix")

把1001对应的TD_Webs.DW_DU_Id改成192.168.1.176，也就是检材3的ip，让我们能访问：

TD_User.DW_Pwd改成加密的密码：

保存之后，在检材4重启sql1容器，在检材3中开启ASP.NET State Service服务：

之后可以在本机访问http://192.168.1.176/dl进行登录操作：

可是到这一步，我登录竟然不成功！

我以为是之前的md5没有大写的原因，可是就算我改成了大写，仍旧是不成功

后面发现是我把加密函数参数位置写错了，正确应该是这样（太铸币了啊）：

Add-Type -Path <Path/to/DBManager.dll>
[DBManager.Encryption]::AESEncrypt( "111OvO",  "HL",  "forensix")

不过当时我认为走流程自己计算密码这一步显然是走不太通了，那我们就得换一个思路：直接让它为我们输出密码

进入控制登录的App_Web_dllogin.aspx.7d7c2f33.dll，在oCmd函数部分右键，编辑：

加入和修改这三处，目的是登录失败的时候弹窗弹出当前使用密码加密后的md5值：

点击编译，注意一定要把上面的非系统引用库也导出并拖进dnspy，否则编译会失败：

编译完成之后点击保存（名称不能变），复制并替换检材三C:\inetpub\wwwroot\v7w\bin下的同名dll：

之后重启网站：

再次访问http://192.168.1.176/dl，使用账号liwente1314520，密码随便（但是一定要记住）登录：

果然报错，不过也带出了加密后的密码！

复制这个md5值作为密码，再次更改数据库内容，保存，重启sql1服务

我们就能使用上一次登录的密码登录了：

总算是搭建并登录了，也不能忘了我们的目标：嫌疑用户的推广链接中参数里包含的ID

一同翻找，在代理信息栏里发现了推广链接：

abe6d2ee630379c3

44.重构该网站，该网站后台的代理用户数量为

用户列表里面数一下，一共三页：

26

45.重构该网站，该网站注册用户中共有过几个代理(包含删除的数据)

上一题是代理用户数量，这一题问的是包括删除的数据，我们就需要找到对应的表

鼠标移动到用户列表按钮，左下角会显示对应的aspx文件：

在检材3里面搜索该文件（火眼也行）：

在文件开头找到使用的库，其实也就是上图我们搜出来的第二个文件：

导入dnspy分析，同样找到和数据库交互的函数：

它同样是在WBus的WUUser里面，使用的表名是TU_User：

数据库里面找到该表，统计一下总数：

32

46.重构该网站，对补发记录进行统计，统计 2019 年10 月1日后补发成功的金额总值

分析方法和上一题一模一样，就是网站配置文件 -> dll -> 逆向找数据库表

同样的，我们找到补发测试的文件：

中间寻找的过程就跳过，直接上逆向结果：

这里找到的VY_TestLog不是表，是一个视图：

在dll里面我们还能知道补发成功的逻辑：

if (dataTable.Rows[i]["YY1T_Type"].ToString() == "3")

也就是说，如果YY1T_CState == "100"，则认为是成功的

我们只需要查询视图中YY1T_CState字段为100，且YY1T_CDate在2019.10.1后的补发金额（YY1T_Money）总值：

select sum(YY1T_Money)
from VY_TestLog
where YY1T_CState = 100 and YY1T_CDate > '2019-10-01 00:00:00'

138408.0000

47.检材 4 中，对"TX_IpLog"表进行分析，所有在"武汉市"登录的次数为

找到该表：

没什么弯绕，就是sql查询：

select count(*)
from TX_IpLog
where XIL_Info like ''%武汉%''

2829

48.重构该网站，该嫌疑人下属代理"liyun10"账户下的余额有多少元

点击结算管理，显示出了余额，说明我们页面没有找错：

找到对应aspx文件，找dll，逆向：

很奇怪，这里竟然什么逻辑也没有，猜测是继承的父类Page_zhye

这里唯一一个非系统库就是RootDPage，同样在检材3里面找到导出逆向

果然，里面写出了完整的余额查询逻辑，而所有数据来源都是MInfo：

这个函数也来自WBus，里面调用的是数据库中间处理函数PD_MInfo：

在数据库找到PD_MInfo这个函数：

这个查询里面涉及了很多张表，一一查看

最终，在TD_MJiFen里面能找到一条数据，id就是我们登录的账号liwente1314520的，余额也对应：

可是除此之外再也找不到其他的用户了，这是怎么回事？

之前我们有使用到过用户表，是TU开头，而这个表是TD开头，那么用户是否也有一张一样的表呢？

果然，我们找到了TU_MJiFen表！

这个里面记录的就是所有用户的余额等信息，根据TD_MJiFen表，_JiFen字段就是真正的余额：

同样的，我们还能找到对应的PU_MInfo函数：

在TU_User表里面，我们能找到liyun10对应的id是1049：

根据之前的PU_MInfo函数，它比对的是UMJF_UU_ID，也就是说在这个字段找1049：

或者直接使用sql语句查询：

select UMJF_JiFen
from TU_MJiFen join TU_User on UMJF_UU_Id = UU_Id
where UU_Ln = 'liyun10'

这就得到了liyun10的余额

不过这种方法太过麻烦，而且有一定的运气因素，万一猜错了表名什么的就完蛋了

换一种方式，在用户列表里面直接找到liyun10，进入后台：

直接访问是失败的：

在前面加上服务器ip，就能自动跳转到用户后台管理了：

192.168.1.176/res/aspx/uin.aspx?user=liyun10&pwd=F58249F4A628AE7B35753EA8416BA943&t=fqgl

在结算管理里面找到余额：

1066449

其实做到这里也就知道为什么之前的方法不能直接找到用户余额表了，因为之前登录的管理员账号使用的结算管理页面.aspx文件和用户使用的不一样，我直接找只能找到管理（？的余额，总之不是liyun10的

另外，直接看数据库余额是有小数部分的，但是答案格式只说是"123456"这样的纯数字，不知道会不会有冲突

49.接上一题，该用户的推广ID是

链接代码中能看见：

d0fdd7a9a010d37e

50.接上一题，该代理商户的最后一次登陆时间是

登录日志里面啥也没有，注册信息里面倒是有：

2016/9/5 17:09:13

总算是做完了，part4真的是异常的艰难啊