一、情景介绍

最近想写几个某支付软件的插件，大家现在都知道现在插件大部分都是基于Xposed的hook功能，包括之前写了很多的某社交软件的插件，所以不多说就直接用Jadx打开支付软件之后然后找到想要hook的方法，可惜的是遇到这个错误：

这个软件内部做了防止Xposed的hook功能检测，当我们写了对应了Xposed模块在打开app的时候就会出现这样的错误，其实吧这个错误网上之前有人写过分析了，我们可以百度一下：

看到这些搜索结果了吧，早在去年这个人就写了这个分析，无独有偶这个人就在我的编码美丽小密圈里，不过更可惜的是，这个方案现在已经不行了。

二、早期的防护检测

支付软件做了另外的防护了，这才是本文的重点，但是不管怎么样还是先来回顾和了解一下先看看之前的防护策略吧：

第一、Xposed框架将Hook信息存储在字段fieldCache，methodCache，constructorCache 中，利用java 反射机制获取这些信息，检测Hook信息中是否含有支付宝App中敏感的方法，字段，构造方法

第二、检测进程中使用so名中包含关键”hack|inject|hook|call” 的信息，这个主要是防止有的人不用这个Xposed框架，而是直接自己写一个注入功能

第三、root检测原理是：是否含有su程序和ro.secure是否为1

第四、防止被Hook的方式就是可以查看XposedBridge这个类，有一个全局的hook开关，所有有的应用在启动的时候就用反射把这个值设置成true，这样Xposed的hook功能就是失效了：

第五、如果应用被Xposed进行hook操作之后，抛出的异常堆栈信息中就会包含Xposed字样，所以可以通过应用自身内部抛出异常来检测是否包含Xposed字段来进行防护：

有的同学会好奇怎么反射操作呀？因为Xposed的hook原理的就是在程序启动都注入jar功能，所以安装hook模块之后，每个应用内部都包含了这个Xposed功能jar，就相当于你的应用中有了Xposed的所有功能类，所以在应用中反射Xposed的类是可以成功的，当然前提是设备装了Xposed并且有相应的hook模块！而这些方案已经都是公开的，一些应用为了防止被hook做了很强的安全防护策略，大家感兴趣可以去看看”一号店”应用，会发现hook他也是失败的，并且很难找到相应的检测机制！

其实除了上面的几个还有很多策略，我们用Jadx去查看支付app代码也发现他的确有这个功能：

就是在ScanAttack类中进行了很多检测，这里就不在截图一一说明了，那么我们直接hook这个类，然后把所有检测都拦截掉不就可以了吗？可惜的是没有效果。

三、逆向分析

所以问题就变成了我们得重新去看看他的检测逻辑到底在哪？这里找突破口我们还是去上面的那个提示框，可以全局搜那个提示信息，可惜的是没搜到。这个后面会解释支付app中的常量字符串全部进行加密了，没法全局搜索字符串来进行定位。那么我们还有第二招就是UI界面分析：

这里我们分析得到了这个对话框的大致布局，找到展示消息的TextView的id值，这里我们先不去public.xml中找到对应的int值，可以先去jadx中搜索R.id.message即可，要是搜不到在去找int值进行搜索：

幸运的是我们在多个dex中都搜到了这个值，而且看上去也是一个对话框类，点进去进行查看：

那么确定是不是这些对话框很简单，直接hook这些对话框的onCreate方法即可，可惜的是全部没有走到也就是没有效果，这里我说的是一些也就是我把搜索到的对话框都hook了一遍都是没效果的。所以到这里我们就陷入了沉思，哦不对是我陷入了沉思，这几天我夜不能寐辗转反侧饭也吃不下水也喝不进去，就在我绝望之际那天我一个人孤独的走在漆黑的小树林里，突然灵机一动想到一个绝妙的思路，那就是不管他是自定义的对话框还是用的系统对话框。那么最终都会调用对话的show方法，那么我们就直接干脆点hook系统的对话框方法：

就这么进行hook系统对话框的show方法，然后在内部进行异常抛出来打印堆栈信息可以更快的跟踪代码调用逻辑，然后运行模块，其实运行前心里没底因为感觉理论上应该差不多可能或许会成功：

