★ FEATURED ARTICLE 看到雷速体育加360加固很多刚入坑逆向的朋友第一反应就是头疼。360加固在国产加固里属于最常见的商业壳之一对新手来说确实是一道不低的门槛但换个角度看它也恰恰是练手最好的样本。这篇文章就围绕“Android逆向之雷速体育(360加固)”这个完整流程来聊从环境搭建、脱壳实操、代码定位到协议还原把每一步拆开讲清楚。不绕弯子直接从头走一遍适合正在研究Android逆向、想啃商业壳但一直卡在脱壳环节的朋友。1. 内容整体设计与逆向思路拆解1.1 核心需求解析雷速体育这个目标到底要逆什么雷速体育本质是一个体育数据聚合类应用核心价值在于它的实时比分、赛事数据、赔率变化等接口数据。对逆向分析者来说这类App常见的分析目标有三类第一是抓取它背后的API接口搞清楚请求参数怎么生成第二是还原它的加密算法比如请求头里那些签名参数是怎么算出来的第三是研究它的数据推送机制比如WebSocket长连接里消息格式怎么定义。不管你最终要哪一类结果第一步永远是同一件事拿到能看的代码。而360加固的引入就是让这件事从“解压APK直接看smali”变成“先脱壳、再修复、后分析”的三步走。1.2 方案选型为什么选择动态脱壳作为主路线对付360加固行内主流方案其实就两条路静态脱壳和动态脱壳。静态脱壳工具大多基于对加固壳特征码的匹配比如早期版本的360壳可以用FDex2直接暴力枚举内存中的dex但加固厂商也不是吃素的新版壳加了很多反调试、反内存dump的检测静态方案经常脱到一半就崩或者dump出来的dex根本不能用。动态脱壳则是在App运行起来之后从内存中抓取已经解密完的dex文件这条路绕过了壳的静态保护逻辑实际操作中成功率要高得多。本次实战我选的是Frida加Objection的组合原因很直接Frida的hook能力覆盖面广Objection则在内存搜索和类枚举上做了很好用的封装。两个工具配合起来对360这类商业壳的脱壳效率是很稳定的。还要强调一点工具不是越新越好关键是你要理解每个工具在脱壳链路里扮演的角色不然出了问题都不知道去哪排查。2. 逆向环境搭建与工具准备2.1 基础环境配置从模拟器到真机的选择做脱壳分析环境准备这块很多人会走弯路。先说结论优先选择真机尤其是针对360加固这种对模拟器检测做得比较严的壳。我早期用夜神模拟器做测试经常出现Frida attach上去没多久进程就退了或者直接检测到调试环境强制闪退排查半天才发现是模拟器特征被壳识别了。推荐方案是一台Android 7~9的老款真机比如Nexus 5X、小米6这类机型原因是360加固的老版本兼容性好高版本Android系统上反而会出现一些莫名奇妙的兼容问题。手机需要先解锁Bootloader并刷入Magisk获取root权限这些基础内容不过多展开网上资料很充足。环境列表整理如下分析机Windows 10 / macOS 皆可需安装Python 3.8目标设备Android 7.0系统的root真机桥接工具ADBAndroid Debug Bridge建议用最新版platform-tools动态注入框架Frida 14.2.18Server端版本需与PC端一致内存审计工具Objection 1.11.0抓包工具Charles 4.6.2 手机端证书JAVA反编译工具jadx 1.4.42.2 核心工具角色拆解与版本坑点很多新人上来就装最新版Frida结果各种报错其实就是没有理解Frida的版本匹配机制。Frida分为PC端和Server端两部分PC端通过pip安装手机端是frida-server二进制文件两边的大版本号必须完全一致小版本号最好也一致否则会报unable to communicate with frida daemon之类的错误。我用的组合是PC端14.2.18配Server端14.2.18这个版本经过大量实战验证对付360加固兼容性很好。Objection是另一款高频工具它的ranger插件提供了内存中直接搜索dex文件的能力可以基于dex的magic number64 65 78 0A 0D 0A 00进行匹配。注意新版本Objection依赖的Python库较多装的时候建议用virtualenv隔离避免污染系统Python环境。jadx用于脱壳后的代码分析建议选1.4.4以上的版本对新的Java语法和资源混淆处理得更好。Charles的SSL Proxying需要手动安装证书到系统证书目录这部分在Android 7以上系统需要把证书以系统身份安装具体命令后面实操部分会写。提示整套环境的版本锁定很重要。不要盲目追新很多商业壳的检测规则就是针对最新版Frida写特征码的老版本反而相对安全。3. 脱壳实操绕过360加固的完整流程3.1 壳特征检测与APK基础信息采集拿到雷速体育的APK后第一步是确认壳的具体类型和版本。别急着上Frida先用工具做个基础体检。这里用jadx直接打开APK你会看到入口Application被替换成了类似com.stub.StubApp这样的类同时assets目录下有一堆so库和加密的dex文件这些就是加固后的特征。360加固的标识性特征有三处第一个是AndroidManifest.xml里application的name属性被改成了com.stub.StubApp第二个是lib目录下有libjiagu.so和libjiagu_a64.so这两个加固核心库第三个是assets目录下存在libjiagu.so对应的加密数据文件。用如下命令验证# 查看APK基本信息 aapt dump badging leisu.apk # 查看加固特征文件 unzip -l leisu.apk | grep -E jiagu|stub输出结果里能直接看到libjiagu.so等文件壳类型基本就可以确定了。这时候再用jadx看AndroidManifest.xml找到originalApplication这个meta-data字段它记录了App真正的Application类名这个信息后面会用到。3.2 Frida环境部署与注入测试接下来把frida-server推到手机并启动。注意架构匹配雷速体育的APK同时包含32位和64位so但frida-server只需要推一个对应手机CPU架构的版本。查询手机架构用adb shell getprop ro.product.cpu.abi一般真机都是arm64-v8a那就推arm64版的frida-server。# 推送frida-server到手机 adb push frida-server-14.2.18-android-arm64 /data/local/tmp/ # 给执行权限并启动 adb shell chmod 755 /data/local/tmp/frida-server /data/local/tmp/frida-server # 另开终端验证连接 frida-ps -U看到进程列表输出后说明Frida环境已经打通了。这里有个细节frida-server启动后默认监听27042端口如果手机上有安全软件拦截端口监听需要先用netstat确认一下端口状态。对360加固App来说早期版本会检测27042端口的开放状态所以如果frida-ps -U能列出进程但一attach就崩溃可以考虑用frida-server -l 0.0.0.0:8888指定一个非常规端口PC端连接时也指定相应端口。3.3 使用Objection自动脱壳环境畅通后直接进入脱壳环节。Objection内置的memory dumping功能可以基于ranger扫描内存中所有dex文件并批量导出这是自动化脱壳最直观、成功率最高的方案之一。# 启动雷速体育App adb shell am start -n com.leisu.sports/.MainActivity # 使用objection注入进程 objection -g com.leisu.sports explore # 在objection交互界面执行内存dex搜索 memory dump dex_from_memory执行完上述命令后objection会在当前目录生成一个以包名命名的文件夹里面是扫描到的所有dex文件。实际操作中dump出来的可能不止一个dex可能包括系统框架的、App本身的、以及壳动态加载的。咱们需要从中筛选出和雷速体育业务逻辑相关的那个。判断方法是逐个查看dex的包结构用jadx打开后搜出现的主包名。雷速体育的业务代码包名多以com.leisu开头找到这个包名对应的dex就是核心目标。3.4 dex文件修复与落盘验证这是整个脱壳流程里最容易翻车的环节。Objection dump出来的dex少数情况是完整可用的但更多时候由于内存中dex已经被类加载器动态修改导出的文件会存在结构残缺问题直接丢给jadx会出现大量解析错误。修复需要用到dexfixer这类工具它的原理是重新计算dex文件的checksum和signature并清理掉文件中不可用的数据段。# 使用dexfixer修复 python3 dexfixer.py input.dex output_fixed.dex # 修复后用jadx打开验证 jadx -d output_folder output_fixed.dex打开后重点看两件事一是包名结构是否完整二是关键类是否能正确反编译。如果jadx能正常输出Java代码脱壳这步就算正式过关了。注意如果dump出的dex用jadx打开后大量类显示为An error occurred while decompiling不要慌这不一定是文件损坏也可能是jadx本身的bug。换用GDA或者Android Studio的APK Analyzer交叉验证一下能确认到底是文件问题还是工具问题。4. 核心代码分析与关键逻辑定位4.1 从脱壳结果中定位业务核心代码脱壳只是第一步真正花时间的在于分析。用jadx打开修复后的dex先别急着全局搜索关键词那样效率很低。我的习惯是先通过AndroidManifest.xml找到入口Activity再顺着页面跳转关系梳理整体结构。雷速体育这种体育数据App核心数据展示页基本都在MainActivity、MatchListActivity这几个类里。jadx打开后直接搜索api.leisu或http字符串把所有网络请求的URL先列出来这一步能帮你在几分钟内看清整个App的接口架构。另一个高效入口是搜索sign或token关键词凡是做请求签名的App必然在代码里有加密入口。雷速体育的请求签名逻辑藏在ApiService类里类里面能看到一个signParams方法的调用链里面涉及MD5、AES混合加密。具体算法细节先不展开但定位方法就是搜索关键词跟随XREF引用这一套组合拳效率最高。4.2 加密算法还原与协议分析实录定位到signParams方法之后接下来的核心任务就是还原它的加密逻辑。jadx反编译出来的代码可读性有时会比较差尤其是混淆过的变量名基本是一堆a、b、c。我的做法是把关键代码片段复制出来用人工方式对照上下文进行重命名和逻辑梳理。雷速体育的签名生成逻辑整理后大概长这样public static String signParams(MapString, String params) { // 1. 按key进行字典排序 // 2. 拼接成keyvaluekeyvalue格式 // 3. 拼接固定盐值 // 4. MD5加密 // 5. 结果转大写 }这段逻辑本身并不复杂但加壳后很多人就是卡在找不到这段代码。所以脱壳之后的第一件事永远是确定代码结构完整性一旦在脱壳过程中dex修复不彻底这类核心逻辑类往往就分析不出来。协议分析还需要配合抓包。Charles挂上SSL代理后把雷速体育的请求头抓下来对比代码里的签名逻辑就能精确还原出完整的请求链路。我大概统计了一下雷速体育的核心接口差不多12个包含比分、赛程、赔率、即时数据等每个接口的请求参数不完全相同但签名算法是一致的。搞清楚一个其他全部通用。4.3 动态调试辅助分析有些逻辑光靠静态分析还不够特别是网络请求加密参数最好配合动态hook来看真实运行时的值。这里写一个简单的Frida脚本hook住signParams方法把输入参数和输出结果都打印出来Java.perform(function() { var ApiService Java.use(com.leisu.sports.api.ApiService); ApiService.signParams.implementation function(params) { var result this.signParams(params); console.log(params: params.toString()); console.log(result: result); return result; }; });保存为hook_sign.js执行frida -U -f com.leisu.sports -l hook_sign.js这个脚本的作用是在App启动时提前注入每次调用signParams都会打印明文参数和签名结果。通过比对不同请求下签名的变化能快速验证你对加密逻辑的猜测是否正确。实测中这个方法帮我节省了大量逆向时间很多时候静态分析看不懂的代码逻辑动态hook一轮就全清楚了。5. 常见问题排查与避坑技巧实录5.1 脱壳失败与注入闪退问题速查整个流程走下来最常遇到的就是下面这些坑整理成表格方便排查问题现象可能原因排查与解决办法frida-ps -U 看不到进程frida-server版本不匹配确认PC端与Server端版本号一致建议统一用14.2.18attach后App秒退360壳检测到注入换用spawn模式而非attach模式dump出的dex无法解析内存数据不完整使用dexfixer修复或用GDA交叉验证hook方法时找不到类类名被混淆或类尚未加载用Java.choose等待类加载或在onCreate之后延迟hookCharles无法解密HTTPS证书未安装到系统目录Android 7需要将证书移动到/system/etc/security/cacertsjadx打开dex大量报错dex文件结构损坏重新dump注意更换frida-server的监听端口5.2 反调试绕过与进程检测对抗360加固的老版本反调试主要靠检测调试端口、检测/proc/self/status里的TracerPid、以及检测Frida特征。新版本加入了更狠的native层反调试直接在so库里定时检查进程状态。针对这些反调试常见对策有使用MagiskHide或Shamiko隐藏root避免壳检测到root环境用frida-server的-g参数指定启动模式绕过部分启动检测通过LD_PRELOAD方式hook系统调用篡改TracerPid返回值在Frida脚本里主动hook掉壳的检测方法比如com.stub.StubApp里的isDebuggerConnected方法有一个细节特别值得注意360壳的部分检测逻辑是在native层执行的单纯用Java层的hook绕过效果有限需要配合frida的Interceptor对native函数进行inline hook。这部分对新手来说难度较高初学时建议先在老版本360加固App上练手等对脱壳流程熟悉了再去碰新版本。5.3 混淆代码分析与还原经验分享雷速体育的代码除了加固外还做了代码混淆这导致jadx反编译出的代码很多地方都变成了抽象晦涩的逻辑。我在分析过程中发现两个比较有效的技巧第一是抓包反推法先看网络请求里实际传输了什么参数再回到代码里搜索对应字段字符串这样能快速锁定混淆后的关键变量第二是行为观察法动态运行App用Frida hook关键类构造函数观察哪些类被频繁实例化那些就是核心逻辑类。另外建议把所有jadx反编译的代码导到Android Studio里利用IDE的全局搜索和调用层次分析功能比单纯在jadx里翻要高效得多。我在做雷速体育的签名算法还原时就先把相关类全部导出到一个临时工程然后用IDEA的Find Usages功能追踪调用链这比肉眼扫描代码快了不止一倍。6. 扩展思考加固对抗的未来方向分析完雷速体育这个案例对加固和逆向之间的博弈会有更深的理解。360加固这类商业壳的核心防御思路是“不让分析者拿到完整的静态代码”而逆向方的核心思路是“在运行时从内存中偷出完整逻辑”。只要App需要在设备上运行内存中必然存在可执行的完整代码这就是脱壳永远有路可走的根本原因。近年来一些新的加固方案开始尝试函数级抽取把真正的函数体从dex中抽离到native层运行到哪个方法才解密哪个方法。这种方案对传统脱壳工具是个挑战因为一次性dump内存可能只能拿到当前已解密的部分函数。针对这种方案思路要转向指令级hook在函数被解密执行的瞬间去抓取解密后的smali指令。不过话说回来逆向分析的最终目的应该放在学习技术上。通过破解商业加固壳、还原加密算法你锻炼的是对Android系统运行机制的理解、对smali字节码的熟悉程度、以及动态调试的能力。这些能力本身是中性的用在App安全测试、漏洞挖掘上是正向价值用在灰色产业上则是完全另一回事。希望看到这篇文章的朋友都能把学到的技能用在正道上。最后分享一个我踩过的坑脱壳时不要光盯着一款工具死磕多备几套方案能救命。有一次Objection在某个新版本360壳上怎么都dump不出完整dex切回Frida手写脚本用枚举ClassLoader的方式逐个加载并保存反而很轻松就拿到了目标dex。工具是死的思路是活的临场换方案的能力比背熟某个工具的教程重要得多。
阅读完成 · 觉得有帮助？
