论支付宝对Xposed框架的被害妄想症
最近真的是被支付宝的操作恶心到了。
跑到医院门口，要出示健康码了。打开支付宝选择随申码，登录授权时要刷脸，然后告诉我手机不支持刷脸？场面一度非常尴尬。
“您的手机不支持刷脸”。为什么不支持？缺少硬件？缺少驱动？含糊其辞，搞得我一开始真以为XDA上下下来的ROM不贴合我国国情少预装了一套刷脸的库。
查了好久才意识到原来是支付宝检测到Magisk和Xposed的缘故。
好啊，这可以理解嘛，人脸验证和支付都是安全性极高的，关键步骤被hook是会出大事的。
于是停用了Riru和EdXposed的模块。但是还是不支持。
三清之后重装，又支持了。
然后我遵循网友的经验，安装Magisk，然后开启随机包名重装和Magisk Hide。没有出问题。
然后再安装EdXposed，即时模块打开，黑名单打开把支付宝加进去，然后开启强制SafetyNet检验。
然后支付宝安全检查之后就又告诉我不支持了。
唉，我啥模块都没装呢，拉黑之后就算装了也hook不到你支付宝紧张啥？
网上逛了一圈，有不少遇到这个问题的，大家都没有好的解决办法，有的说双开，有的说双手机，有的说回退到play上的19年9月份的75版本。最后一条亲测确实有效，但是一直停留在老版本也不是个事啊。
也看了CSDN上一些关于阿里系应用反hook机制的研究，大概是18年左右写的。当时的机制是通过反射检测有没有XposedHelper这个类，有这个类之后检测缓存里面有没有alipay等关键词。这个机制非常巧妙，而且我觉得强度也足够了。
但是现在似乎已经不是这个机制了。通过有些解决方案当中关闭读取应用列表权限这一项我隐约可以猜出这支付宝大概是直接读取手机安装的所有应用，然后发现带Xposed就是不安全？
这也太过了吧，我个人甚至觉得有些流氓之嫌。
看到Xposed，立刻想到自己被hook，立刻想到这hook一定会让用户亏钱，立刻想到自己要赔钱，然后就紧张的要命。支付宝的想像惟在这一层能够如此跃进。
——鲁迅
这个逻辑链有两处是有待商榷的。
为什么所有Xposed插件一定要来hook你？我手机一般就装两模块，一个修改界面的locale让不够本地化的地方本地化，一个修改图标让系统更美观。这两个模块都不用hook进支付宝，而且还都是我自己一行一行写出来的。我脑子坏掉了去搞支付宝自己坑自己？
为什么觉得因为用户因为hook造成的损失一定要支付宝负责？还真就社会责任心爆棚呗。服务条款里面加一行“由于用户使用第三方软件自行修改系统框架进而影响本应用的正常运行，导致财产损失的，责任自负，支付宝概不负责”有那么困难吗？Xposed必须是用户自己装的，模块一定是用户自己下载并且启用的，考虑到使用Xposed基本上都是安卓的发烧友，翻车了自己负责这条道理大家都认，也没有人来说是支付宝的不对。
退一步，如果我真的要搞尽一切代价搞支付宝，支付宝检测有没有被hook的代码可不可能被hook呢？我能不能不用Xposed而用一些更底层的框架例如Riru来搞呢？支付宝作为一个正常权限的应用软件，面对因用户主动选择破坏承载其运行的，本来安全的安卓系统框架，而导致的可能来自底层的，高权限的修改与破坏一定是无能为力的。支付宝完全没有必要对一个受害者主动引发，且本质上自身无能为力的损失负责。
进一步，今天支付宝可以读取应用看到Xposed就不让刷脸，明天如果腾讯和阿里干架，支付宝也可以读取应用列表看到有微信就不让用（3Q大战既视感）。现在看来“读取应用列表”不是安卓原生自带的权限实在是一个设计漏洞。支付宝这个行为也显然开了一个不好的先例。
最后，我其实一直不理解的一点是，是什么让支付宝觉得原来合理的Xposed框架检测逻辑有问题，进而换上了这套长臂管辖似的一刀切呢？
在不知道更多信息以前，我只能认为是支付宝自身在有些情境下不必要的责任感以及过度的被害妄想症在作祟。
在此，向设计这个安全检查模块的所有阿里员工以及十八代亲属致以最诚挚的问候。
最后的最后，讲一讲在保留Magisk和Xposed功能的情况下，可能的解决办法吧。
- 停留在老版本的支付宝。
- 让EdXposed也有和Magisk类似的随机包名重装功能。
- 让支付宝找一个更合理的办法检验自己有没有被hook。
- 让支付宝目前这套方案失效，比如说禁止支付宝调用
getInstalledPackages来获取已经安装的应用。这个我知道在一些国产的系统里面是有类似功能的。但是目前类原生的系统还没有。虽可以通过Xposed模块来实现，但是在这个背景下毫无意义。唯一的一个方案是把系统的源码clone一份下来，然后直接改代码。