來源 | 汽車ECU開發(fā)

特斯拉的Autopilot是馬斯克最引以為豪的系統(tǒng)之一，其可提供L2級(jí)別的自動(dòng)駕駛功能。Autopilot系統(tǒng)主要依賴于攝像頭、超聲波傳感器和雷達(dá)。此外，Autopilot在HW3.0之前的版本配備了來自 Nvidia 等制造商的計(jì)算硬件，允許車輛使用深度學(xué)習(xí)處理數(shù)據(jù)以實(shí)時(shí)對(duì)條件做出反應(yīng)。

APE，即“Autopilot ECU”，是特斯拉自動(dòng)駕駛技術(shù)的關(guān)鍵部件。雖然已經(jīng)有很多文章談?wù)撍挠布鉀Q方案，但關(guān)于它的軟件的討論卻少得多。眾所周知之前所有的 APE 2.0 和 2.5 板卡都是基于 Nvidia 的 PX2 AutoChauffeur（實(shí)際上是高度定制的）。下面討論主要集中在APE2.5。如下圖1所示，簡(jiǎn)單的展示了其內(nèi)部組件是如何連接的。

圖1 APE內(nèi)部模塊的連接

APE和APE-B都是Tegra芯片，和Nvidia的PX2一樣。LB是英飛凌Aurix芯片。此外，還有一個(gè)英偉達(dá)的GPU（GP106）連接到 APE。APE和APE-B上運(yùn)行的軟件鏡像基本相同，而LB有自己的固件。在 APE中，LB 是一個(gè)協(xié)處理器，支持監(jiān)控 CAN 總線上的消息，控制風(fēng)扇速度，確定是否應(yīng)該打開APE的部分功能等。在原始 PX2 板上，Aurix 芯片在串口上運(yùn)行一個(gè)控制臺(tái) 有幾個(gè)有用的功能。但是在APE 2.5上，這個(gè)芯片只提供很少的控制臺(tái)命令。

并非 APE 和 APE-B 都用于 Autopilot，特別是考慮到并非兩個(gè)芯片都連接到所有傳感器。來自雷達(dá)和其他傳感器的信息通過一些 CAN 總線（包括私有的）傳輸，并由 LB 轉(zhuǎn)發(fā)為 UDP 消息，UDP 消息可以被兩個(gè)處理器接收。

但是所有攝像頭，尤其是主攝像頭、窄攝像頭和魚眼攝像頭僅通過 CSI 接口連接到 APE。此外GPU 芯片僅連接到APE，沒有看到足夠的證據(jù)表明兩個(gè)Tegra 芯片（以及攝像頭）共享 GPU 芯片。因此我們認(rèn)為 APE-B 只是一個(gè)類似“存根功能”的東西，而 APE 是執(zhí)行實(shí)際工作的實(shí)際芯片。

后來對(duì)固件的調(diào)查表明，APE-B 有時(shí)可能會(huì)從用于啟動(dòng) APE 的同一鏡像啟動(dòng)。啟動(dòng)過程讓我們相信，只要 APE 和 APE-B 運(yùn)行相同的固件，我們就可以輕松實(shí)施我們的攻擊。APE 的固件是一個(gè) SquashFS 鏡像，沒有任何加密。該映像運(yùn)行高度定制的 Linux（如 CID 和 IC）。在固件中我們觀察到 APE 軟件的二進(jìn)制文件位于 /opt/autopilot 文件夾下。

智特斯拉的視覺系統(tǒng)

在本節(jié)中，我們將介紹Autopilot中視覺系統(tǒng)的實(shí)現(xiàn)細(xì)節(jié)。二元視覺是 Autopilot 的關(guān)鍵組件之一。Autopilot 使用它來處理從所有攝像頭收集的數(shù)據(jù)。我們對(duì)使用純計(jì)算機(jī)視覺解決方案的自動(dòng)雨刷和車道識(shí)別這兩個(gè)功能進(jìn)行了大量反向工作。這些函數(shù)的特殊過程可以概括為兩部分：它們共同的預(yù)處理，以及它們自己的神經(jīng)網(wǎng)絡(luò)計(jì)算和后處理。

預(yù)處理

我們認(rèn)為特斯拉使用的是12位HDR攝像頭，可能是RCCB。視覺神經(jīng)網(wǎng)絡(luò)模型并不是為了直接處理這些圖像而設(shè)計(jì)的。因此，程序需要先對(duì)圖像進(jìn)行預(yù)處理。

