最近真的是被支付宝的操作恶心到了。
跑到医院门口，要出示健康码了。打开支付宝选择随申码，登录授权时要刷脸，然后告诉我手机不支持刷脸？场面一度非常尴尬。
“您的手机不支持刷脸”。为什么不支持？缺少硬件？缺少驱动？含糊其辞，搞得我一开始真以为 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 一份下来，然后直接改代码。