IoT - 标签 - 有价值炮灰 https://evilpan.com/tags/iot/ IoT - 标签 - 有价值炮灰 Hugo -- gohugo.iozh-CNi@pppan.net (evilpan) i@pppan.net (evilpan)This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.Sat, 10 Jul 2021 12:40:00 +0800 蓝牙安全与攻击案例分析 https://evilpan.com/2021/07/10/bluetooth-sec/ Sat, 10 Jul 2021 12:40:00 +0800 evilpan https://evilpan.com/2021/07/10/bluetooth-sec/ 本文是 2020 年中旬对于蓝牙技术栈安全研究的笔记，主要针对传统蓝牙和低功耗蓝牙在协议层和软件安全性上攻击面分析，并介绍了一些影响较大的蓝牙漏洞原理，比如协议层的 KNOB、BIAS 漏洞，软件实现上的 BlueBorne、SweynTooth 以及 BlueFrag 漏洞等。

前言

蓝牙(Bluetooth)是一个短距离无线传输的技术，工作在免证的ISM频段。最初名字为Wibree，在90年代由Nokia设计开发，随后转交给蓝牙特别兴趣小组(SIG)专门维护。

sig

蓝牙标准经过了数十年不愠不火的发展，核心版本从1.0迭代了到目前的5.2，其中在2010年推出的蓝牙4.0版本标准中引进了Bluetooth Smart或者Buletooth Low Energy(BLE)。由于在功耗上有了极大改善，加上智能手机和智能设备的发展，BLE的应用也进入了爆发期。

4.0之前蓝牙通常称为经典蓝牙(Classic Bluetooth)，包括1.0提出的BR(Basic Rate，基础速率)以及2.0提出的EDR(Enhanced Data Rate，增强数据速率)，两者往往放在一起表示与低功耗蓝牙相对的传统蓝牙。BR/EDR常用于相对短距离无线的连续连接，比如耳机的音频传输。

为了进一步提高蓝牙传输速率，在3.0中又提出了基于802.11的AMP(Alternate MAC and PHY layer extension)拓展，这是和BR/EDR不并存的一种传输模式。

核心系统

BR/EDR和BLE虽然都称为蓝牙，但它们在实现上大相径庭。前者主要侧重于点对点的通信，连接性和传输速率是考虑的重点；而BLE则侧重于低功耗的设计，在射频层和基带层上优化了多播和广播的支持。传统上Controller芯片只支持一种射频模式，但越来越多设备中也同时支持两种系统，以覆盖尽量多的使用场景。

framework

蓝牙的核心系统架构包含一个Host和一个或多个Controller，Host可以理解为主核或者主板，运行主流的富操作系统；而Controller可以看做是蓝牙芯片，运行的是裸机程序或者RTOS，主要功能是对射频信号进行编解码。Host和Controller之间通过HCI接口(Host Controller Interface)进行通信，可通过UART、USB等物理接口进行传输。核心系统中包含的组件和之间的关系如下图所示：

core
Core_v5.2 Vol 1: Architecture, Mixing, and Conventions. Part A: Architecture

其中Host部分主要是基于L2CAP抽象出的逻辑信道实现应用层的协议和功能，涉及的关键组件和协议有：

  • Channel Manager：负责创建、管理和释放L2CAP channel。
  • L2CAP Resource Manager：负责管理PDU数据的顺序、调度、分片、重组等功能，是L2CAP核心功能的一部分。
  • SMP：Security Manager Protocol，实现BLE系统中的点对点安全认证功能，包括秘钥生成和认证等；BR/EDR系统的对应功能则在Controller的Link Manager中实现。
  • ATT：Atrribute Protocol，应用层attribute client和server之间的协议。
  • GATT：Generic Attribute Profile，表示ATT server或者client的功能，profile描述了服务和属性的层级结构，主要用于LE profile服务发现中。
  • GAP：Generic Access Profile，表示所有蓝牙设备通用的基础功能，比如传输层、协议、应用所使用的模式或流程等。GAP服务包括设备和服务发现、连接模式、安全认证和关联模型等。

Controller部分中更多是逻辑链路和物理链路的管理，包括：

  • Device Manager：基带(baseband)中控制设备行为的模块，主要负责不与传输直接相关的部分，比如查询周围蓝牙设备，连接蓝牙设备，切换蓝牙设备的状态(discoverable/connectable)，以及修改蓝牙名称、属性等。
  • Link Manager：负责创建、修改和释放逻辑链路(logical links)以及对应的逻辑传输(logical transports)，并更新设备之间对应物理链路(physical links)的相关参数。在BR/EDR系统中，与对端的Link Manager通过LMP协议(Link Manager Protocol)进行通信；在BLE系统中则使用的是LL协议(Link Layer Protocol)。
  • Baseband Resource Manager：负责管理所有到射频媒介的访问。在链路层中，有两种类型的“连接”：
    • SCO：Synchronous Connection Orientated，实时窄带数据传输，如电话音频等，无重传
    • ACL：Asynchronous Connection-Less，异步无连接，用以其他所有数据的传输
  • Link Controller：负责对指定物理信道(逻辑链路和逻辑传输)的蓝牙数据进行编解码。

蓝牙核心系统的每个组件或协议都可以用独立的章节去介绍，整个结构的宏观理解对后面梳理蓝牙的攻击面是非常有必要的。从前面的图中我们可以看到，BR/EDR和BLE在链路层以下是相当不同的，前者为LM而后者为LL，下面分别进行介绍。

在传统蓝牙(即BR/EDR)中，2.4GHz的ISM频段分成79个频段，每个大小为1MHz，并使用特定的跳频模式(Hopping Pattern)来决定一条物理信道，从而减少不同临近终端之间的射频干扰。BR/EDR使用点对点的主从模式，其中Master为确定跳频模式的一方，Slave为与Master时钟和跳频模式同步的其他端点。

传统蓝牙建立链路层连接主要经历两个阶段：Inquiry和Paging。

Inquiry阶段，Master发送查询请求，周围(10米内)可被发现的设备(discoverable)收到请求后会发送查询响应(Inquiry Response)。在查询过程中，因为与周围设备还未连接，因此它们很可能处于不同的信道(跳频序列)，实际上发送查询的设备会在不同的频率进行发送，而接收方(处于standby模式)则以更高地频率进行足够长时间的查询扫描(Inquiry Scan)以确保能被正确唤起。查询响应中包含设备ID和时钟等信息。

Paging阶段，主要解决的是链路层的连接问题。与Inquiry类似，此时各方同样没有进行时钟和频率的同步。Master与Slave的连接需要经过以下六步：

paging

连接状态的两个设备所处于的抽象网络称为piconet，这是一个星状网络，一个Master可以有最多七个Slave，但是Master本身也可以是其他piconet的Slave，这种网络拓扑称为scatternet。传统蓝牙处理链路层连接的管理器称为LM，即Link Manager，两个LM之间通过LMP协议进行通信。

这只是链路层的连接，和我们平常所说的蓝牙配对(pairing)并不是一回事。Paging只是保证了在物理层链路的连通性，进行应用层的通信往往还需要经历两步：

  • 服务发现(Service Discovery)：用以确认对端所支持的服务
  • 服务连接(Service Connection)：使用某个对端设备特定的服务或者配置(Profile)

但是实际上在服务发现之前，蓝牙引入了一层安全性保障，确保双方是自愿连接的，沟通连接意愿的过程就称为配对。经过配对后的设备会分别记住对方，在下一次连接时就不需要进行重新配对，而是使用之前保存的连接秘钥(Link Key)直接进行认证和连接：

LM

蓝牙Spec中定义了legacy authentication和secure authentication情况下的认证流程和状态。当两个设备没有共同的link key时，就需要使用pairing流程来协商创建初始化秘钥Kinit。 关于配对流程的分析在后面会详细介绍。

在BLE中，2.4GHz的ISM频段分成40个频段，每个大小为2MHz，其中3个信道为广播信道(advertising channel)，其余37个为通用信道(general purpose channel)。BLE也支持对建立连接后的端点在通用信道中进行跳频通信。

各个信道的频率为: f = 2402 + k * 2 MHz, k = 0, 1, ... , 39

BLE链路层的状态机包括以下状态：

  • Standby State
  • Advertising State
  • Scanning State
  • Initiating State
  • Connection State
  • Synchronization State
  • Isochronous Broadcasting State

任一时刻只能处于其中的一种状态，有限状态机的转换过程如下：

FSM

实际中的链路层的状态机不一定要实现上述完整的状态，但蓝牙标准中定义了一些相互依赖的状态组合，实现了其中一种就必须要实现另外一种。任何其他状态都可以直接进入Standby状态，而只有Advertising和Initiating状态才能进入Connection状态。Connection状态中连接的双方分别根据来源状态定义为：

  • Master Role：从Initiating状态进入
  • Slave Role：从Advertising状态进入

与传统蓝牙类似，一个Slave只能与一个Master进行连接。在BLE中，链路层数据包所包含的数据称为协议数据单元(PDU)，Advertising的三个物理信道包含Advertising PDU、Scanning PDU和Initiating PDU，数据信道包含LL Data PDU和LL Control PDU等，不同的PDU包含不同类型的Payload。当然这都是发生在双方Controller端的LL之间，Host端还是主要使用HCI协议对其进行封装，根据不同的场景我们可能需要专注某一端的的实现，比如对于蓝牙芯片固件的研究更多是对LL端的数据进行分析，其他情况下对于应用层或者开发者则更多地关注Host端的HCI、L2CAP、ATT等协议。

蓝牙的服务发现和调用不考虑安全性的话可以直接在同步完物理信道后直接进行应用层交互，但为了避免窃听和中间人等攻击，甚至是为了避免错误连接到其他同名设备，蓝牙服务也是必须要有安全性保障的。初次接触蓝牙Spec的人可能会对蓝牙连接和配对的概念比较困惑，因为蓝牙标准在不同版本中定义了不同的配对模型，而BR/EDR和BLE的配对过程又发生在不同的模块中。比如BR/EDR配对过程由双方Controller端的LM(Link Manager)使用LMP协议进行协商，而BLE的配对过程则主要通过Host端的协议栈(Security Manager)进行协商。

从时间线上来看，BR/EDR分为几个阶段：

  • 2.1之前：使用Legacy Pairing，后续版本中称为BR/EDR legacy
  • 2.1：使用 Secure Simple Pairing
  • 4.2：使用 Secure Connection

BLE也经历了几个阶段的变化：

  • 4.0和4.1：使用 Secure Simple Pairing，后续版本中称为BLE legacy
  • 4.2：使用 Secure Connection

Legacy Pairing 使用双方输入或者固定的PIN CODE来进行认证，现在已经非常少见，因此可以不用关注。

Secure Simple Pairing 的配对方式主要经过以下4步(以BR/EDR为例)：

  1. IO capabilities exchange：交换对方的特性，比如是否支持显示和键盘输入等，用以后续协商认证手段
  2. Public key exchange：交换椭圆曲线的公钥
  3. Authentication stage 1：身份认证
  4. Authentication stage 2：ECDH Key校验

