Android混淆总结篇

莫问天涯路几重,轻衫侧帽且从容。这篇文章主要讲述Android混淆总结篇相关的知识,希望能为你提供帮助。
Ⅰ.前言 上篇文章总结混淆相关的知识点, 基本的技术点都有罗列到。如果项目开发比较紧张, 可以考虑套用混淆配置的模板, 复制粘贴的基础上再修修补补. 上篇文章说到和朋友讨论的问题, 前几天也基本探究完了, 那么也得理理思路~总结总结, 期望有更多的问题出现~才可以去探讨.
Ⅱ.异常收集 上篇混淆知识点的总结文章写得还是挺完整的, 可点击查看 Android混淆总结篇(一)
这篇文章主要的技术点是异常收集, 项目上线前除了混淆、打包、加固、签名和发布等, 还有一项是无可避免的, 就是对线上的应用进行各种统计, 对应用进行各种统计包括异常的收集统计、应用的渠道下载率、活跃量、留存率和页面访问路径统计等等, 有很多第三方的统计SDK可供接入使用, 比如友盟+ 、百度、诸葛IO 等第三方, 精细点的话可以考虑下无埋点技术等. 只要在上线前集成了统计SDK, 那么就可以在其相应的后台看到上线后各种数据的统计报表.
统计对于运营和项目维护还是很有必要的, 开发人员可以看到收集到的异常, 然后对异常进行分析并找到相应解决的方案, 那么这里就要开始文章的主题了, 下面的截图是友盟+ 后台收集到的异常信息, 在其异常信息下面还可以收集到该异常发生的手机型号、版本和渠道。看下异常信息吧, 当看到红圈圈出来的部分, 是不是就迷惑了, 异常信息里怎么会有abc 这样的替代符, 本来异常信息可以让开发者清楚知道异常发生的地方, 可以使其轻易定位到, 但现在呢?难不成靠猜的方式去定位异常, 那就呵呵了.怪不得朋友说异常信息定位问题非常迷惑, 那么下面开始来整整这迷惑.
Ⅲ.还原混淆信息的方式

Android混淆总结篇

文章图片

针对上面的异常信息出现abc 的替代符, 主要是由于混淆打包导致的, 上面abc 其实是项目的类名或变量名的代替符, 那么如果apk没有经过混淆就会导致apk源码泄露或被二次打包, 虽说混淆了之后的apk还是很大风险会泄露, 但相对来说代码泄露的难度是增大了, 所以混淆是不可缺的。那么上面的异常信息又该如何定位Bug呢?
android SDK工具包就提供了解决的工具, sdk\\tools\\proguard\\bin路径下名为”proguardgui.bat”和”retrace.bat”(windows和linux下, 工具的后缀名不同)的两个工具, 前者是通过图形化的方式去将被混淆的异常信息反编译, 后者则通过命令行的方式将被混淆的异常信息反编译.那么在使用这工具前, 还得有一个叫”mapping.txt”的文件, 看下面截图, 这是在打包apk完成后生成的一个文件, 主要记录着混淆前后的信息映射关系。
Android混淆总结篇

文章图片

每次打包apk 完成后生成的mapping.txt 都是有必要保存的, 那怎么使用上面提到的 “proguardgui.bat”和”retrace.bat” 这两个工具呢? 看下面截图即可, 简简单单搞定proguardgui.bat ,但抱歉的是本人试了很多次, 都不能将异常信息转换回去, 而最无语的是搜索到的文章介绍的方法跟我操作的完全一样, 这时候我就发现了经常碰到的奇葩问题, 基本文章上演示截图的异常信息都是一样的, 尼玛这些文章的截图既然都是抄袭的, 难不成Android SDK提供的”proguardgui.bat” 图形化工具已经失效了, 接着试试”retrace.bat” 工具.上面也提到了 “proguardgui.bat”和”retrace.bat” 这两个工具基本是一样的, 只是使用方式不同, 一个是图形化方式, 一个则是命令行方式。
Android混淆总结篇

文章图片

在retrace.bat命令行工具里反编译异常, 使用的指令为
格式: retrace.bat|retrace.sh [-verbose] mapping.txt [< stacktrace_file> ] 例如: retrace.bat -verbose d:/mapping.txt d:/wyk_stacktrace.txt

