携程APP user-dun算法逆向实战：从混淆到还原的挑战与突破

1. 缘起从抓包到混淆代码的探索第一次接触携程APP的user-dun算法时我像大多数逆向工程师一样从最基础的抓包分析开始。通过Charles抓取网络请求很快就发现了这个神秘的62字节字符串。有趣的是这个字段在每次请求中都会变化但始终保持着相同的长度和格式特征。顺着Java层逆向追踪很快就定位到了nativeSign这个JNI方法。但当我用IDA打开libduncode.so时眼前的景象让我倒吸一口凉气——整个so文件被混淆得面目全非。函数名全是无意义的字符控制流被各种跳转指令打散就连最基本的字符串引用都被处理成了运行时拼接的形式。尝试使用d810这样的反混淆插件后情况稍微好转了一些但核心逻辑仍然难以辨认。这时候我意识到面对这种级别的混淆传统的静态分析手段已经不够用了必须结合动态调试和模拟执行才能突破。2. 动态Hook照亮黑盒的第一束光2.1 JNI方法调用链分析我首先用Frida对libduncode.so的所有JNI方法进行了全面Hook。通过日志发现在调用nativeSign生成user-dun之前APP会先调用setup和initialization这两个JNI方法。这提示我们user-dun的生成可能依赖于某些前置的设备信息初始化。特别值得注意的是nativeSign方法的入参中有一个叫cid的参数最终会出现在user-dun字符串中。通过多次调用对比发现cid似乎与设备硬件信息相关但在不同设备上会保持相对稳定。2.2 关键线程行为监控更深入的Hook发现libduncode.so在初始化时会创建一个后台线程。这个线程在整个APP生命周期中持续运行甚至在user-dun生成后仍在进行某些操作。通过Hook发现它在反复读取base.apk文件这可能是某种反调试机制。在实际逆向中我选择用一个小体积的假base.apk替换原文件这显著提高了Unidbg的模拟执行效率。虽然这种做法可能会影响某些设备参数的准确性但对于算法还原这个首要目标来说是可以接受的折中方案。3. Unidbg模拟在虚拟环境中重建执行流3.1 初始化阶段的陷阱在Unidbg中模拟libduncode.so时遇到的第一个难题是如何Hook JNI_OnLoad之前的初始化代码。我的解决方案是修改LinuxModule.java在callInitFunction中针对libduncode.so设置断点。虽然这个方法不够优雅但在当时确实解决了问题。另一个棘手的问题是so会尝试FindClass查找一些不存在的Java类。Unidbg默认会创建这些类但这导致后续流程出现偏差。通过在_GetStaticMethodID中插入校验代码我们成功绕过了这个陷阱。3.2 系统调用差异处理在对比Unidbg和真机执行时发现getauxval等系统调用的返回值存在差异。我采用了一种简单粗暴但有效的方法——直接Hook这些系统调用强制返回与真机一致的值。虽然这种做法缺乏理论依据但在实际测试中确实让模拟环境更接近真实设备行为。4. 算法还原从Trace日志到核心逻辑4.1 自定义Base64的发现通过分析Trace日志一个关键发现是user-dun使用了自定义的Base64编码表。这个发现来之不易——我最初按照标准Base64解码时总是得到乱码直到在Trace中看到so内部构建编码表的全过程才恍然大悟。这个教训告诉我们在逆向过程中任何理所当然的假设都值得怀疑。4.2 加密类型识别技巧解Base64后的user-dun末尾2字节暗藏玄机——它们实际上标识了使用的加密算法类型。通过反复清缓存抓包对比结合对rand函数的Hook监控我终于理清了算法选择逻辑。有趣的是同一设备在不同时间可能会使用不同的加密方案这增加了逆向的复杂度。4.3 关键算法定位策略面对混淆严重的代码我总结出几个有效的算法定位方法关注memcpy/memmove操作点这些通常是加密中间结果的传递节点监控rand等随机数生成函数的调用上下文对比不同加密路径的Trace日志寻找共同的处理模式重点关注对cid参数的处理过程5. 经验总结逆向工程中的实用技巧在整个逆向过程中有几个经验教训特别值得分享不要被表面现象迷惑就像我最初误把H5的User-Dun当成目标一样逆向工程中经常会出现这种看起来像的误导动态分析优于静态分析面对现代混淆技术纯静态分析往往事倍功半合理取舍很关键不必追求100%的还原聚焦核心算法往往更高效工具链要灵活组合FridaUnidbgIDA的三角组合在这个项目中发挥了巨大作用最后要提醒的是像user-dun这样的风控算法通常会不断更新。今天我们逆向成功的方案明天可能就会失效。因此理解算法设计思路比单纯还原实现更重要这样才能在变化中保持应对能力。