一种从桌面软件提取内部数据的渐进式工作思路

一种从桌面软件提取内部数据的渐进式工作思路一、问题的起点我是赛尔号玩家精灵收集党。手头有一款叫XM Seer 脱机日常的辅助软件里面有个扩展中心存了近 700 个精灵收集脚本。我的需求很简单把这 700 个脚本的名称批量导出来和我自己已有的精灵图鉴做匹配看看哪些精灵有脚本但还没收集省得一个一个点进去看。但这个软件没有提供任何批量导出功能。于是问题变成了一个技术问题如何从一个不提供导出功能的桌面软件中提取出内部数据二、一种工作思路面对软件内有数据但不提供导出的情况常见的直觉反应是破解它、反编译它、读它的加密文件。但更高效的做法是按投入产出比排序从最简单的路径开始尝试开始 ↓ 第一步文件系统 看看数据是不是以普通文件存着 ↓ 不是加密了 ↓ 第二步反编译可选—— 试一下能不能解开不行就放弃 ↓ 解不开 ↓ 进入侦察阶段 —— 目的是找到 API ├─ 方式A内存 Dump → 搜 http/api/token └─ 方式B网络抓包 → 看发了什么请求 ↓ 找到了 ↓ 第四步直接调 API → 拿到数据这个顺序的核心逻辑是每前进一步技术难度递增但每一步都可能直接解决问题。多数场景下不需要走完四步在第二或第三步就能找到突破口。网络抓包和内存 Dump 是并列的两种侦察手段目的相同——找到 API 地址和调用方式哪个顺手用哪个。以下用赛尔号辅助软件的数据提取过程演示这套思路的落地方式。三、实践过程第一步文件系统分析首先检查软件的安装目录结构了解数据存储方式。D:\赛尔号相关\XM 脱机日常\ ├── XM Seer脱机日常 ver 2.4.5.exe ← 主程序加壳 ├── XMUnityFs.dll ← Unity文件系统库 ├── ini/ │ ├── data/document_center/ ← 扩展中心数据目录 │ │ ├── document.xy315KB ← 核心数据文件加密 │ │ ├── author.xy ← 作者信息加密 │ │ └── config.ini ← MD5校验 时间戳 │ ├── data/*.xy ← 游戏数据均加密 │ └── magic/ ← 本地脚本仅20~30个.xmgic文件发现本地脚本文件仅 20~30 个远不足 700 条——说明大部分数据不在本地文件系统中存在document_center目录内含一个 315KB 的加密文件document.xy应是扩展中心的数据缓存所有.xy文件采用自定义加密格式无法直接读取结论文件系统路径到此为止数据虽在本地但被加密封锁。第二步反编译尝试对主程序和核心 DLL 进行初步分析目标结果原因EXE 解包失败VMProtect 类加壳非标准 UPXXMUnityFs.dll 反编译失败.NET Native AOT 编译无传统 IL 代码.xy 加密格式分析失败无固定魔数算法不明反编译遇到硬壳时不建议死磕。软件的安全防护往往存在木桶效应——磁盘加密做得严密但运行时和网络层面可能是短板。第三步进程内存 Dump核心思路转变数据在磁盘上加密但运行时必须在内存中解密。与其正面破解加密算法不如直接从运行时的内存中提取关键信息。Dump转储的操作方式极为简单任务管理器 → 定位进程 → 右键 → 创建转储文件不需要管理员权限不需要额外工具。操作后得到一个 401MB 的.dmp文件这是进程完整内存的快照。关于 Dump 的几个要点Dump 的本质是观察式侦察——不修改目标进程仅复制其内存状态信噪比极低——401MB 的数据中系统 DLL 路径、输入法缓存等噪声占 99% 以上有效信息往往不足 1KB关键信息在内存中为明文——加密数据被程序解密后会在内存中以明文存在字符串形式的 URL、Token、API Key 尤其容易被定位从 Dump 中提取的关键信息信息内容API 服务器地址http://xxx.xxx.xxx.xx:18888接口端点/WebApi/RunJs/函数名认证 TokenDVL4KxxxxxxxxxxxxxxxxxHTTP 请求示例GET /WebApi/RunJs/获取扩展中心信息MD5?Token...Token 是软件内置的共享 API 密钥硬编码在二进制文件中运行时解密到内存。非用户个人账号凭证。有了 API 地址、Token、请求格式三项信息加密的document.xy文件不再构成障碍。第四步直接调用 API使用 Python 标准库发送 HTTP GET 请求importurllib.request urlhttp://xxx.xxx.xxx.xx:18888/WebApi/RunJs/获取扩展中心信息?TokenDVL4KS...requrllib.request.Request(url)withurllib.request.urlopen(req)asresp:dataresp.read()服务器返回的数据采用三层嵌套编码Base64 → Gzip → JSON解码后获得689 条完整数据每条包含以下字段Id编号Name脚本名称Author作者Type类型数字代码需映射为中文分类Des描述CreatedTime创建时间Url_1/Url_2下载链接及密码整个过程仅使用 Python 标准库urllibbase64gzipjson无需第三方依赖。最终编写为可复用脚本xm_extension_center.py后续可直接拉取最新数据并输出为 CSV。补充另一种侦察手段——网络抓包除了内存 Dump网络抓包同样可以找到 API在本案例中未使用但值得了解。操作方式打开抓包工具如 Fiddler、Charles配置代理启动目标软件操作目标功能如打开扩展中心在抓包工具的请求列表中按域名、关键词等搜索相关的 API 请求优点直接看到完整的请求 URL、请求头和返回值不需要分析二进制数据。缺点如果软件使用 HTTPS 证书锁定或不走系统代理则无法生效。四、总结核心收获Dump 是一个被低估的便捷手段——使用任务管理器即可完成门槛远低于反编译。虽不万能但从内存中寻找网络通信参数是极为高效的用法渐进式探索优于正面强攻——遇到软件有数据但不导出的问题按从易到难的顺序逐级尝试每一步结束后判断当前路径能否解决问题不能则推进到下一步磁盘加密 ≠ 运行时安全——加密仅保护静态存储状态不保护运行时解密后的内存状态和网络通信状态两种侦察手段对比Dump vs 网络抓包对比维度内存 Dump网络抓包操作工具任务管理器右键→创建转储文件Fiddler / Charles / Wireshark安装要求无需安装系统自带需下载安装第三方工具上手难度低点几下就行中需要配置代理和证书适用网络协议不限仅 HTTP/HTTPS走系统代理的HTTPS 证书锁定不受影响抓不到自定义 TCP 协议不受影响但需会读二进制抓不到数据分析量大数百 MB需大海捞针搜关键词小直接看到请求列表看到的东西字符串片段需脑补上下文完整 URL、参数、请求头、返回值对软件的影响无只读不写可能被软件检测到代理选型建议不确定软件走不走系统代理 → 用 Dump更稳确定软件走 HTTP 且能抓到包 → 用抓包更直观两者本质上是互补的——一个不行换另一个方法的通用性本次实践中实际经历的路径是1 → 2(死路) → 3 → 4但如果从第二步直接跳转到网络抓包分析可能跳过了 Dump 环节。这正是渐进式的意义——每步都可能提前收工但即便走到底难度也远低于直接反编译。这套框架适用于多数桌面软件的数据提取场景原因在于加密存储防直接读取文件但不防运行时内存分析代码混淆防静态逆向但不防网络通信监听验证机制防未授权调用但 Token 在内存中为明文服务器 API一旦接口地址和参数被获取任何人都可以调用四步都不奏效的可能性理论上每步都有对应的反制手段步骤可能的反制复杂度文件系统加密文件存储低常见反编译加壳VMProtect、Native AOT 编译中常见内存 DumpAnti-Dump、Token 分段存储、进程保护高少见网络抓包HTTPS 证书锁定、自定义 TCP 协议高少见直接调 API请求签名 nonce、设备指纹、短时效 Token 验证码高少见四层全部做全的软件在实践中极为少见主要出现在以下场景银行客户端、支付类应用企业级 VPN 和远程办公软件游戏反外挂系统Vanguard、EAC 等高价值数字内容保护DRM对于大多数桌面软件来说开发者不会投入这个成本——把四层保护做全的开发成本往往远高于软件本身的价值。这套四步法在大多数实际场景下都能走通不是因为无懈可击而是因为全面防守不划算。