-
-
[原创] 初探安卓隐藏Bootloader锁
-
发表于: 2023-8-17 12:08
-
做完硬件断点记录器后就开始研究如何隐藏Android的Bootloader锁了,当然最近没啥兴趣继续研究了,把目前为止的思路发出来
首先想到的一个方向是要先spoof安卓Setting里的oemlock status
在aoxpxref网站上搜索
bootloader unlocked
看到一个可疑的文件
/frameworks/base/core/java/android/service/oemlock/OemLockManager.java
xref 找到
/frameworks/base/services/core/java/com/android/server/oemlock/OemLockService.java
看到函数
可以看到Setting检测的是系统属性 ro.boot.flash.locked 来判断Bootloader是否解锁
AOSP搜索ro.boot.flash.locked,发现/system/core/init/init.cpp 有初始化该属性值的代码
ro.boot.flash.locked 的值是受到 ro.boot.verifiedbootstate 的值影响
google搜了一下后面的这个属性,发现这个属性可能的值有red,orange,yellow,green
看到一个隐藏bl锁的github项目
看到替换表
可以确定green是bl未解锁,还有一个 ro.boot.vbmeta.device_state 要改成locked状态,实机看这个属性解锁bl状态下是unlocked,除了前三个之外其他属性解bl之后没变
还有 googleplay service 的验证
对应的解决方案是
这个问题不大,国内又不用googleplay service
按照上述总结一下,隐藏bl锁需要修改以下属性
Java层最终会调用native_get方法获取Property的值
顺着native_get 找到函数__system_property_find 这个是用户层标准的获取property值的函数,来自libc.so,往下翻就是android property系统的实现了,可以看这篇文章
https://bbs.kanxue.com/thread-274100.htm
进用户层初始化property service的地方
/system/core/init/property_service.cpp
找到函数 PropertyInit 从名字猜测这是init进程初始化系统基本property值的地方,ProcessBootconfig和ProcessKernelCmdline最后是通过读取/proc/bootconfig和/proc/cmdline调用_system_property_add来设置ro.boot.verifiedbootstate和ro.boot.vbmeta.device_state的值
cat一下这两个设备文件,确实有相关信息
我想到了三个思路
kernel版本 5.10.168 路径/common/fs/proc/bootconfig.c 中的proc_boot_config_init 函数初始化了/proc/bootconfig的输出,顺着全局变量 xbc_data 找到系统获取bootconfig的地方/common/init/main.c -> setup_bootconfig , 可以看到bootconfig是从initrd里拿的
将返回的data copy进全局变量,然后由驱动打印出来看到数据
尝试文本替换
实验发现替换 uuid 和 vbmeta.device_state 系统正常启动,一旦修改 verifiedbootstate 系统就无法启动了,第一个思路就结束在这里了
先说结果: 成功了!!!!!!
安卓的linker使用的是mmap映射的elf文件,hook do_mmap的返回处,判断pgoff和filepath就能拦截到init进程加载libc.so,在这个时机里对_system_property_add函数下execute hook,
hook回调里对参数进行简单处理
修改成功
成功 Spoof Setting
第三个方法暂时没试过,感兴趣的可以试试看
有空就把第二个思路用kprobe来实现hook,包装成驱动连带硬件断点记录器分别开源到github上
刚入坑安卓,如有不对的地方或者有其他方法检测bl锁请大佬们在评论区指出!!!
private static final String FLASH_LOCK_PROP = "ro.boot.flash.locked";private static final String FLASH_LOCK_UNLOCKED = "0"public boolean isDeviceOemUnlocked() { enforceOemUnlockReadPermission(); String locked = SystemProperties.get(FLASH_LOCK_PROP); switch (locked) { case FLASH_LOCK_UNLOCKED: return true; default: return false; }}private static final String FLASH_LOCK_PROP = "ro.boot.flash.locked";private static final String FLASH_LOCK_UNLOCKED = "0"public boolean isDeviceOemUnlocked() { enforceOemUnlockReadPermission(); String locked = SystemProperties.get(FLASH_LOCK_PROP); switch (locked) { case FLASH_LOCK_UNLOCKED: return true; default: return false; }}static void export_oem_lock_status() { if (!android::base::GetBoolProperty("ro.oem_unlock_supported", false)) { return; } SetProperty( "ro.boot.flash.locked", android::base::GetProperty("ro.boot.verifiedbootstate", "") == "orange" ? "0" : "1");}static void export_oem_lock_status() { if (!android::base::GetBoolProperty("ro.oem_unlock_supported", false)) { return; } SetProperty( "ro.boot.flash.locked", android::base::GetProperty("ro.boot.verifiedbootstate", "") == "orange" ? "0" : "1");}static const char *prop_key[] = { "ro.boot.vbmeta.device_state", "ro.boot.verifiedbootstate", "ro.boot.flash.locked", "ro.boot.veritymode", "ro.boot.warranty_bit", "ro.warranty_bit", "ro.debuggable", "ro.secure", "ro.build.type", "ro.build.tags", "ro.vendor.boot.warranty_bit", "ro.vendor.warranty_bit", "vendor.boot.vbmeta.device_state", nullptr };static const char *prop_val[] = { "locked", "green", "1", "enforcing", "0", "0", "0", "1", "user", "release-keys", "0", "0", "locked", nullptr };static const char *prop_key[] = { "ro.boot.vbmeta.device_state", "ro.boot.verifiedbootstate", "ro.boot.flash.locked", "ro.boot.veritymode", "ro.boot.warranty_bit", "ro.warranty_bit", "ro.debuggable", "ro.secure", "ro.build.type", "ro.build.tags", "ro.vendor.boot.warranty_bit", "ro.vendor.warranty_bit", "vendor.boot.vbmeta.device_state", nullptr };static const char *prop_val[] = { "locked", "green", "1", "enforcing", "0", "0", "0", "1", "user", "release-keys", "0", "0", "locked", nullptr };| Property | Value |
|---|---|
| ro.boot.flash.locked | 1 |
| ro.boot.verifiedbootstate | green |
| ro.boot.vbmeta.device_state | locked |
adb shell su -c cat /proc/bootconfigandroidboot.hardware = "qcom"androidboot.memcg = "1"androidboot.usbcontroller = "a600000.dwc3"androidboot.bootdevice = "1d84000.ufshc"androidboot.boot_devices = "soc/1d84000.ufshc"androidboot.prjname = "22803"androidboot.startupmode = "pwrkey"androidboot.mode = "normal"androidboot.product.hardware.sku = "0"androidboot.hw_region_id = "1"androidboot.serialno = "xxxxxxx"androidboot.baseband = "msm"androidboot.dtbo_idx = "12"androidboot.dtb_idx = "1"androidboot.force_normal_boot = "0"androidboot.fstab_suffix = "default"androidboot.verifiedbootstate = "orange"androidboot.keymaster = "1"androidboot.vbmeta.device = "PARTUUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"androidboot.vbmeta.avb_version = "1.0"androidboot.vbmeta.device_state = "unlocked"androidboot.vbmeta.hash_alg = "sha256"androidboot.vbmeta.size = "23232"androidboot.vbmeta.digest = "xxxxx"androidboot.vbmeta.invalidate_on_error = "yes"androidboot.veritymode = "enforcing"androidboot.slot_suffix = "_a"adb shell su -c cat /proc/bootconfigandroidboot.hardware = "qcom"androidboot.memcg = "1"androidboot.usbcontroller = "a600000.dwc3"androidboot.bootdevice = "1d84000.ufshc"androidboot.boot_devices = "soc/1d84000.ufshc"androidboot.prjname = "22803"androidboot.startupmode = "pwrkey"androidboot.mode = "normal"androidboot.product.hardware.sku = "0"androidboot.hw_region_id = "1"androidboot.serialno = "xxxxxxx"androidboot.baseband = "msm"androidboot.dtbo_idx = "12"androidboot.dtb_idx = "1"androidboot.force_normal_boot = "0"androidboot.fstab_suffix = "default"androidboot.verifiedbootstate = "orange"androidboot.keymaster = "1"androidboot.vbmeta.device = "PARTUUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"androidboot.vbmeta.avb_version = "1.0"androidboot.vbmeta.device_state = "unlocked"androidboot.vbmeta.hash_alg = "sha256"androidboot.vbmeta.size = "23232"[培训]Windows内核深度攻防：从Hook技术到Rootkit实战！
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
这个确实难过的,TEE chip里的key很难拿出来 |
|
|
|
|
|
284K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6b7j5i4m8W2M7W2y4@1M7X3W2C8k6g2)9J5c8Y4y4S2k6X3g2@1P5h3&6W2N6q4)9J5k6r3k6A6P5l9`.`. |
|
|
|
|
|
|
|
|
这是通过改成不支持认证的方式来绕过的 |
|
|
删除
最后于 2023-8-18 19:14
被cslime编辑
，原因：
|
|
|
绕不过的，会生成一对密钥，私钥保存在TEE里面拿不到 |
|
|
|
|
|
|
|
|
雀实.... |
|
|
或许可以这样? App层用Hook劫持密钥认证的传输层,利用重放请求来绕过设备密钥认证,密钥认证返回的请求者APP数字签名信息是来自software层,root设备可以修改software层获取到的请求者数字签名绕过防重放,这样就可以利用通过一个CVE-2022-20409提权上去的设备来做重放请求的设备 但是TEE会返回kernel的patch版本,还是会产生一些检测方向,不太理想 最理想的是受害app出现了一个代码执行漏洞,在未解BL的设备上复现受害APP的代码执行漏洞来进行请求的重放
最后于 2023-8-21 11:34
被cslime编辑
，原因：
|
|
|
|
|
|
重放攻击了解一下,root后的设备可以控app执行密钥认证时机的传输层,再给你另外一台未解BL的设备上重放一次 看楼上 |
|
|
|
|
|
太复杂了 哈哈哈哈 ，我现在就是不知道怎么检测shamiko |
|
|
哈哈哈哈哈哈哈哈哈 偷偷截屏ocr分析，手机launcher有shamiko就是有 |
|
|
这是高手 |
|
|
|
|
|
有没有一种可能 shamiko没有launcher |
|
|
|
