一些碎碎念。。。写的不是很有条理
不过真的会有人看嘛（
参考项目 Framework Patch
这两个项目都是同一个作者开发的，但是上面那个提供了一个非常好的思路 -- 通过 patch framework.jar 进行修改证书。下面的项目是一个 xposed 模块，通过修改证书完成了对 bootloader attestation 结果的修改
上面的方案仅仅修改了 Leaf cert，因为作者实际上要求一个已经被重编程过的 TEE，如果有这样的 TEE 那么 root certificate 事实上已经被替换，因此只替换 Leaf 也是可以的。但是我们并不能随意去重编程 TEE，况且这种 reprogram 很容易导致原来 TEE key 丢失。
但是很显然，引入极其容易被检测的 xposed 并不是我们想要的。上面直接 patch 的方案显然是更好的。但是为什么作者没有在上面实现呢？
我个人感觉可能是由于直接修改 smali 的工作量比较大导致的。对于 xposed 模块，他分别 hook 了 setAttestationChallenge，generateKeyPair，engineGetCertificateChain
ps: 其余 hook 是为了让 app 强制使用 TEEkey，因为使用 Keybox 模块的话可能不是很好 Intercept？不过我不是很懂这么做的意义，感觉如果就是为了过而非模拟 attestation 的话应该直接破坏 keystore 服务会更好。
但是这些 hook 之间相互是有关联的。比如 setAttestationChallenge 会将 attestationChallengeBytes 存下来。这个如果要手动改还是有点麻烦的应该。
虽然我感觉可以手动通过 patch smali 实现，但是未免过于繁琐。据作者 chiteroman 说，他尝试过使用 pine 框架，完成了 hook 并且成功 spoof。这种方案看似可行，实际上引入了 arthook 框架以及他的 so。例如 native test 之类比较强大的检测器还是可以检测到 load so 不正常的。而且系统的 loadso 列表也算是公开的指纹收集项，我认为去修改这个地方还不如向应用注入更难被检测的 lsposed
我还查阅了例如 PlayIntegrityFix 这样的项目。看起来 PlayIntegrityFix 好像是使用了类似原理。他也是动态代理了 android keystore 类，但是这个模块使用了 zygisk，而且他的注入方法，我个人认为，不是很恰当。查阅源码可以发现他其实就是使用了 zygisk 然后调用了 jni 来加载 dex，但是不像 lsposed，他并没有做一些隐藏。所以他还是可以被很容易得检测到。不过这个项目判断了包名，只会针对 com.android.gms 注入，所以其实问题也不是很大。。。但是如果要向其他程序注入就需要做一些别的事了
UPDATE 4/30
看起来 chiteroman 做了一些 新的改动。现在可以通过修改 chain 过 STRONG_INTEGRITY 了
看了一下，好像就是把我之前想的实现了？也就是直接构建一个完整的证书链把原来的链给替换掉
不过确实，迟早是能实现的。。。