对于身份认证，BR/EDR定义了4种认证方式：

  • Just Works：静默认证，主要用于没有显示和输入功能的设备，如耳机等
  • Numeric Comparison：双方生成随机数并计算出一个6位数字进行比对确认
  • Passkey Entry Authentication：主要用于一方有显示功能另外一方有输入功能的场景
  • OOB(Out Of Band)：使用蓝牙射频以外的其他通道(如NFC)来交换认证信息

前面说了BR/EDR 2.1和BLE4.0/4.1都使用Secure Simple Pairing进行配对，为什么还特地强调是BR/EDR呢？因为虽然他们都叫做SSP，但实际上也存在不同的地方，比如BLE的SSP没有使用ECDH，因此数字的认证只能防止被动窃听(passive eavesdropping)，不能防止中间人攻击，并且BLE中没有Numeric Comparison的认证方式。

不过，这也只是过去式了。在4.2以后，BLE和BR/EDR终于统一了配对流程，称为Secure Connection。其在SSP的基础上进行了安全性的增强，下面是BR/EDR的对比：

安全特性\配对类型 Legacy Secure Simple Pairing Secure Connection
加密 E0 E0 AES-CCM
认证 SAFER+ SAFER+ HMAC-SHA256
秘钥生成 SAFER+ P-192 ECDH HMAC-SHA-256 P-256 ECDH HMAC-SHA-256

而BLE也是殊途同归，最新实现的配对方式也升级成了功能相同的 Secure Connection。

常见协议

在前面的介绍中我们已经多次提到，主机系统称为Host，蓝牙射频芯片的系统称为Controller，它们之间的通信接口称为HCI(Host Controller Interface)，同时这也是其传输协议的名字。HCI是Host端所能接触的最底层协议，通过内核的HCI驱动进行操作，基于HCI逐步往上封装和实现了一系列高级协议，本节就以自底向上的角度去进行介绍。

HCI协议是HCI接口最底层的协议，可根据传输层的介质分为不同类型，例如：

  • UART传输层：在btsnoop中表示为hci_h4
  • USB传输层：在btsnoop中表示为hci_h5
  • SD传输层：Secure Digital
  • …

HCI数据包分为command、event和data三种类型。command表示Host发送给Controller的命令，event为Controller发送给Host的事件，data通常是实际的蓝牙传输数据。

See: https://software-dl.ti.com/simplelink/esd/simplelink_cc13x2_sdk/1.60.00.29_new/exports/docs/ble5stack/vendor_specific_guide/BLE_Vendor_Specific_HCI_Guide/hci_interface.html

HCI command的格式为：

16bit opcode | 8bit 参数长度 | 可变参数

其中opcode又分为两部分，高6位为OGF(Opcode Group Field)，低10位为OCF(Opcode Command Field)。在Linuz中我们常用的bluez框架也可以直接发送hci命令：

$ hcitool cmd --help
Usage:
        cmd <ogf> <ocf> [parameters]
Example:
        cmd 0x03 0x0013 0x41 0x42 0x43 0x44

HCI event的格式为：

8bit event code | 8bit 参数长度 | 可变参数

通常Host发送的command都会收到Controller的返回event，提示命令的执行结果。例如，HCI命令0x200c表示LE Set Scan Enable，并通过参数控制开启和关闭BLE的扫描，Controller执行完毕后返回event code 0x0e，即Command Complete，并附带status作为参数表示结果是否成功。详细的命令和事件列表可以参考Core_v5.2 Vol 4: Host Controller Interface, Part E-7 HCI commands and events。

除了command和event，HCI中还包括的一大载荷就是数据，比如前面提到的同步数据包SCO、ISO(isochronous)和无连接数据包ACL等。

HCI的ACL协议主要用于在Host和Controller之间传输数据，ACL数据包的格式如下：

12bit   | 2bit    | 2bit    | 16bit             | varlen
Handle 	| PB flag | BC flag | Data Total Length | data

其中，Handle用于区分Host与Controller之间的逻辑链路，PB为Packet Boundary即包边界标志，BC(Broadcast)为广播标志。由于数据总长度只用2个字节表示，因此数据加上头部最多也只有65535字节，这意味着在发送过大的数据时需要在ACL层进行分包和重组，PB Flag就是为了这个目的而设置的，根据PB Flag的值可以表示当前数据包在完整数据中所处的位置。

ACL只提供了一个数据传输协议，类比于网络协议栈中的IP协议，在其之上使用的L2CAP协议可以类比于TCP/UDP协议，实现了更为完善的数据传输功能，包括：

  1. 协议/信道(L2CAP channel)多路复用
  2. 分段(segmentation)和重组(reassembly)
  3. 基于L2CAP channel的流量控制机制
  4. 错误控制重传机制
  5. 支持流式传输(streaming)
  6. 分片(fragmentation)和重组(recombination)
  7. QoS(Quality of Service)
  8. …

L2CAP channel表示两个设备之间的一条逻辑链路，使用channel id(CID)进行区分，并以此为基本单元在Controller逻辑链路上进行多路复用。在基于连接的信道(connection-oriented channels)中，L2CAP PDU也称为B-Frame，其格式如下：

16bit length | 16bit CID | information payload

前32bit称为L2CAP header，length是除了header以外的payload长度。在不同的L2CAP模式中，information payload的内容也不尽相同，比如在Supervisor Frame(S-Frame)、Information Frame(I-Frame)。而对于无连接的L2CAP数据包，在payload之前还包含大于等于2字节的PSM(Protocol/Service Multiplexer)，头部还是和B-Frame一致的。

在L2CAP之上，有着各种各样的应用层协议，比如服务发现协议SDP，蓝牙传输协议RFCOMM/OBEX，BLE的属性协议ATT，甚至是通用以太网协议BNEP以及其上的TCP/IP网络栈等。通过分层和抽象使得上层应用无需关心底层的细节，从而实现了整个蓝牙协议栈的普适性和拓展性。

协议安全

这里的协议安全不是指网络协议栈的安全性，而是蓝牙核心协议，或者说蓝牙标准本身的安全性。虽然蓝牙SIG小组在制定标准前都经过了多方讨论和研究，可依然可能存在一些没有考虑周到的临界情况。

KNOB Attack是2018年3月发现，并在同年10月报告给蓝牙SIG和CERT的一个通用协议漏洞。漏洞点主要出现在LMP协议的秘钥协商阶段，正常来说，两个蓝牙设备连接和配对的过程如下：

LMP

配对之后会先进行蓝牙秘钥协商，协商过程使用的是配对过程协商的ECDH临时秘钥以保证协商过程保密。协商过程使用LMP协议，在各自的Controller端实现：

controller

问题就出在LMP entropy（熵)协商的阶段，因为这部分的协商过程是没有经过ECDH秘钥保护的，所以就容易受到中间人攻击，恶意的攻击者可以将熵设置得尽可能小，从而可以在后面快速地爆破出Kc并实时解密蓝牙的传输数据。这也是为什么该攻击称为KNOB(Key Negotiation of Bluetooth) Attack的原因。

该漏洞的编号为CVE-2019-9506，由于是蓝牙核心协议中的设计漏洞，因此影响了大量的蓝牙设备，比如Broadcom、CYW、Apple、Snapdragon等蓝牙芯片。修复方法自然是对秘钥熵协商的过程进行加密，不过这个要等SIG更新进标准中，而标准的更新和推进又相对缓慢，因此很多蓝牙芯片厂商也各自更新了固件做简单的patch。该漏洞的直接危害就是导致蓝牙链路的中间人攻击，导致传输信息泄露或者劫持，实际攻击场景比如蓝牙键盘、蓝牙鼠标等应该是受影响比较大的。

参考资料：

BIAS全称为Bluetooth Impersonation Attacks，是2020年5月左右公开的另外一个蓝牙协议的漏洞，CERT编号为CVE-2020-10135。该漏洞实际上是一系列协议设计缺陷导致的认证错误，最终导致对未配对的设备进行连接(或者说伪造成已配对的设备)。