如前所述，不同的可執(zhí)行文件（或服務(wù)）之間的通信是通過共享內(nèi)存進(jìn)行的，包括從相機(jī)獲取的原始圖像。這些圖像是根據(jù)調(diào)度圖從某些文件句柄中獲取的。

圖2 緩沖區(qū)由select()模型管理

此外，視覺任務(wù)還會(huì)從 /dev/i2c 和其他共享內(nèi)存區(qū)域獲取一些控制消息。出于診斷和產(chǎn)品改進(jìn)的目的，圖像的副本也將保存到共享內(nèi)存中，以便快照任務(wù)可以獲取和發(fā)送它。快照任務(wù)在不同的任務(wù)中有大量的記錄點(diǎn)，這使得調(diào)試和功能開發(fā)工作更加高效。

從快照中收集的原始數(shù)據(jù)為 HDR、1280x960 和 16 位小端整數(shù)，色調(diào)映射圖像如下圖3所示。

圖3 來自相機(jī)的色調(diào)映射圖像

我們之前提到過函數(shù) tesla:TslaOctopusDetector::unit_process_per_camera，它將處理來自每個(gè)相機(jī)的每一幀，包括預(yù)處理過程。首先從圖像中刪除一些前綴和后綴行。根據(jù)安森美為AR0132AT（可能不是特斯拉的傳感器，但可能是類似型號(hào)）提供的數(shù)據(jù)手冊(cè)，這些線可能僅用于像素調(diào)整和診斷目的，因此我們假設(shè)自動(dòng)駕駛?cè)蝿?wù)沒有使用那些像素。

下一步是色調(diào)映射，調(diào)整相機(jī)HDR圖像的動(dòng)態(tài)范圍，使其適應(yīng)神經(jīng)網(wǎng)絡(luò)的輸入模型。在早期版本中，這個(gè)映像是通過tmp_cuda_exp_tonemapping處理的，現(xiàn)在重命名的函數(shù)是tesla::t_cuda_std_tmrc::compute，有很多改進(jìn)。

T_cuda_std_tmrc有幾個(gè)輸出，包括：

* linear_signal, 經(jīng)過HDR轉(zhuǎn)換和距離壓縮的原始圖像；

* detail_layer，邊界檢測(cè)的結(jié)果，可能會(huì)使用canny邊緣檢測(cè)器并進(jìn)行一些改進(jìn)；

* bilateral_output，可能是某些雙邊過濾器的結(jié)果；

此外，輸出還包含一些其他層，但由于它與我們的研究沒有太大關(guān)系，我們不在這里提及它們。

對(duì)不同相機(jī)的預(yù)處理可能不同。雖然目前我們只注意到代碼中的去馬賽克控制布爾值，但我們相信為不同的相機(jī)添加不同的預(yù)處理過濾器很容易。

預(yù)處理后的圖像輸出根據(jù)其類型和位置通過幾個(gè)不同的模塊進(jìn)行處理。目前，我們觀察到三種不同的類型，通過枚舉來表示所有攝像頭的為位置，如圖4所示。

圖4 通過枚舉來表示不同的攝像頭

圖5 從左到右分別為主攝像頭，長(zhǎng)焦，魚眼攝像頭

通常，這些處理過的圖像都會(huì)被寫入到它們對(duì)應(yīng)的神經(jīng)網(wǎng)絡(luò)的輸入緩沖區(qū)中。每個(gè)神經(jīng)網(wǎng)絡(luò)解析輸入圖像，并為 tesla::t_inference_engine<float>。各種后處理程序接收這些結(jié)果，并向控制器提供控制提示。這些后置處理器負(fù)責(zé)多項(xiàng)工作，包括識(shí)別汽車、物體和車道，繪制周圍環(huán)境的地圖，以及確定降雨量。令我們驚訝的是，這些工作大部分都是在一個(gè)感知神經(jīng)網(wǎng)絡(luò)內(nèi)完成的。

自動(dòng)駕駛?cè)蝿?wù)的復(fù)雜性需要為不同的相機(jī)分配不同的推理引擎，配置不同的檢測(cè)器，并填充幾種不同的配置。因此，Tesla 使用大類來管理這些功能。解析出每個(gè)成員并不是一件容易的事，尤其是對(duì)于一個(gè)被剝離的二進(jìn)制文件，填充了大類和 Boost 類型。

智遠(yuǎn)程轉(zhuǎn)向控制

在本節(jié)中，我們將介紹 APE 單元如何與 EPAS（電動(dòng)助力轉(zhuǎn)向）單元一起實(shí)現(xiàn)轉(zhuǎn)向系統(tǒng)控制。此外，由于我們已經(jīng)獲得了 APE 的 root 訪問權(quán)限，我們將演示如何遠(yuǎn)程影響 EPAS 單元以控制特斯拉汽車在不同駕駛模式下的轉(zhuǎn)向系統(tǒng)。

