裸聊邀请背后
一款 App 如何搬走通讯录、定位和110个媒体文件
从手机号与邀请码注册页出发，我们拆开一款 uni-app APK，在0号隔离设备锁定117条请求，再沿服务器配置找到关联管理端，最终确认“通讯录后台”功能页。
本文内容仅供学习参考，所述技术仅限用于合法授权的安全研究、教学演示及防御机制开发。请勿用于未经授权的访问、测试、数据获取或其他违法活动。读者应自行确保使用行为符合适用的法律法规，并承担因不当使用本内容产生的相应责任。
它以手机号和邀请码“注册/匹配”为入口。用户还没看到注册后的远程页面，客户端已经开始索要通讯录、短信、通话记录、相册、位置和应用列表权限。
| 24Manifest 权限 | 117/117目标 UID 请求 | 110媒体文件上传 |
一、它究竟是什么：先把“裸聊”与已证事实分开
案件线索把它指向裸聊/交友引流场景，但取证不能拿场景标签代替制品事实。样本真实页面使用情感化视觉包装，要求填写手机号与邀请码；此前的权限说明则把通讯录采集解释成“通讯录管理服务”，并声称数据不会泄露给第三方。动态流量后来证明，至少受控联系人确实被发往外部接收端，这与页面承诺直接冲突。
因此，分析从一份确定的 APK 开始。原始样本为36,429,836字节，完整 MD5 和 SHA256 复算一致，以下称为“案例样本 A”。
这一步还解决了一个很容易被忽略的问题：应用显示名中夹有不可见 Unicode 字符，包名也呈随机化。所以不能用桌面图标或肉眼看到的应用名作为证据主键，必须回到 APK 字节、签名和安装包身份。
二、拆掉 uni-app 外壳，找到真正干活的脚本
这次静态分析的第一个关键转折，是没有沿着随机包名下的 Java 类一直追下去。首先从 Manifest 读取入口，主 Activity 指向 io.dcloud.PandoraEntry，这是 DCloud 容器的典型入口，而不是一个常规原生 App 的自定义 Activity。
从入口继续向资源层追
单独看到 PandoraEntry 还不够。接着检查 APK 资源树，可以看到 assets/apps/__UNI__…/www/ 结构，同时在 arm64-v8a、armeabi-v7a 和 x86 三个 ABI 目录下看到 Weex 运行库。这三类证据放在一起，才能把技术栈稳定识别为 DCloud/uni-app 混合应用。
io.dcloud.PandoraEntry | ||
assets/apps/__UNI__…/www/ | ||
页面路由、权限申请、通讯录读取、上传接口和远程跳转逻辑，最终都定位在：
resources/assets/apps/__UNI__…/www/app-service.js
在压缩 JS 里建立业务地图
app-service.js 是一个近48万字节的打包脚本。处理这种文件时，不是从第一个字符开始逐行阅读，而是先建立稳定锚点：基础 URL、/Uploads/ 路径、plus.contacts、PackageManager、MediaStore、plus.geolocation、plus.uploader 和 redirect_urls。再以这些锚点向前后扩展，恢复调用者、参数组装、失败分支和上下游顺序。
上传契约在脚本里是集中定义的。以下将该服务器称为“接收端 A”，并保留业务路径：
通讯录 /Uploads/api
设备资料/Uploads/apiimei
应用列表/Uploads/apiapps
位置/Uploads/apimap
媒体/Uploads/upload
短信/Uploads/apisms
通话记录/Uploads/apicalllog
这意味着必须将两层代码分开：DCloud、Weex 与 Android bridge 是公共框架层；app-service.js 是随样本分发的业务实现。公共库里出现某个高危 API，不等于样本实际启用了该能力。
反向检查“是否还藏有第二阶段代码”
APK 内部确实存在 DCloud 容器用的 DEX、DAT 和 PathClassLoader 信号。但这些信号继续向下追时，只闭合到 Weex/DCloud 公共加载实现；没有取得独立下载载荷字节、业务入口或运行时的新 ClassLoader 事件。因此本轮结论是“无需额外脱壳”，而不是“因为没找到所以它不存在”。
app-service.js。三、在0号机只盯住它：谁发出的每一条请求
一份整机 PCAP 中可能同时存在系统服务、SDK、其他 App 和目标样本的通信。所以，0xSec笔记本apk分析平台 不把“抓包期间看到了”直接写成“由样本发出”。
运行前先准备可识别的受控数据
如果设备里只有真实联系人、真实照片和系统原有数据，即使抓到一个很像联系人的字段，也很难将它与这次可控操作精确绑定。所以运行前先准备只用于实验的唯一标识。
这些数据都在动态运行结束后精确清理，以下使用 C-001 等实验编号指代。
0号机上的唯一 UID 投影
样本安装到0号隔离设备后，先从 PackageManager 取得该包的 Linux UID，再反查该 UID 对应的包列表。只有当列表中只有目标包时，清单状态才写为 isolated_unique_uid。本轮通过了该检查。
抓包时同时保留两个层次：第一层是整机原始 capture.pcap，用于保存完整现场；第二层是 target_app.pcap，它并不是另一次抓包，而是从同一原始现场中确定性重建的样本投影。
出站报文由 UID owner 标记。对每一条已确认的目标出站流，再从同一抓包时间窗中按协议、本地地址与端口、远端地址与端口补入对应入站响应。这样既不会只留下请求丢掉响应，也不会把未归属的整机通信全部算给目标 App。
本轮保留的整机原始抓包为20,337,760字节，目标 UID 抓包为19,167,714字节。两份文件的完整 SHA256 均已记录在封存清单中。目标 UID 只对应该样本包，117/117个 HTTP 请求均进入样本归属统计。
四、用户点击“同意”之后，窃取链怎样启动
逐包列表适合复核，却看不出用户经历了什么。0xSec笔记本apk分析平台 根据请求方法、Host、路径、字段结构和文件类型，将目标 PCAP 重组为业务视图，再与页面代码对齐，恢复从权限诱导到批量上传的先后关系。
从启动页到上传器的实际编排
代码与动态记录结合后，可以把完整顺序恢复为六个节点：
- DCloud 容器启动。
PandoraEntry加载 uni-app 首页，展示权限说明。 - 先取远程配置。
客户端请求 /api/config/getAppConfig，将返回的 UI、权限开关、强制授权策略和跳转列表合并到本地配置。 - 请求隐私权限。
通讯录默认为开启且强制；拒绝后应用直接退出。也就是说，联系人不是一个可有可无的附加权限，而是进入后续流程的门槛。客户端随后根据配置请求短信、通话记录、位置和媒体权限。 - 登记手机号和邀请码。
表单通过后，两个值被写入 uni storage，后续多种载荷都使用它们做关联字段。 - 先上传设备和通讯录，再并发其余链路。
通讯录上传失败会阻断后续数据流程；成功后继续应用列表、位置、媒体等任务。 - 注册后跳入远程 WebView。
服务器可以通过 redirect_urls替换后续页面，但本轮正式动态制品没有封存最终被选中的 URL。
总计得到117个 HTTP 请求、114个 POST、116个可配对响应，且这116个响应均为2xx。请求体声明合计17,677,966字节。
请求数与响应数差1，原因不是统计错误：getModelMap 发出了2次 GET，只有1次在本轮抓包中取得可配对响应。0xSec笔记本apk分析平台 保留这个差值，没有为了让数字“好看”而补造第117个响应。
精确到请求路径的业务投影
GET /api/config/getAppConfig | |||
GET //api/config/getModelMap | |||
POST //api/Uploads/apiimei | |||
POST //api/Uploads/api | |||
POST //api/Uploads/apiapps | |||
POST //api/Uploads/apimap | |||
POST //api/Uploads/upload |
110份媒体内容包括109个 JPEG 和1个 PNG。这能证明110笔媒体上传和110次2xx响应，但不能把某一笔未经唯一标记的报文断言为指定测试图片。
五、先锁死通讯录：它读了什么、发给谁、服务器怎么回
受控联系人是本轮最强的动态证据。它并非仅仅出现在手机界面或应用日志中，而是逐字出现在目标 UID 专属 PCAP 的 HTTP 请求正文里。
先用代码还原字段如何组装
通讯录链通过 plus.contacts.getAddressBook() 读取电话簿，保留 displayName 和 phoneNumbers，最多处理2000个联系人。对于每条记录，代码优先选择移动电话类型，如果没有再退化为第一个非空号码。
上传前，姓名和号码中可能破坏分隔符的字符会先被替换，再与登记手机号、邀请码、设备厂商/型号拼成一条表单值。字段关系如下：
手机号**邀请码**设备信息=联系人姓名|联系人号码上传器会过滤已上传的记录，根据当前策略把并发数限制在5到25之间，并对失败项留下重试状态。这说明它不是一次性把电话簿“打包看看”，而是按记录维护一条可继续的上传流程。
再用动态时间线把它锁定到目标进程
app-service.js 编码 → 目标唯一 UID 请求 → 接收端 A → 服务端应用层返回“处理1条”受控联系人标识出现在目标抓包第273帧的请求正文。 第275帧为对应的 HTTP 200 响应。 响应正文回显了受控联系人内容，并表示处理了1条记录。
这里有三层不同的证据：第一层是请求的网络五元组和 Host；第二层是目标 UID 归属；第三层是请求正文里的唯一受控标识以及服务器逐字回显。如果只有任意一层，结论都会弱很多。
比如，只看到 HTTP 200，只能说明服务器返回了成功状态码；这次之所以可以进一步写成“应用层已解析并处理该联系人”，是因为响应正文同时回显了受控内容和处理数量。
设备资料、应用列表和定位也各自取得1次请求和1次2xx响应，但这三类载荷没有像联系人一样的唯一受控标记，因此证据强度需要分级表达。
六、从手机号到相册：更多数据被怎样组织和上传
联系人是证据强度最高的一条，但不是本轮唯一发生的业务行为。其他数据类别要分别从“代码如何读”、“载荷如何组”、“目标 PCAP 里是否真正出现”三层复原。
6.1 设备资料：不只是一个手机型号
设备链会读取 UUID、device_id、厂商、品牌、型号、Android 版本、应用版本、系统语言等字段，再与用户填写的手机号和邀请码合并。代码还会累积权限失败状态，使接收端不仅知道设备身份，还能看到哪些权限没有成功。
plus.device / Android 系统字段 → 合并手机号、邀请码和权限状态 → //api/Uploads/apiimei → 1次2xx动态请求中可以看到这些类别的明文字段，但本轮没有为设备资料设置独立唯一标识。因此报告确认“设备资料上传请求和响应已发生”，但不把每个字段升格为像 C-001 联系人那样的受控闭环。
6.2 应用列表：从 PackageManager 到目标画像
应用列表链调用 PackageManager.getInstalledPackages(0)，从安装包记录中提取包名、应用名、版本和安装时间。它会过滤部分系统应用，并为命中银行类特征的记录生成 is_bank 标记。
PackageManager → 包名/标签/版本/安装时间 → 过滤系统应用并生成 is_bank → //api/Uploads/apiapps → 1次2xx这类数据可以用来判断设备上是否安装金融、社交或其他特定应用，进而对用户做进一步筛选。本轮目标 PCAP 中实测到1个应用列表请求和1个2xx响应。
6.3 定位：经纬度与登记身份被放在同一条记录
定位链从 Location.coords 取得经度、纬度和精度。真正送出时，核心字段被序列化为“手机号、邀请码、经度、纬度”，也就是说坐标不是匿名遥测，而是与登记身份直接关联。
plus.geolocation / Location.coords → 手机号,邀请码,经度,纬度 → //api/Uploads/apimap → 1次2xx动态上已确认该路径出现1个请求和1个2xx响应，但由于没有为位置设置独立受控坐标，证据等级仍低于联系人逐字命中。
6.4 媒体：从 MediaStore 到110次 multipart POST
媒体链先检查远程存储开关和 Android 媒体权限，再查询 MediaStore.Images，提取路径、显示名、文件大小和修改时间。上传前会根据文件大小和格式处理图片，然后由 plus.uploader 构造 multipart/form-data 请求。
每笔请求中，sjh 字段关联登记手机号，file 字段承载实际图片或视频内容。这次抓包里看到的是：
因此文章可以写“已证实110份媒体内容被作为文件上传，并获得110次2xx响应”；但不写“我们已证实第几包就是那张受控 PNG”。
6.5 短信与通话记录：代码可达，但本轮不写成已发生
短信链会查询 content://sms/ 中的号码、联系人、正文、时间和收发类型，上限为5000条；通话记录链查询 CallLog.Calls 的号码、姓名、呼入/呼出、日期和时长，上限为3000条。对应接口分别为 /Uploads/apisms 和 /Uploads/apicalllog。
6.6 为什么主类型是数据外传，而不是 RAT
样本的远程配置能改变权限开关、界面和 WebView 跳转，但这与远程控制木马所需的命令通道不是一回事。静态与动态证据中没有形成“服务器下发设备动作命令—客户端执行—回传结果”的闭环。
Manifest 与样本自有业务脚本也没有闭合到无障碍服务、悬浮窗、设备管理员、开机持久化、VPN 服务、投屏控制或 WebSocket 命令接收链。JADX 搜索中的部分同名 API 来自 DCloud、Weex、AndroidX 或权限工具公共层，没有连到本样本业务数据结果。
七、配置里出现另一扇门：从数据接收端到关联管理平台
接收端 A 的角色已经由业务脚本中的基础地址、目标 UID 抓包中的 Host、多类上传请求以及服务端响应交叉确认。它是本案已确认的 APK 数据接收/API 端。
接收端下发的配置中，协议页地址直接指向管理平台 B。这是继续研判的直接起点，而不是仅凭域名相似进行猜测。
7.1 最初的枢纽是一份实时配置
目标客户端启动后向接收端 A 请求 /api/config/getAppConfig。返回 JSON 不只包含颜色和背景图，还包含权限开关、是否强制、登录文案、跳转 URL 和协议页地址。正是这份由已确认接收端亲自下发的配置，首次直接出现了管理平台 B 的协议页 URL。
agreement_url 指向管理平台 B → 再对已知公开页面做只读核验这条链的证据强度高于“两个域名看起来很像”，因为起点是 APK 已确认接收端的实时响应。同一配置还给出了对象存储中的管理目录结构。
7.2 配对 API 验证了系统结构，也暴露了多租户边界
两套配置共有41项顶层业务字段，权限配置11/11对应，UI设置34/34对应。但另一套配置呈现的是不同租户外观，不能与本样本当前租户混用。
被动证书透明度记录补出了与管理平台 B 配对的 API 子域。对已知配置路径的一次只读访问返回了同类 JSON，两份配置在业务字段、权限和 UI 结构上高度一致，也指向同一管理协议页。
但配对 API 展示的品牌外观与案例样本 A 不同。这反而提供了一个重要信号：它更像是一套可供多个租户使用的“云通讯录系统”，而不是一个只有单一品牌的固定站点。因此，不能把另一租户的名称、图片或数据并入本案样本。
7.3 页面同构只是辅助线索
接收端 A、管理平台 B 及配对 API 根页使用了高度一致的系统封面和内嵌字符串。这些字符串可以成为后续调证线索，却不能未经平台账户、域名注册或服务器日志核验，就直接对应到现实身份。
7.4 0xSec笔记本apk分析平台 的“同源 & 发散”如何把线索收拢成后台候选
找到管理端不是把域名交给 AI 猜一个 /admin。0xSec笔记本apk分析平台 先把样本静态分析、动态流量和 Web 侧事实绑定到同一个目标，再分层收集能够复核的信号。
界面把结果明确分成两条线：“同源扩展”要求命中工程 ID、专属接口组合、favicon 或资源哈希等代码身份指纹；“信息收集”才容纳证书、同 IP、CDN 和旁站等较弱关联。共享 nginx、Laravel 或同一 CDN 只够生成待核线索，不能据此认定同一运营者。
八、从会话门禁到已登录功能页：后台里看到了什么
沿配置继续追查后，目标不是“闯进后台”，而是判断关联管理平台是否真的存在后台入口，并在已有合法授权下核对登录后的页面。这里先更正一个常见误判：路径能打开、返回200，不等于它就是登录页。新会话直接访问常规登录路径时，返回的是没有任何表单和输入框的系统封面。这个响应大小为15,992字节，只能证明路由被服务器接管。
8.1 用两个独立会话确认稳定入口
在明确授权的有限、限速路径存在性核验中，/test 返回了一个由服务器临时生成的跳转。为了排除偶发缓存或一次性页面，核验使用两个完全独立的新会话重复进行。
/test → 服务器下发一次性入口参数 → 建立临时会话 → 回到常规登录路径 → 展示“通讯录后台”两次临时参数不同，这证明它们不是固定入口；应当记录的稳定路径是 /test，而不是任何一次临时 URL。
8.2 登录页是如何被确认的
两个独立会话最终获得的页面都是58,514字节，标题同为“通讯录后台”。页面包含1个 POST 表单与4个输入字段：用户名、密码、验证码和一次性 CSRF 字段。
两份页面的原始 SHA256 不同，如果在这里停止，可能会误以为后端每次下发了不同页面。逐行差分后发现，两份文档只有 CSRF 隐藏字段所在行不同；将该值替换为固定占位符后，两份页面逐字节相同。这才能把页面差异稳定解释为动态 CSRF，而不是两个不同后台。
两次最终页面大小均为58,514字节。 页面标题为“通讯录后台”。 页面包含用户名、密码、验证码和 CSRF 字段。 两次页面归一化后完全一致，差异仅来自一次性字段。
8.3 一不小心登录上了后台管理界面
后续验证时，我们成功登录并进入了用户/设备管理表格，而不再是公开登录页。页面列出了“设备信息、数据统计、位置信息、重要联系人、已安装 App、数据查看、功能选择、功能操作”等栏目。
每条记录右侧提供通讯录、短信、相册/视频、通话记录和剪贴板等数据查看入口；同一界面还出现短信群发、注入木马、上传视频、扫描群码、绑定二维码、删除用户和导出数据等按钮。
8.4 新证据把结论推进到了哪里
/test | |
现在可以确认的不只是登录界面，而是登录后的关联后台功能结构；要把案例样本 A 的上传数据与某条后台记录一一对应，仍需受控标识检索结果、服务端日志或数据库证据。
真正值得警惕的，是一次“同意”之后发生的一切
这款 App 没有用什么神秘技术“瞬间搬空手机”。它做的事更简单，也更现实：用裸聊邀请把人引到页面前，再将手机号、邀请码和一连串权限请求包装成必经步骤。当用户按下“同意”，联系人、设备资料、应用列表、定位和相册内容便开始被分类、组装和发送。
我们之所以能看清这个过程，不是因为某一段代码“看起来可疑”，而是因为每一步都找到了对应物：uni-app 业务脚本说明它准备读什么，0号机上的目标 UID 证明请求属于谁，载荷显示它实际带走了什么，服务器响应则表明对端确实收到并处理了请求。117次请求与110次媒体上传，就这样从一组数字变成了可复核的数据外传链。
调查还顺着接收端下发的配置继续向后走，最终找到关联管理平台，经过会话门禁与登录页验证后，进入了真实的用户/设备管理界面。页面上的通讯录、定位、已安装 App、相册/视频与数据导出入口，也让前面的上传行为拥有了一个可见的服务端对应面。
一次权限点击只需几秒，但它可能交出的，是一个人的社交关系、行动轨迹、手机环境和私密影像。面对这类 App，最重要的不是它在页面上承诺了什么，而是它在权限获取后真正做了什么。。 📢 免责声明
本文内容仅供学习参考，所述技术仅限用于合法授权的安全研究、教学演示及防御机制开发。请勿用于未经授权的访问、测试、数据获取或其他违法活动。读者应自行确保使用行为符合适用的法律法规，并承担因不当使用本内容产生的相应责任。