该漏洞主要是针对传统蓝牙(BR/EDR)的配对过程。前面已经说过，在蓝牙协议的发展中，安全配对主要分为三个阶段，即Legacy Pairing、SSP和Secure Connection。配对的作用是让从未见过的设备建立可信、安全的链路层链接，宏观来看就是我们常见的输入配对数字过程，微观上是协商了一个双方持有的长期秘钥LTK(Long Term Key，或者说链接秘钥LK(Link Key)，LTK用来生成后续安全链接的会话秘钥(Session Key)。两个设备只用配对一次，但可使用保存的LTK进行多次安全连接。

在蓝牙连接的过程中，数据是不经过加密或者校验的。连接建立的主要作用是让两个设备交换它们公开的capability信息、互相校验对方的长期秘钥并计算会话秘钥。如果连接的设备支持Secure Connection，就使用安全连接方法建立链接，连接的过程使用AES-CCM经过加密和完整性保护；否则，就使用Legacy Secure Connection(简称为LSC)，连接过程使用E0流加密方法进行加密，并按照对应的流程进行连接。安全连接的建立同样通过LMP协议进行。

之所以介绍这些背景，是因为漏洞的成因与背景相关性较大，在上面的基础上，BIAS漏洞可以描述为以下问题：

  1. LSC过程中master发起连接请求，slave返回自己的LTK认证响应，但master可以不进行校验，也就是说在LSC中对LTK的校验只是单向的，即master校验slave的LTK即可。因此在LSC中攻击者可以轻易伪造成master进行连接。

  2. 在LSC过程中，攻击者若想伪造成slave，则可以在收到master的连接请求后发起Role Switch角色互换请求，将自己变成master，从而在1的基础上伪造成Slave。

  3. 在Secure Connection的情况下，攻击者可以通过返回Secure Connection not Support来发起降级攻击，从而使用LSC进行后续连接，即回退到1/2的场景中进行对端伪造。

  4. 在Secure Connection的情况下，另一种攻击方法是反射攻击。即在收到Secure Connection的请求后发起Role Switch操作，并且伪造对端的认证请求，由于两端的LTK相同，因此对端可以返回合法的认证响应；之后再发起一次Role Switch，将合法的认证响应转发给对端，从而完成安全链接。

BIAS漏洞产生的根源是蓝牙协议中不严谨的定义，比如为了兼容性允许Secure Connection降级，并且Role Switch的设计完全没有考虑安全性，对其发起的时机不加判断导致被滥用。从漏洞危害来看，BIAS的直接影响是可以绕过了手动确认的配对认证与目标设备进行连接，一个典型的例子是可以伪造成目标电脑或手机曾经配对过的蓝牙耳机设备，并静默地与目标进行连接，从而实现间接控制扬声器和麦克风的效果。

参考资料：

上面介绍的只是两个比较知名的协议漏洞，类似的协议设计问题还有很多，比如《Breaking Secure Pairing of Bluetooth Low Energy Using Downgrade Attacks》中就介绍了一种针对SCO(Secure Connection Only)模式的降级攻击。实际上蓝牙核心协议的每次修订，都或多或少对以前版本的疏漏进行了修补。蓝牙协议上出现的安全问题往往影响广泛并且难以修复，因为SIG更新协议需要一定时间，从协议更新到各个厂商的实现和测试也旷日持久。通常这类问题出现后都是厂商自身根据自己的理解进行缓解性修补，这也另一方面影响了漏洞修复的质量。

实现安全

由于蓝牙协议是如此复杂，而且协议本身还随着时间的变迁而不断更新进化，这对于蓝牙的实现造成了巨大挑战。这要求蓝牙固件的开发者一方面要深入理解蓝牙协议的实现过程，另一方面也要对软件安全开发本身有一定认识。尤其是在Controller端，目前还没有一个公开的蓝牙参考实现，蓝牙芯片的内部代码都是各个厂商珍藏的intellectual property。

蓝牙的协议本身都复杂到经常出现非预期的安全问题，那蓝牙的实现就更不用说了。从诺基亚时代开始，就出现过许多代码实现导致的蓝牙软件安全漏洞，比如BlueJack、BlueBugging、BlueBump、Bluesmack、SweynTooth、BlueBorne、BlueFrag等等，……下面挑选几个比较著名的漏洞进行分析。

BlueBorne是2017年左右公开的一组蓝牙漏洞，当年影响了多个平台和系统，甚至包括IoT设备如Amazon Echo和Google Home等。虽然时过境迁了，但也值得回顾一下。涉及到的漏洞如下：

  • CVE-2017-0781/CVE-2017-0782：Android中l2cap/bnep的内存破坏，可导致RCE
  • CVE-2017-0785：Android中SDP协议continuation请求偏移校验不当导致的信息泄露
  • CVE-2017-0783：Android中PANU交互不当导致的中间人攻击
  • CVE-2017-8628：Windows中蓝牙驱动实现不当导致的中间人攻击
  • CVE-2017-1000250：Linux BlueZ中SDP实现不当导致的信息泄露，与前面Android中的SDP漏洞原理类似
  • CVE-2017-1000251：Linux BlueZ中处理L2CAP配置响应不当导致的栈溢出，可进一步造成RCE
  • CVE-2017-14315：iOS中LEAP (Low Energy Audio Protocol)协议的堆溢出，可进一步造成RCE

印象中这是首次在蓝牙实现上批量公开的严重漏洞，在审计蓝牙协议实现时可以发现一些常见的错误模式，比如用户可控长度字段时导致的信息泄露和溢出，这些模式在不同平台的实现中可能都有类似的纰漏，因此所产生的安全问题在不同平台中的迁移性是比较高的。

参考资料：

SweynTooth漏洞也是一系列漏洞的集合，在2019年左右公开。虽然把它归类到实现安全中，但其中大部分漏洞的本质是各个厂商在实现蓝牙核心协议未定义行为时引发的异常。低功耗蓝牙BLE的消息交互流程如下图所示：

messages

从这个图中可以引申出许多有趣的问题，比如：”如果LL加密流程在配对的过程中发起会怎么样？“……直觉来看有可能会造成全零LTK的安装、秘钥大小溢出、公钥不合法等错误。但由于蓝牙核心协议中对这种情况没有明确说明，因此这类的错误处理就全由厂商安装自己的理解去实现了。

一个蓝牙产品在打上蓝牙Logo之前需要经过蓝牙的认证，进行一系列基线兼容性检查，但这个检查也不是面面俱到的。因此，有的即便蓝牙核心协议中有明确定义的行为，在实际测试中也会发现一些SoC厂商的实现不一致。比如，蓝牙核心协议中定义peripheral在同一个central-peripheral连接中应该只响应一次version request请求，但实际上Telink的设备会响应多次，这都是基线测试难以顾及到的地方。

作者也就是在测试这些Corner Case的情况下，发现了一系列Bug/漏洞，命名为SweynTooth，例如：

  • CVE-2019-16336, CVE-2019-17519：链路层Length字段溢出，导致DoS和潜在的RCE
  • CVE-2019-17061, CVE-2019-17060：链路层的LLID处理不当导致死锁
  • CVE-2019-17517：处理L2CAP包时对长度字段的校验错误导致内存越界拷贝
  • ….
  • CVE-2019-19194：Telink SMP的Secure Connection实现在配对过程中发起LE加密流程时会导致全零LTK的安装

加起来一共12个公开漏洞，不过利用场景都很有限，除了全零LTK漏洞外，大部分只能造成蓝牙芯片的固件崩溃重新启动或者死锁。不过，从这组漏洞中我们也能看到蓝牙固件的实现也是有不少问题的，蓝牙芯片固件的代码本身难以进行热更新，在一些特殊的HCI Event配合下，我们甚至可以从Controller中获取Host的命令执行权限。

BlueFrag是2020年2月在Android安全通告中披露的一个严重漏洞，影响蓝牙子系统可实现远程命令执行。该漏洞主要是在Android中的L2CAP层实现上，是由于L2CAP的分片和重组包长度计算出错导致的内存破坏。

漏洞修复如下：

diff --git a/hci/src/packet_fragmenter.cc b/hci/src/packet_fragmenter.cc
index 5036ed5..143fc23 100644
--- a/hci/src/packet_fragmenter.cc
+++ b/hci/src/packet_fragmenter.cc
@@ -221,7 +221,8 @@
                  "%s got packet which would exceed expected length of %d. "
                  "Truncating.",
                  __func__, partial_packet->len);
-        packet->len = partial_packet->len - partial_packet->offset;
+        packet->len =
+            (partial_packet->len - partial_packet->offset) + packet->offset;
         projected_offset = partial_packet->len;
       }

值得一提的是，这个漏洞本身会导致memcpy拷贝负数长度，正常情况下会一直拷贝直至触发非法内存空间，但在Android的libc实现上memcpy优化的实现会令拷贝前面的若干字节以及末尾的64字节退出，从而出现一个可控的内存越界读写，在此基础上可以进一步实现控制流劫持导致远程命令执行。 Android中L2CAP的实现在用户层中，称为BlueDroid，用户进程为com.android.bluetooth，因此执行命令后所获得的权限也是bluetooth权限。

参考资料：

应用安全

前面介绍的都是比较底层的协议，而在一般安全论坛和关于蓝牙安全的相关文章中介绍的通常更多是应用相关的安全，比如蓝牙智能门锁的重放、越权等问题。这部分协议的交互主要在LTK协商之后，基于会话秘钥加密的信道传输应用层信息，当然也可以是BLE中基于广播的通信。

在上层的通信中，一个重要的概念就是Profile，表示设备所支持功能的一种垂直切分。其中既包括所有设备都通用的如Generic Access Profile(GAP)和Generic Attribute Profile(GATT)，也包括基于特定用途的Profile如Proximity Profile和Glucose Profile等。Profile本质上定义了如何使用协议来实现某种通用或者特定的目的。

Profile的存在是蓝牙协议与众不同的一个地方，为什么会有这么多Profile，而不是像通用协议一样，定义好协议结构和字段，然后进行通用拓展呢？在《计算机网络》中有这么一段话:

真的有必要分清楚所有应用的细节，并且为每一种应用提供不同的协议栈吗？也许没有这个必要。但是，由于存在多个不同的工作组，他们分别负责设计标准的不同部分，因此，每个工作组都只关注特定的问题，从而形成了自己的Profile。你可以把这个看成是康威法则在起作用。或许蓝牙标准根本不用25个协议栈，两个就可以了，一个用于文件传输，另外一个用于流式实时通信。

可见SIG蓝牙特别兴趣小组各自为战是蓝牙Profile的形式发展至今的重要原因之一。

GATT定义了一个标准的数据模型与流程用以设备发现、读写和推送数据。一个GATT server中通常包含多个Service，而每个Service又可以包含多个Characteristic。每个Characteristic都有一个16位或者128位的UUID，并带有可选的数据描述Descriptor。Characteristic是GATT通信中最小的数据单元，封装了一个单一的数据点，其中可能包含一组相关的数据，比如加速传感器x/y/z轴的坐标数据。根据权限的不同，我们可以向Characteristic中读写数据。

举个例子，对于心率计而言，可能有一个Heart Rate Service，其中包括两个Characteristic，分别是HM(Heart Rate Measurement)和BSL(Body Sensor Location)，前者还包含一个Descriptor，CCCD(Client Characteristic Configuration Descriptor)，这是一个常见的descriptor，用来表示通知开关状态。

service
示例: 蓝牙的心跳服务结构

其中大部分常用的属性在蓝牙SIG文档中都定义了对应的UUID，当然也包括一部分Vendor Specific的UUID留给厂商自行去拓展和定义。

研究蓝牙应用安全的一个常用办法是在收发数据时候进行抓包，比如Android中支持在开发者模式中打开蓝牙日志，iOS支持使用XCode的拓展工具PacketLogger进行抓包。此外还可以通过对应用进行逆向或者动态追踪的方式来观察应用层的交互数据，从而挖掘背后存在的安全漏洞。由于这类问题与具体的产品和应用有关，这里就不举例说明了，感兴趣的朋友可以参考相关蓝牙应用设备的公开安全通告。

小结

从漏洞的影响面来看，协议类的蓝牙漏洞通常影响广泛且难以修复，因为需要修改协议并推进各个蓝牙厂商去进行重新实现和更新；从危害性来看，协议类的漏洞往往影响的是蓝牙信道的安全，在一般场景中危害相对有限；而实现类的漏洞通常导致内存破坏，被攻击者精心构造利用则可以造成整个系统的沦陷，一旦被利用就很可能是个严重的 RCE；应用类的漏洞通常是厂商的应用开发者所造成的疏忽，在某些情况下可导致智能设备被劫持控制，虽然修复较为容易，但这类漏洞频繁出现在不同的蓝牙应用中，因此其安全影响也是不可忽视的。

]]> 树莓派无界面初始化 https://evilpan.com/2021/01/30/headless-rpi/ Sat, 30 Jan 2021 12:40:00 +0800 evilpan https://evilpan.com/2021/01/30/headless-rpi/ 时不时地会用到树莓派，但是每次都忘了怎么配置，因此单独记录一篇方便以后查询。

初始化

无界面初始化，也就是常说的 headless initialization，目的是在不需要给树莓派接入额外的显示器的情况下完成基本的无线网络配置，并且启动好必要的远程管理工具比如 ssh 等。

首先下载镜像，然后根据官方的安装指引将镜像烧写到 SD 卡中，对于 *NIX 系统而言，推荐直接使用 dd 烧写:

dd bs=4M if=2021-01-11-raspios-buster-armhf.img of=/dev/sdX

当然 Linux 和 MacOS 下的操作略有差别，可以参考官方的对应章节。

配置网络

一般我们要让树莓派连接无线网络是通过如下方式:

# 扫描WiFi
iwlist wlan0 scan
# 添加目标 SSID 和密码到 /etc/wpa_supplicant/wpa_supplicant.conf
# 启用配置
wpa_cli -i wlan0 reconfigure

wpa_supplicant.conf 的参考内容如下:

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=US

