帮我分析一下里面有什么服务 特别是http服务怎么访问

我拆开看了，这个包本质上是一套 ARM64 的接收端/靶场服务，启动入口是：

• start_receiver_service.sh：注册成 systemd 服务 receiver.service
• receiver.sh：实际执行 nohup ./des_daemon_linux_arm64 -f daemon.yaml
• 也就是说真正先启动的是 des_daemon_linux_arm64，再由它拉起其他组件

里面有什么服务

按文件和配置看，主要有这几类：

1. 守护进程

   • des_daemon_linux_arm64
   • 作用：总控、拉起/停止其他进程、升级、重置、监控
   • daemon.yaml 里配置了它会管理：
     • des_server_linux_arm64
     • des_agent_linux_arm64
     • des_invoke_linux_arm64
     • des_simulator_linux_arm64

2. 主服务（对外核心）

   • des_server_linux_arm64
   • server.yaml 里明确有：
     • port_grpc: 18888
     • port_http: 5678
     • port_tcp: 5679
     • port_udp: 5679

3. Agent 服务

   • des_agent_linux_arm64
   • agent.yaml：
     • port: 10001
     • illegal_port: 10002
   • 从符号看它负责：
     • StartListening
     • PutData
     • Transport/transportHttp/transportFtp/transportGit/transportSftp/transportSmb
     • RunRansomwareLine
     • GenerateRansomLetter
     • EncryptFile
   • 说明它更像“执行/模拟/数据传输”端

4. 非法/Invoke 服务

   • des_invoke_linux_arm64
   • 对应 illegal_port: 10002
   • 从符号看是 agentillegal 相关能力，和非常规执行/攻击模拟有关

5. 模拟器

   • des_simulator_linux_arm64
   • 从符号看支持：
     • httpRun
     • ftpRun
     • gitRun
     • sftpRun
     • smbRun
     • reverse shell / process simulate

端口总览

启动脚本里会先检查这些端口是否被占用：

• 5677
• 18888
• 5678
• 5679
• 10001
• 10002

对应关系大致是：

• 5677：daemon
• 18888：server gRPC
• 5678：server HTTP
• 5679：server TCP/UDP
• 10001：agent
• 10002：invoke / illegal

---

HTTP 服务怎么访问

1）主 HTTP 服务

最明确的是：

• HTTP 端口：5678

所以访问方式优先试：

• 本机访问：
  • http://127.0.0.1:5678
• 局域网/远程访问：
  • http://<服务器IP>:5678

2）已静态确认到的 HTTP 路径

因为这是 ARM64 二进制，当前环境没法直接运行动态探测，所以路由只能做静态分析；目前能明确识别出的 HTTP 路径有：

• GET /api/test
• GET /remote_files/download/:id

另外二进制里还出现了：

• /index.html

说明它很可能还带静态页面或前端入口。

3）建议你直接这样验证

先在目标机器上执行：

bash
curl -i http://127.0.0.1:5678/
curl -i http://127.0.0.1:5678/index.html
curl -i http://127.0.0.1:5678/api/test

如果要远程访问：

bash
curl -i http://<服务器IP>:5678/
curl -i http://<服务器IP>:5678/api/test

如果下载接口要试：

bash
curl -O http://127.0.0.1:5678/remote_files/download/<id>

---

还有一个“内嵌/子 HTTP 服务”

二进制里还发现了这类 URL 模板：

• http://127.0.0.1:%d/alioth/%s/%s
• http://127.0.0.1:%d/alioth/%s/%s/inject

这说明系统里可能还会动态拉起一个本地 HTTP 子服务（看起来和 Java web service / inject / memory shell 相关），而且：

• 端口是动态生成
• 默认是 127.0.0.1 本机访问
• 不一定对外开放

所以它不是主入口，主入口还是 5678。

---

如果你要在机器上确认“HTTP到底怎么开了”

直接跑这几条最有效：

bash
systemctl status receiver.service
ss -lntup | egrep '5677|5678|5679|18888|10001|10002'
curl -i http://127.0.0.1:5678/
curl -i http://127.0.0.1:5678/api/test
journalctl -u receiver.service -f

如果你愿意，我下一步可以继续帮你做两件事里的任意一个：

1. 把这套服务的调用关系画出来
2. 继续深挖 des_server_linux_arm64，尽量把 HTTP API 路由表再抠出来

继续往下抠后，des_server_linux_arm64 的 主 HTTP 服务已经能比较明确地还原出来了。

结论先说

这套主 HTTP 服务是 Gin 起的，监听配置来自 server.yaml：

