前言
本文并不保证你的手机也能使用同样的方式通过SafetyNet
华为系部分手机等请直接退出本文，由于目前华为系部分机型只能通过极其繁琐的方式使其安装GMS，所以想通过Safetynet请提前把GMS的问题处理好。
本文总体思路简单（目标只有一个——下载那些“特殊应用”，而且有大量现成轮子）但研究过程复杂，难度高（本身就是一个玄学机制，涉及变量多，而且无前人研究资料，能收集到的资料还众说纷纭）尤其是中间使用了很多暴力研究的方法......从开始研究到结束我一共是为了它重启了一百来次手机，而且由于Safetynet本身就是一个玄学存在，我也只是尽可能让玄学变得不那么玄学，其玄学本质还是在那，如果没有耐心的请绕道。
何谓Safetynet
这里我选择直接搬运官方的doc过来解释说明。
SafetyNet Attestation API 是一种反滥用 API......SafetyNet Attestation API 提供采用加密签名的证明，用于评估设备的完整性。为了创建证明，该 API 会检查设备的软件和硬件环境，以查找是否存在完整性问题，并将相应数据与已获批 Android 设备的参考数据进行比较。
通俗地，Safetynet主要检测的可以被分为三大块（其实也是Magisk中的分法）：
——basicintegrity（基本完整性）
——ctsProflie（兼容性）
——evalType（评估类型）
其中最难通过的大概就是ctsProflie，由于ctsProflie测试标准不公开，很多因素都能导致cts不通过。（顺带一提现阶段的ctsProflie极可能包含了部分basicintegrity的测试内容且更严格）
如：
系统本身未提交认证（华为系部分手机、MIUI开发版）
解锁Bootloader（貌似最近才加入）
设备ROOT或刷入Magisk等玄学因素
而evaltype则是Safetynet给出的设备评估类型，HARDWARE属于近几年才加入的类型，而如果设备层级只有BASIC的话则只有默认BASIC。
Play保护机制
其中部分包含了Safetynet的测试内容，可以理解为“商店认证”，且此认证与Safetynet的玄学程度不相上下。
了解了这么多，接下来就开始研究了。
环境
设备：Redmi K30 Pro
系统：国行开发版20.12.2，MiPure官改
其他：已ROOT，已刷入Magisk，已刷入Edxp并开启增强模式。均开启自带的所有隐藏/通过校验选项，Magisk模块除一些优化模块外只有MagiskHide Props Config这一个模块。
探究
由于Safetynet的玄学性，整个探究过程中不可能做到完全控制变量，只能尽可能控制。
为了使问题更清晰，接下来先下几个定论：
①.目前除Edxp本身模块外所有的Edxp模块对于通过Safetynet无效（如SudoHide，早已无实际作用。而Hiddencore Module也只是掩耳盗铃的修改了Safetynet的验证地址，对于经过屡次升级的Safetynet来说也是无效的，并不能骗过商店。）
②.Magisk的Safetynet检测结果并不代表商店检测结果
③在解锁Bootloader、安装Magisk、Edxp的情况下仍然有可能通过认证
猜想1：与“Google账号——安全性”中是否能检测到设备外观和机型有关。
酷安@深渊莫比心 给了我这一条思考的路径。
确实这种想法有其理论依据。因为Safetynet Attestation API中明确写道“并将相应数据与已获批 Android 设备的参考数据进行比较”，如果设备没有被识别出来，自然也代表着无法通过认证了。
图1-1 原文
图1-2 示例图
然而，这种想法并不完全正确
因为有部分新机型外观Google未入库的可能性，所以“能识别出外观”这一部分自然被证伪。
而“能识别出机型”呢？
其实从这张图可以看出我有两次失败的尝试
我使用MagiskHide Props Config修改成了小米10的指纹，成功识别机型——无法下载
小米9的指纹——同上
我还尝试了K20 Pro、小米10T、10T Pro的指纹均以失败告终
而且从中还可以发现一个有趣的规律：
在大部分情况下，无论怎样修改指纹，Google并不会显示出一台新的设备，而是在原有设备的基础上匹配了一下机型（如从小米10指纹改为10T指纹，仅仅是将Mi 10变为了M2007J3SC），甚至在不退出账号重新登录的情况下没有任何改变。
但在无法识别出机型的情况下，确实会大概率导致无法通过Safetynet（只显示“Android”实际上也就代表服务器没有可以进行数据比较的设备）
由此我们可以得出结论1：
“能显示设备外观”是“通过Safetynet”的既不充分也不必要条件
“能显示设备名称”是“通过Safetynet”的必要不充分条件
“能显示设备名称和外观”是“通过Safetynet”的既不充分也不必要条件
猜想2：与是否进行GSF设备注册有关
在我找资料时，少数派中的一篇文章吸引了我的注意：
https://sspai.com/post/55536
文中指出：“要知道，即便是 Google 自家的亲儿子（比如我手里这两台），在解锁 Bootloader 并自行刷写完整版工厂镜像后，也可能会遭遇「Play 保护机制未认证」的尴尬状况。
为了让那些出厂前已经通过了 Google 兼容性认证但机主喜欢动手折腾的 Android 设备 也能平等地享受到应有的 Play 保护机制待遇，流淌着「极客」之血的 Google 其实也为用户开了个「小灶」：GSF 设备注册。”
注册方法也简单，首先下载DeviceID这个APK（Play商店有，也可以搜索）
复制下来GSF ID（点一下GSF，然后COPY）
访问
https://www.google.com/android/uncertified/（需要魔法）
输入复制的GSF ID，注册即可。
注册后访问
https://play.google.com/settings
进行验证，若能显示注册机型即已通过。
事实上GSF设备注册“可能”能帮你通过的是商店认证而非Safetynet，但有时候未通过认证还真不是因为Safetynet，而是它。
结论2：
“进行GSF设备注册对于通过商店认证有一定帮助，但具体影响尚不明确。
猜想3：与是否刷入过官方ROOT包有关
先说句晦气话，官方ROOT包自从“后XP框架时代”（EDXP）以来，已经变成了一个没有半点鸡毛用的阴间摆设，并不是说其功能，而是各种体验方面。
首先，部分版本官方根本不支持开启ROOT
其次，一个应用获取权限就要20s......这简直让我这N年老米粉大为失望。虽说现在手机厂商也是越来越封闭，但MIUI也变成了这样（虽说不是那么狠），也确实挺让我失望的。
刷入官方ROOT包之后，由于官方根本没有提供任何隐藏ROOT的途径，你已经ROOT的事实将在软件前暴露无遗，本来用Magisk一刷就可以解决的事情，却还要这么搞，真可谓是脱了裤子放屁。
由此我们可以得出结论3：
“未刷入官方ROOT包”是“通过Safetynet”的充要条件
猜想4：与evalType是/不是HARDWARE有关
在酷安上有两种矛盾的说法：
①.Safetynet不通过与evalType不是HARDWARE有关，因为basic很容易改出来而HARDWARE不行。
②.HARDWARE是一种更难通过的类型，所以需要force basic才能通过
两种说法走向了完全相反的两个方向，但实际上他们都没有触碰到问题的本质。
evalType实质上只是一个评估类型，无论是BASIC通过还是HARDWARE通过都是被承认的，而MagiskHide Props Config的原理也正是强行使用BASIC指纹来通过验证。（虽然不一定会被降到BASIC层级，比如我）
由此可以得出结论4：
“evalType是HARDWARE”是“通过Safetynet”的既不充分也不必要条件
“evalType不是HARDWARE”是“通过Safetynet”的既不充分也不必要条件
猜想5：与service.cn.google.xml有关
service.cn.google.xml，在MIUI12上位于product/permission/etc（OPPO和EMUI的此文件所在目录貌似不同）。
其实service.cn.google.xml的初衷是为了解决国内无法连接Google服务器却不停连接而耗电的问题。
初衷是好的，可它却俨然成为了横在国内用户享受“无添加”GMS全家桶的一道壁垒。
就拿“DF-DFERH-01”这个错误来说吧，它是导致这个问题的罪魁祸首之一。
而最近也已经被证明与部分通过Safetynet的机型无法下载这些应用有关。
感谢酷安@Barve の Haert
本人测试之后也的确如此，同时这也是导致众多Safetynet通过的手机无法下载部分应用的罪魁祸首。
由此可以得出结论5：
service.cn.google.xml不会直接干扰Safetynet，但和部分应用玄学般无法下载问题有关
猜想6：与Riru Core版本过旧有关
Riru Core和Edxp Manager最近都在加强反检测措施，尤其是Edxp最近直接删了链接库，导致内核检测Xposed链接库这一方法失效。
理论上来说可能与其有一定关系，但不能肯定。
结论6：
无法证伪的猜想，但随着以后Safetynet的升级旧版本被检测出的事实可以肯定。
猜想7：与内置Google服务安装的分区不对有关
爬Google的时候发现台湾同胞倒是通过对比MIUI EU
发现了这个不对劲的地方：
https://www.ptt.cc/bbs/Android/M.1543807061.A.025.html（需要魔法）
在这篇文章两年后，我也发现酷安有人效法了此方式并成功让不少人通过认证（商店多半也是可以下的，评论区暂未见很多反馈）
https://xiaomi.shxj.pw/android-phone/k30-ultra/420/
我通过求证后，也证实了确实是新瓶装旧酒。
感谢酷安@tommy1616和 @冰糖I/O 提供的MIUI EU的该目录具体内容截图
所以我便萌发了自己做一个适用于我机型的模块的想法。
做这种模块一点也不复杂的说！
好，先刷入进去。
见证奇迹的时刻到了
完！美！了！
话说这什么垃圾ctsProfile啊，不如直接改名advancedIntegrity得了
这里我还是把模块放出来：【正在传包中】
需要注意的是，此模块最佳配用基于Android11的MIUI12，其余Android11的机型理论可兼容。至于Android11以下的机型由于不清楚GMS套件分布目录，需要找一个参照机才能进行模块制作，如果各位有的话可以发目录到此帖，我会进行制作。
蓝奏：
MEGA：
后记
本文最后更新于2020.12.12，不保证后续这些方式还有效。
总而言之，我认为以下方法对于通过Safetynet会较为有效
基础的隐藏（Magisk Hide、Edxp黑名单、强制通过Safetynet）+删除services.cn.google.xml+安装MagiskHide Props Config并配置+让GMS成为系统框架+GSF设备注册
都废话，哔哔赖赖，释放负能量：
从这篇文章你们也可以看出我就是个爬搜索引擎混吃等死的核心管理，里面所有的内容90%都可以轻松在胡松华和咖喱处找到，要是查重肯定过不了（XD）。相比于其它几位核心管理，我实在没啥很硬核的东西奉献给各位。我不是学富五车的巨佬，也不是什么所谓“熟能生巧”的能手，我也就是我吧。