network={
    ssid="YOURSSID"
    psk="YOURPASSWORD"
    scan_ssid=1
}

在插入 SD 卡前，我们可以先挂载并直接将该文件放置在 boot 目录下，这样树莓派启动后就会自动进行配置并连接网络。例如 /Volumes/boot/wpa_supplicant.conf。值得一提的是第一次启动并连接网络可能需要比较长时间。

参考: Setting up a Raspberry Pi headless

如果想要启动时开启 SSH，可以在 boot 目录下添加 ssh 文件，raspbian 启动时会检测该文件是否存在，如果存在则启动 SSH 服务。

touch /Volumes/boot/ssh

在旧版本中文件名是 ssh.txt

配置串口

在没有网络或者网络不佳的情况下，我们还可以通过串口登录树莓派。如下在挂载的 SD 卡中启用串口:

echo enable_uart=1 >> /Volumes/config.txt

默认情况下主串口分配给了 Linux console，因此开机后就可以从串口登录 shell 了。

参考: UART configuration

当然这默认你手上有一个 USB 转串口的线，不同的树莓派型号对应的串口引脚位置略有不同，例如树莓派 3 Model B 的引脚如下:

pin.png
树莓派 3B+ 引脚图片

每个引脚对应的功能如下:

pin1.png
树莓派 3B+ 引脚说明

其他型号的具体引脚说明可以参考 Pi4J - Pin Numbering，或者树莓派官方的资料。

也就是说我们只需要将串口线分别接到 6，8，10号引脚即可。

u2u.png

有几个值得注意的点:

  1. TX接RX, RX接TX, 有usb供电的情况下不用接VCC
  2. MacOS 下串口设备通常是 /dev/cu.*
  3. 默认波特率可能是 115200 或者 115600

命令行下可以用 screen 或者 miniterm 等连接串口，例如:

screen /dev/cu.usbserialxxx 115200

screen 的退出方式为 ctrl+A 加 ctrl+\。

其他

对于树莓派 Zero 而言，我们还可以使用 OTG Ether Gadget，将树莓派本身配置(模拟)成 USB 网卡，然后通过 USB 去连接树莓派。不过这种方式并不是很稳定，而且只适用于支持 OTG 的 Zero，因此对于无界面配置而言更推荐使用串口方式。

一般启用 USB 网卡模拟的方式如下:

  1. 在 /boot/config.txt 中添加 dtoverlay=dwc2。dwc2 是一个 OTG 驱动，用于检测 USB 口的模式。
  2. 在 /etc/modules 中添加所需要的内核模块:
dwc2
g_ether

如果需要无界面配置，在第二步中该为修改内核命令行文件cmdline.txt，在nowait之后添加 modules-load=dwc2,g_ether。

重新启动后 OTG 口就可以被 host 识别为 USB 网卡，通过网卡分配的地址即可连接到树莓派中:

ssh pi@raspberrypi.local
]]> 深入浅出ELF https://evilpan.com/2020/08/09/elf-inside-out/ Sun, 09 Aug 2020 22:40:00 +0800 evilpan https://evilpan.com/2020/08/09/elf-inside-out/

本文介绍了ELF的基本结构和内存加载的原理，并用具体案例来分析如何通过ELF特性实现HIDS bypass、加固/脱壳以及辅助进行binary fuzzing。

前言

作为一个安全研究人员，ELF可以说是一个必须了解的格式，因为这关系到程序的编译、链接、封装、加载、动态执行等方方面面。有人就说了，这不就是一种文件格式而已嘛，最多按照SPEC实现一遍也就会了，难道还能复杂过FLV/MP4？曾经我也是这么认为的，直到我在日常工作时遇到了下面的错误:

$ r2 a.out
Segmentation fault

作为一个开源爱好者，我的radare2经常是用master分支编译的，经过在github中搜索，发现radare对于ELF的处理还有不少同类的问题，比如issue#17300以及issue#17379，这还只是近一个月内的两个open issue，历史问题更是数不胜数。

总不能说radare的开发者不了解ELF吧？事实上他们都是软件开发和逆向工程界的专家。不止radare，其实IDA和其他反编译工具也曾出现过各类ELF相关的bug。

说了那么多，只是为了引出一个观点: ELF既简单也复杂，值得我们去深入了解。网上已经有了很多介绍ELF的文章，因此本文不会花太多篇幅在SPEC的复制粘贴上，而是结合实际案例和应用场景去进行说明。

ELF 101

ELF的全称是Executable and Linking Format，这个名字相当关键，包含了ELF所需要支持的两个功能——执行和链接。不管是ELF，还是Windows的PE，抑或是MacOS的Mach-O，其根本目的都是为了能让处理器正确执行我们所编写的代码。

在上古时期，给CPU运行代码也不用那么复杂，什么代码段数据段，直接把编译好的机器码一把梭烧到中断内存空间，PC直接跳过来就执行了。但随着时代变化，大家总不能一直写汇编了，即便编译器很给力，也会涉及到多人协作、资源复用等问题。这时候就需要一种可拓展(Portable)的文件标准，一方面让开发者(编译器/链接器)能够高效协作，另一方面也需要系统能够正确、安全地将文件加载到对应内存中去执行，这就是ELF的使命。

view.png
view

从大局上看，ELF文件主要分为3个部分:

  • ELF Header
  • Section Header Table
  • Program Header Table

其中，ELF Header是文件头，包含了固定长度的文件信息；Section Header Table则包含了链接时所需要用到的信息；Program Header Table中包含了运行时加载程序所需要的信息，后面会进行分别介绍。

ELF头部的定义在elf/elf.h中(以glibc-2.27为例)，使用POD结构体表示，内存可使用结构体的字段一一映射，头部表示如下:

#define EI_NIDENT (16)

typedef struct
{
  unsigned char	e_ident[EI_NIDENT];	/* Magic number and other info */
  Elf32_Half	e_type;			/* Object file type */
  Elf32_Half	e_machine;		/* Architecture */
  Elf32_Word	e_version;		/* Object file version */
  Elf32_Addr	e_entry;		/* Entry point virtual address */
  Elf32_Off	e_phoff;		/* Program header table file offset */
  Elf32_Off	e_shoff;		/* Section header table file offset */
  Elf32_Word	e_flags;		/* Processor-specific flags */
  Elf32_Half	e_ehsize;		/* ELF header size in bytes */
  Elf32_Half	e_phentsize;		/* Program header table entry size */
  Elf32_Half	e_phnum;		/* Program header table entry count */
  Elf32_Half	e_shentsize;		/* Section header table entry size */
  Elf32_Half	e_shnum;		/* Section header table entry count */
  Elf32_Half	e_shstrndx;		/* Section header string table index */
} Elf32_Ehdr;

注释都很清楚了，挑一些比较重要的来说。其中e_type表示ELF文件的类型，有以下几种:

  • ET_NONE: 未知类型
  • ET_REL: 可重定向类型(relocatable)，通常是我们编译的*.o文件
  • ET_EXEC: 可执行类型(executable)，静态编译的可执行文件
  • ET_DYN: 共享对象(shared object)，动态编译的可执行文件或者动态库*.so
  • ET_CORE: coredump文件

e_entry是程序的入口虚拟地址，注意不是main函数的地址，而是.text段的首地址_start。当然这也要求程序本身非PIE(-no-pie)编译的且ASLR关闭的情况下，对于非ET_EXEC类型通常并不是实际的虚拟地址值。

其他的字段大多数是指定Section Header(e_sh)和Program Header(e_ph)的信息。Section/Program Header Table本身可以看做是数组结构，ELF头中的信息指定对应Table数组的位置、长度、元素大小信息。最后一个e_shstrndx表示的是section table中的第e_shstrndx项元素，保存了所有section table名称的字符串信息。

上节说了section header table是一个数组结构，这个数组的位置在e_shoff处，共有e_shnum个元素(即section)，每个元素的大小为e_shentsize字节。每个元素的结构如下:

typedef struct
{
  Elf32_Word	sh_name;		/* Section name (string tbl index) */
  Elf32_Word	sh_type;		/* Section type */
  Elf32_Word	sh_flags;		/* Section flags */
  Elf32_Addr	sh_addr;		/* Section virtual addr at execution */
  Elf32_Off	sh_offset;		/* Section file offset */
  Elf32_Word	sh_size;		/* Section size in bytes */
  Elf32_Word	sh_link;		/* Link to another section */
  Elf32_Word	sh_info;		/* Additional section information */
  Elf32_Word	sh_addralign;		/* Section alignment */
  Elf32_Word	sh_entsize;		/* Entry size if section holds table */
} Elf32_Shdr;

其中sh_name是该section的名称，用一个word表示其在字符表中的偏移，字符串表(.shstrtab)就是上面说到的第e_shstrndx个元素。ELF文件中经常使用这种偏移表示方式，可以方便组织不同区段之间的引用。

sh_type表示本section的类型，SPEC中定义了几十个类型，列举其中一些如下:

  • SHT_NULL: 表示该section无效，通常第0个section为该类型
  • SHT_PROGBITS: 表示该section包含由程序决定的内容，如.text、.data、.plt、.got
  • SHT_SYMTAB/SHT_DYNSYM: 表示该section中包含符号表，如.symtab、.dynsym
  • SHT_DYNAMIC: 表示该section中包含动态链接阶段所需要的信息
  • SHT_STRTAB: 表示该section中包含字符串信息，如.strtab、.shstrtab
  • SHT_REL/SHT_RELA: 包含重定向项信息
  • …

虽然每个section header的大小一样(e_shentsize字节)，但不同类型的section有不同的内容，内容部分由这几个字段表示:

  • sh_offset: 内容起始地址相对于文件开头的偏移
  • sh_size: 内容的大小
  • sh_entsize: 有的内容是也是一个数组，这个字段就表示数组的元素大小

与运行时信息相关的字段为:

  • sh_addr: 如果该section需要在运行时加载到虚拟内存中，该字段就是对应section内容(第一个字节)的虚拟地址
  • sh_addralign: 内容地址的对齐，如果有的话需要满足sh_addr % sh_addralign = 0
  • sh_flags: 表示所映射内容的权限，可根据SHF_WRITE/ALLOC/EXECINSTR进行组合

另外两个字段sh_link和sh_info的含义根据section类型的不同而不同，如下表所示:

type.png
type

至于不同类型的section，有的是保存符号表，有的是保存字符串，这也是ELF表现出拓展性和复杂性的地方，因此需要在遇到具体问题的时候查看文档去进行具体分析。

program header table用来保存程序加载到内存中所需要的信息，使用段(segment)来表示。与section header table类似，同样是数组结构。数组的位置在偏移e_phoff处，每个元素(segment header)的大小为e_phentsize，共有e_phnum个元素。单个segment header的结构如下:

typedef struct
{
  Elf32_Word	p_type;			/* Segment type */
  Elf32_Off	p_offset;		  /* Segment file offset */
  Elf32_Addr	p_vaddr;		/* Segment virtual address */
  Elf32_Addr	p_paddr;		/* Segment physical address */
  Elf32_Word	p_filesz;		/* Segment size in file */
  Elf32_Word	p_memsz;		/* Segment size in memory */
  Elf32_Word	p_flags;		/* Segment flags */
  Elf32_Word	p_align;		/* Segment alignment */
} Elf32_Phdr;