那么接着就验证下命令行形式的 “retrace.bat”, 并不同于上面的proguardgui.bat 工具有面板可以粘贴报错信息, 所以先把异常信息保存为txt文件, 然后命令行进入Android SDK存放的路径sdk\\tools\\proguard\\bin目录, 根据上面的指令格式进行输入, 结果如下:
Android混淆总结篇

文章图片

结论: ”proguardgui.bat”和”retrace.bat” 这两个工具包无法还原Apk线上被混淆的异常信息.
上面的截图就是使用”retrace.bat” 工具的反编译异常信息的结果, 可以看到abc 的标识符依然存在, 所以仍得不到完整的异常信息。反复试了很多次, 依旧无果, 还是找找有没有其他方式吧~~话说在Android SDK的sdk\\tools\\proguard\\lib目录下有”proguardgui.jar”和”retrace.jar” 这两个jar包, 上面使用到的”proguardgui.bat”和”retrace.bat” 这两个工具可能是基于这两个jar包的, 思考如果直接使用这两jar包尝试反编译异常信息的话是否有解。先试试retrace.jar 这个jar包, 命令行进入到jar包所在的目录, 在命令行输入如下指令, 输出的信息和上面的retrace.bat工具输出的一样, 依然没有完整的异常信息.
格式: java -jar retrace.jar [-verbose] mapping.txt [< stacktrace_file> ] 例如: java -jar retrace.jar -verbose d:/mapping.txt d:/error.txt

接着试试proguardgui.jar, 命令行进入jar包所在的目录, 输入 “java -jar proguardgui.jar” 启动proguard工具, 看到的界面和proguardgui.bat 是一样的, 应该说proguardgui.bat 启动的也是这个jar包, 验证之后还是没有得到完整的异常信息.
结论: ”proguardgui.jar”和”retrace.jar” 这两个jar包无法还原Apk线上被混淆的异常信息.
Ⅳ.根据mapping.txt文件验证 【Android混淆总结篇】上面的工具可以还原被混淆的异常信息, 其原理是因为mapping.txt存在其混淆前后的映射信息, 那是不是可以根据被混淆的一小段异常信息在mapping.txt文件查找相应的映射关系, 拷贝被混淆的异常信息在mapping.txt文件进行全文搜索, 下面图1是收集在统计异常后台的信息, 图2是在mapping.txt文件查找图1红圈部分的映射信息.图3也是异常信息和映射关系.
Android混淆总结篇

文章图片

Android混淆总结篇

文章图片

Android混淆总结篇

文章图片

结论: 通过上面异常信息混淆前后的映射关系, 切记打包时将相应的apk和生成的mapping.txt进行对应保存, 这将对上线之后的Bug追踪和维护起着非常重要的作用;
Ⅴ.其他还原混淆异常信息的方式 上面根据mapping.txt查找信息映射关系的方式, 显然不适合线上Bug的追踪和应用的维护, 因此就得另找出口, 经常使用到的统计异常SDK有友盟+ 和Bugly, 早前一直都在用友盟+ 的统计异常SDK, 之后由于统计数据不及时和疏漏, 所以之后的应用选择接入Bugly, Bugly针对异常的收集还是非常及时和准确的。
这些统计异常的SDK其实都有提供还原被混淆异常信息的功能, 这样对开发者就非常友好了, 该功能的位置在SDK后台的异常信息上边, 只需要导入异常信息对应的应用版本的mapping文件, 点击”解析”按钮就可以看到原始的异常信息。
Android混淆总结篇

文章图片

Android混淆总结篇

文章图片

在友盟+ 的统计后台亲测发现, 被混淆的异常无法还原, 探究了几番仍找不到原因.而在Bugly的统计后台亲测是有效的, 可以看到下面被混淆的异常信息和还原之后的异常信息.
Android混淆总结篇

文章图片

Ⅵ.总结
  • App线上异常的追踪, 可以选择友盟+ 、百度、诸葛IO等第三方, 精细点的话可以考虑下无埋点技术等;
  • 经过测试发现, Android SDK包的”proguardgui.bat” 和”retrace.bat” 这两个工具包无法还原Apk线上被混淆的异常信息;
  • Apk打包后生成的的mapping文件保存着代码混淆前后的映射关系;
  • 第三方SDK的统计后台一般都提供还原 “被混淆异常信息” 的功能;
  • 切记 打包时将apk版本和生成的mapping.txt进行对应保存.
本篇章总结的点, 有不对的地方, 请多多指正.

    推荐阅读