对高通启动链的一点研究--后记

想一想还是说一说吧。
虽然我们能够解锁高通8E5的BOOTLOADER
但是面临几个问题
首先是需要9008写入文件
如果机器的9008的firehose需要授权，那么就必须拆机写入了。
这是问题1
所以说有没有办法呢？
我们想到比如说fastboot flash
但是abl源码告诉我们锁定状态是不能刷入分区的
尽管有些OEM修改了允许刷入少数分区但是没有efisp
然后就是dd命令，需要root权限才能访问dev下的块
想一想之前的几个路径

Recovery漏洞刷更新包:

这里是华为的办法
华为存在一个USB更新模式，是recovery模式下执行一个程序update-binary
这个程序会初始化一个USB端口，可以进行通信将华为定制的UPDATE.APP发送到设备
但是这个UPDATE.APP有签名和CRC在里面，会进行验证
但是我们发现EMUI9以及以下的版本没有签名验证只有CRC验证
那不就可以利用CRC的线性性，对于长度相同的A和B
有 \(CRC(A xor B)=CRC(A) xor CRC(B)\)
如果存在碰撞\(CRC(A)=CRC(B)\)
那么\(CRC(AxorB)=0\)
那么我们记这个是C
那么\(CRC(C)=0,CRC(A)=CRC(AxorC)\)
找到一个C发现是通用
对于EMUI9往上的版本，有签名验证了
但是不是所有分区都有签名验证
有些分区没有签名验证，比如说PRELOADER
但是本来华为是没有这个分区的，但是PRELOADER和XLOADER都是一个物理位置
而这个recovery的这个模式就是识别镜像的分区名决定写入到哪里
所以还是CRC碰撞
这样可以修改关键的物理分区

对于小米旧的recovery
好像可以使用adb push指令push一些镜像进去
这里面不知道能不能用shell
实际上已经存在漏洞了，好像说放一些特定的固件进去可以刷工程内核还是怎么样
具体我不清楚了

然后当然华为还有一个recovery正常OTA的漏洞早被修复过了说的是ZIP压缩包末尾的签名通过巧妙的设计偏移量
可以使得在签名前面走私一个PK的压缩包然后都会被解析，这样就可以实现任意代码执行然后换成自己的update-binary
这个实际上我找了很多镜像都已经被修复了，不知道taszk找的哪个镜像，所以无法复现。

提权到临时root：

这个是最常用的办法
但是现在的安卓有SELINUX，即使有临时root各种权限也受到限制
临时root一般是通过内核提权，比如说我们有一个内核任意写之类的
可以把当前cred的uid和gid改成0
然后清除所有的secure bits
当然改security结构体里面的sid改成kernel的似乎可以关掉selinux
但是大概率是不行的
也可以改全局的selinux_enforcing变量改成0就permissive了
当然这些前提是hyp没有保护这些区域
华为和三星就不能这样简单的修改但是小米可以

临时root还有办法比如说有一个服务或者一个工程模式，本身有root权限，那么我们如果能够劫持它的程序执行来执行我们的shellcode或者命令，那么就可以实现root权限，但是仍然受到selinux限制
这个相对简单一些我们可以看到之前的unisoc以及oneplus都存在这样的漏洞
https://zhuanlan.zhihu.com/p/55609013?utm_id=0

fastboot漏洞刷任意分区：

这里有些OEM厂商允许在锁定状态下刷写部分分区，可能要签名检查什么的
那么我们就可以想办法绕过
再比如分区名的检查和实际写入分区时候的匹配用的不一样的话也有可能绕过
或者说有一个隐藏的命令（backdoor），我们执行之后能够修改某些标志位使得允许刷写
再比如说如果我们有ABL的任意代码执行的漏洞，那么当然可以直接刷写任意分区，但是这样我们也可以直接解锁我们的BOOTLOADER了

那么我们这次应该怎么办呢？
首先我们发现高通的ABL锁定状态下就是不允许刷写
所以这块不要想了。
我们把思路往提权临时root上靠
结果呢，在浏览ABL代码时候我们发现了一些patch似乎修复了一些漏洞的样子。

https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commits/uefi.lnx.5.0.r25-rel/QcomModulePkg/Library/FastbootLib/FastbootCmds.c?ref_type=heads
我一看有一个似乎别人之前还给我发过，说是什么cmdline的漏洞，但是这个漏洞不能用来abl的任意代码执行因为高通的写入RPMB的scm call过了milestone之后调用就没有用了这也是防止你有内核的权限之后调用解锁函数。所以说就放到一边了。
现在我们细看一下发现有两个命令
一个命令是"fastboot oem set-hw-fence-value"
另一个命令是

另外一个问题是解锁炸tee，这是问题2

这个问题的根源是我们没有完全按照高通官方的解锁流程导致tee的密钥等等密钥被正确的更新
因为解锁后tee似乎不再信任原先的一些密钥等等，这只是一些猜测。
所以解决问题的办法很简单，直接模仿官方的解锁流程重写我们的UEFI APP即可。

第三个问题是OEM修改了解锁检查的逻辑不使用标志位而是使用RSA验证等，那么需要通过GBL正常启动到系统

这个问题就是说，我们需要编译一个GBL使得他能够充当linuxloader的角色，其实这也是GBL的本意。

当然也可以直接修补官方的linuxloader，直接放会crash，想想也行了无限递归

所以至少要patch掉efisp加载的逻辑，具体后面有空再看了（咕了x