反编译与逆向分析apktool之初体验

由于工作原因,所以需要对Android的apk文件反编译做一些了解,当然,首先开始就要选择工具进行解包了,在之前因为做过这方面的一些需求,所以毫无犹豫的使用了apktool来解包,apktool的命令非常简单,这里就不多说了。

最近几天解包合包非常频繁,于是乎不出意外就遇到了这种:
(1).解包时候还好好的,合包时候就抽风:

反编译与逆向分析apktool之初体验_第1张图片
Paste_Image.png

(2).相同的apktool,上一个文件还没有问题,再解一个新包的时候:

反编译与逆向分析apktool之初体验_第2张图片
Paste_Image.png

(3).换了个apktool来解包,直接失败,然后再换一个apktool,还是失败:

反编译与逆向分析apktool之初体验_第3张图片
Paste_Image.png

此时我的内心是崩溃的,不同版本的apktool差异如此巨大,这活儿还怎么干。
当然后来都找出来了原因:

(1).由于本身包体太大,文件的资源目录太长,导致windows在执行cmd命令时超出了windows命令行极限长度8091个字节,当时使用的是apktool 2.0.2,于是自己换成了apktool 2.0.0居然就可以了,虽然我也不知道为什么会低版本正常,但是高版本居然出问题

(2).比如在使用了apktool 2.0.2对demoA进行了解包,下次我换成apktool 2.0.0对demoB进行解包,此时会异常,因为必须要删除这个文件:


Paste_Image.png

具体为什么要删除?对不起,我也不知道

(3).在对这个游戏包进行解包时,使用apktool 2.0.0失败,换成2.0.2就成功,就是这么任性,原因?对不起,根本看不懂

看清楚了apktool的本质了吧?就是这么不靠谱,在之前曾经遇到过更坑的事情,将游戏提交给十个渠道,九个渠道都正常,就是有一个渠道,所有玩家在玩的时候,第一次打开,一定闪退,第二次就正常了,后来得知,渠道对所有提交的游戏包都会用自己的签名重新打上签名文件然后发行出去,最终检查出来这个高版本的apktool会将游戏包的资源压缩,但是CP并没有对资源做解压缩处理,所以导致找不到资源文件从而Crash,此刻从发行商到CP,到渠道商,内心都是崩溃的(apktool:怪我咯!)

所以现在使用这种方式解包,我的内心是拒绝的,为了解决出现apktool出现的诡异问题,目前只能是将2.0.0之后版本的apktool完全下载下来,然后使用的时候进行遍历,其实这种方式很傻,因为我们先看一眼apktool的版本:

反编译与逆向分析apktool之初体验_第4张图片
Paste_Image.png

嗯,每次都从第一个遍历,不行就试第二个,虽然可行,但是总觉得很傻。

所以在思考有没有更方便的方式,因为工作需要,我会修改smali文件以及AndroidManifest.xml文件,首先分两块思路:

(1).如果不用apktool的话,我该如何拿到apk里面的smali文件呢?
这个其实很简单,因为本身.apk文件就是一种文件压缩格式,我直接解压就可以拿到.dex文件:

Paste_Image.png
反编译与逆向分析apktool之初体验_第5张图片
Paste_Image.png

那么我们拿到.dex文件之后如何转换成.smali文件呢?
此时可以祭出大杀器--baksmali.jar,它可以将dex文件转成smali:


Paste_Image.png

打开指定的文件夹baksmaliFile文件夹:

反编译与逆向分析apktool之初体验_第6张图片
Paste_Image.png

OK,没有问题

(2).下一步开始操作我们需要的AndroidManifest.xml
在直接解压包之后,因为经过了aapt的操作,所以我们拿到的xml是无法操作的,
所以我开始想的是能不能通过aapt将xml直接导出来,然后再通过aapt将apk中的AndroidManifest.xml给remove掉,随后再将我处理过来的xml给add进去,结果当然是导出来啦:

反编译与逆向分析apktool之初体验_第7张图片
Paste_Image.png

可是,这个是什么鬼,怎么这么丑?

反编译与逆向分析apktool之初体验_第8张图片
Paste_Image.png

虽然能看懂,但不是我想要的,格式完全不对,只能想其他办法。

后来找到了AXMLPrinter2.jar这个神器:

Paste_Image.png

果然成功了:

反编译与逆向分析apktool之初体验_第9张图片
Paste_Image.png

但是俩不一般大让我感觉不舒服,不过还好,Androidmanifest.xml是一个二进制的AXML文件,后者就是一个纯xml,大小不一样很正常,浏览了一下,格式也比较舒服,看起来比aapt导出来的好多了:

反编译与逆向分析apktool之初体验_第10张图片
Paste_Image.png

(3).至于签名,可以使用jarsigner和需要的keystore文件来生成RSA和SF文件,然后进行替换,这个比较简单。

接下来的事情至于如何对smali文件进行插桩,如何对AndroidManifest.xml进行merge,我就可以交给脚本去做啦,包括后面的将AndroidManifest2.xml替换掉原来的AndroidManifest.xml我都可以放心的交给脚本去做啦!

前方高能:
这种替代apktool的方式其实我并没有经过更多的市场验证,甚至我自己的脚本都还没有完成,完全不知道是不是可能会不会有比apktool更多的坑等着我,只是因为被apktool折磨的不要不要的了,所以就想着有没有能满足自己需求的方式,我觉得如果不是对打包拆包有很大需求量的同学,不要尝试,因为apktool本身算是一个懒人集合工具包,它已经很完善了

只是那些跟我一样,对apktool的有以下几点很DT:
(1).感觉各个版本完全是不兼容的,一个版本的apktool和另一个版本的像是两个不同的工具
(2).出现的拆包打包crash日志完全看不懂,不知道在说什么
(3).对apktool的拆包合包的速度不能忍,通过解一个300M的包,我的8G内存的电脑通常就干不了什么了,通过解压和压缩回去,我觉得能将速度提升不少

对这一块有想法的同学可以跟我一起尝试一下有没有坑,如果有更好的方式,跪求分享 。

你可能感兴趣的:(反编译与逆向分析apktool之初体验)