APE是特斯拉高級(jí)駕駛輔助系統(tǒng)的核心單元。它負(fù)責(zé)汽車在輔助駕駛和自動(dòng)泊車模式下的轉(zhuǎn)向系統(tǒng)控制和電子速度控制。據(jù)我們所知，這些先進(jìn)的輔助駕駛功能是基于高級(jí)視覺和汽車總線（以太網(wǎng)、CAN、LIN、FlexRay）系統(tǒng)。

CAN總線系統(tǒng)

圖6 APE的CAN總線系統(tǒng)

通過對(duì)APE中與CAN總線相關(guān)的一些服務(wù)(canrx、cantx等)進(jìn)行逆向工程，初步了解了APE CAN總線系統(tǒng)的網(wǎng)絡(luò)結(jié)構(gòu)。如圖6所示，APE集成了兩個(gè)CAN-Bus接口(CAN0和CAN1)，通過CAN1與雷達(dá)互連。為了冗余機(jī)制或其他安全考慮，CAN0和LB一起連接到私有CAN總線。

此外，由于域隔離，APE與LB單元共享一個(gè)邏輯CAN(稱為APE2LB_CAN)總線，用于與PT(動(dòng)力總成)和CH(底盤)CAN總線通信。

對(duì)于特斯拉汽車，轉(zhuǎn)向系統(tǒng)可由底盤 CAN 總線上的 EPAS 單元控制。雖然有了APE的系統(tǒng)的完全接入，但顯然我們需要打破APE的CAN總線系統(tǒng)的一些安全機(jī)制障礙，比如冗余CAN總線、CAN消息計(jì)數(shù)器和域隔離。

我們主要關(guān)注 cantx 服務(wù)，它接收來自視覺系統(tǒng)的中間信號(hào)，然后將信號(hào)轉(zhuǎn)換為車輛控制命令。這些命令將被封裝到特殊的 CAN 消息（APE2LB_CAN）中，并通過 LB 單元轉(zhuǎn)發(fā)到 PT/CH CAN 總線。

APE2LB_CAN

圖7 APE2LB_CAN的格式

APE2LB_CAN 是一種基于 UDP 協(xié)議的 CAN 報(bào)文。APE 中的 cantx 服務(wù)使用 APE2LB_CAN 與 LB 單元進(jìn)行通信。使用APE2LB_CAN，APE可以與LB構(gòu)建邏輯CAN總線。LB 更像是一個(gè)支持以太網(wǎng)和 CAN 協(xié)議的網(wǎng)關(guān)，它負(fù)責(zé)從 APE2LB_CAN 中提取 CAN ID 和原始 CAN 報(bào)文，然后將它們封裝成一個(gè)標(biāo)準(zhǔn)的 CAN 報(bào)文幀，最后將該幀傳送到不同 CAN 總線上的各個(gè) ECU（ Chassis, Body, Powertrain) 。

轉(zhuǎn)向控制消息

DasSteeringControlMessage (DSCM)是最關(guān)鍵的CAN信息之一，用于汽車在ACC (Adaptive Cruise control)和APC (Automatic Parking control)兩種模式下的轉(zhuǎn)向系統(tǒng)控制。

在cantx服務(wù)的DasSteeringControlMessageEmitter::populate_message()函數(shù)中，產(chǎn)生DSCM并封裝到APE2LB_CAN的raw_can_msg中，DSCM的目的地包括一些與轉(zhuǎn)向系統(tǒng)和汽車速度相關(guān)的ECU，如EPAS（Electric Power Assisted Steering） 和 EPB（電動(dòng)駐車制動(dòng)器）裝置。

圖8 DasSteeringControlMessage幀格式

圖8描述了DSCM的幀格式：

1、轉(zhuǎn)向角的值存儲(chǔ)在DSCM的前2個(gè)字節(jié)中；

2、第三個(gè)字節(jié)是 CAN 報(bào)文計(jì)數(shù)器和控制類型的組合。該字節(jié)的低 6 位是 CAN 報(bào)文計(jì)數(shù)器，一旦填充了一個(gè) CAN 報(bào)文，報(bào)文計(jì)數(shù)器應(yīng)增加 0x01。第三個(gè)字節(jié)的高2位表示CAN報(bào)文的控制類型。當(dāng)特斯拉汽車處于ACC或APC模式時(shí)，控制類型應(yīng)設(shè)置為0x01，表示啟用轉(zhuǎn)向角控制，LB單元允許APE讓EPAS單元控制轉(zhuǎn)向系統(tǒng)。

