demo5
第五关
网上找了很多，但是发现关于这一个版本的demo去除教程是一点没有，而且我也找不到原始的demo无法做到IO重定向。所以我也就直接通过jadx分析软件的java代码查找签名校验函数逻辑，然后通过NP管理器打开dex文件修改对应的smail代码，对于没有学过这两种语言的人来说，AI可以帮你实现阅读这种小函数的分析。对于我的学习感受来说，或者是科班的经历吧，感觉这种通过hash逻辑分析校验，直接修改最终判断更加更直接。IO重定向等多被用于作为一些去除签名校验的工具的底层原理。 我的方法简直是一招鲜，吃遍天！！！
1、普通签名校验
方法1：
修改snail判断逻辑，
将这个nez改为eqz
方法2：
修改函数内置硬编码的签名值：替换成你自己签名后的签名值
结果：
2、CRC校验：
正己的方法为IO重定向，其实本质上来说就是修改代码读取的dex文件的路径逻辑，将读取的dex指针指向原版软件的dex原文件，但是我实在是找不到原版demo，所以直接手撕签名校验逻辑，修改签名校验判断逻辑就好了。
java代码中可以看出是判断==，直接修改对应的smail代码判断逻辑为eqz
smail代码修改后为：
结果：
3、sha-1校验：
方法：
代码中使用的是内置函数Intrinsics.areEqual 是 Kotlin 标准库的工具方法，所以zAreEqual就是true或者false，直接修改smai代码中返回值确保为1就好了
smail代码：
添加一行代码const/4 p1, 0x1，直接赋值p1为1，后续返回值也就是true，无论如何修改签名都返回通过。
结果：
4、新的API签名校验
听正己说MT管理器的最新去除API校验就是采用的IO重定向，通过hook钩子open等函数，保证读取原始的程序软件，保证签名验证通过
方法：手撕代码
对应的java代码，发现还是采用内置方法判断相等。
修改smail代码判断逻辑，直接赋值为1，何必管那么多
验证结果：
5、so校验
SecurityUtil.getSecret(challengeFifth2) 这是一个静态 Native 方法（由native 关键字声明）。所有方法的代码在so层，这里显示传入的是当前ChallengeFifth页面的实例（同时也是Context类型对象），校验逻辑发生在native层，我直接在java层次修改最后校验结果false变成true，使他显示通过。
直接修改成为nez，直接变成通过。
