26龙信（服务器部分）

26龙信杯（服务器）

两台服务器的对应关系如下

两台服务器正常挂载仿真即可，01服务器192.168.91.100（根据自己服务器仿真的ip更改）连接不上的可以更改一下网关

ip addr add 192.168.188.100/24 dev ens33

之后应该就能正常连接上了

服务器中的pc密码

服务器中是藏有pc的一个密码的，在pckey.qenc文件中

调用解密服务器中的解密脚本，在/usr/local/bin/qdec下，直接调用原有脚本解密即可

/usr/local/bin/qdec /home/goyasha/pckey.qenc

gys666…

1.分析两台服务器，找出网站服务器负责完整启动查询系统的 systemd 服务名称。[标准格式：xxx.service]

ss -lntp先看看都有哪些端口在运行

排去几个ssh，systemed-resolve，其他的全部是以 Docker 容器的方式运行，看看系统后台服务的配置文件

看到这个dq-bootstrap.service.d，bootstrap有启动的意思，应该是这个了，按格式只到service就行 dq-bootstrap.service

2.分析网站服务器的 systemd 配置，找出负责启动查询业务的服务实际执行的宿主机程序完整路径。[标准格式：/xxx/xxx]

题目意思就是要找这个服务到底运行了哪个真实的程序

systemctl cat dq-bootstrap.service

由于第一题看到这些都以 Docker 容器的方式运行，实际执行的完整程序路径是 Docker 的可执行文件，由它来执行容器的启动指令，负责启动查询业务的服务实际执行的宿主机程序路径就是ExecStart后跟的/opt/delivery-query/bin/crypto-agent

同时也确认该文件确实存在

/opt/delivery-query/bin/crypto-agent

3.分析网站服务器查询业务相关程序及文件时间线，找出系统后期调整前使用的原始核心启动程序完整路径。[标准格式：/xxx/xxx]

接上一题，直接看了crypto-agent文件 会发现它是 shell 脚本，而不是核心业务二进制 ，发现他把核心core给了crypto-agent.core，也就是说现在运行的是这个crypto-agent.core

在同一目录下翻一翻，在.v347这个文件夹中看到一个命名为before的，打开后看到内容和core差不多，调整前应该就是这个

/opt/delivery-query/bin/crypto-agent.core

4.嫌疑人做了反取证手段编写了安全清理功能，请分析开始清理时最先被停止的查询业务容器名称。[标准格式：容器名称]

在这个目录下看到过一个/opt/delivery-query/bin/dq-failclosed-cleanup，应该是清理脚本

在脚本里可以看到是先停止的gate再停止app这样的顺序，那么在上面的stop服务中cname命名规则

按照默认的容器命名规则：项目名_服务名_序号得出答案

dqmain-gate-1

5.分析查询应用容器及镜像。运行中的容器可以访问完整业务源码，但镜像本身未保存这套完整源码，请确定源码运行时实际生成在宿主机的目录。[标准格式：/xxx/xxx]

前面是看到过一个.yml文件的，在/opt/delivery-query/docker-compose.yml路径下

可以看到app服务下的- /run/dq-runtime/app:/srv/app:ro和 - /run/dq-runtime/secret:/run/dq-runtime/secret，冒号左边是宿主机路径，右边是容器路径

考虑到run是临时运行位置，应该没错（在run路径下找不到dq-runtime）

/run/dq-runtime/secret

6.分析查询系统的启动程序和 Docker 镜像，确定用于打开、转换或验证加密业务数据库的工具镜像标签。[标准格式：repository:tag]

前面的题目已经提到，核心是/opt/delivery-query/bin/crypto-agent.core，但是由于它是二进制，不适合直接用文本编辑器阅读，用下面一条命令提取可读字符串 ，意思是把带有sqlcipher-tool的提取出来

strings /opt/delivery-query/bin/crypto-agent.core | grep ‘sqlcipher-tool’

能看到标红的镜像引用dqmain/sqlcipher-tool:3.4.6

然后再镜像列表中核对docker image ls

dqmain/sqlcipher-tool:3.4.6

7.分析解密服务器上的 Docker 服务，确定实际负责向网站服务器提供临时授权并封装运行密钥的核心服务镜像标签。[标准格式：repository:tag]

找到cryptod服务，并查看他的image

解密服务器就去看02的相关的文件，在同样的/opt/query-crypto文件下可以看到docker-compose.yml

实际负责向网站服务器提供临时授权并封装运行密钥的核心服务镜像标签，就是crtptod服务下对应的信息，image就是配置项名称，而它后面的值就是镜像名称和标签（Tag）

dqcrypto/cryptod:3.4.4

8.分析服务端返回临时授权结果时的签名验证逻辑，确定所使用的数字签名算法。[标准格式：ab88888]

尝试全盘寻找数字签名算法所在的文件，grep -Rni --include=“crypto_service” “ed25519|sign” / 2>/dev/null，搜索包含crypto_service的文件，发现基本都是在/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/309/fs/srv/crypto_service.py路径里的

打开相应的文件进行查看

搜索数字签名相关的字样，在搜索sign时可以看到一行lease_sign=ed25519.Ed25519PrivateKey.from_private_bytes(b64d((BASE/‘identity/lease-sign.key’).read_text().strip()))

看答案这个格式，ed25519应该就是要找的数字签名算法

ed25519

9.恢复服务端生成授权响应签名原文时的字段排列顺序，填写参与签名的第 6 个字段名称。[标准格式：字段名称]

同上题，签名依旧是在这个文件里找，可以看签名的fields表来确定顺序，搜索acquire_sig_text

acquire_sig_text本质上是一个签名数据标准化函数，它的作用是将复杂的业务数据按照严格固定的字段顺序提取出来，并用换行符拼接成一段毫无歧义的纯文本，从而确保服务端进行 Ed25519 数字签名时，双方对数据的哈希计算是完全一致且不可篡改的

按照这个fields表，顺序就是’lease_id’