WorkBuddy + REA 逆向框架：从一个不给导出的 App 里拿回 936 条打卡记录
内容提要
作者需导出打卡App中两年半的936条记录，但App仅提供云备份、不支持导出。他借助AI助手WorkBuddy配合REA逆向框架：反编译发现App被加固，但资源文件暴露了数据结构；抓包因证书绑定失败；最终在可root的模拟器中登录账号，只执行“一键恢复”而不点“一键备份”，成功取出zlib压缩的JSON数据文件，并导出为Markdown、CSV和JSON。作者指出加固并非最大障碍，证书绑定才是，且最大风险是误点备份覆盖云端唯一数据。
延伸解读
加固与证书绑定：真正的门槛不同
文章指出，App 虽被腾讯乐固加固，但资源文件仍暴露了数据结构，静态分析并非完全无效。真正封死抓包路径的是证书绑定：服务器只认 APK 内打包的自签证书，即使安装系统证书也无法绕过。这提醒读者，评估逆向可行性时，应优先确认证书绑定和 targetSdk 等网络配置，而非只关注代码加固。
模拟器恢复：可行但需警惕覆盖风险
在无法抓包、本地无权限的情况下，作者选择在可 root 的模拟器中登录账号并执行“一键恢复”，将云端备份拉取到模拟器私有目录，再直接提取数据文件。关键风险在于：模拟器初始为空，若误点“一键备份”会用空数据覆盖云端唯一真实备份。因此操作时必须只恢复、不备份，并立即验证文件时间戳与云端一致。
数据格式朴素：zlib 压缩的 JSON
取回的主数据文件 signin.dat 仅 6.6KB，解压后为 64KB 的 JSON，字段包括打卡记录、计时、待办和版本号，未使用 SQLCipher 或 AES 加密。这说明许多小厂 App 的本地存储并不复杂，逆向时不必预设高强度加密。但备份仅含文字，打卡配图未上传，依赖云备份保存图片并不可靠。
导出路径的优先级判断
作者根据实践给出判断顺序：先查 allowBackup 是否为 true，再找 App 内是否有导出/分享功能，其次考虑云备份配合模拟器恢复，最后才尝试抓包。抓包前需确认 targetSdk、network_security_config 和证书绑定三项条件。若手机已 root，可直接 adb pull 私有目录文件。这一顺序有助于减少无效试错。
Q&A
为什么这个打卡App不能直接导出数据？
该App只提供“云备份与恢复”功能，数据存储在服务器上，用户可以恢复但无法导出。同时，App的allowBackup属性为false，且未声明debuggable，因此无法通过adb backup或直接读取本地文件的方式获取数据。
抓包为什么失败？证书绑定是怎么回事？
抓包失败是因为App做了证书绑定：服务器返回的证书就是APK内assets/srca.crt中打包的自签证书，App只信任这一张证书，不认系统证书链。即使将证书安装到系统证书区（需root），也无法绕过，因为App只认包里写死的那张。
最终用什么方法拿到了打卡数据？具体步骤是什么？
最终在可root的Android模拟器（Android 11 arm64）中安装App，登录账号，只点击“一键恢复”将云端备份恢复到模拟器，然后通过adb pull提取/data/data/<包名>/files/signin.dat文件。该文件是zlib压缩的JSON，解压后即可得到全部数据。
操作过程中最大的风险是什么？如何避免？
最大风险是在模拟器中误点“一键备份”，用空数据覆盖云端唯一一份真实备份。避免方法是只点“一键恢复”，绝不点“一键备份”，并在恢复后立即验证文件时间戳与云端备份时间一致。
导出的数据包含哪些内容？有什么意外发现？
共导出936条打卡记录，涵盖5个打卡项、79条带文字备注，时间跨度2024年5月至2026年10月。意外发现：计时和待办模块为空（因未使用）；打卡配图不在备份中，云备份只传文字不传图片。
AI助手WorkBuddy在逆向过程中扮演了什么角色？
WorkBuddy负责实际动手操作：安装环境、反编译、判断下一步、执行命令（如换便携版JDK、比对证书指纹、启动模拟器等），并能自主发现路走不通后切换方案。作者仅负责选择和验收，但AI也有判断错误的时候（如误读allowBackup属性层级）。
如果我想导出自己App的数据，应该按什么顺序尝试？
建议顺序：1. 检查allowBackup是否为true，是则尝试adb backup；2. 查看App是否有自带“导出/分享”功能；3. 若有“云备份”，优先用模拟器+恢复方案；4. 以上都不行再考虑抓包，并先确认targetSdk、network_security_config和证书绑定；5. 手机有root则直接adb pull。
