地址：https:/www.jianshu.comp/fe0206f8be5b
前言
方法一：如果把so放在libs/armeabi/下，eclipse中so会自动打包进去，然后使用System.load("data/data/xxx.xxx.xxx/lib/xx.so")；载入so。方法二：如果放到assert下的话，程序运行后将assert中的so写到data/data/xxx.xxx。.
昨天dfqin同学给我们分享了移动端加密和混淆的相关知识。今天让继续跟着他学习其他移动端的安全知识。
NDK
NDK全称为Native Development Kit，翻译过来叫原生开发工具包，官方解释是可以在Android中使用C/C++的工具。我没找到这里Native的详细解释，个人理解常规Android程序是运行在虚拟机上面的，而Native指直接运行在操作系统上面的程序，可以调用操作系统的API。
一般情况下我们没有必要使用NDK，官方也提到了使用native开发会增加开发过程的复杂性。但是对于一些计算密集型的应用，例如游戏、图像处理，使用NDK能提高运算性能。还有一些情况为了复用现有库或者跨平台库，也会选择NDK。上面提到的一些核心算法和秘钥，大家选择放到native层，潜意识中也是默认native的破解难度比java高，还有欺负大部分Android程序员不会写C/C++代码:)
我们可以创建一个新工程，创建时勾选上"Include C++ support"，如下图：
这时会创建一个支持NDK的默认工程，项目里包含从C++代码中获取一个字符串的demo：
我们编译出apk并反编译这个程序如下图，会发现包里面多了一堆libnative-lib.so(其实只是一个库，为了支持不同的CPU架构编程出了多个版本)。
字符串的生成的实现放到了这个so库里面，相比较直接在java代码中生成字符串，破解起来的确麻烦了些。这个时候如果想破解拿到这个字符串，so文件格式手机怎么打开，该怎么办呢？，
字符串的生成的实现放到了这个so库里面，相比较直接在java代码中生成字符串，破解起来的确麻烦了些。这个时候如果想破解拿到这个字符串，该怎么办呢？
对创建的文件夹进行昵称，在昵称中进行输入“jnilibs”，然后点击“ok”。这样在main的文件中创建一个为jnilibs的文件夹。然后在jinlibs中文件进行添加so的文件，进入到so文件存放的文件中，直接把so的文件拖动到jinlibs的文件。
一个简单的办法，直接写java代码，通过jni调用这个so的方法。这尼玛就尴尬了，本来封装so是为了隐藏数据，结果倒好，别人才不管你怎么实现，把你直接拿来用。为了避免这种尴尬，我们可以在so中判断当前应用的签名，前面分析过，只要别人拿不到你的keystore就没办法伪造你的签名。如果没办法直接调用这个so，只能想办法破解才能洞察到里面隐藏的秘密了，下面我们谈一下怎么来破解。
PE/ELF和反汇编
其实在Windows系统上我们平时运行的.exe安装文件和使用共(破)享(解)软件时用来覆盖的.dll动态链接库文件，都是PE格式文件。在Linux系统上(我们可以把Android理解为Linux系统)的.o目标文件、.a静态连接库和.so动态连接库，都属于ELF文件。如下图所示，一段C程序编译生成ELF文件后的结构
当然我们直接用文本编辑器打开so文件，看到的是如下二进制文件：
根据ELF文件格式的定义，可以把这个二进制文件还原为图3.4右边的结构。这些细节很复杂我们也没必要去全部弄清楚，我们可以使用一些命令直接查看ELF文件。以图3.2中的C++代码生成的so为例，我们输入：
readelf -a libnative-lib.so
可以看到结果：
.so文件是linux平台下的动态链接库，反编译动态链接库参见windows下*.dll文件的反编译，类似的 Linux：是一套免费使用和自由传播的类Unix操作系统，是一个基于POSIX和UNIX的多用户、多任务、支持多线程和多CPU的操作系统。它。
内容很长，不了解ELF格式的话很难看懂(我这里在使用“greadelf”是因为使用的mac系统自己安装的类似工具)，我们可以先大概看一下，这里的“节头”其实就是对应的图3.4中的section，我们可以查看第12个segment——.rodata:
我们发现了之前辛苦藏到so中的字符串"Hello from C++"。如果想看代码实现，可以使用objdump命令，能看到反汇编后的代码。
现在我们可以理解ELF文件已经是机器指令了，我们如果想看一些代码逻辑，要么像机器一样读机器指令，要么把这些机器指令反编译成人类方便阅读的汇编代码(汇编语言人类也很难读的好吧)，这个过程我们就是反汇编。
当然真正去破解一些so文件时，使用上面的办法效率太低，这是可以去使用一些专业的破解工具，里面集成了很多很强大的功能，可以大大提高工作效率，例如使用IDA直接把so打开，我们可以很方便的定位到jni函数：
加壳与脱壳
在当时就有了加壳脱壳这个说法，看一些破解软件的文章时，第一步基本都是脱壳。加壳直观理解就是给程序加一层壳，可以用来对原程序进行资源压缩、防调试、防注入、防反编译，也就是说通过一个壳把原来的程序保护了起来。
我们知道一个常规Android程序它的所有代码都在dex文件中，程序启动时要先把这个dex文件载入到内存中，所以如果要加壳的话，主要工作就是把原dex文件加密或者隐藏起来，放一个新的壳dex到apk中，程序启动时运行这个壳dex，然后这个壳dex在运行时再加载原dex，用一张图表示如下：
打开 SO文件的最快速最容易的方法便是双击文件。这样做可以让Windows智能决定使用正确的程序打开SO文件。若出现无法打开SO文件的情况，很可能是因为电脑上没有安装查看或编辑SO文件扩展名的恰当程序。若电脑打开了SO文件，但使用。
其实这时候我们发现，破解原dex的工作变成了破解壳dex了，最终的原理是一样的，早期的梆梆、360等公司的加固方案都被人破解，网上能查到破解步骤。当然他们的加固方案升级很快，网上看的破解方案对于新的加固方案基本已经无效。我们使用腾讯的乐固加密一个不包含so库的APK后反编译后可以看到如下：
我们可以看到程序一开始就加载了libshella.so库，这里我们可以推测我们的原dex被加密为了mix.dex和mixz.dex，dex的动态还原方案的实现放到了libshell.so库中，即dex的加壳方案放到了so实现，再次佐证了大家公认so的破解难度比较高。这里我测试发现这两个so使用IDA反汇编工具已经无法直接打开了，很显然这个so是加过壳的。
关于so的脱壳，我也是小白，就不班门弄斧了，这里乐固.so V2.8版本的脱壳方案(乐固目前最新是V2.10)，可以证明上面我们的推测是正确的，大家有兴趣可以看一下
.comthread-217556.htm
补充： 这是一年前的文章，当时认为加固是比较安全的方案，毕竟逆向so成本非常高，后面发现使用像xposed框架这样的hook技术，类似于降维打击，可以绕过加固技术轻松获取到dex文件。目前的乐固、360等大厂加固都可以绕过，从原理上看，加固技术对于这种hook技术获取dex也没有什么好办法，作为APP的作者，需要加强hook方面的防御来提高加固技术的安全性，后面有时间的话我会写一篇文章介绍这方面的攻防。
今日问题：
你的应用出过安全事故嘛？
打卡格式：
打卡 X 天，答：xxx 。
