汽车网络安全之——一个汽车ECU的逆向分析

前言

飞思卡尔的MC9S12系列是一款非常经典的16位单片机,主要用于汽车电子,目前可能很少使用了,不过在一些需要考虑成本的件上依然使用。相比于32位单片机,其分页机制给芯片开发带来很多不便(特别是对于bootloader这种需要操作Flash的开发)。本文章是对汽车一般ECU的一个逆向分析过程,主要思路是破解ECU BootLoader,结合UDSonCAN实现固件的任意下载。
目标:
ECU Flash区域分布
FlashDriver提取
跳转地址(程序偏移地址)
中断向量偏移地址

环境&工具

S12内核作为一个专用内核,很少有工具可以调试,不过飞思卡尔提供了开发工具,而且可以通过调试口直接进行内部flash的动态调试!
PE 专用的芯片调试工具
CW1.0 飞思卡尔提供的IDE

准备

对于一个固件进行逆向,首先需要了解这个固件的体系结构。对于汽车ECU,根据功能一般分为三个区域:
BootLoader:用于启动和下载应用程序
Application:ECU中的应用程序
Data:存储一些标定数据等
本次主要针对boot进行分析

MC9S12体系结构

1.启动流程
(可以利用抢刷模式进入刷写模式)
汽车网络安全之——一个汽车ECU的逆向分析_第1张图片
把Flash驱动读出来,把APP的链接位置找出来,进入刷写模式,结合刷写的协议就可以对程序进行任意刷写了。
2.非分页区与分页区
由于是一个16位的单片机,其直接寻址能力差,于是这款芯片采用了分页机制,其映射关系可以参考芯片手册。我们需要利用的是两个信息:1.复位向量要放到非分页区;Flash驱动要放到非分页区;(这样的话,可以看出一般跳转地址就是1400 4000 C000)
汽车网络安全之——一个汽车ECU的逆向分析_第2张图片

BootLoader结构

汽车为什么要有BootLoader
ECU中的BootLoader和广义的BootLoader有几分相似但是更大的是不同。一般ECU的MCU都是支持XIP的,完全可以在flash自启动,这一点不同于外带存储器的嵌入式Linux,其bootloader的作用主要是启动的作用。而ECU的bootloader主要是为了放便更新程序,因为程序都是通过烧录器固化到内部flash中去的,当ECU被封装后便不能再通过这种方法更新程序了,就必须通过预留的通讯接口进行更新,汽车上最常用的便是CAN协议。ECU的bootloader就是基于CAN线的程序更新软件。为了统一ECU的更新规范提出了UDS协议,为了解决CAN多帧传输的问题,提出了ISO-TP协议。

逆向过程

1.跳转位置
启动时 可以看到Boot放到了C000
在这里插入图片描述
对JMP指令进行分析找到跳转点(调试 发现下一个page是E),找到PAGE E,寻找JMP
找到JMP指令
汽车网络安全之——一个汽车ECU的逆向分析_第3张图片
SP指针 20CD 处数据 4000 (X寄存器的值,为应用程序起始地址)
#127(7F) 为中断向量偏移
至此找到应用程序入口与中断向量偏移(根据这个修改恶意代码的链接文件,编译出可用这个boot启动的代码)

2.flash
已知Flash只能存在于三个非分页区位置,那么在观察这三个位置时很容易看出有一片区域有数据,而附近没有其他数据;(程序放到了分页区)
3.27服务逆向
采用一般逆向的手法,动态看27的过程(内容就不贴图了,算法还是要保密的)

安全措施

上面只说了固件层面的分析,协议的分析目前来说还是一个苦力活;通过对以上过程的分析,可以看出对ECU至少要做以下几点防护:
1.保护好调试口,开发模式和发布模式一定不能相同。
2.启用Flash加密,这一点可以写入规范
3.程序中加入一些干扰信息,对于一些重要数据和代码要进行伪装
4.新的27服务安全方法

你可能感兴趣的:(汽车,Security)