学而思网校客户端 · 网络行为被动观测报告

四个最关键的发现

1. 客户端用阿里云 HTTPDNS 做域名解析（203.107.1.1:443 / 203.107.1.34:443）。这意味着走 UDP 53 端口的常规 DNS 观测基本拿不到有效信息——域名解析被封装在 HTTPS 里。这是本阶段最重要的技术判断，直接决定了后续观测手段的选择。
2. 客户端是"多进程 + 多 RTC 引擎并存"架构：主进程 pcs_literacy.exe 拉起界面进程与 6 类子进程；音视频层同时内置声网 Agora、火山引擎 VolcEngine、腾讯 TRTC、自研 OmniRtc 四套 RTC SDK，属于明显的多供应商冗余/灰度设计。
3. 存在主动环境检测组件（XesMonitor.exe、XesCheck.exe、AutoCheckTool.exe）。这类模块的典型职责就是检测代理、虚拟网卡、抓包工具与调试器。所以后续若进入主动阶段，很可能被识别。
4. 资源下发走明文 HTTP，且其中一条是长连接：http://liveclient.xesimg.com/student/resource_load/… 没有 TLS 保护；更值得注意的是 39.105.53.105:80 这条明文连接在 58 秒采样窗口内全程保持 Established，不是一次性下载。这是整条链路上唯一的明文环节。

2.1 目标标识

2.2 进程树与通信角色

本次共观测到 10 个常驻进程 + 5 个渲染子进程。注意：真正发起网络请求的是 pcs_literacy（引导/更新/登录）和 XesStudent_literacy（业务主链路），渲染进程本身不直接持有对外连接。

2.3 本机暴露面（安全姿态）

结论：TCP 服务全部绑定在回环地址，没有向局域网暴露监听端口，本地攻击面较小。

采样方式：每 3 秒抓取一次系统 TCP/UDP 连接表，过滤到该客户端的 10 个进程，共 20 轮、约 72 秒。下表按「远端 IP」聚合，"★"= 已通过独立域名解析精确命中归属，"○"= 归属待确认。

合计 23 个远端 IP。其中 7 项通过独立域名解析精确命中（★），可确定业务归属；其余为 CDN 节点或第二供应商通道，建议在主动阶段确认。

3.1 连接持续性判读（第二阶段试跑，覆盖 58 秒 / 14 轮采样）

把采样延长后，连接被明显分成两类，说明客户端在网络层是「长连接保活 + 短连接轮询」混合模型。

来源：客户端 Chromium 内核的 HTTP/2 服务记录（Network Persistent State）、历史库与 Cookie 库、资源清单 resource_cache_ex.ini、RTC 核心日志、以及 ConfigInfo.ini 等配置文件。已剔除前端代码里的属性名噪声（如 *.style.top）。

依据：客户端安装目录内的 SDK 动态库文件名 + 日志中出现的对应域名。这部分回答"它到底在跟谁说话"。

6.1 本次实际使用的四条取证路径

6.2 核心命令（可直接复用）

# 1) 锁定目标进程 PID
$procs = Get-Process | Where-Object { $_.Path -like '*Xes_Literacy_Client*' }
$pids  = @($procs | Select-Object -ExpandProperty Id)

# 2) 被动轮询连接（每 3 秒一次，过滤到目标 PID）
foreach($c in (Get-NetTCPConnection -ErrorAction SilentlyContinue)){
  if($pids -contains $c.OwningProcess){
    "$(Get-Date -Format HH:mm:ss) $($c.OwningProcess) $($c.RemoteAddress):$($c.RemotePort) $($c.State)"
  }
}
Get-NetUDPEndpoint | Where-Object { $pids -contains $_.OwningProcess }   # RTC 端口

# 3) 读取 Chromium 内核残留（域名最干净的来源）
Get-Content "$env:APPDATA\SharedProcess\QtWebEngine\xes\Network Persistent State" -Raw

# 4) 提取日志中的主机名（URL 上下文口径，避免前端属性名噪声）
$rx = [regex]'https?://([a-z0-9\-]{1,63}(?:\.[a-z0-9\-]{1,63}){1,5})'
#    遍历目标目录下文本文件，命中结果按频次聚合；注意剔除 *.style.top / *.offset.top 类噪声

# 5) 域名 → IP → 归属 关联
Resolve-DnsName api.xueersi.com -Type A        # 与实测 IP 求交集即可确定归属
curl -s -X POST http://ip-api.com/batch --data '[{"query":"39.174.179.5"}]'   # 归属查询

6.3 本阶段踩到的三个坑（供后续参考）

1. 系统 DNS 日志无效。客户端走阿里云 HTTPDNS，域名解析封装在 443 端口的 HTTPS 请求里，UDP 53 观测拿不到任何有效域名。
2. 不要用"裸域名正则"扫前端资源。首次扫描时 .top/.com 结尾的 JS 属性名（this.offset.top、t.style.top）产生了近 200 条假阳性。必须限定「URL 上下文」或「JSON 字段上下文」口径。
3. 本机当前的权限与工具条件：无管理员权限，且未安装 Wireshark / Fiddler / mitmproxy / Npcap，系统代理为关闭状态（ProxyEnable = 0）。因此本阶段只能到「连接级」，到不了「数据包级」。

如果要把观测推进到「数据包级 / 应用层」，需要面对三个现实约束：

约束一：必须提权，且要装驱动或使用内置抓包

• 系统内置的 pktmon（Win10 1809+）可直接按进程 PID 过滤抓包，无需安装任何软件，但必须管理员权限；
• netsh trace start 同样内置，也需管理员；
• Wireshark + Npcap 需安装内核驱动，本机目前未安装。

好消息：当前系统已有 pktmon.exe，只要提权即可直接进入包级观测，无需新增第三方组件。

约束二：TLS 解密这条路，这个客户端大概率走不通

约束三：客户端带主动环境检测，主动手段可能被观测到

建议的推进顺序

1. 先做"增强被动"（零风险）：把连接采样从 72 秒延长到完整一节课（≥45 分钟），覆盖"登录 → 进教室 → 上课 → 下课 → 交作业"全链路，即可拿到完整的服务端接口地图，且完全不触碰客户端。
2. 再做"包级被动"（需提权，但仍是只读）：用 pktmon 按 PID 抓包。不解密、不代理、不改包，只读 TLS 握手中的 SNI 字段与流量时序。这一步能把现在标为「○ 待确认」的 7 个 IP 全部对应到域名，且几乎无风险。
3. "应用层解密"暂不建议推进：收益有限（自带 CA bundle 会挡住）、风险明显（风控检测），且在继续之前需要先明确用途与授权边界。

本报告的全部结论来自本机（设备所有者本人）上运行软件的系统状态读取与本地文件取证，未对目标服务端发起任何请求、未进行流量篡改、未使用中间人代理、未绕过任何技术保护措施。所记录的域名与 IP 归属信息为公开可查的网络基础设施信息。

继续推进到主动阶段（抓包、代理、解密）时需注意：这可能触及该软件的用户协议与相关服务条款；请确保用途限于自有设备的网络安全自查、采购/集成评估、或经授权的技术对接，不要用于获取未授权内容、规避版权保护或干扰服务正常运行。