夜雨聆风
序
朋友给我发来一个安装包，说是一家"科技公司"发来的面试前测评软件。
我习惯性地扫了一眼包名：com.gyhSQuhRgSJw.wiEHPrCGpv。
应用图标是一个🏐。
"这公司还挺有意思，面试软件用个排球当图标。"朋友在电话那头说。
我没说话。
一个正经的办公软件，包名是随机字符组合，图标用emoji，下载链接来自邮件而非应用商店——这三个特征放在一起，让我默默打开了模拟器。
FIRST：初探
安装过程并不顺利。
下载资源中途断了两次，手机系统弹出"无法验证应用"的安全提示。我让朋友用备用且没绑银行卡的手机装上了。
打开App，是一套简陋的聊天界面。登录模块、调用的服务器地址……一切看起来普普通通。
但当我把它拖进反编译工具时，眉头开始皱了。
第一个疑点：硬编码的密钥
在代码里翻了一会儿，我找到了一段固定的字符串：
9ae05717这是一个 DES 加密密钥，被直接写死在代码里。
DES 是一种对称加密算法，密钥直接硬编码在客户端，意味着任何逆向工程师都能拿到它——然后解密App和服务器之间所有的通讯内容。
正常商业App早就不这么干了。正规厂商会用服务端的非对称加密，或者把密钥放在系统级安全凭据区，绝不会直接写在代码里。
这个做法，像是在说："我不怕被人看。"
SECOND：顺着线路摸下去
我截获了App运行时的网络请求。
它会向以下地址发包：
154.206.xxx.1:30063154.206.xxx.2:30063154.206.xxx.3:30063...（总计30条）154.206.xxx.30:30063
30个IP地址，同一端口，同一时间段响应。
这不是正常的"办公服务器"。正常企业不会有30台"备份服务器"专门跑一个内部办公App。
而且这些IP的归属地，全在境外。
备用生命线
主线路池之外，还有更多"取线地址"：
http://063.h.dvhrdt.cnhttp://063.dbh70.cnhttp://120.27.19.158:5566/?action=get&port=1https://api.sdmurv.cn/api/nodeshttps://mp-xinian.oss-cn-hangzhou.aliyuncs.com/oss/nodes.json
注意到那个阿里云OSS的地址了吗？
一个"企业内部办公软件"，把节点列表存在阿里云对象存储上，域名是xinian（听起来像某个年份或纪念日）。
这是典型的动态配置手法——开发者把服务器地址放在云端，App启动时实时读取，随时可以更换，而不需要更新App本身。
换句话说：如果这条线路被封了，他们可以在几个小时内切到另一条。
THIRD：模块清单
我深入看了代码结构和调用关系，整理出了一份简化版的业务模块清单：
| 模块 | 功能描述 |
|---|---|
| 登录认证 | 处理用户账号密码 |
| 短信服务 | 接收/发送短信验证码 |
| 实名认证 | 上传身份证信息 |
| 钱包 | 账户余额管理 |
| 充值 | 资金转入 |
| 提现 | 资金转出 |
| 红包 | 红包收发 |
这不是一个"数据测评软件"该有的模块。
这是一个完整的支付系统。
FOURTH：那些被忽视的信号
回过头看，这个App的设计，处处都是破绽。
第一，下载渠道。
任何一款正规公司的办公软件，都可以在华为应用市场、小米应用商店、App Store里找到。而这个App，只能通过邮件里的链接安装——因为应用商店不允许它上架。
第二，图标和包名。
🏐 emoji图标 + 无意义包名。这在个人开发者和灰产圈子里非常常见，正规企业绝不会这么做。
第三，网络通讯。
30条境外IP线路、动态下发的服务器配置、硬编码的加密密钥……这套架构的设计目的只有一个：让分析变得困难，让追踪变得几乎不可能。
第四，业务边界。
一个所谓的"测评工具"，拥有独立的支付、充值、提现模块——这个设计，从一开始就不是为了帮你找数据，它的目标是另一个方向。
尾声
我把分析报告发给了朋友，他沉默了许久，再后来朋友删掉了那个App，退掉了那个群。
他后来说，群里当时有五十多个人在"做任务"，现在想想，可能大部分都是同一个剧本里的角色。
而那个App，连同它背后的那一整套精密的线路架构，依然在某个地方运行着——也许换了名字，也许换了图标，也许正在以另一种"面试邀请"的形式，出现在另一个人的手机里。
本事件纯属虚构，如有雷同纯属巧合。
