1. 為什么用Scapy模擬SOME/IP消息搞車載以太網(wǎng)測(cè)試這些年我經(jīng)常遇到一個(gè)很尷尬的場(chǎng)景手頭沒有完整的SOME/IP協(xié)議棧也沒有昂貴的總線仿真工具但就是要給對(duì)端ECU發(fā)一條自定義的SOME/IP請(qǐng)求驗(yàn)證它的響應(yīng)邏輯或容錯(cuò)能力。這時(shí)候用Python配合Scapy是最快能落地的方案沒有之一。先解釋下SOME/IP是什么。SOME/IP全稱是Scalable service-Oriented MiddlewarE over IP是車載ECU之間做服務(wù)發(fā)現(xiàn)和遠(yuǎn)程調(diào)用的一套中間件協(xié)議跑在以太網(wǎng)上承載方通常是UDP或TCP。它的核心思路是把ECU提供的功能抽象成服務(wù)客戶端通過(guò)Request/Response或者Fire-and-Forget的方式調(diào)用服務(wù)端通過(guò)提供Service ID和Method ID來(lái)區(qū)分不同功能。這套協(xié)議在整車SOA架構(gòu)里幾乎繞不開智能座艙和自動(dòng)駕駛域控制器之間的通信大量使用它。Scapy是Python生態(tài)里非常老牌的網(wǎng)絡(luò)報(bào)文構(gòu)造工具傳統(tǒng)上大家拿它玩TCP/IP比較多構(gòu)造個(gè)SYN Flood、偽造個(gè)DNS響應(yīng)之類的但用Scapy直接構(gòu)造應(yīng)用層協(xié)議——尤其是SOME/IP這種帶服務(wù)發(fā)現(xiàn)語(yǔ)義的中間件報(bào)文——的資料非常少很多同行還在用最原始的socket拼字節(jié)流或者用C拉起一個(gè)vsomeip實(shí)例來(lái)做。這恰恰是大問題。用原生socket發(fā)SOME/IP你面對(duì)的是幾十個(gè)字節(jié)的裸報(bào)文得自己一位一位地填Message ID、Request ID、Length偏移稍不留神就把Length算錯(cuò)對(duì)端直接丟棄報(bào)文而拉起完整協(xié)議棧又太重改一個(gè)字段要重新編譯根本沒有“快速驗(yàn)證”的靈活性。Scapy正好卡在中間它允許你以字段為單位操作報(bào)文還能自動(dòng)做協(xié)議層嵌套和長(zhǎng)度計(jì)算同時(shí)保留了底層發(fā)送的完全控制權(quán)。一句話概括這篇文章要解決的需求當(dāng)你在測(cè)試SOME/IP服務(wù)、驗(yàn)證異常場(chǎng)景、構(gòu)造調(diào)試報(bào)文時(shí)用Scapy在幾分鐘內(nèi)拼出想要的SOME/IP消息發(fā)到目標(biāo)IP并且在Wireshark里能看到規(guī)規(guī)矩矩的協(xié)議解析。這個(gè)能力對(duì)三種人特別有用一是做車載以太網(wǎng)測(cè)試的測(cè)試工程師二是做SOA服務(wù)開發(fā)需要自己構(gòu)造請(qǐng)求的開發(fā)三是研究SOME/IP協(xié)議棧做規(guī)模測(cè)試的協(xié)議同學(xué)。我接下來(lái)會(huì)從報(bào)文結(jié)構(gòu)講起然后給出可復(fù)現(xiàn)的Scapy構(gòu)造方案再講發(fā)送和抓包驗(yàn)證的完整鏈路最后把我在實(shí)際項(xiàng)目中踩過(guò)的坑整理出來(lái)。整個(gè)過(guò)程用到的代碼都能直接跑不依賴特殊的硬件和商業(yè)工具。2. SOME/IP報(bào)文結(jié)構(gòu)拆解構(gòu)造前必須先搞懂的字段2.1 頭部字段與長(zhǎng)度計(jì)算邏輯SOME/IP的基礎(chǔ)報(bào)文分為Header和Payload兩部分Header固定長(zhǎng)度是16字節(jié)也就是128比特。這16字節(jié)拆成6個(gè)字段Message ID4字節(jié)高16位是Service ID低16位是Method ID?？蛻舳苏{(diào)用某個(gè)服務(wù)的方法時(shí)靠這兩個(gè)ID組合來(lái)定位。Request ID4字節(jié)高16位是Client ID低16位是Session ID。Client ID標(biāo)識(shí)調(diào)用方Session ID標(biāo)識(shí)同一Client下的會(huì)話序號(hào)。Protocol Version1字節(jié)當(dāng)前固定為0x01。Interface Version1字節(jié)接口版本號(hào)由服務(wù)提供方定義通常從0x01開始。Message Type1字節(jié)區(qū)分請(qǐng)求和響應(yīng)等類型。Return Code1字節(jié)標(biāo)記調(diào)用結(jié)果。Length4字節(jié)從Request ID字段開始到Payload末尾的總長(zhǎng)度。這里最容易被忽視的是Length的計(jì)算范圍。很多第一次寫SOME/IP報(bào)文的人會(huì)以為L(zhǎng)ength是整個(gè)報(bào)文的長(zhǎng)度實(shí)際上協(xié)議規(guī)定Length是從Request ID開始的長(zhǎng)度也就是第4字節(jié)往后。換句話説對(duì)于16字節(jié)的固定HeaderLength最小也是12——從Request ID到Return Code的這12字節(jié)——再加上Payload的長(zhǎng)度。如果你手動(dòng)構(gòu)造報(bào)文時(shí)把Length算錯(cuò)一位對(duì)端在解析時(shí)直接會(huì)把頭的后半段當(dāng)成Payload結(jié)果就是校驗(yàn)失敗、報(bào)文被扔。2.2 Message Type與Return Code的取值Message Type主要會(huì)用這幾個(gè)值0x00是REQUEST客戶端發(fā)起調(diào)用0x01是REQUEST_NO_RETURN不需要服務(wù)端回應(yīng)的請(qǐng)求0x02是NOTIFICATION服務(wù)端主動(dòng)推送事件0x80是RESPONSE服務(wù)端對(duì)REQUEST的應(yīng)答。后邊還有0x81、0x82這類帶錯(cuò)誤碼語(yǔ)義的變體但日常測(cè)試最常見的就是0x00、0x01、0x02和0x80。Return Code在REQUEST里一般填0x00在RESPONSE里同樣填0x00表示成功。如果需要構(gòu)造錯(cuò)誤響應(yīng)來(lái)測(cè)試對(duì)端異常處理可以填0x01E_NOT_OK或者0x02E_NOT_REACHABLE這類標(biāo)準(zhǔn)錯(cuò)誤碼。測(cè)試工程師經(jīng)常故意構(gòu)造異常Return Code驗(yàn)證客戶端在拿到錯(cuò)誤響應(yīng)后是否會(huì)走重試或降級(jí)邏輯這時(shí)候用Scapy構(gòu)造這種報(bào)文非常順手。2.3 服務(wù)發(fā)現(xiàn)階段的特殊報(bào)文Magic CookieSOME/IP還有一類非常重要的特殊報(bào)文是服務(wù)發(fā)現(xiàn)消息簡(jiǎn)稱SOME/IP-SD。它復(fù)用了SOME/IP的頭部但Message ID固定為0xFFFF8100Request ID固定為0x00000000Protocol Version是0x01Interface Version固定為0x01Message Type固定為0x02Return Code固定為0x00。這其實(shí)是把頭部“僵化”成一個(gè)固定前綴后面跟著接下來(lái)要說(shuō)的Magic Cookie格式字段和各個(gè)服務(wù)條目。SD消息的真正內(nèi)容是從Payload開始的。第一個(gè)需要構(gòu)造的就是Magic Cookie它是一個(gè)固定的16字節(jié)串0xFF 0xFF 0xFF 0xFF 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x00。這個(gè)字段存在的意義是為了讓接收方確認(rèn)“后面跟著的確實(shí)是SOME/IP-SD載荷”做一次格式同步。之后緊跟的是若干服務(wù)條目每個(gè)條目由Type1字節(jié)、Index3字節(jié)、Option個(gè)數(shù)1字節(jié)等字段組成用來(lái)聲明服務(wù)實(shí)例或訂閱服務(wù)。SD消息的完整解析是個(gè)大工程但如果你只是想模擬一個(gè)簡(jiǎn)單的服務(wù)宣告或者查找請(qǐng)求用Scapy把最外層的SOME/IP-SD頭構(gòu)出來(lái)已經(jīng)夠用了。2.4 為什么必須理解這些才能用Scapy構(gòu)造Scapy內(nèi)置了兩個(gè)跟SOME/IP有關(guān)的層一個(gè)叫SOMEIP一個(gè)叫SOMEIPSD。SOMEIP是基礎(chǔ)報(bào)文層對(duì)應(yīng)剛才說(shuō)到的16字節(jié)頭部支持字段級(jí)填充和自動(dòng)序列化SOMEIPSD專門用于構(gòu)造服務(wù)發(fā)現(xiàn)條目包含Entries和Options的字段。這兩個(gè)層在功能上覆蓋了90%的測(cè)試場(chǎng)景。但要注意一個(gè)細(xì)節(jié)Scapy內(nèi)置的SOMEIP層在構(gòu)造Length字段時(shí)會(huì)自動(dòng)排除Header自己的4個(gè)字節(jié)。也就是說(shuō)你只要指定了Request ID、Payload等字段Scapy會(huì)把Length算成一個(gè)“把后面所有字段加在一起”的值這正好符合SOME/IP的Length定義。很多人在用Scapy構(gòu)造時(shí)還手動(dòng)去填Length結(jié)果發(fā)現(xiàn)發(fā)出去的報(bào)文在Wireshark里解析出來(lái)Length是錯(cuò)的就是因?yàn)橹貜?fù)計(jì)算了。我待會(huì)兒實(shí)操部分會(huì)專門演示這個(gè)坑。3. Scapy構(gòu)造與發(fā)送SOME/IP消息的具體實(shí)操3.1 環(huán)境準(zhǔn)備和Scapy安裝開始之前先把工具鏈準(zhǔn)備好。Scapy支持Python 3推薦直接用3.8以上的版本。安裝Scapy很簡(jiǎn)單pip install scapy如果你在Linux環(huán)境里需要直接操作網(wǎng)卡發(fā)包可能還需要裝一下libpcap的開發(fā)庫(kù)。Debian/Ubuntu系統(tǒng)可以用命令apt install libpcap-dev裝好之后驗(yàn)證一下是否能正常導(dǎo)入SOME/IP層from scapy.contrib.someip import SOMEIP, SOMEIPSD print(SOMEIP layer available)如果導(dǎo)入失敗多半是Scapy的contrib模塊沒有把SOME/IP編譯進(jìn)來(lái)。這時(shí)候需要確認(rèn)一下Scapy版本低于2.4.3的老版本對(duì)SOME/IP的支持并不完整建議直接升級(jí)pip install --upgrade scapy我在Ubuntu 22.04上實(shí)測(cè)過(guò)Scapy 2.5.0和2.6.1都能正常導(dǎo)入SOMEIP層。Windows環(huán)境也可以跑但發(fā)包時(shí)建議配合Npcap驅(qū)動(dòng)純socket方式在Windows上會(huì)受限。3.2 構(gòu)造一條基礎(chǔ)的SOME/IP Request消息來(lái)看一段最基礎(chǔ)的代碼構(gòu)造一條普通的REQUEST消息并發(fā)送到目標(biāo)ECUfrom scapy.all import IP, UDP, Ether, sendp from scapy.contrib.someip import SOMEIP def build_someip_request(service_id0x1234, method_id0x0001, client_id0x0001, session_id0x0001, payloadb\x01\x02\x03\x04): someip_pkt ( SOMEIP(ServiceIDservice_id, MethodIDmethod_id, ClientIDclient_id, SessionIDsession_id, MsgType0x00, ReturnCode0x00) / payload ) udp_pkt ( IP(dst192.168.1.100) / UDP(sport30500, dport30501) / someip_pkt ) return udp_pkt packet build_someip_request() packet.show()這段代碼的核心邏輯是先用SOMEIP層定義頭部字段把Payload直接拼在旁邊然后再套上UDP和IP頭。這里有幾個(gè)關(guān)鍵參數(shù)需要解釋ServiceID0x1234和MethodID0x0001組合起來(lái)構(gòu)成Message ID?？蛻舳嗽谡{(diào)用服務(wù)時(shí)只有這個(gè)組合跟服務(wù)端注冊(cè)的一致請(qǐng)求才會(huì)被路由到正確的處理函數(shù)。ClientID和SessionID用于標(biāo)識(shí)一次事務(wù)。SessionID一般用遞增序號(hào)但測(cè)試時(shí)固定填0x0001問題也不大。MsgType填0x00表示這是REQUEST服務(wù)端收到后應(yīng)該回復(fù)RESPONSE。UDP的源端口可以任意選一個(gè)空閑端口目標(biāo)端口要根據(jù)服務(wù)端實(shí)際監(jiān)聽端口來(lái)填。很多ECU默認(rèn)監(jiān)聽30490或者30501但實(shí)現(xiàn)各有不同建議先用Wireshark抓一下服務(wù)正常啟動(dòng)時(shí)的服務(wù)發(fā)現(xiàn)廣播看看真正開放的端口。構(gòu)造完成后可以用packet.show()打印報(bào)文結(jié)構(gòu)確認(rèn)每個(gè)字段都落在期望的節(jié)拍上。這一步雖然簡(jiǎn)單但能提前發(fā)現(xiàn)問題避免發(fā)到對(duì)端才被丟包。3.3 構(gòu)造RESPONSE消息和帶業(yè)務(wù)載荷的消息測(cè)試時(shí)經(jīng)常需要模擬服務(wù)端給客戶端回RESPONSE。跟REQUEST相比RESPONSE的MsgType要填0x80ReturnCode按業(yè)務(wù)結(jié)果填0x00或錯(cuò)誤碼Message ID必須跟客戶端發(fā)來(lái)的REQUEST保持一致Request IDClientIDSessionID也要原樣返回。代碼結(jié)構(gòu)跟REQUEST完全一樣只是字段值變了def build_someip_response(service_id0x1234, method_id0x0001, client_id0x0001, session_id0x0001, return_code0x00, payloadb\x00\x00\x00\x00): someip_pkt ( SOMEIP(ServiceIDservice_id, MethodIDmethod_id, ClientIDclient_id, SessionIDsession_id, MsgType0x80, ReturnCodereturn_code) / payload ) udp_pkt ( IP(dst192.168.1.200) / UDP(sport30501, dport30500) / someip_pkt ) return udp_pktPayload這里我填的是4字節(jié)的\x00\x00\x00\x00實(shí)際業(yè)務(wù)載荷可能是一串序列化后的結(jié)構(gòu)體數(shù)據(jù)具體格式要看服務(wù)的IDL定義。很多SOME/IP服務(wù)用vsomeip做序列化常見格式是每個(gè)字段按4字節(jié)對(duì)齊字符串和數(shù)組會(huì)在開頭帶長(zhǎng)度字段。這塊我建議測(cè)試前先拿一個(gè)正常的服務(wù)端日志或者抓包樣本對(duì)一下Payload字節(jié)確認(rèn)格式后再去構(gòu)造。3.4 構(gòu)造SOME/IP-SD服務(wù)發(fā)現(xiàn)報(bào)文如果需要模擬服務(wù)上線廣播或者服務(wù)發(fā)現(xiàn)請(qǐng)求就要用到SOMEIPSD層。下面這段代碼構(gòu)造了一個(gè)最簡(jiǎn)單的服務(wù)發(fā)現(xiàn)廣播報(bào)文from scapy.all import Ether, IP, UDP, sendp from scapy.contrib.someip import SOMEIP, SOMEIPSD sd_pkt ( Ether(dstff:ff:ff:ff:ff:ff) / IP(src192.168.1.100, dst224.244.224.245) / UDP(sport30490, dport30490) / SOMEIP(ServiceID0xFFFF, MethodID0x8100, ClientID0x0000, SessionID0x0000, MsgType0x02, ReturnCode0x00) / b\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00 / SOMEIPSD(Entries[ # 這里可以填服務(wù)條目 ]) ) sendp(sd_pkt, ifaceeth0)這段代碼里有幾個(gè)值得注意的點(diǎn)目標(biāo)MAC是廣播地址SOME/IP-SD的UDP組播地址默認(rèn)是224.244.224.245端口固定30490這是AUTOSAR規(guī)范里定義的保留地址。Message ID固定為0xFFFF8100其中ServiceID0xFFFFMethodID0x8100這就是SD報(bào)文的標(biāo)識(shí)。Magic Cookie是我們手動(dòng)加的那個(gè)字節(jié)串。Scapy的SOMEIPSD層在構(gòu)造Entry時(shí)會(huì)自動(dòng)處理一部分字段但Magic Cookie位置比較特殊直接作為原始字節(jié)拼在后面最穩(wěn)定。不過(guò)有一點(diǎn)我得說(shuō)實(shí)話SOMEIPSD層在處理復(fù)雜Entry和Option時(shí)的支持并不完善尤其是Option里的IPv4 Endpoint、配置字符串等高級(jí)字段Scapy內(nèi)置的格式可能跟實(shí)際ECU的SD實(shí)現(xiàn)有細(xì)微差別。我的建議是如果只是少量SD報(bào)文驗(yàn)證用Scapy足夠如果要做完整的SD交互邏輯測(cè)試還是得靠vsomeip這類完整協(xié)議棧。這里沒必要硬撐著用Scapy。3.5 發(fā)包方式與參數(shù)選擇Scapy發(fā)送報(bào)文有三種常用方式send()走三層需要完整的IP/UDP頭適合已經(jīng)配置好路由的場(chǎng)景。sendp()走二層直接以以太網(wǎng)幀發(fā)送需要指定網(wǎng)卡接口和MAC地址適合測(cè)試環(huán)境里需要精確控制幀頭的情況。sr() / sr1()發(fā)送并等待響應(yīng)適合做請(qǐng)求-響應(yīng)測(cè)試可以直接拿到對(duì)端的回包。實(shí)際測(cè)試中我更喜歡用sendp()。因?yàn)檐囕d測(cè)試環(huán)境經(jīng)常是多網(wǎng)卡、多IP的設(shè)備路由表未必按預(yù)期走用二層直接指定網(wǎng)卡最靠譜。舉個(gè)例子sendp(packet, ifaceeth0, count10, inter0.1)這條命令會(huì)把包從eth0網(wǎng)卡發(fā)出發(fā)送10次每次間隔0.1秒。count和inter是發(fā)包壓力測(cè)試常用的參數(shù)模擬客戶端連續(xù)請(qǐng)求場(chǎng)景很方便。如果對(duì)端有響應(yīng)可以用sr1()發(fā)一條等一條from scapy.all import sr1 reply sr1(packet, ifaceeth0, timeout2) if reply: reply.show() else: print(timeout, no response)這個(gè)方式特別適合你剛搭好一個(gè)SOME/IP服務(wù)想快速確認(rèn)它是否響應(yīng)正確構(gòu)造的請(qǐng)求。4. 抓包驗(yàn)證與Wireshark解析4.1 怎么確認(rèn)發(fā)出去的報(bào)文格式正確構(gòu)造報(bào)文只是第一步發(fā)出去之后你有沒有真正驗(yàn)證過(guò)對(duì)端是怎么看待這個(gè)報(bào)文的這一點(diǎn)很重要因?yàn)镾capy的字段序列化過(guò)程對(duì)你的代碼是沒有感知的你看到的packet.show()只是它在內(nèi)存里的結(jié)構(gòu)真正抓到的幀才是對(duì)端視角的幀。我習(xí)慣的驗(yàn)證方式是在發(fā)送端打開Wireshark的抓包窗口再跑發(fā)包腳本抓到那一條報(bào)文后展開看。如果SOME/IP層能被Wireshark正確解析出來(lái)說(shuō)明頭部字段的構(gòu)造沒有問題。順便看下Length字段是否等于Payload長(zhǎng)度12這是個(gè)非常重要的快速自檢項(xiàng)。Wireshark默認(rèn)自帶SOME/IP解析器支持但有時(shí)候版本較老或者沒加載插件會(huì)直接把SOME/IP的UDP載荷當(dāng)成普通data顯示。這種情況可以下載SOME/IP的Wireshark插件有開源項(xiàng)目專門做這個(gè)或者手動(dòng)用“Decode As”把UDP端口指定為SOME/IP協(xié)議。如果你手上是Wireshark 4.0以上的版本官方解析器已經(jīng)能識(shí)別大部分SOME/IP基礎(chǔ)報(bào)文但SD報(bào)文里的Entries和Options解析有時(shí)仍會(huì)顯示為raw data這不影響調(diào)試重點(diǎn)還是看Header字段。4.2 字段的自檢邏輯抓包后我建議關(guān)注這幾個(gè)關(guān)鍵字段每一項(xiàng)都跟協(xié)議規(guī)范對(duì)應(yīng)Length應(yīng)該等于Payload長(zhǎng)度12。如果差4說(shuō)明把Length自身的大小也算進(jìn)去了這是最典型的Scapy構(gòu)造錯(cuò)誤。Message ID確認(rèn)Service ID和Method ID落在預(yù)期范圍。0xFFFF8100是SD專用普通業(yè)務(wù)報(bào)文不應(yīng)該出現(xiàn)。MsgTypeREQUEST是0x00RESPONSE是0x80NOTIFICATION是0x02搞混了會(huì)導(dǎo)致對(duì)端完全無(wú)法處理。Request ID模擬客戶端時(shí)Client ID要唯一Session ID每次請(qǐng)求應(yīng)該遞增或至少不重復(fù)。有些ECU會(huì)檢查重復(fù)的Session ID并丟棄。我用Wireshark“可讀字符串”視圖看一個(gè)典型REQEUST時(shí)實(shí)際展開的效果是IP層和UDP層完全正常SOME/IP層各字段清晰可見Payload部分就是那一段業(yè)務(wù)數(shù)據(jù)。如果你發(fā)現(xiàn)Payload里混進(jìn)了某些多余的00字節(jié)大概率是Scapy自動(dòng)填充了對(duì)齊字段需要去看SOME/IP層的缺省字節(jié)對(duì)齊策略。4.3 驗(yàn)證Response是否被正確構(gòu)造構(gòu)造一個(gè)模擬服務(wù)端的RESPONSE時(shí)抓包驗(yàn)證尤其重要。除了檢查頭部字段外還要對(duì)著客戶端發(fā)出的REQUEST來(lái)核對(duì)服務(wù)端返回的Message ID是否跟請(qǐng)求一致ClientID和SessionID是否原樣帶回來(lái)了。只要這些一致客戶端才能把Response和請(qǐng)求匹配上反之它就會(huì)一直傻等超時(shí)。我碰到過(guò)一種情況測(cè)試平臺(tái)的客戶端不檢查Return Code只要Message ID和Session ID對(duì)得上就當(dāng)作成功處理。這種情況下你故意構(gòu)造一個(gè)Return Code為0x01的錯(cuò)誤響應(yīng)發(fā)給它它居然毫無(wú)反應(yīng)。這說(shuō)明被測(cè)系統(tǒng)對(duì)這個(gè)字段的校驗(yàn)本身就是弱的這種情況做異常測(cè)試時(shí)要額外關(guān)注不能因?yàn)閷?duì)端不檢查就認(rèn)為協(xié)議棧實(shí)現(xiàn)正確。5. 常見問題與排查技巧實(shí)錄5.1 問題快速定位表我用表格整理一下在實(shí)際項(xiàng)目中遇到的典型問題方便你對(duì)照排查。問題現(xiàn)象可能原因排查方法Wireshark無(wú)法識(shí)別SOME/IP協(xié)議端口未配置為SOME/IP解碼用Decode As手動(dòng)指定協(xié)議Length字段顯示比預(yù)期多4手動(dòng)計(jì)算Length把自身長(zhǎng)度算進(jìn)去了讓Scapy自動(dòng)算Length不手動(dòng)覆蓋對(duì)端完全無(wú)響應(yīng)Service ID/Method ID與注冊(cè)不符用Wireshark抓正常通信報(bào)文對(duì)比IDSession ID重復(fù)導(dǎo)致請(qǐng)求被丟棄每次發(fā)包用了相同SessionID遞增SessionID重新發(fā)送報(bào)文能看到但Payload為空構(gòu)造時(shí)SOMEIP層后未拼接Payload檢查協(xié)議拼接語(yǔ)法是否用/連接廣播幀發(fā)不出去網(wǎng)卡沒有加入組播組或交換機(jī)丟棄用本機(jī)Wireshark驗(yàn)證是否發(fā)送成功單條消息自發(fā)自收無(wú)法實(shí)現(xiàn)僅構(gòu)造環(huán)路地址未走真實(shí)網(wǎng)卡改用sendp指定實(shí)際網(wǎng)卡接口5.2 典型坑一長(zhǎng)度字段算不對(duì)這是新手最容易踩的坑也是最容易排查的坑。SOME/IP的Length定義是“從Request ID字段開始到Payload末尾的總字節(jié)數(shù)”因?yàn)镠eader有16字節(jié)其中Message ID和Length本身共8個(gè)字節(jié)不參與計(jì)算所以Length實(shí)際等于Payload長(zhǎng)度12。Scapy在處理SOMEIP層時(shí)默認(rèn)會(huì)把Payload長(zhǎng)度加12作為L(zhǎng)ength字段的值這個(gè)行為是內(nèi)置的你不需要手動(dòng)去改。如果你為了保險(xiǎn)自己手寫了一個(gè)Length結(jié)果就是實(shí)際值被覆蓋成兩個(gè)Length相加報(bào)文直接錯(cuò)。我的建議是構(gòu)造階段不要碰Length字段直接用Scapy默認(rèn)值然后靠Wireshark的解析結(jié)果來(lái)校準(zhǔn)。遇到了問題再手動(dòng)調(diào)。5.3 典型坑二源端口和目的端口搞反很多ECU在SOME/IP協(xié)議棧里做了端口白名單比如固定從30490端口接收SD消息、從30501接收業(yè)務(wù)消息但也有廠商是動(dòng)態(tài)綁定端口。測(cè)試時(shí)如果你把源端口和目標(biāo)端口填反了對(duì)端雖然能收到UDP包但應(yīng)用層過(guò)濾時(shí)看到端口不匹配直接丟棄。排查方法也很簡(jiǎn)單先跑一次正常的服務(wù)啟動(dòng)流程用Wireshark抓一段參考報(bào)文看它的源端口、目標(biāo)端口以及Message ID然后照著參考報(bào)文去改Scapy參數(shù)。不要憑印象填端口不同項(xiàng)目的端口規(guī)劃差別很大。5.4 典型坑三在lo接口發(fā)不出來(lái)如果你在開發(fā)機(jī)上直接跑Scapy而且包的目標(biāo)IP寫的是127.0.0.1那么只能走lo接口并且發(fā)送時(shí)常見問題如下Scapy的sendp發(fā)送二層幀到lo時(shí)網(wǎng)卡會(huì)丟棄因?yàn)閘o不是標(biāo)準(zhǔn)以太網(wǎng)接口。正確的做法是直接用send()走三層環(huán)路或者用UDP socket發(fā)送。不過(guò)模擬SOME/IP消息的場(chǎng)景一般是跨設(shè)備測(cè)試很少走loopback所以我更推薦直接用sendp指定實(shí)際物理網(wǎng)卡。5.5 典型坑四SD廣播幀發(fā)不出去構(gòu)造SD廣播報(bào)文時(shí)如果只是單純指定組播IP而不指定目標(biāo)MAC為組播MAC交換機(jī)會(huì)把幀丟掉。SOME/IP-SD默認(rèn)目標(biāo)IP是224.244.224.245對(duì)應(yīng)的組播MAC是01:00:5e:74:f0:f5也就是把IP后23位映射到MAC后23位。用Ether層的時(shí)候必須手動(dòng)設(shè)置dst為這個(gè)組播MAC否則發(fā)出去的對(duì)端根本收不到。第3.4節(jié)的代碼里我已經(jīng)寫好了這個(gè)目標(biāo)MAC實(shí)際項(xiàng)目里要注意確認(rèn)網(wǎng)卡所在的VLAN和交換機(jī)是否放通了對(duì)應(yīng)組播組。5.6 構(gòu)造異常報(bào)文時(shí)的心得最后分享一個(gè)我在做負(fù)向測(cè)試時(shí)的技巧。用Scapy的好處之一是你可以非常方便地構(gòu)造“畸形”報(bào)文——比如故意把Length改小、把ReturnCode改成未知值、把SessionID填成0。這種報(bào)文在真實(shí)環(huán)境中幾乎不會(huì)出現(xiàn)但恰恰是對(duì)端協(xié)議棧健壯性最好的試金石。我在測(cè)試某個(gè)座艙域控制器的SOME/IP服務(wù)時(shí)就是用Scapy連續(xù)發(fā)了幾個(gè)不同異常組合的報(bào)文還真發(fā)現(xiàn)了一個(gè)當(dāng)請(qǐng)求的Payload長(zhǎng)度超過(guò)服務(wù)端緩沖時(shí)直接宕機(jī)的問題。如果你想做類似的負(fù)向測(cè)試建議用Scapy的Raw層繞開SOMEIP層直接構(gòu)造原始字節(jié)流這樣可以完全繞過(guò)Scapy自動(dòng)計(jì)算Length等機(jī)制想怎么改就怎么改from scapy.all import IP, UDP, Raw malformed_pkt ( IP(dst192.168.1.100) / UDP(sport30500, dport30501) / Raw(loadb\x12\x34\x00\x01\x00\x01\x00\x01\x01\x01\x00\x00\xff\xff\xff\xff) ) send(malformed_pkt, ifaceeth0)這片Raw區(qū)域的16個(gè)字節(jié)就是SOME/IP頭部你可以按需改動(dòng)任何一位。這種方式的好處是頭部字段完全可控不會(huì)因?yàn)镾capy自動(dòng)填充而“糾正”你的錯(cuò)誤。6. 結(jié)尾這個(gè)方案后續(xù)還能怎么擴(kuò)展寫到這里我想起一個(gè)場(chǎng)景。去年有個(gè)項(xiàng)目需要在沒有完整SOME/IP協(xié)議棧的情況下把一個(gè)測(cè)試用的假服務(wù)端掛在以太網(wǎng)上接受真實(shí)客戶端的訂閱請(qǐng)求并發(fā)布模擬數(shù)據(jù)。我當(dāng)時(shí)就是用Scapy搭了一個(gè)“半自動(dòng)”服務(wù)端一個(gè)腳本里同時(shí)起了兩個(gè)線程一個(gè)線程收包解析請(qǐng)求另一個(gè)線程按固定頻率用Scapy構(gòu)造NOTIFICATION消息發(fā)給客戶端。雖然不及vsomeip那么完整但對(duì)驗(yàn)證客戶端邏輯已經(jīng)夠用了。這個(gè)方案往后還可以擴(kuò)展。比如配合Scapy的sniff()接口做在線重放測(cè)試——把線上抓的pcap文件里的SOME/IP消息讀出來(lái)改掉關(guān)鍵字段后再發(fā)出去用來(lái)驗(yàn)證某個(gè)字段的敏感性再比如把構(gòu)造好的報(bào)文封裝成Pytest測(cè)試用例集成到CI流水線里做回歸測(cè)試前提是對(duì)端設(shè)備已接入測(cè)試網(wǎng)絡(luò)。這些都是順手就能做的事不需要額外的框架和工具。我個(gè)人在實(shí)際操作中的體會(huì)是Scapy模擬SOME/IP消息最大的價(jià)值不在于它能不能替代完整協(xié)議棧而在于它給了你一個(gè)能精確控制每一個(gè)bit的調(diào)試入口。測(cè)試車載以太網(wǎng)協(xié)議時(shí)你真正需要的往往不是“很標(biāo)準(zhǔn)”的報(bào)文而是“剛剛好”的報(bào)文——能在你需要的字段上做各種變形的那種。Scapy恰好能滿足這個(gè)需求。