那么今天我们就用另外一种方式来破解apk:动态方式,关于动态方式其实很广义的,因为动态方式相对于静态方式来说,难度大一点,但是他比静态方式高效点,能够针对更过的破解范围。当然动态方式很多,所以这里就分为三篇文章来讲解这块:
1、动态方式破解apk前奏篇(Eclipse动态调试smail源码)
2、动态方式破解apk升级篇(IDA动态调试so源码)
3、动态方式破解apk终极篇(应对加固的apk破解方法)
从这三篇文章能够让我们破解一般的apk没有任何问题,不过不能代表能够破解所有的apk,因为没有绝对的安全,也是没有绝对的破解,两方都在进步,我们只能具体问题具体分析。好了,下面我们就来看第一篇文章,也是今天的重点:Eclipse动态调试smali源码
首先需要解释一下,这里为什么说是调试smali源码,不是Java源码,因为我们弄过反编译的人知道,使用apktool反编译apk之后,会有一个smali文件夹,这里就存放了apk对应的smali源码,关于smali源码这里不解释了,网上有介绍。
因为这一篇是一个教程篇,所以不能光说,那样会很枯燥的,所以这里用一个例子来介绍一下:
我们就用阿里2014年安全挑战赛的第一题:AliCrack_one.apk
看到这张图了,阿里还挺会制造氛围的,那么其实很简单,我们输入密码就可以破解了,下面我们就来看看如何获取这个密码。
java -jar apktool_2.0.0rc4.jar d -d AliCraceme_1.apk -o out
这里的命令不做解释了,但是有一个参数必须带上,那就是:-d
因为这个参数代表我们反编译得到的smali是java文件,这里说的文件是后缀名是java,如果不带这个参数的话,后缀名是smali的,但是Eclipse中是不会识别smali的,而是识别java文件的,所以这里一定要记得加上这个参数。
反编译成功之后,我们得到了一个out目录,如下:
源码都放在smali文件夹中,我们进入查看一下文件:
看到了,这里全是Java文件的,其实只是后缀名为java了,内容还是smali的:
上面我们反编译成功了,下面我们为了后续的调试工作,所以还是需要做两件事:
1》修改AndroidManifest.xml中的android:debuggable="true"
关于这个属性,我们前面介绍run-as命令的时候,也提到了,他标识这个应用是否是debug版本,这个将会影响到这个应用是否可以被调试,所以这里必须设置成true。
2》在入口处添加waitForDebugger代码进行调试等待。
这里说的入口处,就是程序启动的地方,就是我们一般的入口Activity,查找这个Activity的话,方法太多了,比如我们这里直接从上面得到的AndroidManifest.xml中找到,因为入口Activity的action和category是固定的。
当然还有其他方式,比如aapt查看apk的内容方式,或者是安装apk之后用adb dumpsys activity top命令查看都是可以的。
找到入口Activity之后,我们直接在他的onCreate方法的第一行加上waitForDebugger代码即可,找到对应的MainActivity的smali源码:
然后添加一行代码:
invoke-static {}, Landroid/os/Debug;->waitForDebugger()V
这个是smali语法的,其实对应的Java代码就是:android.os.Debug.waitForDebugger();
这里把Java语言翻译成smali语法的,不难,网上有smali的语法解析,这里不想再解释了。
java -jar apktool_2.0.0rc4.jar b -d out -o debug.apk
还是使用apktool进行回编译
编译完成之后,将得到debug.apk文件,但是这个apk是没有签名的,所以是不能安装的,那么下面我们需要在进行签名,这里我们使用Android中的测试程序的签名文件和sign.jar工具进行签名:
关于签名的相关知识,可以看这篇文章:Android中的签名机制详解
java -jar .\sign\signapk.jar .\sign\testkey.x509.pem .\sign\testkey.pk8 debug.apk debug.sig.apk
签名之后,我们就可以进行安装了。
这里我们新建一个Java工程,记住不是Android工程,因为我们最后调试其实是借助于Java的调试器,然后勾选掉Use default location选项,选择我们的smali源码目录,也就是我们上面反编译之后的out目录,点击完成
我们导入源码之后的项目工程结构:
主要看MainActivity类:
这一步我们看到,其实说的比较广义了,这个要具体问题具体分析了,比如这个例子中,我们知道当我们输入密码之后,肯定要点击按钮,然后触发密码的校验过程,那么这里我们知道找到这个button的定义的地方,然后进入他的点击事件中就可以了。这里分为三步走:
1》使用Eclipse自带的View分析工具找到Button的ResId
点击之后,需要等待一会,分析View之后的结果:
看到了,这里我们能够看到整个当前的页面的全部布局,已经每个控件的属性值,我们需要找到button的resource-id
这里我们看到定义是@+id/button这个值。
2》我们得到这个resId之后,能否在smali工程中全局搜索这个值,就可以定位到这个button的定义的地方呢?
然后我们看看搜到的结果:
这时候我们其实是在资源文件中搜到了这个id的定义,这个id值对应的是0x7F05003E。
当然除了这种方式,我们还有一种方式能快速找到这个id对应的整型值,那就是在反编译之后的values/public.xml文件中:
这个文件很有用的,他是真个apk中所有资源文件定义的映射内容,比如drawable/string/anim/attr/id 等这些资源文件定义的值,名字和整型值对应的地方:
这个文件很重要,是我们在寻找突破口的重要关键,比如我们有时候需要通过字符串内容来定位到关键点,这里就可以通过string的定义来找到对应的整型值即可。
当我们找到了button对应的id值了之后,我们就可以用这个id值在一次全局搜索一下,因为我们知道,Android中编译之后的apk,在代码中用到的resId都是用一个整型值代替的,这个整型值就是在R文件中做了定义,将资源的id和一个值对应起来,然后代码里面一般使用R.id.button这样的值,在编译出apk的时候,这个值就会被替换成对应的整型值,所以在全局搜索0x7F05003E
搜索的结果如下:
看到了,这里就定位到了代码中用到的这个button,我们进入代码看看:
在这里,看到了,使用了findViewById的方式定义Button,我们在往下面简单分析一下smali语法,下面是给button添加一个按钮事件,这里用的是内部类MainActivity$1,我们到这个类看看,他肯定实现了OnClickListener接口,那么直接搜onClick方法:
在这里我们就可以下个断点了,这里就是触发密码校验过程。
在第五步中,我们找到了关键点,然后打上断点,下面我们就来运行程序,然后在Eclipse中设置远程调试的工程
首先我们运行程序,因为我们加入了waitForDebug的代码,所以启动的时候会出现一个Wait debug的对话框。不过,我测试的时候,我的手机没有出现这个对话框,而是一个白屏,不过这个不影响,程序运行起来之后,我们看看如何在Eclipse中设置远程调试工程,首先我们找到需要调试的程序对应远程调试服务端对应的端口:
这里我们看到有几个点:
1》在程序等待远程调试服务器的时候,前面会出现一个红色的小蜘蛛
2》在调试服务端这里我们会看到两个端口号:8600/8700,这里需要解释一下,为什么会有两个端口号呢?
首先在这里的端口号,代表的是,远程调试服务器端的端口,下面在简单来看一下,Java中的调试系统:
这里我们看到,这里有三个角色:
111》JDB Client端(被调试的客户端),这里我们可以认为我们需要破解的程序就是客户端,如果一个程序可以被调试,当启动的时候,会有一个jdwp线程用来和远程调试服务端进行通信
这里我们看到,我们需要破解的程序启动了JDWP线程,注意这个线程也只有当程序是debug模式下才有的,也就是AndroidManifest.xml中的debug属性值必须是true的时候,也就是一开始为什么我们要修改这个值的原因。
222》JDWP协议(用于传输调试信息的,比如调试的行号,当前的局部变量的信息等),这个就可以说明,为什么我们在一开始的时候,反编译成java文件,因为为了Eclipse导入能够识别的Java文件,然后为什么能够调试呢?因为smali文件中有代码的行号和局部变量等信息,所以可以进行调试的。
333》JDB Server端(远程调试的服务端,一般是有JVM端),就是开启一个JVM程序来监听调试端,这里就可以认为是本地的PC机,当然这里必须有端口用来监听,那么上面的8600端口就是这个作用,而且这里端口是从8600开始,后续的程序端口后都是依次加1的,比如其他调试程序:
那么有了8600端口,为什么还有一个8700端口呢?他是干什么的?
其实他的作用就是远程调试端备用的基本端口,也就是说比如这里的破解程序,我们用8600端口可以连接调试,8700也是可以的,但是其他程序,比如demo.systemapi他的8607端口可以连接调试,8700也是可以的:
所以呀,可以把8700端口想象成大家都可以用于连接调试的一个端口,不过,在实际过程中,还是建议使用程序独有的端口号8600,我们可以查看8600和8700端口在远程调试端(本地pc机)的占用情况:
看到了,这里的8600端口和8700端口号都是对应的javaw程序,其实javaw程序就是启动一个JVM来进行监听的。
好了,到这里我们就弄清楚了,Java中的调试系统以及远程调试的端口号。
注意:
其实我们可以使用adb jdwp命令查看,当前设备中可以被调试的程序的进程号信息:
下面继续,我们知道了远程调试服务端的端口:8600,以及ip地址,这里就是本地ip:localhost/127.0.0.1
我们可以在Eclipse中新建一个远程调试项目,将我们的smali源码工程和设备中需要调试的程序关联起来:
右击被调试的项目=》选择Debug Configurations:
然后开始设置调试项目
选择Romote Java Application,在Project中选择被调试的smali项目,在Connection Type中选择SocketAttach方式,其实还有一种方式是Listener的,关于这两种方式其实很好理解:
Listner方式:是调试客户端启动就准备好一个端口,当调试服务端准备好了,就连接这个端口进行调试
Attach方式:是调试服务端开始就启动一个端口,等待调试端来连接这个端口
我们一般都是选择Attach方式来进行操作的。
好了,我们设置完远程调试的工程之后,开始运行,擦发现,设备上的程序还是白屏,这是为什么呢?看看DDMS中调试程序的状态:
擦,关联到了这个进程,原因也很简单,我们是上面使用的是8700端口号,这时候我们选中了这个进程,所以就把smali调试工程关联到了这个进程,所以破解的进程没反应了,我们立马改一下,用8600端口:
好了,这下成功了,我们看到红色的小蜘蛛变成绿色的了,说明调试端已经连接上远程调试服务端了。
注意:
我们在设置远程调试项目的时候,一定要注意端口号的设置,不然没有将调试项目源码和调试程序关联起来,是没有任何效果的
下面我们就开始操作了,在程序的文本框中输入:gggg内容,点击开始:
好了,到这里我们看到期待已久的调试界面出来了,到了我们开始的时候加的断点处,这时候我们就可以开始调试了,使用F6单步调试,F5单步跳入,F7单步跳出进行操作:
看到了,这里使用v3变量保存了我们输入的内容
这里有一个关键的地方,就是调用MainActivity的getTableFromPic方法,获取一个String字符串,从变量的值来看,貌似不是规则的字符串内容,这里先不用管了,继续往下走:
这里又遇到一个重要的方法:getPwdFromPic,从字面意义上看,应该是获取正确的密码,用于后面的密码字符串比对。
查看一下密码的内容,貌似也是一个不规则的字符串,但是我们可以看到和上面获取的table字符串内容格式很像,接着往下走:
这里还有一个信息就是,调用了系统的Log打印,log的tag就是v6保存的值:lil
这时候,我们看到v3是保存的我们输入的密码内容,这里使用utf-8获取他的字节数组,然后传递给access$0方法,我们使用F5进入这个方法:
在这个方法中,还有一个bytesToAliSmsCode方法,使用F5进入:
那么这个方法其实看上去还是很简单的,就是把传递进来的字节数组,循环遍历,取出字节值,然后转化成int类型,然后在调用上面获取到的table字符串的chatAt来获取指定的字符,使用StringBuilder进行拼接,然后返回即可。
按F7跳出,查看,我们返回来加密的内容是:日日日日,也就是说gggg=>日日日日
最后再往下走,可以看到是进行代码比对的工作了。
那么上面我们就分析完了所有的代码逻辑,还不算复杂,我们来梳理一下流程:
A>调用MainActivity中的getTableFromPic方法,获取一个table字符串
我们可以进入看看这个方法的实现:
这里可以大体了解了,他是读取asset目录下的一个logo.png图片,然后获取图片的字节码,在进行操作,得到一个字符串,那么我们从上面的分析可以知道,其实这里的table字符串类似于一个密钥库。
B>通过MainActivity中的getPwdFromPic方法,获取正确的密码内容
C>获取我们输入内容的utf-8的字节码,然后调用access$0方法,获取加密之后的内容
D>access$0方法中在调用bytesToAliSmsCode方法,获取加密之后的内容
这个方法是最核心的,我们通过分析知道,他的逻辑是,通过传递进来的字节数组,循环遍历数组,拿到字节转化成int类型,然后在调用密钥库字符串table的charAt得到字符,使用StringBuilder进行拼接。
通过上面的分析之后,我们知道获取加密之后的输入内容和正确的密码内容做比较,那么我们现在有的资源是:
密钥库字符串和正确的加密之后的密码,以及加密的逻辑
那么我们的破解思路其实很简单了,相当于,我们知道了密钥库字符串,也知道了,加密之后的字符组成的字符串,那么可以通过遍历加密之后的字符串,循环遍历,获取字符,然后再去密钥库找到指定的index,然后在转成byte,保存到字节数组,然后用utf-8获取一个字符串,那么这个字符串就是我们要的密码。
下面我们就用代码来实现这个功能:
代码逻辑,很简单吧,其实这个函数相当于上面加密函数的bytesToAliSmsCode的反向实现,运行结果:
OK,得到了正确的密码,下面来验证一下:
哈哈,不要太激动,成功啦啦~~。破解成功。
补充:
刚刚我们在断点调试的时候,看到了代码中用了Log来打印日志,tag是lil,那么我们可以打印这个log看看结果:
看到了,这里table是密钥库,pw是正确的加密之后的密码,enPassword是我们输入之后加密的密码。
所以从这里可以看到,这个例子,其实我们在破解apk的时候,有时候日志也是一个非常重要的信息。
破解需要的资料,我已经上传了,下载地址:http://download.csdn.net/detail/jiangwei0910410003/9526113
1、我们通过apktool工具进行apk的反编译,得到smali源码和AndroidManifest.xml,然后修改AndroidManifest.xml中的debug属性为true,同时在入口处加上waitForDebug代码,进行debug等待,一般入口都是先找到入口Activity,然后在onCreate方法中的第一行这里需要注意的是,apktool工具一定要加上-d参数,这样反编译得到的文件是java文件,这样才能够被Eclipse识别,进行调试。
2、修改完成AndroidManifest.xml和添加waitForDebug之后,我们需要在使用apktool进行回编译,回编译之后得到的是一个没有签名的apk,我们还需要使用signapk.jar来进行签名,签名文件直接使用测试程序的签名文件就可以,最后在进行安装。
3、然后我们将反编译之后的smali源码导入到Eclipse工程中,找到关键点,进行下断点,这里的关键点,一般是我们先大致了解程序运行的结构,然后找到我们需要破解的地方,使用View分析工具,或者是使用jd-gui工具直接查看apk源码(使用dex2jar将dex文件转化成jar文件,然后用jd-gui进行查看),找到代码的大体位置。然后下断点,这里我们可以借助Eclipse的DDMS自带的View分析工具找到对应控件的resid,然后在全局搜索这个控件的resid,或者直接在values/public.xml中查找,最终定位到这个控件位置,在查看他的点击事件即可。
4、设置远程调试工程,首先运行需要调试程序,然后在DDMS中找到对应的调试服务端的端口号,然后在Debug Configurations中设置远程调试项目,设置对应的调试端口和ip地址(一般都是本机pc,那就是localhost),然后红色小蜘蛛变成绿色的,表示我们的远程调试项目连接关联上了调试程序,这里需要注意的是,一定需要关联正确,不然是没有任何效果的,关联成功之后,就可以进行操作。
5、操作的过程中,会进入到关键的断点处,通过F6单步,F5单步进入,F7单步跳出,来进行调试,找到关键方法,然后通过分析smali语法,了解逻辑,如果逻辑复杂的,可以通过查看具体的环境变量的值来观察,这里也是最重要的,也是最复杂的,同时这里也是没有规章可寻的,这个和每个人的逻辑思维以及破解能力有关系,分析关键的加密方法是需要功底的,当然这里还需要注意一个信息,就是Log日志,有时候也是很重要的一个信息。
6、最后一般当我们知道了核心方法的逻辑,要想得到正确的密码,还是需要自己用语言去实现逻辑的,比如本文中的加密方法,我们需要手动的code一下加密的逆向方法,才能得到正确的密码。
1、使用apktool工具进行反编译有时候并不是那么顺利,比如像这样的报错:
这个一般都是apktool中解析出现了错误,其实这个都是现在apk为了抵抗apktool,做的apk加固策略,这个后面会写一篇文章如何应对这些加固策略,如何进行apk修复,其实原理就是分析apktool源码,找到指定的报错位置,进行apktool代码修复即可。
2、本文中说到了Java的调试系统,但是为了篇幅限制,没有详细的讲解了整个内容,后面会写一篇文章具体介绍Java中的调试系统以及Android的调试系统。
3、有时候我们还会遇到回编译成功了,然后遇到运行不起来的错误,这个就需要使用静态方式先去分析程序启动的逻辑,看看是不是程序做了什么运行限制,比如我们在静态分析那篇文章中,提到了应用为了防止反编译在回编译运行,在程序的入口处作了签名校验,如果校验失败,直接kill掉自己的进程,退出程序了,所以这时候我们还是需要使用静态方式去分析apk。
4、如何做到不修改AndroidManifest.xml中的debug属性就可以进行调试:
1》 修改boot.img,从而打开系统调试,这样就可以省去给app添加android:debuggable="true",再重打包的步骤了。 2.》直接修改系统属性,使用setpropex工具在已经root的设备上修改只读的系统属性。使用此工具来修改ro.secure和ro.debuggable的值。
这个也会在后面详细介绍这两种方法
这篇文章我们就介绍了如何使用Eclipse去动态调试反编译之后的smali源码,这种方式比静态方式高效很多的,比如本文中的这个例子,其实我们也可以使用静态方式进行破解的,但是肯定效率没有动态方式高效,所以以后我们又学会了一个技能,就是动态的调试smali源码来跟踪程序的核心点,但是现在市场上的大部分应用没有这么简单就破解了,比如核心的加密算法放到了native层去做,那么这时候就需要我们去动态调试so文件跟踪,这个是我们下一篇文章的内容,也有的时候,apk进行加固了,直接在apktool进行反编译就失败了,这时候我们就需要先进行apk修复,然后才能后续的操作,这个是我们下下篇的文章,如何应对apk的加固策略。通过这篇文章我们可以看到动态方式破解比静态方式高效的多,但是有时候我们还需要使用静态方式先做一些准备工作,所以在破解apk的时候,动静结合,才能做到完美的破解。