既然program header的作用是提供用于初始化程序进程的段信息，那么下面这些字段就是很直观的:

  • p_offset: 该segment的数据在文件中的偏移地址(相对文件头)
  • p_vaddr: segment数据应该加载到进程的虚拟地址
  • p_paddr: segment数据应该加载到进程的物理地址(如果对应系统使用的是物理地址)
  • p_filesz: 该segment数据在文件中的大小
  • p_memsz: 该segment数据在进程内存中的大小。注意需要满足p_memsz>=p_filesz，多出的部分初始化为0，通常作为.bss段内容
  • p_flags: 进程中该segment的权限(R/W/X)
  • p_align: 该segment数据的对齐，2的整数次幂。即要求p_offset % p_align = p_vaddr。

剩下的p_type字段，表示该program segment的类型，主要有以下几种:

  • PT_NULL: 表示该段未使用
  • PT_LOAD: Loadable Segment，将文件中的segment内容映射到进程内存中对应的地址上。值得一提的是SPEC中说在program header中的多个PT_LOAD地址是按照虚拟地址递增排序的。
  • PT_DYNAMIC: 动态链接中用到的段，通常是RW映射，因为需要由interpreter(ld.so)修复对应的的入口
  • PT_INTERP: 包含interpreter的路径，见下文
  • PT_HDR: 表示program header table本身。如果有这个segment的话，必须要在所有可加载的segment之前，并且在文件中不能出现超过一次。
  • …

在不同的操作系统中还可能有一些拓展的类型，比如PT_GNU_STACK、PT_GNU_RELRO等，不一而足。

至此，ELF文件中相关的字段已经介绍完毕，主要组成也就是Section Header Table和Program Header Table两部分，整体框架相当简洁。而ELF中体现拓展性的地方则是在Section和Segment的类型上(s_type和p_type)，这两个字段的类型都是ElfN_Word，在32位系统下大小为4字节，也就是说最多可以支持高达2^32 - 1种不同的类型！除了上面介绍的常见类型，不同操作系统或者厂商还能定义自己的类型去实现更多复杂的功能。

程序加载

在新版的ELF标准文档中，将ELF的介绍分成了三部分，第一部分介绍ELF文件本身的结构，第二部分是处理器相关的内容，第三部分是操作系统相关的内容。ELF的加载实际上是与操作系统相关的，不过大部分情况下我们都是在GNU/Linux环境中运行，因此就以此为例介绍程序的加载流程。

Linux中分为用户态和内核态，执行ELF文件在用户态的表现就是执行execve系统调用，随后陷入内核进行处理。

内核空间对execve的处理其实可以单独用一篇文章去介绍，其中涉及到进程的创建、文件资源的处理以及进程权限的设置等等。我们这里主要关注其中ELF处理相关的部分即可，实际上内核可以识别多种类型的可执行文件，ELF的处理代码主要在fs/binfmt_elf.c中的load_elf_binary函数中。

对于ELF而言，Linux内核所关心的只有Program Header部分，甚至大部分情况下只关心三种类型的Header，即PT_LOAD、PT_INTERP和PT_GNU_STACK。以3.18内核为例，load_elf_binary主要有下面操作:

  1. 对ELF文件做一些基本检查，保证e_phentsize = sizeof(struct elf_phdr)并且e_phnum的个数在一定范围内；
  2. 循环查看每一项program header，如果有PT_INTERP则使用open_exec加载进来，并替换原程序的bprm->buf;
  3. 根据PT_GNU_STACK段中的flag设置栈是否可执行；
  4. 使用flush_old_exec来更新当前可执行文件的所有引用；
  5. 使用setup_new_exec设置新的可执行文件在内核中的状态；
  6. setup_arg_pages在栈上设置程序调用参数的内存页；
  7. 循环每一项PT_LOAD类型的段，elf_map映射到对应内存页中，初始化BSS；
  8. 如果存在interpreter，将入口(elf_entry)设置为interpreter的函数入口，否则设置为原ELF的入口地址；
  9. install_exec_creds(bprm)设置进程权限等信息；
  10. create_elf_tables添加需要的信息到程序的栈中，比如ELF auxiliary vector；
  11. 设置current->mm对应的字段；

从内核的处理流程上来看，如果是静态链接的程序，实际上内核返回用户空间执行的就是该程序的入口地址代码；如果是动态链接的程序，内核返回用户空间执行的则是interpreter的代码，并由其加载实际的ELF程序去执行。

为什么要这么做呢？如果把动态链接相关的代码也放到内核中，就会导致内核执行功能过多，内核的理念一直是能不在内核中执行的就不在内核中处理，以避免出现问题时难以更新而且影响系统整体的稳定性。事实上内核中对ELF文件结构的支持是相当有限的，只能读取并理解部分的字段。

内核返回用户空间后，对于静态链接的程序是直接执行，没什么好说的。而对于动态链接的程序，实际是执行interpreter的代码。ELF的interpreter作为一个段，自然是编译链接的时候加进去的，因此和编译使用的工具链有关。对于Linux系统而言，使用的一般是GCC工具链，而interpreter的实现，代码就在glibc的elf/rtld.c中。

interpreter又称为dynamic linker，以glibc2.27为例，它的大致功能如下:

  • 将实际要执行的ELF程序中的内存段加载到当前进程空间中；
  • 将动态库的内存段加载到当前进程空间中；
  • 对ELF程序和动态库进行重定向操作(relocation)；
  • 调用动态库的初始化函数(如*.preinit_array, .init, .init_array*)；
  • 将控制流传递给目标ELF程序，让其看起来自己是直接启动的；

其中参与动态加载和重定向所需要的重要部分就是Program Header Table中PT_DYNAMIC类型的Segment。前面我们提到在Section Header中也有一部分参与动态链接的section，即.dynamic。我在自己解析动态链接文件的时候发现，实际上 .dynamic section中的数据，和PT_DYNAMIC中的数据指向的是文件中的同一个地方，即这两个entry的s_offset和p_offset是相同。每个元素的类型如下:

typedef struct
{
  Elf32_Sword	d_tag;			/* Dynamic entry type */
  union
    {
      Elf32_Word d_val;			/* Integer value */
      Elf32_Addr d_ptr;			/* Address value */
    } d_un;
} Elf32_Dyn;

d_tag表示实际类型，并且d_un和d_tag相关，可以说是很有拓展性了:) 同样的，标准中定义了几十个d_tag类型，比较常用的几个如下:

  • DT_NULL: 表示_DYNAMIC的结尾
  • DT_NEEDED: d_val保存了一个到字符串表头的偏移，指定的字符串表示该ELF所依赖的动态库名称
  • DT_STRTAB: d_ptr指定了地址保存了符号、动态库名称以及其他用到的字符串
  • DT_STRSZ: 字符串表的大小
  • DT_SYMTAB: 指定地址保存了符号表
  • DT_INIT/DT_FINI: 指定初始化函数和结束函数的地址
  • DT_RPATH: 指定动态库搜索目录
  • DT_SONAME: Shared Object Name，指定当前动态库的名字(logical name)
  • …

其中有部分的类型可以和Section中的SHT_xxx类型进行类比，完整的列表可以参考ELF标准中的Book III: Operating System Specific一节。

在interpreter根据DT_NEEDED加载完所有需要的动态库后，就实现了完整进程虚拟内存映像的布局。在寻找某个动态符号时，interpreter会使用广度优先的方式去进行搜索，即先在当前ELF符号表中找，然后再从当前ELF的DT_NEEDED动态库中找，再然后从动态库中的DT_NEEDED里查找。

因为动态库本身是位置无关的(PIE)，支持被加载到内存中的随机位置，因此为了程序中用到的符号可以被正确引用，需要对其进行重定向操作，指向对应符号的真实地址。这部分我在之前写的关于GOT,PLT和动态链接的文章中已经详细介绍过了，因此不再赘述，感兴趣的朋友可以参考该文章。

实际案例

有人也许会问，我看你bibi了这么多，有什么实际意义吗？呵呵，本节就来分享几个我认为比较有用的应用场景。

在渗透测试中，红队小伙伴们经常能拿到目标的后台shell权限，但是遇到一些部署了HIDS的大企业，很可能在执行恶意程序的时候被拦截，或者甚至触发监测异常直接被蓝队拔网线。这里不考虑具体的HIDS产品，假设现在面对两种场景:

  1. 目标环境的可写磁盘直接mount为noexec，无法执行代码
  2. 目标环境内核监控任何非系统路径的程序的执行都会直接告警

不管什么样的环境，我相信老红队都有办法去绕过，这里我们运用上面学到的ELF知识，其实有一种更为简单的解法，即利用interpreter。示例如下:

$ cat hello.c
#include <stdio.h>
int main() {
	return puts("hello!");
}
$ gcc hello.c -o hello
$ ./hello
hello!

$ chmod -x hello
$ ./hello
bash: ./hello: Permission denied
$ /lib64/ld-linux-x86-64.so.2 ./hello
hello!
$ strace /lib64/ld-linux-x86-64.so.2 ./hello 2>&1 | grep exec
execve("/lib64/ld-linux-x86-64.so.2", ["/lib64/ld-linux-x86-64.so.2", "./hello"], 0x7fff1206f208 /* 9 vars */) = 0

/lib64/ld-linux-x86-64.so.2本身应该是内核调用执行的，但我们这里可以直接进行调用。这样一方面可以在没有执行权限的情况下执行任意代码，另一方面也可以在一定程度上避免内核对execve的异常监控。

利用(滥用)interpreter我们还可以做其他有趣的事情，比如通过修改指定ELF文件的interpreter为我们自己的可执行文件，可让内核在处理目标ELF时将控制器交给我们的interpreter，这可以通过直接修改字符串表或者使用一些工具如patchelf来轻松实现。

对于恶意软件分析的场景，很多安全研究人员看到ELF就喜欢用ldd去看看有什么依赖库，一般ldd脚本实际上是调用系统默认的ld.so并通过环境变量来打印信息，不过对于某些glibc实现(如glibc2.27之前的ld.so)，会调用ELF指定的interpreter运行，从而存在非预期命令执行的风险。

当然还有更多其他的思路可以进行拓展，这就需要大家发挥脑洞了。

与逆向分析比较相关的就是符号表，一个有符号的程序在逆向时基本上和读源码差不多。因此对于想保护应用程序的开发者而言，最简单的防护方法就是去除符号表，一个简单的strip命令就可实现。strip删除的主要是Section中的信息，因为这不影响程序的执行。去除前后进行diff对比可看到删除的section主要有下面这些:

