核心：破解安卓NDK端native方法动态JNI反射的so文件签名校验
分析之前，关于Android的签名机制就略过啦，先简单恶补一下Android签名校验的方式，方便小白理解。
在讲签名校验的方式前，需要先明确dex文件校验和签名校验：
1、将apk以压缩包的形式打开删除原签名后，再签名，安装能够正常打开，但是用IDE工具反编译(classes.dex)后再二次打包，却出现非正常情况的，如：闪退/弹出非正版提示框。可以确定是dex文件校验。
2、将apk以压缩包的形式打开删除原签名再签名，安装之后打开异常的，则基本可以断定是签名检验。如果在断网的情况下同样是会出现异常，则是本地的签名检验。如果首先出现的是提示网络没有连接，则是服务器端的签名校验。
对于Android编程我们知道分为SDK编程和NDK编程，当然Android签名校验也都是通过SDK或NDK来实现的。SDK编程也就是我们通常所说的java端的即编译出来的classes.dex静态校验，NDK编程也就是C / C++端的即编译出来的*.so动态加载的校验。
总之，
Java层一般通过getPackageManager().getPackageInfo.signatures来获取签名信息。
NDK层一般调用Native方法/DLL/Lua脚本等通过获取Java的context/Activity对象，动态JNI反射调用getPackageInfo等来获取签名。
好了，话不多说，切入正题。
群里聊天，小伙伴找我去除某款图像处理软件的广告，介于此软件已一年未更新，且互联网上出现的修改版均无法使用。。。。那么。。开搞。。。。
apk重签名，闪退，断定有签名校验。
直接拖入AndroidKiller大法，一段等待之后反编译完毕。
因为没有错误提示，那么对整个项目搜索
signatures
或
[Landroid/content/pm/Signature
或
Landroid/content/pm/PackageInfo;->signatures:[Landroid/content/pm/Signature
或
Ljava/security/Signature;->verify([B)Z
等一系列可能调用或者判断签名的方法
我们基本找到四处可能为签名对比函数的验证，我们让其强制返回true。
满心欢喜的回编译，安装。。。。。
结果。。依旧闪退。。。内心无数匹你懂得马奔驰而过。。。。
看到\lib目录和\assets\lib目录下的.so文件，我倒是有些怀疑悬疑在.so动态文件中。
继续对整个项目搜索
loadLibrary
或
Ljava/lang/System;->loadLibrary(Ljava/lang/String;)V
等一系列读取.so文件的方法
我们得到了三个结果，前两个是图像处理的lib，第三个嘛。。。别急啊！先等等。。。
以armeabi-v7a架构为例，我们把所有lib都弄到一起，用EditPlus或者UltraEdit呀notepad++呀之类的编辑器来全局搜索signature
看看我们得到了什么~
我的天哪，有戏啊！
说时迟那时快，我的IDA已经饥渴难耐。
New-Open-Ok一气呵成！
打开文本查找：
搜索signature 勾选上Find all occurences
搜索完毕，没什么说的，妥妥的在5个Function中找到
双击第一个Function跳过去
右键选择Graph view切换图形视图
通过视图，我们找到了一个关键跳转（可以通过Ctrl+鼠标滑轮来调整视图缩放）
右键选择Text view切换回文本视图
其对应的就是文本视图界面中的
F5看一下C语言代码（这样做的前提是，你的IDA Pro必须支持F5功能）
通过分析C代码我们得知这里将获取到的签名信息进行判断，
由此我们得知BEQ指令就是问是不是不相等，不相等那么为真的意思。而查阅之后印证了我们的判断：
BEQ指令是“相等（或为0）跳转指令”，
BNE指令是“不相等（或不为0）跳转指令”，
B指令是“无条件跳转指令”，
CBZ 指令是“比较，为零则跳转”，
CBNZ指令是“比较，为非零则跳转”。
通过工具，我们发现：
BNE跳转指令对应的HEX机器码是D1，
BEQ跳转指令对应的HEX机器码是D0，
CBZ跳转指令对应的HEX机器码是B1，
CBNZ跳转指令对应的HEX机器码是B9。
回过头来，简单的看一下指令流程，BEQ下面是exit方法，则说明不能跳转指令为签名验证失败，反向逻辑一下，把BEQ指令改为相反的BNE指令即可。
修改方式一：我们可以在HEX界面右键Edit将D0改为D1，再右键Apply changes来保存修改，需要注意的是，在IDA中的修改仅仅是为了验证我们修改的正确与否，源文件并不会改变，我们可以定位修改位置后再利用010Editor、UltraEdit等编辑器来对源文件进行修改。
验证发现BEQ已经修改为BNE
修改方式二：当然，强大的IDA怎么可能没有修改后保存的功能呢。我们可以使用Edit->Patch Program菜单来方便的进行修改保存。
（需要注意的是，Patch Program菜单是GUI版本的IDA的一项隐藏功能，用户需要编辑idagui.cfg配置文件才能激活该菜单， 编辑IDA配置文件cfg目录下的idagui.cfg，修改DISPLAY_PATCH_SUBMENU=YES，重启IDA即可）
首先我们在IDA View 中显示十六进制机器码, Options -> General -> Disassembly -> Number of opcode bytes = 8
然后Edit->Patch Program->Change byte
将D0改为D1，OK
然后Edit->Patch Program->Apple patches to input file
OK即可
同理，我们找到其他方法中的跳转点来进行反向逻辑，保存so文件，覆盖原文件，回编译，安装。完美运行~
具体去广告过程不是本次重点所以就不再过多陈述，另外说一点sdk23以上的权限请求问题，当过完签名校验并去除广告后，当要读取图库照片来进行处理时，原本应该进行文件存储的权限请求，但是此时却FC了，当我手动给予权限后才正常。想想就苦恼，让人安装后边还得手动给权限。。。。
不行，我们得解决了它。我们知道如果APP运行在Android 6.0或以上版本的手机，并且target sdk>=23，那么在使用一些相对敏感的权限时，需要征求用户的许可。比如读写sdcard，摄像，联系人信息等。 这是Android 6.0，在原有的AndroidManifest.xml声明权限的基础上，新增了运行时权限动态检测。不过为了兼容性，Android为targetSdkVersion小于23的应用默认授予了所申请的所有权限，所以如果你以前的APP设置的targetSdkVersion低于23，也能正常使用。等于或者大于23，则必须 request permission,否则会崩溃闪退。
当我们用apktool反编译后破坏了complierSdkversion的值，我们可以在apktool.yml中的sdkInfo中添加complierSdkversion: '23'，或者干脆我们索性将targetSdkVersion设置为22，默认给它权限就好了。(complierSdkversion的值和targetSdkVersion的值一定要统一，不然会出错)
修改apktool.yml文件完美解决~
步骤回顾：
1、反编译apk
2、利用关键词查找签名调用
3、IDA静态调试分析
4、了解arm指令详情作用
5、修改逻辑跳转绕过签名校验
总结：
本文主要介绍破解安卓NDK端native方法动态JNI反射so文件签名校验的方法。
