APK反编译-混淆

放下你的浮躁,放下你的懒惰,放下你的三分钟热度,放空你禁不住诱惑的大脑,放开你容易被任何事物吸引的眼睛,放淡你什么都想聊两句八卦的嘴巴,静下心来做你该做的事,该好好努力了!有时候真的努力后,你会发现自己要比想象的优秀很多。记住一句话,越努力,越幸运

APK你不加固就好比一个妹子全裸在你面前,你可以看到里面的源码,很危险,哪怕是现在市面上一些APP也有百分之三十左右也没有加固的。当然也可以用第三方框架加密。

一般APP快上线的时候,我们才会做这一步,一年也就这么几次,因为我是做SDK开发的,所以经常混淆不可避免。

目前反编译工具有四类

1、apktool 主要用于资源文件的获取
2、dex2jar 将apk中的dex文件编译成jar文件
3、jd-gui 查看反编译后的jar中的class
4、jadx 直接查看资源与代码

apktool:如果APK未加固,解压后可以看到APK里面的一些资源文件,比如我们看中了某个APP的一些UI控件,或者想分析AndroidManifest里面的启动是怎样的,或者游戏apk包需要改icon和名称,直接用apktool解压就行了。

网上随便找一个apktool版本,尽量高一点的,我们反编译可以用这种方式。在当前目录,存在一个apktool和一个apk,并且在当前目录打开cmd文件,输入java -jar apktool_2.4.0.jar d app-debug.apk -o dir,最后可以得到一个dir文件,资源什么的都出来了。对于仅仅只需要反编译需求。


image.png

指令很多,我通常用我自己的一套反编译方法,有反编译,回编译。
反编译:需要当前目录的apk,apktool.jar,apktool.bat,执行命令后就会得到一个test的文件夹,注意配置好jdk环境变量啥的。

image.png

xdqxz.keystore是你的签名文件,里面包含签名密码和alias
Test.apk是要反编译的目标apk
apktool是你要反编译工具的版本,名称就改成apktool
apktool.bat里面的东西为下图

@echo off
set PATH=%CD%;%PATH%;
java -jar "%~dp0\apktool.jar" %1 %2 %3 %4 %5 %6 %7 %8 %9

Test文件夹就是你反编译之后的文件夹

回编译
比如我改了游戏apk里面的icon等等之后,想让他重新变为新的apk
我先把Test文件夹改成huanxiang这个名字,其实改成什么名字都一样,到时候执行命令的时候要同步变化即可
apk解压后的文件变成APK,但这仅仅是没签名的APK
apktool b huanxiang -o new_huanxiang_unsign.apk

image.png

要变成签名的apk执行命令jarsigner -verbose -keystore xdqxz.keystore -storepass 123456 -keypass 123456 -signedjar new_huanxiang_signed.apk new_huanxiang_unsign.apk android.keystore -sigalg SHA1withRSA -digestalg SHA1


image.png

dex2jar是将apk中的dex文件编译成jar文件
如果我们有个apk,想看编译apk里面dex文件的源码,可以用这个工具。
下载dex2jar工具,在工具当前目录打开cmd文件,如果目标文件叫app-debug.apk
执行命令d2j-dex2jar.bat app-debug.apk -o app-debug.jar就可以在当前目录得到一个app-debug.jar的jar包
然后用jdu工具去查看这个jar包里面的东西就可以了。直接把jar拖进去就可以看

image.png

jadx
这个工具的作用就是直接可以查看apk里面的代码,双击jadx工具选择对应的apk就会出现目录结构。

image.png

混淆

Proguard是一个代码优化和混淆工具。
能够提供对Java类文件的压缩、优化、混淆,和预校验。压缩的步骤是检测并移除未使用的类、字段、方法和属性。优化的步骤是分析和优化方法的字节码。混淆的步骤是使用短的毫无意义的名称重命名剩余的类、字段和方法。压缩、优化、混淆使得代码更小,更高效。

开启proguard

buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
        debug {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }

我们常用的混淆方法其实可以有个模板在AS里面能找到


image.png

可以拿以上图左参考,混淆的规则还是挺多的,讲几个最常用,用的最多最有效的吧。

我们代码里面很多没有在程序里面使用过调用过的类,打包出去的时候可以混淆过滤掉,可以在根目录的proguard-rules.pro文件里面添加-dontoptimize属性,一般来说这个属性都要添加。

