android壳,浅谈Android某数字壳“修复”

真正的脱壳修复是脱壳后修复被抽空的onCreate方法里的代码，而这样的话需要从so中解密并自行修复代码。目前通用常见的所谓的脱壳修复，原理很简单，就是利用MultiDex机制，将脱出来的dex用作dex2，更多的还有dex3..等等，然后塞进安装包，当软件运行时，系统会优先加载脱出来的dex2,dex3.. ，从而达到修改的目的。这样做，可以去除签名校验，可以修改代码(当然除了onCreate方法里的代码)，但壳依然存在着，运行速度和性能依然有很大影响。当然，不可否认这是一个在不能修复onCreate方法前提下的唯一办法，在这里提一个建议，脱壳后的dex，不用完全塞进安装包，这样不仅影响性能，还添加了一倍的体积。所以，脱壳后，只需保留已经修改的类名，其余没有进行修改的可以全部删除，这样就不会造成不必要的性能损耗和体积膨胀。另外，塞进安装包后闪退的，你肯定是动了加固后的dex文件，这个文件一旦经过任何软件重新编译，都会成为一个废掉的dex，所以，这个文件(加固后的dex)必须原封不动，除非你脱壳并修复了onCreate方法的所有代码，否则安装后打开都会闪退。

关于脱壳后出现很多dex文件

脱壳，原理是利用xposed劫持系统的ClassLoader这个方法，然后dump出dex文件输出到本地。为什么打开应用进行dump的时候，会有这个多个dex文件？而且都不是软件内所需要的？原因很简单，ClassLoader这个方法，不仅仅加载软件所带的dex，还需要加载系统核心dex(java/lang/String，android/content/Context，android/app/Activity，java/io/InputStream 等等 )，所以dump dex的过程中，必然会dump 出许多系统dex文件和软件自带的dex文件。那么如何选择我所需要的dex文件呢，这个只需查看一下每个dex里的内容，如果含有和脱壳软件包名相同的关键字，则就是我们所需要的dex，凡事带有java.. javax .. sun..的 都是系统核心的dex，miui系统的还会有miui..等等 可以忽略。(注意，一些大型软件可能含有多个dex，尽量将脱出来的dex逐个查看，以免遗漏，多个dex可以重名为classes.dex2  classes.dex3..以此类推)(我一般都是优先查看体积较大的)

附件下载