一、情景介绍
最近想写几个某支付软件的插件，大家现在都知道现在插件大部分都是基于Xposed的hook功能，包括之前写了很多的某 交软件的插件，所以不多说就直接用Jadx打开支付软件之后然后找到想要hook的方法，可惜的是遇到这个错误：
看到这些搜索结果了吧，早在去年这个人就写了这个分析，无独有偶这个人就在我的编码美丽小密圈里，不过更可惜的是，这个方案现在已经不行了。
二、早起的防护检测
**第一、**Xposed框架将Hook信息存储在字段fieldCache，methodCache等中， 利用java 反射机制获取这些信息，检测Hook信息中是否含有支付宝App中敏感的方法，字段，构造方法
**第三、**root检测原理是：是否含有su程序和ro.secure是否为1
第五、如果应用被Xposed进行hook操作之后，抛出的异常堆栈信息中就会包含Xposed字样，所以可以通过应用自身内部抛出异常来检测是否包含Xposed字段来进行防护：
就是在ScanAttack类中进行了很多检测，这里就不在截图一一说明了，那么我们直接hook这个类，然后把所有检测都拦截掉不就可以了吗惜的是没有效果。
三、逆向分析
所以问题就变成了我们得重新去看看他的检测逻辑到底在哪里找突破口我们还是去上面的那个提示框，可以全局搜那个提示信息，可惜的是没搜到。这个后面会解释支付app中的常量字符串全部进行加密了，没法全局搜索字符串来进行定位。那么我们还有第二招就是UI界面分析：
幸运的是我们在多个dex中都搜索到了这个值，而且看上去也是一个对话框类，点进去进行查看：
就这么进行hook系统对话框的show方法，然后在内部进行异常抛出来打印堆栈信息可以更快的跟踪代码调用逻辑，其实运行前心里没底因为感觉理论上应该差不多可能或许会成功：
看到这个类方法之后，发现了一件惊天秘密就是这个支付应用内部为了防止被字符串查找，内部的字符串信息全部用Base64进行编码，其实这个我在之前也说过了，现在有些应用为了保护自己应用内的常量字符串信息在编译期做了防护编码。后面会单独出一篇文章解析这个操作的，我们可以把一个应用内部的字符串常量全部加密。其实 上已经有这种插件或者工具了，但是没怎么说原理。然后这里我们看到他用的是AlertDialog对话框进行展示的，不过AlertDialog对话框是继承Dialog类的，这里看到为什么我们hook这个Dialog类的show方法了吧，因为最终调用show方法都是调用Dialog的show方法。
我们继续查看逻辑代码，看到有一个按钮是关闭的，直接看看内部代码：
在这里就强制退出程序了，那么到这里我们继续来看什么时候弹出这个对话框的呢们查看堆栈信息：
然后这里做了一个判断逻辑之后开始调用展示对话框逻辑：
合理看到如果想屏蔽原始方法直接返回null即可，那如果还是想调用原始方法该怎么办呢为有时候我们可能需要判断有一些情况需要屏蔽原始方法，有些情况是不需要的，那么不屏蔽的方法就是直接返回 XposedBridge.invokeOriginalMethod 即可。下面就直接运行这个模块即可。
五、延伸技术点
第二、在分析应用的时候发现他内部的常量字符串全部都用Base64进行编码了，这样破解就很难找到突破口了，而且也发现他的string.xml中没有几个字符串信息的。所以这个支付软件真的做了很多前期防护策略，但是这样做有个弊端就是效率问题，因为原本只是去常量池中取字符串，而这样弄完之后每次都需要进行解码字符串。更重要的是这样的混淆编码一旦被破解了，那么等于完全没意义了，因为我们可以hook这个编码方法：
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！