• port_http: 5678

而且从 initRouter() 静态反汇编看，明确注册的主路由只有 3 个：

1. GET /api/test
2. GET /api/remote_files/download/:id
3. POST /tasks/sync

所以主访问入口就是：

bash
http://127.0.0.1:5678
http://<服务器IP>:5678

---

我纠正一下前面的一个点

之前我根据字符串粗扫提到过 /remote_files/download/:id 和 /index.html。

这次是按 initRouter() 真正把路由表抠出来的，结果是：

• 下载接口真实路径是：/api/remote_files/download/:id
• 没有看到显式的 / 或 /index.html 路由注册
• 也没看到 Static() / StaticFile() / NoRoute() 这类静态页面注册

所以：

• index.html 更像是普通字符串噪音，不能当成实际可访问页面
• 这服务更像 接口服务，不是传统前端站点

---

这 3 个 HTTP 路由分别怎么访问

1）GET /api/test

这是最适合先拿来探活的一个。

访问：

bash
curl -i http://127.0.0.1:5678/api/test

或者远程：

bash
curl -i http://<服务器IP>:5678/api/test

我的判断：

• 这是 /api 分组下的测试/探测接口
• 看函数名对应的是 Server.Test
• 大概率返回结构化结果，而不是下载文件

但它具体是否需要额外参数，这次静态分析还没完全还原干净。
所以最实用的方式是先直接请求一次，看服务返回什么报错或结果。

---

2）GET /api/remote_files/download/:id

这个是 文件下载接口，路径参数 id 是必须的。

访问格式：

bash
curl -i http://127.0.0.1:5678/api/remote_files/download/<id>

直接下载附件：

bash
curl -OJ http://127.0.0.1:5678/api/remote_files/download/<id>

这个接口我能看得更清楚一点：

• handler 是 Server.GetRemoteFile
• 会先按 id 去本地 sqlite 记录里查文件
• 然后走 gin.Context.FileAttachment(...) 回文件

所以它不是随便传文件名，而是要传 数据库里的 remote file 记录 ID

也就是说：

• 你知道 id，这个接口才有意义
• 不知道 id，直接访问通常会报“找不到”之类的错误

---

3）POST /tasks/sync

这个接口不是普通浏览器点一下就能用的那种。

访问形式是：

bash
curl -X POST http://127.0.0.1:5678/tasks/sync

但我不建议你把它当普通 JSON API 去试，因为从 syncTask() 的反汇编看，它的处理流程是：

1. 读原始请求体
2. 做 AES 解密
3. 再对解密后的内容做 JSON 反序列化

这说明它更像一个 内部同步回调接口，不是公开给人工直接调的简单 HTTP 接口。

所以这个接口的实际访问条件是：

• 需要正确格式的请求体
• 请求体还不是明文，得先满足它的加密协议

换句话说，POST /tasks/sync 虽然是 HTTP 服务，但不是“拿 curl 发个普通 JSON”就能成功访问。

---

主 HTTP 服务怎么判断是不是对外开放

这包里我没看到 nginx / apache / caddy / docker compose 之类反向代理配置。
所以这套包本身的设计更像：

• 直接由程序自己监听 5678
• 直接访问程序端口

通常可以这样确认：

bash
ss -lntp | grep 5678

如果你看到类似：

bash
0.0.0.0:5678

或者

bash
[::]:5678

那就是对外可访问。

如果只看到：

bash
127.0.0.1:5678

那就只能本机访问，远程得走端口转发或改监听方式。

---

我现在对 HTTP 服务的判断

可以直接试的

• GET /api/test

需要已知资源 ID

• GET /api/remote_files/download/:id

有协议门槛，不适合直接手调

• POST /tasks/sync

---

建议你在目标机上直接这样验证

bash
systemctl status receiver.service
ss -lntp | egrep '5678|18888|5677|10001|10002'
curl -i http://127.0.0.1:5678/api/test
curl -i http://127.0.0.1:5678/api/remote_files/download/1
journalctl -u receiver.service -f

---

额外补充

除了主 Gin HTTP 服务，我在二进制里还看到了 另一个本地 HTTP 子服务迹象，形如：

• http://127.0.0.1:%d/alioth/%s/%s
• http://127.0.0.1:%d/alioth/%s/%s/inject

这个更像某个子模块动态拉起来的 本地回环 HTTP 服务，端口是动态的，而且默认走 127.0.0.1。
它不是主入口，主入口还是 5678 这个 Gin 服务。

如果你要，我下一步可以继续帮你把 /api/test 的请求/响应结构 也往下抠一层。