如何保护你的Auto.js代码


我与autojsの羁绊-保护篇

想必很多读者有这种经历,本以为代码完成后万事大吉,却在某一天的早晨,惊现 “xx工具破解版”,”xx源码首发”。(啊~暴击x10000(>_<))。就在发布这篇文章的前几天,我发布了第一款用autojs编写的小工具release版,于是开始研究autojs的代码保护,总结了本文。

今天是我与autojs相遇已快2个年头,为了写这一篇文章,我对autojs进行了构思得出了一个全称。(估计作者当时也不是这样想)

Android Uiautomation To Obey JavaScript
(服从js指令的安卓自动化工具 简称: autojs)

明确保护对象

对于大部分开发者来说,保护往往都是弱项。然而要保护好对象,我们就得先了解对象是谁,我们才能选择更适合TA的保护方式。autojs 作为一款依赖rhino引擎执行js指令实现自动化的工具,所以我们可以知道重点保护对象是js里的代码。但autojs里的js,不仅仅只有js,独立打包会生成一个apk文件,并通过这个apk框架解析我们的js文件来进行运作。简单理解则是 apk框架+js脚本。

apk框架是开发者提供的,每个人都一样的,不一样的只有使用者们编写的js脚本,那如果说你加了一个360的壳,保护的仅仅是框架,而不是js文件。再好的保护,用得不在其位,效果云泥之别。

常用的加密方式

首先来看看autojs提供的加密方式,一共有三种:

autojs自带保护

编者注:Auto.js Pro 9.2即将推出更强的在线加密和Node.js加密,敬请期待。

这3种都是对js脚本做的防破保护,但由于是官方提供的保护,研究它的人自然也多,因为这些保护方向固定。所以只要解过一遍,就基本解了所有同类保护的脚本。但不代表我们就不可以加以利用,就像上面说的,组合拳永远比直拳带来更多伤害,多重保护也是一种保护手法。

抛开官方提供的加密,再则大部分使用的就是网上的js混淆加密。在这里我们得思考一个问题,无论对js进行多深的保护,最终若要被引擎所解析,它都会在引擎调用之前变回引擎所能识别的样子。否则脚本根本无法运作。所以对于js混淆加密,所有解密算法都会集中在js文件里,最终破解者也仅仅需要对js进行分析即可解密。

v6混淆

上图中,红色为加密后的数据,绿色为解密算法,蓝色为混淆后的js代码

从这里可以看出,仅仅只对js单方面做保护是一件不放心的事情。所以本文的思路是把js融合进apk框架里,而不是把autojs独立包分成js脚本+autojs框架。

Dex2c代码保护

对于程序来说,最好的保护就是与云端之间的交互,但作为工具英语来说,大部分都是本地化功能。退而求其次,在Android程序里最好的保护就是把代码写到native里。

看雪上krash提供了他的开源工具dex2c,通过此工具可以直接将java代码编译为so,结合autojs提供的将js编译成dex文件的功能,我们就可以打出一套完整的组合拳了。

手机上也有现成的dcc工具,比如:

  • NP管理器 (一款免费的文件管理器,里面提供多种加密保护,不过它版本的dcc失败率比较高,且过程比较漫长)
  • arm pro (这是一款收费版云端加密工具,需要将apk上传到云端进行加密,加密快,兼容性好)

本文以NP管理器为例。

1. Dex加密

编写好脚本ui与代码后,选择打包单文件,并且在加密选项里选择 “离线dex加密”。此加密模式是将js编译到apk框架的java代码里,这样就可以让apk框架与js脚本融合了。

离线dex加密

2. NP管理器

现在可以使用np管理器对其进行加密保护了,点击需要保护的apk文件,选择功能。

功能

保护

3. 控制流混淆

如果代码量比较少,并没特别速度要求,可以考虑先来一波控制流混淆,它会将代码拆分成多个分支进行运作以提高逆向难度。图中就是它混淆后的逻辑代码,但是因为逻辑变多了,所以就会影响到脚本速度。

Np管理器里其实有2种控制流混淆,一种是开发者整合提供的,另一种则是blackdex开发者提供的milk控制流混淆,这里选择第二种,并输入需要保护的类路径,后面*号为目录下所有文件都进行保护,如果只需要对几个类进行保护,请直接写上完整路径即可。我们填上”org.autois.autoispro.gen.*”。

milk控制流混淆

保护好后会在同目录下新增命名为_flow的apk文件,至此就完成了控制流保护。

4. dex2c

此时需要再进行dex2c保护(如果未使用控制流混淆,请选择原包进行,使用控制流混淆请选择flow包进行),保护方式与控制流一样,这里就不再阐述,直接上图。

dex2c

完成后会再次在同目录下新增一个apk包,此时可以通过反编译查看代码是否保护成功,图中可以看见已经编译成native类型了,所以保护成功。

dex2c后

5. VMP保护

新包里的lib目录下则会新增名为libstub.so的文件,将其拖出来,并前往第三方加固对so文件进行加密。再把加密后的文件下载并拖回去替换新包里的libstub.so文件。由于dex2c仅仅只是将java代码编译到native可解析的类型以防止还原,但它并不具备加密效果,所以才需要通过so加固把代码里的字符串与代码进行vmp保护,到这里组合拳已完成。

比如小密盾加固(网站需要注册登录才可使用)

dex2c新增so

6. 加固

由于js脚本已融合到java与native里,现在我们可以对其进行加固保护就能达到保护效果了,可以自行前往各大加固厂进行加固保护(如不需要可忽略此步骤)

后记

保护手法千变万化,并不是你加得多就是最好的保护,而是需要对症下药的去保护你需要保护的对象,这样才能达到你预期的保护效果。另外你也可以自己对脚本进行校验保护,签名保护,防hook保护,逻辑复杂的验证保护,云端数据验证等,然后再使用本文里的保护手法效果会更佳。


本文不允许转载。
  目录