$ diff 0 1
1c1
< There are 35 section headers, starting at offset 0x1fdc:
---
> There are 28 section headers, starting at offset 0x1144:
32,39c32
<   [27] .debug_aranges    PROGBITS        00000000 00104d 000020 00      0   0  1
<   [28] .debug_info       PROGBITS        00000000 00106d 000350 00      0   0  1
<   [29] .debug_abbrev     PROGBITS        00000000 0013bd 000100 00      0   0  1
<   [30] .debug_line       PROGBITS        00000000 0014bd 0000cd 00      0   0  1
<   [31] .debug_str        PROGBITS        00000000 00158a 000293 01  MS  0   0  1
<   [32] .symtab           SYMTAB          00000000 001820 000480 10     33  49  4
<   [33] .strtab           STRTAB          00000000 001ca0 0001f4 00      0   0  1
<   [34] .shstrtab         STRTAB          00000000 001e94 000145 00      0   0  1
---
>   [27] .shstrtab         STRTAB          00000000 00104d 0000f5 00      0   0  1

其中**.symtab是符号表，.strtab**是符号表中用到的字符串。

仅仅去掉符号感觉还不够，熟悉汇编的人放到反编译工具中还是可以慢慢还原程序逻辑。通过前面的分析我们知道，ELF执行需要的只是Program Header中的几个段，Section Header实际上是不需要的，只不过在运行时动态链接过程会引用到部分关联的区域。大部分反编译工具，如IDA、Ghidra等，处理ELF是需要某些section信息来构建程序视图的，所以我们可以通过构造一个损坏Section Table或者ELF Header令这些反编译工具出错，从而干扰逆向人员。

当然，这个方法并不总是奏效，逆向人员可以通过动态调试把程序dump出来并对运行视图进行还原。一个典型的例子是Android中的JNI动态库，有的安全人员对这些so文件进行了加密处理，并且在.init/.initarray这些动态库初始化函数中进行动态解密。破解这种加固方法的策略就是将其从内存中复制出来并进行重建，重建的过程可根据segment对section进行还原，因为segment和section之间共享了许多内存空间，例如:

$ readelf -l main1
...
 Section to Segment mapping:
  Segment Sections...
   00
   01     .interp
   02     .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rel.dyn .rel.plt .init .plt .plt.got .text .fini .rodata .eh_frame_hdr .eh_frame
   03     .init_array .fini_array .dynamic .got .got.plt .data .bss
   04     .dynamic
   05     .note.ABI-tag .note.gnu.build-id
   06     .eh_frame_hdr
   07
   08     .init_array .fini_array .dynamic .got

在Section to Segment mapping中可以看到这些段的内容是跟对应section的内容重叠的，一个segment可以包含多个section，但是依然可以根据内存的读写属性、内存特征以及对应段的一般顺序进行区分。

如果程序中有比较详细的日志函数，我们还可以通过反编译工具的脚本拓展去修改.symtab/.strtab段来批量还原ELF文件的符号，从而高效地辅助动态调试。

考虑这么一种场景，我们在分析某个IoT设备时发现了一个定制的ELF网络程序，类似于httpd，其中有个静态函数负责处理输入数据。现在想要单独对这个函数进行fuzz应该怎么做？直接从网络请求中进行变异是一种方法，但是网络请求的效率太低，而且触达该函数的程序逻辑也可能太长。

既然我们已经了解了ELF，那就可以有更好的办法将该函数抽取出来进行独立调用。在介绍ELF类型的时候其实有提到，可执行文件可以有两种类型，即可执行类型(ET_EXEC)和共享对象(ET_DYN)，一个动态链接的可执行程序默认是共享对象类型的:

$ gcc hello.c -o hello
$ readelf -h hello | grep Type
  Type:  DYN (Shared object file)

而动态库(.so)本身也是共享对象类型，他们之间的本质区别在于前者链接了libc并且定义了main函数。对于动态库，我们可以通过dlopen/dlsym获取对应的符号进行调用，因此对于上面的场景，一个解决方式就是修改目标ELF文件，并且将对应的静态函数导出添加到dynamic section中，并修复对应的ELF头。

这个思想其实很早就已经有人实现了，比如lief的bin2lib。通过该方法，我们就能将目标程序任意的函数抽取出来执行，比如hugsy就用这个方式复现了Exim中的溢出漏洞(CVE-2018-6789)，详见Fuzzing arbitrary functions in ELF binaries(中文翻译)。

总结

本文主要介绍了32位环境下ELF文件的格式和布局，然后从内核空间和用户空间两个方向分析了ELF程序的加载过程，最后列举了几个依赖于ELF文件特性的案例进行具体分析，包括dynamic linker的滥用、程序加固和反加固以及在二进制fuzzing中的应用。

ELF文件本身并不复杂，只有三个关键部分，只不过在section和segment的类型上保留了极大的拓展性。操作系统可以根据自己的需求在不同字段上实现和拓展自己的功能，比如Linux中通过dymamic类型实现动态加载。但这不是必须的，例如在Android中就通过ELF格式封装了特有的.odex 、 .oat文件来保存优化后的dex。另外对于64位环境，大部分字段含义都是类似的，只是字段大小稍有变化(Elf32->Elf64)，并不影响文中的结论。

参考链接

]]> Android进程间通信与逆向分析 https://evilpan.com/2020/07/11/android-ipc-tips/ Sat, 11 Jul 2020 22:40:00 +0800 evilpan https://evilpan.com/2020/07/11/android-ipc-tips/ 最近在分析一个运行Android系统的IoT平台，其中包含设备管控和日志服务(Agent)、升级服务(FOTA)、自定义桌面(Launcher)、端上IDS以及前台的图形界面应用等多个前后台进程。在对其中某个功能进行逆向时发现调用链路跨越了多个应用，因此本文就做个简单记录。

前言

熟悉安卓开发的同学应该都知道构建IPC的流程，但从逆向工程的角度分析的却比较少见。 说到安卓跨进程通信/调用，就不得不提到AIDL和Binder，在逆向一个东西之前，首先需要了解它，因此本文也会先对其工作流程和工作原理进行介绍。

AIDL 101

AIDL是Google定义的一个接口定义语言，即Android Interface Definition Language。两个进程(称为客户端和服务端)共享同一份AIDL文件，并在其基础上实现透明的远程调用。

从开发者的角度如何使用AIDL呢？下面参考Android的官方文档以一个实例进行说明。我们的目标是构建一个远程服务FooService，并且提供几个简单的远程调用，首先创建AIDL文件IFooService.aidl：

package com.evilpan;

interface IFooService {
    void sayHi();
    int add(int lhs, int rhs);
}

AIDL作为一种接口语言，其主要目的一方面是简化创建IPC所需要的IPC代码处理，另一方面也是为了在多语言下进行兼容和适配。使用Android内置的SDK开发工具可将其转换为目标语言，本文以Java为例，命令如下：

aidl --lang=java com/evilpan/IFooService.aidl -o .

生成的文件为IFooService.java，文件的内容后面再介绍，其大致结构如下：

public interface IFooService extends android.os.IInterface {
    /** Default implementation for IFooService. */
	public static class Default implements com.evilpan.IFooService
  {
  	// ...
  }
	/** Local-side IPC implementation stub class. */
  public static abstract class Stub extends android.os.Binder implements com.evilpan.IFooService
  {
    // ...
  }

  public void sayHi() throws android.os.RemoteException;
  public int add(int lhs, int rhs) throws android.os.RemoteException;
}

在这个文件的基础上，服务端和客户端分别构造远程通信的代码。

服务端要做两件事：

  1. 实现AIDL生成的的接口
  2. 创建对应的Service并暴露给调用者

实现接口主要是实现AIDL中的Stub类，如下：

package com.evilpan.server;

import android.os.RemoteException;
import android.util.Log;
import com.evilpan.IFooService;

public class IFooServiceImpl extends IFooService.Stub {
    public static String TAG = "pan_IFooServiceImpl";

    @Override
    public void sayHi() throws RemoteException {
        Log.i(TAG, "Hi from server");
    }

    @Override
    public int add(int lhs, int rhs) throws RemoteException {
        Log.i(TAG, "add from server");
        return lhs + rhs;
    }
}

客户端调用接口需要经过Service，因此我们还要创建对应的服务：

package com.evilpan.server;

import android.app.Service;
import android.content.Intent;
import android.os.IBinder;
import android.util.Log;

public class FooService extends Service {
    public static String TAG = "pan_FooService";
    private IBinder mBinder;

    public FooService() {
        Log.i(TAG, "Service init");
        mBinder = new IFooServiceImpl();
    }

    @Override
    public IBinder onBind(Intent intent) {
        Log.i(TAG, "return IBinder Object");
        return mBinder;
    }
}

注意这个服务需要在AndroidManifest.xml中导出：

<service android:name=".FooService"
         android:enabled="true"
         android:exported="true"/>

这里的服务与常规服务不同，不需要通过startService之类的操作去进行启动，而是让客户端去绑定并启动，因此也称为Bound Service。客户端绑定成功后拿到的IBinder对象(远程对象)就相当于上面onBind中返回的对象，客户端中操作本地对象可以实现远程调用的效果。

客户端在正常调用远程方法之前也需要做两件事：

  1. 实现ServiceConnection接口
  2. bindService

