某次ctf内部赛上出了一题android的re，算是第一次认真出题了23333
因为太菜了，这破题从开始想到写花我4天= =，最后还改了一个思路
首先吐槽一下小米3移动版，居然用的是英伟达的CPU，而联通、电信版是高通的
比较舒服的是小米已经开源了很多内核源码，资料基本都能查到
虽然安卓底层也是linux的内核，但因为安卓百花齐放，一堆不同的硬件、适配，不同版本的手机也有定制的内核，不然很可能出现某个硬件用不了的情况
另外，编译过程还出了很多的错误emmmmm
猜测是编译器版本不同导致的问题
一下算是手把手教如何编译一遍了……
在目前许多的Android应用加固中，都用到了so文件，并且通过针对so文件的section table进行混淆处理，以避免ida等逆向工具进行静态分析，因为在Android源码中，so的加载是完全不需要section信息的。
在此之前，很多文章都已经写到过关于Android so加载的流程，但很多都是基于Android4.x系统
虽然流程大同小异，但在Android5.0以后已经从Dalvik转换成ART，文件关系上已经对不上
因此，我针对Android7.1.2_r28的代码，对so加载过程进行分析
在加载一个so的时候，必然要写一句
1 | System.loadLibrary("native-lib"); |
那么，我们就从这个函数看起
接上一篇，接下来介绍7.0后新增的v2签名认证方式
与v1方式签名不同的是，v2的签名是对整个文件的一种签名方式
直接从字节码上对apk进行签名，不必遍历每个入口进行计算签名
并且每一个改动都会使得签名失败，因此其提高了签名认证的速度和签名保护的安全性
但是有一点得注意的是，v2签名仅用在7.0以上的系统中，因为只有7.0以上的系统有有关v2签名认证的代码
因此为了适配早前的系统，正常还是采用v1签名，或是v1v2签名并存
在后面的代码可以看出来，7.0以上的系统会先进行v2签名的认证，若没检测到v2签名信息，则再进行v1的方法
但是由于一些应用需要打包渠道包，每次修改再编译再签名实在太耗时，大部分会选择关闭v2签名
在build Gradle中添加
v2SigningEnabled false
因为在v1签名中，META-INF中的内容是不会检测的，这使得在打包渠道包时不需要重复重新签名
渠道包指的是在各大应用市场，发布的apk包的清单文件中，某个meta-data标签下，配置的value不一样，这个标签的作用就是用来区分是哪个市场的
因为某些不知名的原因，让我感觉很有必要学习一下apk签名的方式，于是。。。便有了这篇
（真的好久没写了哇，近期烦心事真的太多了）
我在网上搜了各种大大小小关于apk签名的文章，但始终没有能让我满意的，而且也感觉一直缺乏一篇能从字节上分析对比新旧两种签名方式的文章，so……
传统的安卓签名方式是通过jar的签名方式实现的，在apk包下，会有一个META-INF的文件夹，META-INF的文件夹下，会有MANIFEST.MF CERT.SF CERT.RSA三个文件，均是用于apk签名认证的。
而在Android7.0后，新增了一个APK Signature Scheme v2的签名方式，更为强效。而原来的签名方式则是 JAR-signed APK verification (v1 scheme)
详细可看官方的文档
https://source.android.com/security/apksigning/v2#v1-verification
为什么会想去破解这个app呢？正所谓有需求才有生产……
这一切都要从上个学期期末那个抽烟种树喝洗脚水的日子讲起……
（往事不堪回首，此处省略一个里约奥运碧池的苦水）
所以，其实forest的用处就是让你离开手机，设定种树时间，如果你在这个时间中打开了别的app，微信啊、QQ啊，总之如果你玩了手机，那么你的树就会死掉。