哈哈哈，果然成功了我们定位到了代码关键点在CI这个类中弹出这个对话框的，查看代码：

看到这个类方法之后，发现了一件大事就是这个支付应用内部为了防止被字符串查找，内部的字符串信息全部Base64编码类，其实这个我在之前也说过了，现在有些应用为了保护自己应用内的常量字符串信息在编译期做了防护编码。后面会单独出一篇文章解析这个操作的，我们可以把一个应用内部的字符串常量全部加密。其实网上已经有这种插件或者工具了，但是没怎么说原理。然后这里我们看到他用的是AlertDialog对话框进行展示的，不过AlertDialog对话框是继承Dialog类的，这里看到为什么我们hook这个Dialog类的show方法了吧，因为最终调用show方法都是调用Dialog的show方法。我们继续查看逻辑代码，看到有一个按钮是关闭的，直接看看内部代码：

然后看看点击事件：

在这里就强制退出程序了，那么到这里我们继续来看什么时候弹出这个对话框的呢？我们查看堆栈信息：

有一个内部类中的run方法：

然后这里做了一个判断逻辑之后开始调用展示对话框逻辑：

这里看到他在做检测逻辑了，这些功能都还是在CI这个类中，其实到这里有的同学会好奇上面的堆栈方法信息到run就结束了，也没看到他调用这个检测方法呀？其实这里有个遗憾就是没法继续跟踪下去了，因为堆栈信息断了，而且我猜想支付应用内部还有什么判断逻辑而已。

四、过滤hook检测

但是用我们现有的结果完全可以搞定这个提示信息了，有很多种方法，比如可以不展示这个对话框，也可以拦截那个自杀方法，也可以屏蔽对话框的点击事件都可以。这里为了给大家介绍一个技巧就采用屏蔽对话框展示逻辑，这里需要用到Xposed中的一个技术就是如何屏蔽原始方法，需要用到这个回调接口：XC_MethodReplacement，比如这里我们屏蔽那个展示对话框的a方法：

合理看到如果想屏蔽原始方法直接返回null即可，那如果还是想调用原始方法怎么办呢？因为有时候我们可能需要判断有一些情况需要屏蔽原始方法有些情况是不需要的，那么不屏蔽的方法就是直接返回 XposedBridge.invokeOriginalMethod 即可。下面就直接运行这个模块即可。

五、延伸的技术点

到这里我们就解决掉了某支付软件的方Xposed的hook功能检测功能了，而在本文中我们得到两个重要技术：

第一、在你绝望的时候一定要记得独自一人去小树林这样才会迸发出灵感，在本文中软件加密了字符串我们通过id查找突破口无望的时候，突然灵关闪现去hook系统的对话框show方法，因为以后以及现在在你hook无望的时候一定要记住另类思想，比如肉眼看不到的东西，对话框展示最终都会调用系统对话框的show方法，那么我们可以曲线救国去hook这个show方法就可以了，通过打印堆栈信息更快的定位方法调用顺序逻辑。
第二、我们在分析应用的时候发现他内部的常量字符串全部都用Base64进行编码了，这样破解就很难找到突破口了，而且也发现他的string.xml中没有几个字符串信息的。所以这个支付软件真的做了很多前期防护策略，但是这样做有个弊端就是效率问题，因为原本只是去常量池中取字符串，而这样弄完之后每次都需要进行解码字符串。更重要的是这样的混淆编码一旦被破解了，那么等于完全没意义了，因为我们可以hook这个编码方法：

既然这个方法是Base64编码的，那么拦截这个编码方法打印他的原始字符串信息即可获取所有原始没有编码的常量字符串信息了，即使不这么做也可以自己写一个程序进行编码然后全局搜索这个Base64编码字符串信息也是可以定位到的。那么我们后面要做的是介绍如何把应用中的常量字符串信息全部编码一下，至于什么编码加密可以自行定义。

本文的目的只有一个就是学习逆向分析技巧，如果有人利用本文技术进行非法操作带来的后果都是操作者自己承担，和本文以及本文作者没有任何关系，本文涉及到的代码项目可以去编码美丽小密圈自取，欢迎加入小密圈一起学习探讨技术