ServiceConnection接口主要是连接远程服务成功的异步回调，示例如下：

    private ServiceConnection mConnection = new ServiceConnection() {
        @Override
        public void onServiceConnected(ComponentName name, IBinder service) {
            Log.i(TAG, "onServiceConnected");
            mService = IFooService.Stub.asInterface(service);

            Log.i(TAG, "sayHi");
            try {
                mService.sayHi();
                Log.i(TAG, "add");
                mService.add(3 , 4);
            } catch (RemoteException e) {
                e.printStackTrace();
            }
        }

        @Override
        public void onServiceDisconnected(ComponentName name) {
            Log.i(TAG, "onServiceDisconnected");
        }

连接成功时会获得一个IBinder对象，就是前面说的IFooService.Stub实现。我们可以直接通过asInterface将其转换为IFooService对象。

bindService方法用来将Activity绑定到目标Service上，第一个参数为目标Service的Intent，第二个参数为上面的ServiceConnection实例。

    @Override
    protected void onStart() {
        super.onStart();
        Log.i(TAG, "onStart");

        Intent intent = new Intent();
        String pName = "com.evilpan.server";
        intent.setClassName(pName, pName + ".FooService");
        boolean ret = bindService(intent, mConnection, Context.BIND_AUTO_CREATE);
        Log.i(TAG, "bindService: " + ret);
    }

注意这里的包名指定的是服务端的包名，并且类名是服务类而不是AIDL中的接口类。绑定成功后启动客户端进程，可看到ADB日志如下所示：

07-11 06:01:25.767  8492  8492 I pan_Client: onCreate
07-11 06:01:25.768  8492  8492 I pan_Client: onStart
07-11 06:01:25.769  8492  8492 I pan_Client: bindService: true
07-11 06:01:25.770  8451  8451 I pan_FooService: Service init
07-11 06:01:25.770  8451  8451 I pan_FooService: return IBinder Object
07-11 06:01:25.785  8492  8492 I pan_Client: onServiceConnected
07-11 06:01:25.785  8492  8492 I pan_Client: sayHi
07-11 06:01:25.785  8451  8463 I pan_IFooServiceImpl: Hi from server
07-11 06:01:25.786  8492  8492 I pan_Client: add
07-11 06:01:25.786  8451  8508 I pan_IFooServiceImpl: add from server

Server和Client示例文件可见附件。

前面我们简单介绍了AIDL的使用，实际上AIDL支持丰富的数据类型，除了int、long、float、String这些常见类型外，还支持在进程间传递对象(Parcelable)，以及传递函数。在AIDL中定义对象如下：

package com.evilpan;
parcelable Person {
	int age;
	String name;
}

也可以在AIDL中只声明parcelable对象，并在Java文件中自己定义。

而函数也可以看做是一个类型进行传递，例如：

package com.evilpan;
oneway interface IRemoteServiceCallback {
	void onAsyncResult(String result);
}

可以把IRemoteServiceCallback当做一个类型，在其他的AIDL中使用：

package com.evilpan;

import com.evilpan.IRemoteServiceCallback;

interface IRemoteService {
	void registerCallback(IRemoteServiceCallback cb);
}

这种模式可以让服务端去调用客户端实现的函数，通常用来返回一些异步的事件或者响应。

Binder

通过上面的介绍我们知道AIDL实际上只是对boundService接口的一个抽象，而boundService的核心是有一个跨进程的IBinder接口(即上面onBind返回的对象)。实现这个接口有三种方式：

  1. 拓展Binder类来实现接口
  2. 使用Messenger来创建服务的接口，实际上底层也是基于AIDL实现的
  3. 直接使用AIDL

通常实现IPC用得更多的是Messenger，因为其接受的信息是在同一个线程中处理的；直接使用AIDL可能需要多线程的能力从而导致复杂性增加，因此不适合大部分应用。

但不管是AIDL还是Messenger，其本质都是使用了Binder。那么什么是Binder？简单来说Binder是Android系统中的进程间通信(IPC)框架。我们都知道Android是基于Linux内核构建的，而Linux中已经有了许多进程间通信的方法，如：

  • 管道（半双工/全双工）
  • 消息队列
  • 信号量
  • 共享存储
  • socket
  • …

理论上Binder可以基于上面的这些机制实现一套IPC的功能，但实际上Binder自己构建了新的进程间通信方法，这意味着其功能必须要侵入到Linux内核中。为满足商业公司需求而提交patch到Linux upstream，所受到的阻力可想而知，为什么Google仍然坚持呢？Brian Swetland在Linux邮件组中指出，现有的Linux IPC机制无法满足以下两个需求：

  1. 通过内核将数据直接到目标地址空间的环形缓冲区，从而减少拷贝开销。
  2. 对可在进程间共享和传递的远程代理对象的生命周期管理。

因此目前Binder在内核中实现为独立的驱动，即/dev/binder(后续还进行了细分，如hwbinder、vndbinder)。

除了Binder之外，Android还在Linux的基础上增加了一些其他驱动，比如Ashmem、Low Memory Killer等，在内核的drivers/[staging]/android目录中。

从驱动的层面看，Binder的使用也很简单：使用open(2)系统调用打开/dev/binder，然后使用ioctl(2)系统调用进行数据传输。以前面的AIDL IPC为例，其底层的实现如下图所示：

img-binder

图：http://newandroidbook.com/files/Andevcon-Binder.pdf

逆向分析

上面介绍了那么多，但本文不是Binder Internal的文章，不要忘记了我们的目的是逆向。从上面Binder IPC的流程中可以看到一个很重要的特点，即Binder使用transact发送数据，并且在(另一个进程的)onTransact回调中接收数据。

大部分逆向工程的工作都是类似的，寻找一种经过编译器处理特定文件后的的模式，并在此基础上构建还原出原始的操作。比如，对于C语言的逆向是通过调用约定以及函数入口/出口对栈的分配/释放来判断函数的调用，对于C++则是通过对vtable的查找/偏移来判断虚函数的调用。

对于我们一开始的目标而言，就是需要分析出系统中存在的进程间调用，更准确地说是需要确定某个进程中函数的交叉引用(xref)。以AIDL为例，.aidl文件是不包含在release后的apk文件中的，不过我们还是可以通过生成文件的特征判断这是一个AIDL服务。从生成的代码上来看，主要有这些特点：

  1. 服务端和客户端生成的接口文件是相同的
  2. 生成的主类拓展android.os.IInterface，包含AIDL中所定义的函数声明
  3. 主类中包含了自身的3个实现，分别是默认实现Default、本地实现Stub以及远程代理实现Proxy

一般而言，本地的实现(Stub)需要服务端继承并实现对应方法，Stub同时也拓展Binder类，并在onTransact方法中根据code来选择不同的函数进行处理。比如对于前面的例子，有：

public static abstract class Stub extends android.os.Binder implements com.evilpan.IFooService {
  public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags) {
    // ...
    switch (code) {
        //...
      case TRANSACTION_sayHi:
        this.sayHi();
	    reply.writeNoException();
       	return true;
      case TRANSACTION_add:
        int _arg0 = data.readInt();
        int _arg1 = data.readInt();
        int _result = this.add(_arg0, _arg1);
	    reply.writeNoException();
        reply.writeInt(_result);
        return true;
      // ...
    }
  }
}

Proxy即Client端的实现则通过指定transact的code来调用对应远程代码，如下：

private static class Proxy implements com.evilpan.IFooService {
  private android.os.IBinder mRemote;
	// ...
	public void sayHi() throws android.os.RemoteException {
    //...
  	boolean _status = mRemote.transact(Stub.TRANSACTION_sayHi, _data, _reply, 0);
    //...
	}
}

除了生成代码的特征，通常远程调用都会用到 Bound Service，因此在服务端的AndroidManifest.xml文件中必然会有导出的服务声明，这也可以作为分析的一个辅助验证。

示例

假设我们正在逆向分析上面编译好的APK，在找到某个关键函数(比如add)后Find Usage发现没有任何交叉引用，但实际上这个函数是被调用了的。那么这就有几种可能，比如这个函数是通过反射调用的，或者这个函数是在native代码中调用的。……当然这里实际上是父类中进行多态调用的，本质是Binder唤起的远程调用。

img-re

跨进程交叉引用的一个前提是需要知道是在哪个进程调用的。如果有权限在Server中进行调试或者代码注入，我们就可以在触发调用或者绑定时使用Binder.getCallingUid()函数获取调用者的UID，从而获取Client的包名。

单纯静态分析的话可以把系统中所有相关的进程pull下来，分别反编译后使用grep进行搜索。因为远程调用的接口是共享的，所以即便使用了proguard等混淆也不会影响到接口函数。

小结

本文主要是记录下最近遇到的一个Android智能设备的逆向，与以往单个APK不同，这类智能设备中通常以系统为整体，其中包含了多个业务部门内置或者安装的应用，在分析时发现许多应用间跳转和通信的场景。由于NDA的原因没有详细介绍，因此使用了我自己创建的Client/Server作为示例进行说明，但其中的方法都是类似的，即先从正向了解IPC的运行方式，然后通过代码特征去鉴别不同应用间的跳转。对于复杂的系统而言，先理清思路比头铁逆向也更为重要。

参考资料

]]> 从STM32L4看ARM裸板的启动过程 https://evilpan.com/2020/04/11/stm32-bare-metal/ Sat, 11 Apr 2020 22:40:00 +0800 evilpan https://evilpan.com/2020/04/11/stm32-bare-metal/ Fundamental, fundamental, fundamental, …without the fundamental, all those fancy magics won’t work.

有经验的程序员都知道源码需要进行编译、链接、封装，然后才能执行。那你知道如何为一块CPU编写并编译程序吗？知道编译后的程序如何写入MCU、并让CPU加载运行的吗？

前言

早先收到阿里云提供的Developer kit开发板，对他们的RTOS进行体验，就是下面这款：

devkit.png

不得不说，使用aos全家桶运行、烧写和调试代码都非常方便；而且最近看发现还支持最小化定制裁剪，根据自己的需求下载对应的代码，算是咱256G小硬盘的福音了：）

不过今天不是分析阿里的RTOS(AliOS Things)，也不是把玩这块开发板，而是借助其中的MCU来探索下裸板的开发和运行之路。

芯片分析

在开始为一块MCU编程之前，我们要做的第一件事就是先查看这个MCU的文档。例如，如果我们想写一个helloworld程序，那么就至少需要知道：

  1. MCU复位之后从哪启动，这决定了我们的main程序位置。
  2. MCU内存映射，这是为了查看串口的地址空间。

对于我们而言，手上的MCU型号是STM32L496VGTx，因此这些大部分都能在stm32l496ae datasheet中查看到。首先，在datasheet中我们知道STM32L496VGTx中的CPU是ARM Cortex-M4，内存SRAM为320KB，内部含有1MB的Flash。

根据ARM的文档中关于Cortex-m4 中断向量表的介绍，我们可以看到保存第一条指令地址的地址为0x0004：

vec.png

其中0x0000保存的是栈的地址。也就是说，CPU复位之后，会首先将0x0000地址的内容加载到栈寄存器sp中，然后将0x0004地址的内容加载并保存到指令寄存器pc中，然后才开始执行第一条指令。

CPU执行每条指令，本质上包含5步：取指、译码、执行、访存、写回。如果不影响状态，多条指令的5步可以交错，这就称为CPU的流水线，现代CPU都包含多级流水线的设计和其他的优化来提升执行速度。……扯远了，说这个主要是强调一点：CPU实际运行的第一条指令的地址为*(addr *)0x0004。而前面两条"指令"，即加载sp和加载pc，实际上是通过CPU硬件的有限状态机实现的。

还是在ARM的文档Memory-Model中，可以看到我们的芯片内存映射的结构大致如下：

mm.png

在32位的寄存器下，有大约4GB的寻址空间。其中ARM只定义了一个大概的范围，地址空间的实际映射其实和厂商的设计有比较大的关系。比如在我们的STM32L4 MCU中，实际的映射如下：

mm1.png

需要注意的是flash地址空间，为0x08000000 ~ 0x08100000，大小为0x10000正好是datasheet中所说的1MB。还有就是APB的地址空间，因为APB总线通常是用来控制外设的，比如我们下面会用到的串口(UART)。

The Code

Talk is cheap，接下来就是实际的编码，我们的目标是在CPU上电启动后马上打印“HelloWorld”，没有其他多余的操作。

在打印HelloWorld之前，我们先确保MCU能够正常启动并运行我们的代码。为此，需要正确编译和链接我们的程序。根据上面ARM初始化向量表的定义，我们先写个汇编文件startup_m4.s：

.syntax unified
.cpu cortex-m4
.fpu softvfp
.thumb

.global g_pfnVectors
.global Default_Handler
.global Reset_Handler

.section .text
Default_Handler:
Infinite_Loop:
    b   Infinite_Loop

Reset_Handler:
    ldr sp, =stack_top
    mov r0, #0
    mov r1, #1
    mov r2, #2
    ror r3, r0, #2
_loop:
    add r3, #1
    B _loop