圖9 填充DasSteeringControlMessage的代碼片段

CAN消息的第四個(gè)字節(jié)是一個(gè)單字節(jié)的校驗(yàn)和，它是由8bit_checksum算法以CAN ID (0x0488)作為初始種子計(jì)算出來的:

圖10 eightbit_checksum算法

圖11顯示了在cantx服務(wù)的DasSteeringControlMessageEmitter::finalize_message()函數(shù)中填寫了DasSteeringControlMessage的校驗(yàn)和：

圖11 DasSteeringControlMessage的代碼片段

遠(yuǎn)程控制轉(zhuǎn)向系統(tǒng)

在弄清楚APE、LB和其他與轉(zhuǎn)向系統(tǒng)控制相關(guān)的ECU（EPAS、EPB）之間的CAN-bus通信后，我們還不能通過直接從APE向LB注入惡意DSCM來欺騙EPAS控制轉(zhuǎn)向系統(tǒng) . 原因是，如前所述，DSCM 受到消息時(shí)間戳和計(jì)數(shù)器的保護(hù)，以及在 APE 中稱為 PARTY CAN-bus 的冗余 CAN。

最后，我們找到了一個(gè)有效的解決方案：將惡意代碼動(dòng)態(tài)注入 cantx 服務(wù)，并鉤住 cantx 服務(wù)的 DasSteeringControlMessageEmitter::finalize_message() 函數(shù)，以重用 DSCM 的時(shí)間戳和計(jì)數(shù)器，以任意值操縱 DSCM。此外，關(guān)鍵部分是DSCM的控制類型必須設(shè)置為0x01，APE2LB_CAN的can_bus設(shè)置為0x01，表示DSCM的目的地是底盤CAN總線。

到目前為止，我們能夠通過利用這些漏洞遠(yuǎn)程入侵 APE 的系統(tǒng)，從遠(yuǎn)程移動(dòng)設(shè)備向 APE 中的 cantx 服務(wù)發(fā)送任意 DSCM。

為了可視化這個(gè)針對(duì)轉(zhuǎn)向系統(tǒng)的遠(yuǎn)程攻擊鏈，我們?cè)O(shè)法使用游戲手柄演示了遠(yuǎn)程轉(zhuǎn)向控制。游戲手柄控制器的控制過程如下圖所示：游戲手柄通過藍(lán)牙連接到我們的移動(dòng)設(shè)備上。同時(shí)，移動(dòng)設(shè)備接收來自游戲手柄的控制信號(hào)并將該信號(hào)轉(zhuǎn)換成相應(yīng)的DSCM。一旦 APE 受到威脅，cantx 服務(wù)將定期通過 3G/Wi-Fi 從移動(dòng)設(shè)備拉取 DSCM。此外，APE 需要不斷地將實(shí)時(shí)轉(zhuǎn)向角推送到移動(dòng)設(shè)備，以計(jì)算出我們預(yù)期的準(zhǔn)確轉(zhuǎn)向角。

圖12 采用手柄進(jìn)行遙控控制

在測(cè)試中，我們發(fā)現(xiàn)這種方法在不同的駕駛模式下對(duì)汽車有不同的影響：

1、當(dāng)汽車停放時(shí)，我們可以毫無限制地控制轉(zhuǎn)向系統(tǒng)；

2、當(dāng)汽車通過換擋手柄從R(倒車)模式切換到D(駕駛)模式時(shí)，APE似乎認(rèn)為汽車處于APC(自動(dòng)泊車控制)模式，該模式允許我們以大約8km /H的速度控制轉(zhuǎn)向系統(tǒng)；

3、當(dāng)汽車處于高速ACC(自適應(yīng)巡航控制)模式時(shí)，轉(zhuǎn)向系統(tǒng)也可以不受限制地控制；

4、即使汽車不在ACC(自適應(yīng)巡航控制)模式下，方向盤也有可能受到影響。

以上就是通過靜態(tài)逆向工程和動(dòng)態(tài)調(diào)試，對(duì)APE視覺系統(tǒng)進(jìn)行了深入分析。根據(jù)研究結(jié)果，在物理世界做了一些實(shí)驗(yàn)測(cè)試，成功的讓Tesla APE在攻擊場(chǎng)景下表現(xiàn)異常。這證明，通過一些物理環(huán)境裝飾，可以在不與車輛物理或遠(yuǎn)程連接的情況下，干擾或在一定程度上控制車輛。

參考： 整理自騰訊科恩實(shí)驗(yàn)室的資料