汽车网络安全之——一个汽车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.启动流程
（可以利用抢刷模式进入刷写模式）

把Flash驱动读出来，把APP的链接位置找出来，进入刷写模式，结合刷写的协议就可以对程序进行任意刷写了。
2.非分页区与分页区
由于是一个16位的单片机，其直接寻址能力差，于是这款芯片采用了分页机制，其映射关系可以参考芯片手册。我们需要利用的是两个信息：1.复位向量要放到非分页区；Flash驱动要放到非分页区；（这样的话，可以看出一般跳转地址就是1400 4000 C000）

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指令

SP指针 20CD 处数据 4000 （X寄存器的值，为应用程序起始地址）
#127（7F） 为中断向量偏移
至此找到应用程序入口与中断向量偏移（根据这个修改恶意代码的链接文件，编译出可用这个boot启动的代码）

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

安全措施

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