美文网首页
如何实现一个防重打包的APK【反脱壳反HOOK】

如何实现一个防重打包的APK【反脱壳反HOOK】

作者: dfg_fly | 来源:发表于2021-12-02 21:47 被阅读0次

    APK需要被重打包,势必是为了修改其中的代码,可能是dex,可能是so,可能是dll(unity3d),也可能是某个脚本等等,重打包后签名(未泄露)就会被改变。

    不管怎样,可以确定的是签名和其中的某些文件会被修改。

    那么防止重打包的主要目标就是检测这些修改

    在保护之前,先来说说cracker可能会干的几件事:

    1.爆破。直接修改代码,常见于纯java编写的或者简单的so校验。

    2.脱壳。如果方法1不行,那可能是APK被加固了,所以可以考虑脱壳后再修改。局限性很大,困为很多壳脱出来没法直接打包运行。但是脱壳可以了解程序逻辑,为方法3做准备。

    3.内存补丁。如果方法2不行,那就不脱壳了,根据程序逻辑,可以直接加载自己编写的so打内存补丁跳过检测。

    4.hook,这可能是最近几年用得最多的方案了。上面所有方法试了不行(或者懒得试了),就要走上hook这条路了。

    针对以上,可以做的事:

    1.针对爆破。这没啥好说的,把校验写进so,复杂一点,花里胡哨一点,再弄个ollvm,或者加个壳。

    2.针对脱壳。上文就说了,很多壳脱出来直接打包是不行的,也有些壳是脱不了的,比如java转c(保护java代码),vmp(保护so),加壳之后原指令彻底消失不见,也就不存在脱壳的说法了。

    3.针对内存补丁。这个方法其实很冷门,因为内存补丁对逆向要求较高,有能力读懂ollvm和加壳后的so的逻辑的,基本很难阻止他做事了。

    4.针对hook:

    做为最热门的方法,有必要单独拎出来多说几句。

    a)检测hook。方法太多了,各种hook都有或多或少的特征,要注意的是,会有诸如《通过hook绕过hook检测》之类的文章……今天你hook我,明天我检测你,后天你跳过我的检测,大后天我检测你跳过我的检测……对抗永无止境。

    b)不被hook。怎样不被hook?自己写函数。用java代码来举个例子,有一个bytes数据要计算它的md5,最简单的MessageDigest.getInstance("MD5").digest就完事了,如果调用了公共库,那么就容易被hook住,然后就bytes数据暴露了,计算结果也被修改了。所以多用原生类型自己写函数吧。

    下面开始真正做事

    1.对某些关键的逻辑(如果逻辑是用java写的,可以先套java转C壳)加一个壳。

    2.这个壳的静态代码中不存在任何svc特征,一旦加载so,先进行完整性校验,当校验需要读取APK时,释放svc代码执行读取操作,这样在内存搜索不到svc,也就无法被hook。如果要校验maps中是否有hook框架也在这里进行。

    3.当校验通过,再执行真正的程序逻辑,并且此时原程序逻辑的so是碎片化的(就像java的指令抽取),此时从内存dump出来的so也是不完整的,所以无法脱壳出原so。

    以上,实现了防爆破(加壳无法修改),防脱壳(so分解了,无法脱壳),防hook(svc即插即用,无法hook,除非改内核)。

    然后,就只有内存补丁一条路了。

    APK内的AndroidManifest.xml,resources.arsc,classes.dex,这3个文件全部修改一下,就会触发完整性保护。有兴趣的可以试试。

    相关文章

      网友评论

          本文标题:如何实现一个防重打包的APK【反脱壳反HOOK】

          本文链接:https://www.haomeiwen.com/subject/uxpuxrtx.html