欢迎来到 黑吧安全网 聚焦网络安全前沿资讯,精华内容,交流技术心得!

安全圈是这么玩车的——对Tesla Model S 固件更新过程的逆向研究

来源:本站整理 作者:佚名 时间:2020-03-12 TAG: 我要投稿

CID VCM软件架构
与大多数嵌入式系统相比,CID更大更复杂;对于嵌入式系统而言,CID是Linux发行的Ubuntu的完整版本,这与嵌入式系统不同。
在内核中,我们找到了自定义元素,例如Harman Redbend,该内核是使用Linaro工具链构建的。
为了满足使用开源软件的法律要求,特斯拉在项目进行到一半的时候就透露了内核来源,但是,这对逆向无济于事,因为它仅占系统的一小部分。
引导加载VCM
这似乎与许多Tegra设备相似。BPMP(启动和电源管理处理器)是Tegra SoC的辅助处理器,它执行存储在ROM中的只读引导加载程序,并且是ARM7处理器,此时,我们关闭了Tegra中的主处理器。
当BPMP ROM引导加载程序从NOR闪存中读取一条数据时,会提供大量信息,这就是BCT(引导配置表),信息包括:
· 内存中几个引导程序的地址
· 将引导程序加载到SDRAM的位置
· SDRAM中引导加载程序的入口点
· 连接到系统的SDRAM的配置(需要进行引导才能访问)
将第一阶段引导加载程序复制到SDRAM之后,BPMP开始执行,此时尚未打开Tegra中的主处理器。
第一阶段的引导加载程序为QUICKBOOT,其大小约为56KiBytes。明确引用了AES-CMAC(消息认证代码),“ AES-CMAC Xor”是在此使用的字符串之一,这些字符串也在U-boot(开源的引导程序)中可以找到。
(https://github.com/u-boot/u-boot/commit/b149c4c399b111cec1ff7505ca9fabbeeb4fe394)

来自第一阶段引导程序的字符串
有人可能会认为引导加载程序是基于U-boot的,但是特定的加密功能实际上是由Nvidia编写的,因此可以由Nvidia在其他地方自由使用。
当第一阶段引导加载程序正确设置SoC时,主处理器就会启动,然后加载第二阶段的引导加载程序,以允许主处理器运行。
当解压缩并运行内核时,我们发现第二阶段的引导程序非常简单,没有看到任何加密保护的迹象。
宽松地遵循Android bootimg格式,内核映像由一个文件中的内核和ramdisk组成。内核激活后,将运行/sbin/init-stage-0.sh脚本,其主要目的是通过安装NAND闪存分区使系统完全可操作。
NOR flash
我们在NOR flash中找到了BCT、第一级和第二级引导程序以及内核。

CID NOR闪存的布局
我们发现许多分区已镜像到主分区和恢复分区上了。
NAND flash
/ usr /文件系统存储为sqaushfs文件系统,其中包含在正常操作期间不会更改的二进制文件和脚本。SquashFS在低资源嵌入式系统中很常见,它是一种压缩的只读文件系统,它允许文件系统的不可更改部分占用较小数量的闪存。
/ var /目录包含日志,是一个小的128Mb ext4文件系统。
/ home /目录包含升级文件和临时数据,并作为ext4文件系统存储在其余的闪存中。
/ home和/ var目录覆盖在只读文件系统上,仅允许少数几个目录被读/写,这意味着系统的大部分内容都是只读的。
Dual-bank 固件
初始ROM引导加载程序运行后,引导加载过程可以选择两个映像:
· ROM引导加载程序,仅提供一个副本。除非存在灾难性的硬件问题,否则它是不变的。
· stage1_primary / stage1_recovery 由ROM引导程序顺序选择。如果第一个失败,则第二个运行,除了内存中的位置,这两个引导程序看上去几乎相同。
· stage2_primary / stage2_recovery 在此运行的引导程序由哪个stage1引导程序运行确定。同样,两个引导加载程序看起来几乎相同,除了内存中的位置外。
· kernel_a / kernel_b 这两个内核的引导参数非常不同。
· 系统启动时可以挂载在线/离线usr分区。
这是两个内核的引导参数:

init-stage-0.sh脚本读取thispartid的值,并加载两个/ usr / squashfs分区之一,如果其中一个损坏,则可以使用另一个恢复。
我们还可以看到AppArmor通常处于启用状态,该强制访问控制系统允许内核将二进制文件限制为受限的资源集,Ubuntu默认情况下启用此功能,Tesla上的配置看起来是标准配置。
安全 Boot
Tegra支持安全启动,但是围绕它的文档和代码示例很零散。在开发人员论坛中,关于如何实现它的内容也很少,这在高端处理器中很常见。
我们无法最终验证使用安全启动的程度,但是确实发现了几个问题。
ROM引导加载程序通过内部存储的密钥验证BCT的签名,这是SBK,AES-CMAC是BCT的一部分,并经过了验证,这是对称加密,如果发现了密钥,则可以生成有效的BCT。
我们无法确定SBK在每个设备/车辆上是唯一的还是较大的组所共有,需要多个车辆来确定这一点。
另外,Tegra只能在内部存储一个公钥,因此可以使用公钥密码,即使发现了公钥,也仍然无法生成正确签名的BCT图像,这是对称密钥的更强替代方案。据我们估计,在2015年之前(特斯拉CID部署后),软件支持还没有到位。
第一级引导程序执行第二级引导程序的AES-CMAC,无法确定在此使用了哪个密钥,但是Tegra文档指出也可以使用SBK。
第二阶段引导加载程序仅执行内核的CRC。如果信任链中断,攻击者可能会在此阶段将恶意内核加载到设备上。
Userspace 软件
CID一旦启动,便进入用户空间。
一系列Qt二进制文件就会出现在CID的用户界面。我们仅对这些进行了非常有限的逆向,一个8字符的PIN保护CID上的服务菜单,该菜单每天都在变化,并由CID实现。
Shell脚本在车辆中实现了大量功能,逆向很容易,因为它们是可读的文本文件。

[1] [2] [3] [4] [5] [6] [7] [8] [9]  下一页

【声明】:黑吧安全网(http://www.myhack58.com)登载此文出于传递更多信息之目的,并不代表本站赞同其观点和对其真实性负责,仅适于网络安全技术爱好者学习研究使用,学习中请遵循国家相关法律法规。如有问题请联系我们,联系邮箱admin@myhack58.com,我们会在最短的时间内进行处理。
  • 最新更新
    • 相关阅读
      • 本类热门
        • 最近下载