第一次尝试反编译绕过 apk 简单的 jni 签名校验
第一次尝试反向操作绕过 apk 简单的 jni 签名校验1. 现象
修改了应用的内容之后，搜索 smali 没发现有做应用的签名校验，但重打包之后应用打开直接出现闪退。查看日志，确定是 jni 方法做了签名校验。
Caused by: java.lang.UnsatisfiedLinkError: JNI_ERR returned from JNI_OnLoad in "/data/app/pkgpath/lib/arm64/libencryption.so"
错误出现在JniUtils去 load libencryption.so 的过程中，查看 java 代码，发现这个库是用来做 aes 加密的，每一个网络请求都会用到这个方法，把签名校验放到这里的JNI_Onload可以防止直接从java层去掉LoadLibrary。
打开（下载安装） IDA 看代码。
2. 定位
由于第一次下载 IDA ，最开始下的 IDA Free 不支持 arm，又重新去搞 IDA Pro。
第一次用了 ida64 去加载 armeabi-v7a 的文件，才直到需要区分64位，用不同的 exe。
终于成功加载了，直接搜索Signature，找到了一个checkSignature方法，然后在右边看不懂的界面里看到了熟悉的字符串，这个应该就是用来比较的本地签名缓存了。
因为是简单的签名校验，只要把这个值改成我们重签名之后的 MD5 值，应该就可以了。最简单粗暴的方法，直接改数据。。。
在 Hex View 中找到字符串，按 F2 编辑，可以看到直接改16进制的值，就可以生效了。把这一段替换好后，保存重打包，就可以正常运行了。
但这样改实在是太Low了，也没有学到任何知识。还是需要找到错误的出处，尝试去绕过校验，不是简单的修改签名
第一次用 IDA，边查教程边操作。先用Ctrl+F5让 IDA 反编译一个 C 的伪代码出来，IDA-View 里面全是指令，完全看不懂。
200KB 的 lib 直接导出了一个三万多行的 C 文件，看的让人头大。不过总算是能理一理逻辑了，先看出现错误的 JNI_OnLoad 方法。可以看到在判断签名非空和checkSignature的结果的地方，return -1或版本号。
定位到问题，接下来就要解决怎么改了。
3. 修改
作为只能看得懂一点点 smali 的菜鸡，对于 IDA 里面显示的内容没有一处能看得懂。
找到了对应的方法位置，要是 smali 代码，真的是随便就改掉了。这个第一次搞，完全无从下手。
迫于人菜瘾还大，不会改if(!checkSignature())，也不会直接改return 65542，最终决定从checkSignature方法的返回值下手，让他无论如何都return true就好了。依靠Copy to assembly，把反编译后的代码放到天书里面，至少让我看到了哪是哪。
可以看到这里调用了strcmp方法，比较 s1 与 s2 ，直接把这里改成 s1 比较 s1 就好了。
想法是美好的，改这个参数花了好久，最后用key-patch实现了，直接改这里的调用
修改后重新看反编译的代码，实现了绕过签名校验的功能。
4. 测试
64和32位的库都对应修改好之后，重新打包签名，运行正常。
5. 总结
比较笨方法直接改存储的签名信息，后面更多的是尝试修改 lib 库的代码。
理代码逻辑，修改内容可比绕过签名校验本身有意思多了，后面还是要多学习。
6. PS
我自己写的第一个 jni 的代码，就是从网上扒来的签名校验，实现几乎和这个一模一样，在Application:onCreate中调用 JNI 方法，然后方法内和写死的签名比较，错误的话直接killProcess。从安全性上还不如这个放在必须调用的加密库里面，我当时写的直接不去调用就可以绕过。
做这个尝试的时候好几次完全看不懂想放弃，想着直接用笨方法也能实现需求就算了。
但总想看看，如何能彻底把自己以前写过的垃圾代码干掉，就一点点的查和改。
后面可以通过这个去学习别的应用更好的签名校验做法。之前遇到过一个有意思的设计，签名校验成功之后去初始化一个静态的单例，然后在其它地方直接调用这个单例的方法。如果签名校验失败，这里的调用只会抛出空指针错误导致应用 crash，一开始不会联想到是因为重签名导致的应用错误。。。
当然一看 traces 就找到了问题，也可能只是设计的时候没考虑到这里会导致空指针，毕竟没什么人会无聊到闲着没事去重签名别人 apk。
文档来源：博客园https://www.cnblogs.com/maiiiii/p/15049705.html
页:
[1]