某物APP的newSign与X-Auth-Token逆向分析与实战破解

1. 逆向分析前的环境准备搞逆向分析的第一步永远是搭建好调试环境。这次我们用的测试机是Pixel 2系统版本Android 9目标APP版本v4.82.0。刚开始用Charles抓包时发现什么都抓不到这其实是APP启用了防抓包机制——具体来说就是设置了Proxy.NO_PROXY。这种情况我遇到过太多次了推荐使用Drony这款神器来绕过检测。Drony的配置其实很简单主要注意这几个参数代理模式选择指定应用目标应用选择我们要分析的APP代理服务器设置成Charles的监听地址一般是本机IP加8888端口记得开启VPN服务配置完成后APP的流量就会乖乖地流经Charles了。这里有个小技巧建议在Drony里把系统应用的流量过滤掉只保留目标APP的流量这样抓包界面会清爽很多。2. 绕过hook环境检测当我兴冲冲地准备上Frida开搞时发现一启动hook工具APP就直接闪退。这种情况明显是做了hook环境检测而且检测逻辑通常都藏在so文件里。经过一番排查果然在/data/app/com.xxx.xxx/lib/arm64目录下发现了可疑文件libmsaoaidsec.so。解决方法简单粗暴adb shell su cd /data/app/com.xxx.xxx/lib/arm64 rm libmsaoaidsec.so删除这个so文件后hook时APP就不再闪退了。不过要注意有些APP会校验so文件的完整性直接删除可能导致其他问题。还好这次目标APP没有做这种校验。说到Frida最近遇到个坑用最新版Frida时手机会卡死。后来在GitHub上看到有人提到这是新版Frida的兼容性问题回退到12.8.20版本就正常了。所以建议大家做逆向时不要盲目追新稳定才是王道。3. newSign生成机制分析通过jadx反编译后搜索newSign关键词发现有三处相关代码m89559a、m89559b和m89559c。这种命名风格一看就是混淆后的代码我们需要用Frida来确认哪个才是搜索接口真正使用的。hook测试后发现是m89559c这个函数在生成newSign。进一步分析其加密逻辑发现是AES和MD5的组合加密而且还调用了so文件里的native方法。考虑到so逆向的复杂性我建议采用RPC方式来获取加密参数。RPC服务搭建可以参考我之前写的教程核心代码大概长这样function getNewSign(params) { // 调用原生加密方法 var result m89559c(params); return result; } rpc.exports { newsign: getNewSign };测试时要注意比对RPC返回的newSign和实际抓包获取的是否一致确保我们的hook没有遗漏任何加密环节。4. X-Auth-Token获取方案X-Auth-Token的规律很明显由三段用点号连接的字符串组成典型的JWT格式。通过反编译定位到getJwtToken()方法确认这个token是由服务端下发的。抓包分析发现X-Auth-Token是通过这个接口获取的api/v1/app/message/client/v1这个token的有效期很长实测超过一个月都不会失效。获取方式也很简单清空APP数据后重新登录在Charles里过滤这个接口的response就能拿到新鲜的X-Auth-Token。这里有个细节要注意有些APP会在请求头里添加时间戳等防重放参数但目标APP的这个接口居然没有任何防护措施直接请求就能拿到token安全性确实有待提高。5. 完整请求示例把前面分析的成果整合起来一个完整的搜索请求应该包含这些参数GET /api/search HTTP/1.1 Host: xxx.com X-Auth-Token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.xxxxx.xxxx newSign: a1b2c3d4e5f6g7h8i9j0其中X-Auth-Token是长期有效的凭证newSign则是每次请求都需要重新计算的签名。实际测试时可以用Postman先固定X-Auth-Token然后通过RPC服务实时生成newSign。6. 安全防护建议虽然我们成功逆向出了加密逻辑但从安全角度来看目标APP的防护措施确实比较薄弱。给开发者几个改进建议对核心so文件做完整性校验为X-Auth-Token设置合理的过期时间在newSign生成时加入时间戳等动态参数对高频访问的接口增加人机验证逆向分析的过程中我发现很多安全问题都是由于开发者过度依赖客户端加密导致的。实际上客户端加密更多是防君子不防小人关键业务逻辑还是应该在服务端做充分校验。