还剩3页未读,继续阅读
文本内容:
先来说一下一些常用的加密方法伪加密 伪加密是Android
4.
2.x系统发布前的加密方式之一,通过j__a代码对APK压缩文件进行伪加密,其修改原理是修改连续4位字节标记为”PK0102”的后第5位字节,奇数表示不加密偶数表示加密 虽然伪加密可以起到一定防破解作用,但也会出现问题,首先使用伪加密对其APK加密后市场无法对其进行安全检测,导致部分市场会拒绝这类APK上传;其次,伪加密的加密方式和解密方式也早已公布导致它的安全程度也大大降低;再次,Android
4.
2.x系统无法__伪加密的APK;最后伪加密只是对APK做简单保护,在j__a层源码加壳保护、核心so库、资源文件、主配文件、第三方架包方面却没有任何保护处理注意高版本不支持这样的方法,所以还是不要尝试使用这样的加密方式了混淆加密 把原来有具体含义的类名,变量名,方法名,修改成让人看不懂的名字,例如方法名getUserName编程了方法名 破解耐心运行时验证 运行时验证,主要是指在代码启动的时候本地获取签名信息然后对签名信息进行检验来判断自己的应用是否是正版,如果签名信息不是正版则提示盗版或者直接崩溃当然你可以把必要的数据放在服务器端破解找到__ali文件中,判断是否相等的部分改为常量true即失效总之,反编译一些apk之后,只要是j__a代码写的总会有__il文件对于__il文件,如果耐心读的话,还是可以查看到一些关键代码的 相较于应用来说,游戏apk因为采用cocos2d-x或者unity3D,采用的是c++和c#编写的跨平台程序,在apk采用JNI的方式所以没有__ali,可以防止静态被破解apk包当然游戏包apk在运行的时候,会把.*so加载到内存中动态也是可以在内存中抓取相应的数据只不NDK相对于__ali破解来说,根部不是一个层级的关系难道真的就没有好的加密方式吗想做一个应用非要把核心部分使用ndk这么复杂的东西嘛其实,我们完全可以借助第三方工具比如爱加密以我上次使用gameChange.apk为例这是我在爱加密__申请的加密程序 该classes.dex是我原来的代码没有混淆,没有任何的加密保护反编译的话,真的是____的漏了出来 该classes.dex是经过爱加密处理之后的,反编译之后发现莫名其妙的代码其实这两个类是,运行使用jni加载so库的代码 NativeApplication类,加载exec.so和exec__in.so,里面应该是固定的代码,是对源码
1.packagecom.shell;
1.
1.importandroid.app.Application;
1.
1.publicclassNativeApplication
1.{
1. static
1. {
1. System.loadLibraryexec;
1. System.loadLibraryexec__in;
1. }
1.
1. publicstaticnativebooleanloadApplicationpara__pplicationStringparamString;
1.
1. publicstaticnativebooleanrunApplicationpara__pplicationStringparamString;
1.
1. publicstaticnativebooleanrunAllApplicationpara__pplicationStringparamString;
1.}SuperApplication继承自Application,程序主入口
1.packagecom.shell;
1.
1.importandroid.app.Application;
1.importandroid.content.Context;
1.
1.publicclassSuperApplicationextendsApplication
1.{
1.protectedvoidattachBaseContextContextparamContext
1.{
1.super.attachBaseContextparamContext;
1.NativeApplication.loadthiscom.example.gamechange;
1.}
1.
1.publicvoidonCreate
1.{
1.NativeApplication.runthisandroid.app.Application;
1.super.onCreate;
1.}
1.}在加密之后的apk包中,多了一个assets目录,该目录下,有一些ijiami.dat,其实这个就是我们原来的clas___.dex 基本原理是在jni层,使用DexClassLoader动态加载技术完成对加密clas___.dex的动态加载,内存中解密clas___.dex,完成动态加载PS使用DexClassLoader动态加载技术 可以使用AndroidDexClassLoader完成DEX的动态加载,DEX文件可以附属在assert或raw目录也可以运行时从网络下载 我们知道DexClassLoader加载的类是没有组件生命周期的,也就是说即使DexClassLoader通过对APK的动态加载完成了对组件类的加载,当系统启动该组件时,还会出现加载类失败的异常___组件类被动态加载入虚拟机,但系统却出现加载类失败呢?通过查看Android源代码我们知道组件类的加载是由另一个ClassLoader来完成的,DexClassLoader和系统组件ClassLoader并不存在关系,系统组件ClassLoader当然找不到由DexClassLoader加载的类,如果把系统组件ClassLoader的parent修改成DexClassLoader,我们就可以实现对apk代码的动态加载总结一下,爱家密的加密步骤把原来的clas___.dex用未知的加密算法实现加密成assets/ijiami.dat把事先写好的jni代码和相应的clas___.dex替换到原有的位置程序__完运行起来以后,先运行爱加密的加壳程序,在jni里面动态加载原来的clas___.dex代码,从而达到加壳保护的目的.源clas___.dex隐藏起来了,在静态的时候就没有办法对其破解至于动态运行,最好还是在自己代码里面下工夫了比如内存加密啦由于申请加密之后,爱加密需要增加自己资源(两个so一个clas___.dex文件和三个bin文件)只增加了
198.1KB的容量,对于我们动辄上百MB的游戏app而言,这点都不算事儿。