// ISR vecotor data
.section .isr_vector, "a"
g_pfnVectors:
    .word stack_top
    .word Reset_Handler
    .word Default_Handler // NMI
    .word Default_Handler // HardFault
    .word Default_Handler // MemManage
    .word Default_Handler // BusFault
    .word Default_Handler // UsageFault
    .word 0
    .word 0
    .word 0
    .word 0
	.word Default_Handler // SVC
    // and a lot more ...

Reset_Handler是我们实际运行的第一条指令地址，其地址写在中断向量表的0x04偏移处。对于其他的中断处理程序，我们先简单放一部分到Default_Handler中。

有了代码，还需要链接到对应的地址中，执行这项任务的就是linker脚本。通常我们使用ld时也会调用默认的linker脚本，可以通过ld --verbose命令查看，不过默认的链接脚本无法满足我们的需求，所以根据上面的文档，我们写一个简单的链接脚本m4.ld如下：

ENTRY(Reset_Handler)

MEMORY {
    FLASH (RX) : ORIGIN = 0x08000000, LENGTH = 1024K
    SRAM (RWX) : ORIGIN = 0x20000000, LENGTH = 320K
}

stack_top = 0x20050000;

SECTIONS {
    .isr_vector : {
        . = ALIGN(8);
        KEEP(*(.isr_vector))
        . = ALIGN(8);
    } > FLASH

    .text : {
        . = ALIGN(8);
        *(.text)
        . = ALIGN(8);
        text_end = .;
    } > FLASH

    .data : { *(.data) } >SRAM AT>FLASH
    .bss : { *(.bss COMMON) } > SRAM
    . = ALIGN(8);
}

编译并链接我们的程序：

arm-none-eabi-as startup_m4.s -g -o startup_m4.o
arm-none-eabi-ld -T m4.ld startup_m4.o -o startup.elf

最后生成的是ELF程序，为了在裸板上运行，需要将无用的信息去掉，只保留纯粹的代码和数据：

arm-none-eabi-objcopy -O binary startup.elf startup.bin

如果想要了解更多链接脚本的语法和含义，可以参考官方的文档——Linker Scripts。

有了starup.bin之后，就可以使用对应的接口写入Flash，对于我们这块开发板引出的接口是ST-LINK，所以可以直接使用stlink程序来写，前面说了Flash地址为0x08000000：

st-flash --reset write startup.bin 0x08000000

当然，你也可以使用其他工具，比如我最喜欢的OpenOCD。使用openocd需要自己对接口进行适配，其中包含了很多预置的配置，例如对于我们手上的开发板，可以使用以下配置：

source [find interface/stlink.cfg]

transport select hla_swd

source [find target/stm32l4x.cfg]

reset_config srst_only

值得一提的是，openocd的配置使用的是裁剪过的TCL语言，使用前可以花一两个小时先了解下。

OpenOCD中内置了gdbserver，不过如果你用openOCD+gef进行调试的话，很可能会遇到错误。经过查看代码和相关的资料，我发现openocd的gdbserver会将程序状态字寄存器命名为xPSR而不是传统的cpsr，所以我写了个gdb脚本解决这个问题：

set remote hardware-breakpoint-limit 6
set remote hardware-watchpoint-limit 4

# openOCD-gdbserver name $cpsr as $xPSR, make gef known about it
pi current_arch.all_registers = ['$r0', '$r1', '$r2', '$r3', '$r4', '$r5', '$r6', '$r7', '$r8', '$r9', '$r10', '$r11', '$r12', '$sp', '$lr', '$pc', '$xPSR']
pi current_arch.flag_register = '$xPSR'
reset-cache

# ignore stack
gef config context.layout "legend regs code args source memory threads trace extra"

target extend :3333

烧写成功后复位使用JTAG接口进行调试，可以看到进入了我们的程序中：

jtag.png

PS：由于我们的大部分中断都没有处理，所以单步调试触发中断后程序很可能跑飞：）

说句题外话，生成的starup.bin就是我们常说的固件，实际上在逆向分析时从flash读出来的数据也就是这个格式，从0x00地址开始。比如，分析这个固件的时候通常使用的方法是：

r2 -n -a arm -b 16 -m 0x08000000 startup.bin

其他工具也可以用类似的方法将首地址rebase进行分析，但关键是要知道对应芯片的中断向量表定义，这样才能找到真正的入口函数。

现在有了骨架，可以实现真正的功能了。在操作系统中，我们printf("hello world")本质上是经过系统调用让内核把数据写到标准输出，但是在裸板上可没那么方便，一切都要自己操作。

打印数据到串口的功能通过UART实现，而UART是连接在CPU的APB总线上的。在软件上向UART发送数据实际上是通过向APB总线发送数据到UART硬件对应的接口，发送数据的操作通过将APB总线的读写映射为MMIO实现，简单来说就是通过CPU向内存读写数据实现总线上的读写操作。

在前面的图片中我们能看到APB总线的MMIO映射地址为0x40000000，那么UART在哪个地址呢？可以通过STM32的应用文档中查看；或者更简单地，直接查看STM32的驱动文件stm32l496xx.h：

#define PERIPH_BASE           (0x40000000UL) /*!< Peripheral base address */
...
/*!< Peripheral memory map */
#define APB1PERIPH_BASE        PERIPH_BASE
#define APB2PERIPH_BASE       (PERIPH_BASE + 0x00010000UL)
...
/*!< APB1 peripherals */
#define USART2_BASE           (APB1PERIPH_BASE + 0x4400UL)
#define USART3_BASE           (APB1PERIPH_BASE + 0x4800UL)
#define LPUART1_BASE          (APB1PERIPH_BASE + 0x8000U)
..
/*!< APB2 peripherals */
#define USART1_BASE           (APB2PERIPH_BASE + 0x3800UL)
  
#define USART2              ((USART_TypeDef *) USART2_BASE)
#define USART3              ((USART_TypeDef *) USART3_BASE)
#define UART4               ((USART_TypeDef *) UART4_BASE)
#define UART5               ((USART_TypeDef *) UART5_BASE)
#define LPUART1             ((USART_TypeDef *) LPUART1_BASE)
#define USART1              ((USART_TypeDef *) USART1_BASE)

在stm32l496xx中，APB总线连接了6个串口，起始地址分别是：

  • USART1, 0x40013800
  • USART2, 0x40004400
  • USART3, 0x40004800
  • ….

UART地址空间的定义是：

/**
  * @brief Universal Synchronous Asynchronous Receiver Transmitter
  */

typedef struct
{
  __IO uint32_t CR1;         /*!< USART Control register 1,                 Address offset: 0x00 */
  __IO uint32_t CR2;         /*!< USART Control register 2,                 Address offset: 0x04 */
  __IO uint32_t CR3;         /*!< USART Control register 3,                 Address offset: 0x08 */
  __IO uint32_t BRR;         /*!< USART Baud rate register,                 Address offset: 0x0C */
  __IO uint16_t GTPR;        /*!< USART Guard time and prescaler register,  Address offset: 0x10 */
  uint16_t  RESERVED2;       /*!< Reserved, 0x12                                                 */
  __IO uint32_t RTOR;        /*!< USART Receiver Time Out register,         Address offset: 0x14 */
  __IO uint16_t RQR;         /*!< USART Request register,                   Address offset: 0x18 */
  uint16_t  RESERVED3;       /*!< Reserved, 0x1A                                                 */
  __IO uint32_t ISR;         /*!< USART Interrupt and status register,      Address offset: 0x1C */
  __IO uint32_t ICR;         /*!< USART Interrupt flag Clear register,      Address offset: 0x20 */
  __IO uint16_t RDR;         /*!< USART Receive Data register,              Address offset: 0x24 */
  uint16_t  RESERVED4;       /*!< Reserved, 0x26                                                 */
  __IO uint16_t TDR;         /*!< USART Transmit Data register,             Address offset: 0x28 */
  uint16_t  RESERVED5;       /*!< Reserved, 0x2A                                                 */
} USART_TypeDef;

对应硬件接口：

usart.png

软件中对UART的读写主要通过对UART本身的寄存器操作实现，例如向串口写一个字节就是：USART->TDR = 0x41，具体的写入内容根据型号有所差异，在STM32F4XX的驱动中相关代码如下：

  /**
    * @brief  Transmits single data through the USARTx peripheral.
    * @param  USARTx: where x can be 1, 2, 3, 4, 5, 6, 7 or 8 to select the USART or
    *         UART peripheral.
    * @param  Data: the data to transmit.
    * @retval None
    */
  void USART_SendData(USART_TypeDef* USARTx, uint16_t Data)
  {
    /* Check the parameters */
    assert_param(IS_USART_ALL_PERIPH(USARTx));
    assert_param(IS_USART_DATA(Data));

    /* Transmit Data */
    USARTx->DR = (Data & (uint16_t)0x01FF);
  }

对于我们STM32L4XX的MCU，在官方的cube中代码实现为stm32l4xx_cube/Drivers/STM32L4xx_HAL_Driver/Src/stm32l4xx_hal_uart.c的HAL_UART_Transmit函数，虽然相对复杂，但本质上也大同小异。

实际上在MCU中printf和puts等函数的实现都是通过逐字节写入UART寄存器实现的。所以我们新建一个c文件并定义最简单的print函数如下：

// hello_m4.c
volatile unsigned int * const UART_TDR = (unsigned int *)0x40008028; // LPUART1->TDR
void my_print(const char *data) {
    while(*data != '\0') {
        *UART_TDR = (unsigned int)(*data);
        data++;
    }
}

void my_entry() {
    my_print("hello world!\n");
    for(;;);
}

然后在之前的Reset_Handler稍加修改，令其跳转到我们的主程序执行：

Reset_Handler:
    ldr sp, =stack_top
    bl my_entry

最后编译并重新链接：

arm-none-eabi-gcc -c -O0 -mcpu=cortex-m4 -g hello_m4.c -o hello_m4.o
arm-none-eabi-ld -T m4.ld hello_m4.o startup_m4.o -o hello_m4.elf

监听串口的数据并重新烧写，一个硬核的HelloWorld就完成了！

$ miniterm /dev/ttyACM0 115200
--- Miniterm on /dev/ttyACM0  115200,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
hello world!

如果串口是USART而不是UART，那么可能需要经过一些额外的配置，具体可以参考USART vs UART: Know the difference。

在实际工程中，真正进入用户程序之前需要初始化好各个硬件外设，配置好基本的中断处理程序。这部分代码一般是由MCU vendor提供的，作为Bootloader(Boot ROM)固化。当然我们这里是绕过MCU直接针对CPU编写程序，以展示软硬件之间的微妙联系。

后记

本文主要介绍了CPU上电从硬件到软件的启动过程，其中一个关键概念就是中断向量表，这是所有First Stage Bootloader都需要理解和实现的地方。此外还介绍了如何通过控制串口在裸机上实现了一简单的HelloWorld应用，这实际上是一个简化的外设驱动，即通过总线读写外设寄存器来封装外部硬件的调用，这部分代码在内核中也是相当常见的。

参考资料

]]>