另外用的最多的混淆的三个地方就是:

-keep 指定类和类成员(变量和方法)不被混淆。
    -keep class com.dongnao.proxy.guard.test.Bug
    (保护了类名)
    -keep class com.dongnao.proxy.guard.test.Bug{
        public static void *();
    }
    (保护了 public static void的没有参数的函数)
    -keep class com.dongnao.proxy.guard.test.Bug{
        *;
    }
    (保护所有)
-keepclassmembers 指定类成员不被混淆(就是-keep的缩小版,不管类名了)。
    -keepclassmembers
    class com.dongnao.proxy.guard.test.Bug
    (都被混淆了)
-keepclasseswithmembers 指定类和类成员不被混淆,前提是指定的类成员存在。
    -keepclasseswithmembers class   com.dongnao.proxy.guard.test.Bug
    (保护类名,但是没指定成员,所以函数名被混淆)
    -keepclasseswithmembers class       com.dongnao.proxy.guard.test.Bug{
        native ;
    }

全被混淆了。注意 前提是指定的类成员存在 因为不存在native函数,所以这条语句等于无效,

然后混淆后的apk通过jadx来查看,就会看到类名变成了a/b/c这样的。那如果我们集成了类似友盟、bugly等异常上报功能,那么我们怎么知道这个异常到底出现在哪里?

我们在Activity中主动写一个bug
image.png

然后生成一个debug的apk


image.png

运行产生这样的日志:
image.png

这个日志有两个问题:
1、 我们不知道是哪个类报告出的。
2、 不知道这个类是哪一行报出的。

混淆后的代码错误栈恢复方法(outputs/mapping/debug/mapping.txt文件中保存了混淆前后的对应关系)
1.把错误信息保存到文件
2.使用工具 sdk/tools/groguard/bin/retrace.bat先配置 -keepattributes SourceFile,LineNumberTable再执行 retrace.bat -verbose mappint文件 bug文件

第一个问题很显然是由于我们的代码进行了混淆。
在开启混淆后,我们生成apk会产生


image.png

dump.txt
说明 APK 中所有类文件的内部结构。
这个文件内容非常多,可读性也并不高

mapping.txt
提供原始与混淆过的类、方法和字段名称之间的转换。

seeds.txt

列出未进行混淆的类和成员。我们保护的zip没有被混淆
image.png

usage.txt
列出从 APK 移除的代码。可以在这个文件中查看是不是有我们不想被移除的类

image.png

最重要的当然就是我们的mapping文件了。通过这个文件我们就能定位到:


image.png

出现错误的函数是Bug类中的test函数。

我们现在比较简单,所以一下子就能定位到错误函数,如果函数层级较深,光靠自己比对来查找难度就比较大了。所以sdk中提供了一个工具在tools/proguard/bin中。
我们把logcat里面保存的错误堆栈复制到一个文件中:


image.png

然后执行retrace 脚本(在 Windows 上为 retrace.bat;在 Mac/Linux 上为 retrace.sh)
retrace.bat|retrace.sh [-verbose] mapping.txt []

image.png

image.png

现在错误日志一句mapping还原了。
所以我们每次在发布版本之后都需要保留这个mapping文件。所以一般异常上报平台都会提供mapping上传然后帮助我们分析。
第一个问题解决的,第二个问题是行数显示的是Unknow Source


image.png

如果希望出现具体行数,我们需要在配置文件中加入
抛出异常时保留代码行号,在异常分析中可以方便定位
-keepattributes SourceFile,LineNumberTable


image.png

另外还可以配合
-renamesourcefileattribute AAA
使用字符串"AAA"来替代真正的类,避免泄漏更多的信息
image.png

虽然我们的代码经过了混淆,但是实际上,对于有耐心有条件的人来说,还是能够从混淆过后的代码中看到蛛丝马迹。

dex2jar: java
https://sourceforge.net/projects/dex2jar/

image.png

反编译后生成了一个jar
image.png

然后使用jd-gui打开:
http://jd.benow.ca/
直接跳到了,更加方便。
image.png

所以只要花功夫,混淆完全能够被完整的解读出来。当然并不是说混淆就没用。混淆之后解读难度更大了。
proguard移除无用代码还能缩小apk大小。

你可能感兴趣的:(APK反编译-混淆)