长安杯2022赛题复现详解

【不咕鸟】三战长安杯，有幸在本科阶段的最后一次长安杯取得了一个新的突破，比起第一年的全国第三，也算是善始善终啦。

lq & rx nb！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！

案情背景

某地警方接到受害人报案称其在某虚拟币交易网站遭遇诈骗，该网站号称使用“USTD 币”购买所谓的“HT 币”，受害人充值后不但“HT 币”无法提现、交易，而且手机还被恶意软件锁定勒索。警方根据受害人提供的虚拟币交易网站调取了对应的服务器镜像并对案件展开侦查。

复盘总览

【网站重构】请见【检材3】部分，【案情还原】请见【检材4】部分

检材1

1. 检材1的SHA256值为

2. 分析检材1，搭建该服务器的技术员IP地址是多少？用该地址解压检材2

last 命令，172.16.80.100

在有了【检材2】的解压密码后，就可以两个检材同时进行取证分析，这种个人 PC 往往都有远程管理或者访问服务器的记录

3. 检材1中，操作系统发行版本号为

cat /etc/*-release

或者仿真的时候也能解析

4. 检材1系统中，网卡绑定的静态IP地址为

# 查看网卡
ip a

# 查看网卡配置文件
cat /etc/sysconfig/network-scripts/ifcfg-ens33

5. 检材1中，网站jar包所存放的目录是

看 bash 的历史记录 history，可以过滤一下 jar，可以看到大量的 /web/app

6. 检材1中，监听7000端口的进程对应文件名为

直接用 netstat 命令过滤 7000 端口发现并没有这个进程，说明不是自启动的进程，查看历史记录可以发现启动最多的服务就是那几个 jar 包，手动尝试启动每一个 jar 包，过滤关键字

可以看到是 cloud.jar

7. 检材1中，网站管理后台页面对应的网络端口为

在【检材2】的 Google Chrome 历史记录中，可以看到【后台管理】对应 9090 端口，且访问地址对应【检材1】的静态 IP

8. 检材1中，网站前台页面里给出的APK的下载地址是

很明显这个题需要我们把前台启动后查看，通过看历史命令，可以看到有很多关于 vue 文件的操作，find 命令搜一下 vue 文件，可以看到都在 /web/app 这个目录下，由此可以初步断定该网站使用了 vue 框架，而简单搜索一下历史命令中的另一条 npm run dev 命令，就能知道它是用来启动 vue 项目的，同样我们可以得知 npm run 命令实际上是用来执行配置在 package.json 文件中的脚本的

在历史命令的 50 条左右，可以看到有对 web.tar 包的操作，在解压 tar 包后就在该目录下执行了 npm install 和 npm run dev 命令

我们同样尝试在该目录下执行 npm run dev ，发现 vue 项目部署在了本机的 3000 端口

而在【检材2】的 Google Chrome 历史记录中可以看到，http://172.16.80.133:3000 对应的正是【某币交易网站】的前台

如何使物理机连通仿真后的检材

火眼仿真起来的虚拟机默认的网络连接配置都是 NAT 方式，我们将【虚拟网络编辑器】中 NAT 模式的子网 IP 改为【检材1】配置的静态 IP 的网段

此时就可以使物理机与虚拟机连通，此时就可以通过 Xshell 或 Xftp 连接到检材中，也可以在物理机的浏览器直接访问启动好的网站

扫描右上角的【APP下载】中的二维码，就可以得到下载地址

通过这个地址下载到的 apk，就是后面 apk 部分题目的分析目标，我们可以把它放在手机模拟器里运行，也能够判断它是能够锁机的恶意软件

这道题在比赛的时候还踩了个坑，我后面答这道题的时候直接去看的下载记录，结果里面给的链接是跳转后的真实的下载地址，痛失10分

9. 检材1中，网站管理后台页面调用的用户表(admin)里的密码字段加密方式为?

见下题，md5

10. 分析检材1，网站管理后台登录密码加密算法中所使用的盐值是

实际上在我们得到【检材2】的解压密码后，通过对【检材2】中浏览器历史记录的分析，就可以在 GitHub 上找到这个开源的网站框架

框架的名称与我们通过网站前台二维码下载的 apk 完全相同，这里也相当于是一个提示，在这个开源项目中也可以确定这个网站使用了 SpringBoot+Vue 的架构

我们把【检材2】放着后登录，可以看到有 Xftp，打开 Xftp 中【最近的会议】选项，可以看到有多次连接 172.16.80.133 的记录

在取证结果中搜索 xftp，可以找到一系列通过 Xftp 下载的文件记录

其中就有曾在【检材1】中使用过但已经被删除的脚本 start_web.sh，在历史命令的最后部分可以看到

继续在【检材2】的取证记录中搜索该文件，可以定位到原始文件

还有 建站笔记.txt

这个网站必须先启动后端全部组件，再启动前端，而且启动jar包还有顺序

(╯‵□′)╯︵┻━┻

可以看到和在 GitHub 上的开源框架中给出的 项目启动说明 几乎一致，那个 start_web.sh 中的内容也是一致的

导出 start_web.sh，传到【检材1】的 /web/app 目录下并执行

启动网站后就可以在物理机的浏览器中直接访问后台

在 GitHub 中可以看到网站管理后台对应的是 admin 模块

而在网站启动脚本中对应 admin 模块启动的 jar 包为 admin-api.jar

echo "Starting App：admin" 
nohup  java -jar /web/app/admin-api.jar &
sleep 20s

导出这个 jar 包，用 jd-gui 对其进行反编译后分析，搜索关键字【密码】，可以定位到

找和 password 相关的操作，就可以看到密码字段的加密方式，即【第9题】答案（MD5）

同样在这个类中可以看到有个 md5Key

跟进跳转

可以看到这是一个引用进来的字符串常量，无法直接跳转，于是想到查看配置文件，SpringBoot 的配置文件为 application.properties，找到当前类所在根目录下的对应文件

在该配置文件的最后找到的 key 就是【第10题】所说的盐值

同时在这个文件的开头，也能看到管理后台连接的数据库配置，后续会用到

JDBC 是 Java 中访问数据库的一套 api，全称是 Java DataBase Connectivity

Part1 小结

很经典的服务器检材，其中最重要的内容是用于构建网站前台和后台的全部文件，难点在于对这个大型网站文件结构和内容的解析，以及对长达 1000 条的历史命令记录的审计。出题人选择了一个启动命令非常繁琐复杂的虚拟币交易网站，对于该网站的搭建同样使用的站库分离的架构，在【检材1】中并不能找到有任何连接数据库相关的命令，我们需要从历史命令中找到启动网站相关的内容，以便我们在仿真环境中进行重现。

【检材1】和【检材2】的联系非常紧密，我们在得到【检材2】的解压密码后需要同步对其进行分析，其中包括了很多与【检材1】相关的内容，比如远程管理记录（Xshell & Xftp）、访问网站前台后台的浏览器历史记录和终端里的远程连接记录等，当我们能够把这两个检材联系在一起进行分析，许多问题就会很容易地找到答案。

至此，我们已知的线索：

• 【检材1】的静态 IP 地址：172.16.80.133
• 搭建网站的【技术员】的 IP 地址：172.16.80.100
• 【检材2】有对【检材1】的远程管理和访问记录，【检材2】曾使用 Xftp 从【检材1】中下载了文件
• 【检材1】中搭建的网站使用了开源的 ZTuoExchange_Framework 框架，前台端口 3000，后台端口 9090
• 在网站前台可以下载到名为 ZTuoExchange 的 apk 文件，可以判定其为恶意软件
• 网站后台连接的数据库为 mysql

- IP 地址为 **172.80.16.128**，端口为 **33050**，数据库名为 `b1`，用户名为 `root`，密码为 `shhl7001`

检材2

11. 检材2中，windows账户Web King的登录密码是

仿真可以识别出来

12. 检材2中，除检材1以外，还远程连接过哪个IP地址？并用该地址解压检材3

直接看 Xshell 的连接记录中就有，取证结果和仿真查看都可以看到：172.16.80.128

仿真后打开 Xshell 会直接显示下面的结果

13. 检材2中，powershell中输入的最后一条命令是

两种方法，可以仿真后打开 PowerShell 然后按【上】键，就能看到最后一条命令

或者找到保存历史命令的文件，默认在该目录

\Users\[user]\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt

14. 检材2中，下载的涉案网站源代码文件名为

在【第10题】就分析过了，Google Chrome 的下载记录中，ZTuoExchange_framework-master.zip

15. 检材2中，网站管理后台root账号的密码为

首先我们要知道网站管理后台的地址是：http://172.80.16.133:9090

这道题也有两种做法，火眼可以直接将其分析出来

仿真之后打开 Chrome，在自动填充里也可以找到，用【第11题】解析出来的登录密码就可以查看

16. 检材2中，技术员使用的WSL子系统发行版本是

这个题也有几种不同的方法可以找，仿真后可以在【开始】菜单里看到两个子系统，分别点开，可以看到 20.04 版本的子系统可以直接启动

还可以查看它的历史命令记录

但是 22.04 的系统要安装

那很明显【技术员】使用的是已经安装好可以直接使用的 Ubuntu 20.04.5 LTS

也可以看取证大师的分析结果

也可以直接找到保存子系统的根目录，Windows 下的 wsl 子系统默认统一保存在该目录

\Users\[user]\AppData\Local\Packages

可以看到两个文件夹的大小和文件数量完全不在一个数量级，使用的哪个子系统可想而知

17. 检材2中，运行的数据库服务版本号是

承接上一题的子系统，通过查看子系统中的历史命令可以看到有启动 mysql 服务的记录，于是可以进入到子系统中直接查询

18. 上述数据库debian-sys-maint用户的初始密码是

先简单介绍一下这个用户，这个用户是只有 Debian 或者 Ubuntu 系统中安装 mysql 后会生成的默认用户，它的作用是在忘记 root 用户密码的情况下仍然可以连接数据库并进行密码重置的操作，这个用户的相关配置信息默认在以下目录

/etc/mysql/debian.cnf

在子系统中，实际的路径如下

\Users\Web King\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu20.04LTS_79rhkp1fndgsc\LocalState\rootfs\etc\mysql

文件内容如下

# Automatically generated for Debian scripts. DO NOT TOUCH!
[client]
host     = localhost
user     = debian-sys-maint
password = ZdQfi7vaXjHZs75M
socket   = /var/run/mysqld/mysqld.sock
[mysql_upgrade]
host     = localhost
user     = debian-sys-maint
password = ZdQfi7vaXjHZs75M
socket   = /var/run/mysqld/mysqld.sock

可以看到密码是：ZdQfi7vaXjHZs75M

19. 检材3服务器root账号的密码是

在解压【检材3】后，可以确定【检材3】配置的静态 IP 地址为：172.16.80.128

在子系统的历史命令中就有通过 ssh 命令连接该 IP 的记录

可以看到 -p 参数的值就是本题要找的 root 用户的密码：h123456

Part2 小结

这部分的题目都比较简单，而且对于同一道题都可以找到几种不同的解法，不局限在某个思路上，比较有创新点的地方是今年使用了 wsl 子系统，围绕这个子系统提出了一系列的考题，但万变不离其宗，子系统本质也就是个 Linux 系统，常用的命令和分析方式都适用于此。

对【检材2】的分析，我们得知【技术员】使用了 Windows 下的 wsl 子系统远程连接了【检材3】，而【检材3】就是【检材1】中搭建的网站的数据库，这一点我们在【第10题】中对 SpringBoot 配置文件的分析也可以得知：

通过静态分析我们也可以确定【检材2】的初始网络配置 IP 地址就是 172.16.80.100，与【第2题】答案相照应。

至此我们已经初步理清这前三个检材之间的联系：

• 【检材1】IP 为 172.16.80.133，用于搭建虚拟货币交易网站的前台（3000）和后台（9090）
• 【检材2】IP 为 172.16.80.100，是【技术员】用于远程管理【检材1】和【检材3】的机器
• 【检材3】IP 为 172.16.80.128，是【检材1】中搭建网站的数据库（33050）

检材3

20. 检材3中，监听33050端口的程序名（program name）为

经过上面的分析，我们已知 33050 端口是 mysql 数据库服务所在的端口，仿真后通过 netstat 查看发现 33050 端口并没有被监听，说明服务还没启动，history 查看历史命令，过滤 mysql，可以看到在本机和 docker 中都有一个 mysql 服务

然而我们实际操作时会发现本机的 mysql 服务无法正常启动，于是尝试启动 docker 服务，再次过滤 33050 端口

可以看到 program name 对应为 docker-proxy

同时我们查看 docker 的容器也可以发现这个 33050 端口是从内部的 3306 端口映射出来的，而 3306 端口也正是 mysql 服务的默认端口

21. 除MySQL外，该网站还依赖以下哪种数据库

几种方法，可以看历史命令记录，有 mongodb 和 redis

或者 GitHub 上也写了【ZTuo平台使用的技术】

或者【第10题】中提到的 SpringBoot 的配置文件 application.properties 中也有关于数据库连接的配置

22. 检材3中，MySQL数据库root账号的密码是

【第10题】中已经提到过了，在 application.properties 中

23. 检材3中，MySQL数据库在容器内部的数据目录为

开启 docker 服务，进入容器的交互终端，查看历史命令，就可以看到默认的 mysql 数据目录 /var/lib/mysql

也可以直接进入数据库查看 datadir

mysql -uroot -pshhl7001
show variables like 'datadir';

24. 涉案网站调用的MySQL数据库名为

同样在 application.properties 中

【网站重构】

后面的题目全部都和数据库相关，而且通过题干我们也能知道有部分数据被删除，需要进行还原。当我们实际进入到 docker 中，连接到数据库去查看信息时，也可以发现数据库中并不存在 b1 这个库，后续我们通过对【检材4】的分析，就可以得知实际上 b1 这个库已经被删掉了

那么被删掉的 b1 应该如何还原呢，实际上我们在分析【检材1】和【检材2】的时候，在【检材2】中找到了【检材1】中被删除的 start_web.sh 脚本，定位到保存该文件的目录，仿真后是 D盘，在这个目录下可以看到存在一个 b1 文件夹

打开这个文件夹可以看到里面正是常规数据库应该有的所有数据文件，同时在这个目录下还有一个 start.sh 脚本，如果你看【检材3】的历史命令记录比较仔细，就可以发现这个脚本曾在【检材3】中被使用

通过这个脚本的内容和名称，也可以推断出它的用途和 start_web.sh 类似，应该是用来启动后端服务的

那么我们现在已经找齐了被删除的数据库 b1 和后端服务的启动脚本 start.sh，只需要把数据库恢复到【第23题】的数据目录，就大功告成了

至于恢复数据库的方法有很多，可以把它利用 Xftp 上传到【检材3】中，然后再通过 docker cp 命令复制到 docker 中，但是再次我们来讲下本次长安杯中设计的另一个新的考点：docker-compose

docker-compose

【检材3】的历史命令记录中存在大量的与 docker-compose 相关的命令，docker-compose 是用于定义和构建多个容器 docker 应用程序的工具，通过配置 yml 文件，就可以只通过一条 docker-compose up 命令来启动多个不同配置运行不同服务的 docker 容器

配置文件默认是 docker-compose.yml，我们通过历史命令记录可以看到它在【检材3】中的目录

或者直接 find 命令全盘搜索

find / -name docker-compose.yml

查看文件内容

version: '3'

services:
  mysql:
    image: "mysql:5.7.32"
    restart: always
    container_name: mysql57
    environment:
      MYSQL_ROOT_PASSWORD: shhl7001
      TZ: Asia/Shanghai
    command:
      --default-authentication-plugin=mysql_native_password
      --character-set-server=utf8mb4
      --collation-server=utf8mb4_general_ci
      --explicit_defaults_for_timestamp=true
      --lower_case_table_names=1
      --max_allowed_packet=128M
    ports:
      - 33050:3306
    volumes:
      - /data/mysql/db:/var/lib/mysql
      - /data/mysql/conf/my.cnf:/etc/mysql/my.cnf

其中每个 service 就代表一个容器，这个容器可以从 dockerhub 中的镜像来创建，也可以通过从本地的 dockerfile build 出的镜像来创建，在这个配置文件中只创建了一个 mysql 的容器，其中有容器名、root 用户的密码、时区等信息，其中 ports 字段配置了容器和宿主机的端口映射，容器内的 3306 端口映射到宿主机的 33050 端口，而 volumes 字段则表示容器中目录与宿主机中目录的映射，: 左侧是宿主机的目录，右侧是容器中的目录，在其中一个目录中进行文件的修改，就会同步到另一个目录下，这样的配置是为了进行数据持久化，当容器并未启动时宿主机中也保留有完整的数据

重构过程

那么我们将 b1 文件夹上传到【检材3】的 /data/mysql/db 目录下，就可以完成数据库的恢复

再次进入数据库查看，已经可以看到恢复成功的 b1 数据库，但此时我们要注意，我们通过 root 用户恢复的数据库，需要将其赋予 mysql 用户能够执行的权限，数据库才能正常被调用，即 chmod 777 ./b1

根据【建站笔记.txt】中所写的先启动后端，再启动前端，查看历史命令可以知道 start.sh 原本在 /web/ 目录下

重启【检材3】的 docker 服务，上传 start.sh 到指定目录（/web/），先在【检材3】中执行 start.sh

启动完成后再在【检材1】的 /web/app/ 目录中执行 start_web.sh

完成网站重构，此时如果一切都正常，网站前后台都可以正常访问，而且后台登录页面的验证码也能够正常显示

25. 勒索者在数据库中修改了多少个用户的手机号？

见下题，3 条

26. 勒索者在数据库中删除的用户数量为

28 条

这两道题放在一起说，题目问的是数据库修改和删除的记录，这种已经修改和删除过的数据，在数据库中是不会保存的，所以很明显是要我们去看日志，连接到数据库中查找日志文件的保存位置

show variables like '%general%';

在 docker 中的 /var/lib/mysql 目录下，根据 docker-compose 的配置映射到宿主机上就在 /data/mysql/db 目录下

可以导出来查看，比较方便，【第25题】问修改的数量，过滤 update 关键字，在日志中有 8 处匹配，但实际上有关 mobile_phone 的日志只有 3 条

【第26题】问删除的数量，过滤 delete 关键字，可以看到一共有 28 条，且全部都与 member_id 相关

27. 还原被破坏的数据库，分析除技术员以外，还有哪个IP地址登录过管理后台网站？用该地址解压检材4

数据库的 admin_access_log 表中，172.16.80.197

或者进入到重构好的网站后台（登录账户和密码可见【第15题】），在【系统管理】的【系统日志】页面也可以看到

28. 还原全部被删改数据，用户id为500的注册会员的HT币钱包地址为

同样在数据库和网站后台都可以查到，数据库的 member_wallet 表

后台的【会员管理】搜索 500 找到对应的用户，然后【查看】

29. 还原全部被删改数据，共有多少名用户的会员等级为'LV3'

在数据库的 member 表中，member_grade_id 字段对应着每个用户的等级，我们可以随便找一个会员 ID，然后查看它的 member_grade_id 与网站后台中是否一致，依此来判断等级的对应，可以发现当 member_grade_id 为 3 时就对应会员的等级为 LV3

写个 sql 语句查询下数据条数

SELECT COUNT(*) FROM b1.member WHERE member_grade_id = 3;

可以看到在表中的用户等级为 LV3 的用户数量为 158，但题干问的是【还原全部被删改数据】，实际上 member 表中还有 28 条被删除的用户记录（见【第26题】），我们还需要看这 28 个用户中有几个 LV3

我们在数据库的日志中可以过滤到给 member 表插入数据的记录，这个插入数据的操作在【检材4】的聊天记录中也有体现，从日志的第 4701 行开始，从 1~1000 一共在 member 表中插入了 1000 条数据，而在原表中从 973 开始后面的 28 条数据被删除掉了，插入的数据格式应该与我们在数据库中看到的表头顺序是完全对应的，member_grade_id 在倒数第四列，所以我们找到 insert 语句中的倒数第四个数据，看有几个 3

被删掉的用户数据中一共有 6 个 LV3，加上未被删除的 158 个，一共有 164 个 LV3 用户

30. 还原全部被删改数据，哪些用户ID没有充值记录

这个题我们可以在 member_wallet 表中查看，没有充值记录就一定没有余额（balance），让表中的 balance 字段升序排列，就能看到余额为 0 的用户

也可以参考复盘讲解中的做法，过滤用户的交易记录 member_transaction

31. 还原全部被删改数据，2022年10月17日总计产生多少笔交易记录？

交易记录在 member_transaction 表中，写个 sql 语句查询一下数量

SELECT COUNT(*) FROM b1.member_transaction WHERE create_time LIKE '2022-10-17%';

32. 还原全部被删改数据，该网站中充值的USDT总额为

还是 member_transaction 这个表，计算下 amount 的总和即可

SELECT SUM(amount) FROM b1.member_transaction;

Part3 小结

这一部分题目算是本次长安杯考题的重点和难点，涉及到 docker-compose、数据库还原、网站重构、数据库日志分析和 sql 语句的使用等多个技术点，而且与【检材1】和【检材2】紧密相连：管理后台的账号密0码在【检材2】中，数据库备份和服务启动脚本在【检材2】中，管理后台网站在【检材1】中，前后端启动服务的顺序也与【检材1】有关，而数据库中有些插入和删除用户数据的操作，在案件剧情上还与【检材4】密切相关。

至此，随着对【检材3】这部分分析结束，前三个检材之间的关联分析与虚拟货币交易平台的重构就告一段落，【检材4】作为独立在外的一个检材，虽然与前三个检材在分析过程中没有实质性的关联，但它是贯穿整个案件剧情最重要的部分，我们通过对【检材4】的分析，就可以将前三个检材与案情背景串联起来，还原整个案情的真相。

检材4

解压后会得到一个 npbk 文件，根据【检材4】部分题目的描述可以知道这部分题目与安卓模拟器有关，那么检索关键字【npbk模拟器】

可以得知这是【夜神模拟器】的备份文件，下载一个夜神模拟器并导入备份，就可以正常打开这个安卓机，导入备份后默认在该目录下会生成这个安卓模拟器的镜像文件（vmdk）

\Nox\bin\BignoxVMS\nox

将这个文件在拷贝到其他目录，然后再导入火眼取证工具中，就可以对这个安卓模拟器进行取证分析，需要注意的是这里一定要单独复制一份用于取证，否则当模拟器启动后会使用上述目录中的镜像文件，会导致火眼取证分析不完整，无法解析出全部的数据

33. 嫌疑人使用的安卓模拟器软件名称是

夜神模拟器

34. 检材4中，“老板”的账号是

在微信聊天记录中

【案情还原】

在这个案情中最关键最核心的部分也在这两个微信聊天记录中：

【老板】也就是这四个检材的所有者推广新发行的虚拟货币搞诈骗，找到了【灰色信仰】给他搭建网站，这个【灰色信仰】也就是上面题目中所说的【技术员】，还找到了【关心】和他的团队给他发行的新币做推广冲热度，【关心】找到了他的【小舅子】来给这个交易平台添加模拟数据，我们通过分析插入数据部分的日志也可以得知【小舅子】的 IP 地址是 172.16.80.200

在【老板】和【灰色信仰】聊天记录的后半部分，因为网站的功能和使用方式与交付金额等问题发生争吵，【灰色信仰】给【老板】发送了勒索邮件（在手机模拟器的 QQ 邮箱里可以看到），同时也修改和删除了网站以及数据库中部分数据，将网站上的 apk 下载内容换成了诈骗 apk（这也可以解释为什么我们在【检材1】部分下载到的 apk 就是后面要分析的恶意 apk），后面就与案情背景衔接起来，因而有了这些检材和本次取证。

有了这些背景，我们就可以理解为什么【检材3】中的数据库一开始是被删除掉的，为什么网站前端和后端的启动脚本也都被删除了，以及为什么数据库的备份是在【检材2】中，因为【灰色信仰】即【技术员】通过【检材2】对前后端服务器进行远程管理，从【检材2】的浏览器历史记录中也可以印证这个【检材2】就是【灰色信仰】的个人 PC，并且其中还保留着一些案情相关的搜索记录

通过下面这个架构图可以更直观的看到整个案情的脉络与各个检材和一些数据操作之间的联系

35. 检材4中安装的V**软件名称是

用取证工具可以解析到

启动模拟器也可以看到

36. 上述V**工具中记录的节点IP是

同样在取证分析结果和模拟器中都能找到

37. 检材4中，录屏软件安装时间为

火眼分析，【应用列表】，按照时间降序排列

虽然没有应用名称，但是通过包名也可以判断出这个应用就是录屏软件

38. 上述录屏软件中名为“s_20221019105129”的录像，在模拟器存储中对应的原始文件名为

由于是使用软件生成的录像文件，就去找这个应用对应的外部存储中的文件数据路径，这里的外部存储，也就是模拟器中 Amaze 文件结构中的主目录

/storage/emulated/0/Android/data/com.jiadi.luping/files

在 Movies 文件夹下，长按选择【重命名】，就可以得到完整的文件名

39. 上述录屏软件登录的手机号是

这个手机号，我们用模拟器打开录屏软件，只能看到前三位和后四位

这里我用的方法是根据已有的前三位和后四位电话号，直接去镜像文件的原始数据中进行正则匹配，用 010editor 打开 vmdk，然后搜索

复盘中官方给出的解法是去这个应用的数据库中找，数据库在这个目录中

也就是这个应用对应的内部存储路径中的 databases 目录下

/data/data/com.jiadi.luping/databases

这里涉及到 sqlilte 的【预写日志】这个知识点，读者可以自行搜索学习，在此不多讲述，使用预写日志的数据库需要在同一目录下同时具有 db、shm 和 wal 三个文件才能正常查看

导出上图中这三个文件，再用数据库工具打开 record.db 就能正常看到数据库中的数据，电话号在 AccountInfo 表中

40. 检材4中，发送勒索邮件的邮箱地址为

邮件在收件箱里

Part4 小结

这一部分的取证分析过程与前三部分没什么联系，算是独立存在的一个检材，问的题目也都相对比较简单，如果你很了解手机文件存储结构那么就能更快的找到答案，这部分检材也将整个案情与前三个检材联系起来，是对案情细节的补充和说明，也是这个案情中最核心最关键的部分，是还原案件的最后一块拼图。

exe分析

exe 在哪

从【第40题】的勒索邮件中可以看到附件中有一个【数据下载地址.docx_encrypted】文件，很明显就是被加密的 docx 文档，我们已知这个勒索邮件是【灰色信仰】发给【老板】的，而且在【检材2】的历史记录中也可以看到他登录网易邮箱的记录

既然是通过在电脑浏览器里登录邮箱来发送邮件，那么很大概率这个被加密的文档和加解密用的 exe 都能在电脑中找到，事实也是如此，这些文件都和前面用到的网站启动脚本和数据库备份文件都在 D 盘中

直接在取证结果中搜索这个加密文档的名字也可以定位到这个目录

41. 分析加密程序，编译该加密程序使用的语言是

直接看这个 exe 的图标就能知道是 python 写的，就算你没发现，也可以用 die 来识别

可以看到是用 PyInstaller 打包生成的 exe

42. 分析加密程序，它会加密哪些扩展名的文件？

PyInstaller 打包的程序可以用 Github 上的开源工具 pyinstxtrator 来解包

找到解包后的与原 exe 名相同的 pyc 文件，用 uncompyle6 反编译

uncompyle6.exe .\encrypt_file_1.pyc > .\encrypt.py

查看反编译出的源码就能知道完整的加密逻辑

43. 分析加密程序，是通过什么算法对文件进行加密的？

44. 分析加密程序，其使用的非对称加密方式公钥后5位为？

pubkey = '-----BEGIN PUBLIC KEY-----\nMIIBIzANBgkqhkiG9w0BAQEFAAOCARAAMIIBCwKCAQEAx5JF4elVDBaakgGeDSxI\nCO1LyyZ6B2TgR4DNYiQoB1zAyWPDwektaCfnvNeHURBrw++HvbuNMoQNdOJNZZVo\nbHVZh+rCI4MwAh+EBFUeT8Dzja4ZlU9E7jufm69TQS0PSseIiU/4Byd2i9BvIbRn\nHLFZvi/VXphGeW0qVeHkQ3Ll6hJ2fUGhTsuGLc1XXHfiZ4RbJY/AMnjYPy9CaYzi\nSOT4PCf/O12Kuu9ZklsIAihRPl10SmM4IRnVhZYYpXedAyTcYCuUiI4c37F5GAhz\nRDFn9IQ6YQRjlLjuOX8WB6H4NbnKX/kd0GsQP3Zbogazj/z7OM0Y3rv3T8mtF6/I\nkwIEHoau+w==\n-----END PUBLIC KEY-----\n'

45. 被加密文档中，FLAG1的值是

用同样的方法对解密用的 exe 进行逆向分析

可以看到在解密部分对我们输入的密码与 4008003721 进行判断，如果相等则解密，说明这串数字就是密钥，将解密用的 exe 和加密的 docx 放在同一个目录下，运行 exe 即可解密

打开解密后的文档里就有 FLAG1

Part5 小结

简单的 python exe 逆向，稍加搜索就可以知道通常是用 PyInstaller 打包，即使不了解 python 相关的逆向分析方法，只要在网上搜索相关字词，也能够找到大量的资料，程序内容也很简单，并没有涉及对算法的考察，也不需要自行编写解密脚本，整体来说还是很简单的。

apk分析

这部分题目比较方便的解法是围绕弘连的【雷电APP智能分析】工具来展开（每年的保留项目工具推广题），apk 被加壳，自己手动脱壳会需要比较长的时间，使用工具自带的一键脱壳就能节省大量的时间，脱壳之后就是常规的 apk 逆向分析的流程，如果做过去年的长安杯，或者去年的中科实数杯，应该都会比较熟悉，难点在于最后两道题，交给逆向带师 rx 来处理了（

46. 恶意APK程序的包名为

或者查看逆出来的 apk 主配置文件 AndroidManifest.xml

47. APK调用的权限包括

同样在 AndroidManifest.xml 中也能看到，实际上取证工具就是通过分析这个文件的内容从而给出的结论

48. 解锁第一关所使用的FLAG2值为

脱壳之后给出的 4 个 dex 文件中最大的那个就是 apk 的主要逻辑代码部分，在 cn.forensix.cab/MainActivity 中是主函数，其中就包含了 FLAG2 的明文

49. 解锁第二关所使用的FLAG3值为

待补充

50. 解锁第三关所需的KEY值由ASCII可显示字符组成，请请分析获取该KEY值

待补充

总结

关于比赛案情和题目相关的内容上面都总结过了，在最后就简单说说和比赛相关的事吧，主要还是两点，一个是赛前准备，一个是赛时分工：

关于赛前准备方面，比赛之前还是要把各种常用的工具都打开看一看，看看有没有需要更新的，有没有使用过程中需要其他依赖软件的，比如像【雷电APP智能分析】这个工具使用的时候需要连接特定的手机模拟器，如果不提前下载安装好，就只能等到比赛的时候现下载现安装，会浪费一些不必要的时间，或者像 Android 逆向需要用的工具，等比赛的时候现去学习和了解使用方法肯定是要花很多时间的，这种就只能靠平时做其他的比赛或者 CTF 题去积累了；

关于赛时分工方面，这个分工的问题一直是取证比赛中比较难处理的地方，按照每个队员自己擅长的方向去做题肯定效率会比较高，我们队一直都是每个人负责不同的检材，不过这样做就很少会有额外的时间投入到其他人负责的检材中，但往往检材之间的线索关联和相关文件的搜寻又需要把不同的检材联系在一起进行分析，如何平衡好这两点我觉得主要还是要靠多沟通多交流吧，线下在一起做题的优势比起线上用共享文档和电话会议交流还是差太多了，没有什么交流方式比直接看队友的电脑屏幕更快了，希望美亚杯的时候能正常恢复线下做题吧。