如何將Sniffle項(xiàng)目的一部分嵌入到CatSniffer中并使用機(jī)載RP2040
掃描二維碼
隨時(shí)隨地手機(jī)看文章
開始
這個(gè)項(xiàng)目一開始的意圖是利用BLE門鎖的漏洞來繞過訪問碼。我們計(jì)劃使用CatSniffer板來實(shí)現(xiàn)這一點(diǎn),因?yàn)樗С衷S多物聯(lián)網(wǎng)協(xié)議,包括BLE(低功耗藍(lán)牙)。
同樣,我們主要嘗試尋找可能存在安全問題的廉價(jià)中國門鎖。由于網(wǎng)上沒有太多關(guān)于有安全問題的門鎖的信息,我們想買一堆然后全部測試一下。
在研究了很多門鎖后,我們發(fā)現(xiàn)大多數(shù)門鎖只會使用BLE進(jìn)行初始配對。之后,大多數(shù)人會切換到Wi-Fi進(jìn)行實(shí)際通信。這將使它幾乎不可能打開門鎖一旦它已配置。
在此之后,項(xiàng)目的重點(diǎn)發(fā)生了變化,但是門鎖項(xiàng)目發(fā)送包裹的部分并沒有被丟棄,而是我們決定從發(fā)送包裹的例子開始。
Sniffle
Sniffle是一個(gè)專注于嗅探藍(lán)牙5和4.x的BLE項(xiàng)目。最近他們增加了對廣告的支持。這激起了我們的興趣,因?yàn)檫@個(gè)項(xiàng)目與CatSniffer兼容。該項(xiàng)目已經(jīng)有了一個(gè)Python腳本,該腳本發(fā)布了一個(gè)帶有默認(rèn)設(shè)備名稱的默認(rèn)包。我們想嵌入這個(gè),這樣它就可以在不使用主機(jī)的情況下在貓嗅探器上工作。
另一個(gè)促使我們與Sniffle項(xiàng)目合作的因素是,最近CatSniffer被添加為官方支持的主板。在此之前,我們必須自己編譯項(xiàng)目才能在CatSniffer上使用它。
現(xiàn)在我們既可以直接編譯項(xiàng)目,也可以使用Catnip工具直接獲取最新版本。
Sniffle固件通過使用Python腳本從計(jì)算機(jī)向兼容的TI CC1352/CC26x2 MCU發(fā)送命令來使用。Python腳本在計(jì)算機(jī)上運(yùn)行,并向運(yùn)行Sniffle固件的MCU發(fā)送UART命令。我們想找到一種直接在黑板上完成所有這些的方法。CatSniffer有一個(gè)TI CC1352和一個(gè)RP2040。為了實(shí)現(xiàn)這一目標(biāo),我們決定用Arduino IDE在RP2040上編碼,將命令發(fā)送到CC1352。RP2040與PC通信使用Serial0,與CC1352通信使用Serial1。
Python腳本
分析發(fā)送命令的Python腳本,我們注意到有幾個(gè)不同的腳本用于不同的任務(wù),我們選擇了廣告商.py來滿足我們的需求。
Python代碼相對簡單。首先,為BLE通信配置不同的參數(shù)。
代碼的重要部分在后面。廣告和掃描響應(yīng)數(shù)據(jù)在代碼的這一部分中定義。然后使用cmd_advertise函數(shù)處理廣告掃描響應(yīng)數(shù)據(jù),進(jìn)入廣告人模式。
使用print語句,我們檢查了如何格式化和生成信息。
Sniffle HW
Python代碼的主要部分是一個(gè)名為sniffle_hw.py的程序。在終端上運(yùn)行的所有其他腳本都與這個(gè)腳本通信。然后該程序?qū)ART消息發(fā)送到CC1352上的C代碼。
cmd_advertise函數(shù)生成廣告和掃描響應(yīng)數(shù)據(jù)的填充版本。數(shù)據(jù)包需要31個(gè)字節(jié),所以它們被檢查,如果它們更短,就用0填充。如果數(shù)據(jù)包較長,它們將被截?cái)?。此函?shù)還檢查模式中的錯誤。我們不斷使用print語句檢查數(shù)據(jù)。
填充數(shù)據(jù)后,使用send_cmd將其發(fā)送到C代碼。send命令由所有其他腳本和函數(shù)共享,用于與C代碼通信。
send命令通過組合兩個(gè)數(shù)據(jù)包并添加它們的長度來構(gòu)建消息。最后,消息用base64編碼并通過UART發(fā)送。
RP2040代碼
我們決定直接跳入并嘗試使用Arduino制作相同的代碼,使用Arduino RP2040進(jìn)行測試,正如Python腳本一樣一步一步地復(fù)制創(chuàng)建消息的整個(gè)過程。許多部分都是硬編碼的,以避免目前代碼的復(fù)雜性,因?yàn)樗且粋€(gè)測試。
定義
首先,我們添加了一些必要的庫,創(chuàng)建了要發(fā)送的數(shù)據(jù)和數(shù)組的大小變量,最后定義了advertise和send函數(shù)。我們還從存儲庫中為一些Cat Sniffer引腳定義添加了Serial Pass Through頭文件。
在設(shè)置中,代碼初始化串行通道,等待打開串行監(jiān)視器,并設(shè)置一些必要的引腳進(jìn)行通信。然后,它將一些值打印到串行中,以便能夠?qū)λ鼈冞M(jìn)行比較。最后,Advertise函數(shù)創(chuàng)建消息的其余部分。
在廣告函數(shù)中,代碼填充數(shù)據(jù),檢查它們是否具有正確的長度,并從該函數(shù)調(diào)用“cmd發(fā)送函數(shù)”來發(fā)送數(shù)據(jù)。它傳遞模式和已經(jīng)以0作為參數(shù)的數(shù)據(jù)。
在send函數(shù)中,我們創(chuàng)建cmd變量、消息和b0。在這一部分中,代碼變得有點(diǎn)長,因?yàn)槟仨毇@得數(shù)組的長度并將它們添加為數(shù)組的第一個(gè)值,這在C中有點(diǎn)繁瑣。
最后,最后的消息用base64編碼并通過串行1發(fā)送。
雖然這段代碼可以正確地創(chuàng)建要發(fā)送的數(shù)據(jù),但它無法與Sniffle的C代碼建立通信。
永遠(yuǎn)不可能得到代碼來響應(yīng)發(fā)送給它的廣告。由于這不起作用,我們嘗試了一些更簡單的方法,直接發(fā)送sniffle會發(fā)送的base64編碼的數(shù)據(jù)幀。這也沒有奏效。
我們還嘗試了另一個(gè)Sniffle Python腳本,即reset腳本,并獲得了類似的結(jié)果。
發(fā)送的Python數(shù)組被復(fù)制。
在代碼中,我們創(chuàng)建了一個(gè)函數(shù)來發(fā)送同步命令,然后以與Python腳本相同的方式重置命令5次。
不幸的是,無論我們發(fā)送什么,董事會都不會采取任何行動。
Bus Pirate
由于發(fā)送值不工作,我們必須找到一種方法來逐位查看數(shù)據(jù)幀。由于這是一個(gè)數(shù)字信號,我們考慮使用邏輯分析儀。我們決定用“巴士海盜”,因?yàn)槲覀兩磉吘陀幸惠v。安裝這些工具來使用Bus Pirate本身就是一個(gè)挑戰(zhàn)。Windows上有個(gè)bug,我們必須報(bào)告才能使軟件正常工作。我們在Bus Pirate論壇上報(bào)告了這個(gè)漏洞,他們修復(fù)了它,但這花了幾天時(shí)間。該漏洞主要影響了Bus Pirate用于圖形化顯示數(shù)據(jù)并解碼數(shù)據(jù)的Pulse View工具,這正是我們需要做的。Bus Pirate團(tuán)隊(duì)真的很好,很快就幫我們解決了問題。
一旦修復(fù)了錯誤,我們使用Arduino對程序進(jìn)行了一些測試,以學(xué)習(xí)如何使用它,并成功解碼了兩個(gè)Arduino之間的UART通信。
在這之后,希望又回來了!因?yàn)槲覀兛梢钥吹綆系谋忍亍N覀儑L試了同樣的事情,但在發(fā)射臺CC1352P7-4上使用Sniffle,但這揭示了另一個(gè)問題。
大多數(shù)來自Sniffle的Bus Pirate數(shù)據(jù)都是不完整或有錯誤的,這是因?yàn)锽us Pirate的最大采樣率是135 ks/s,而Sniffle固件的運(yùn)行速度是1M或2M。試圖改變固件的速度,但將其降低到1M以下會導(dǎo)致它崩潰。由于這些原因,我們決定使用示波器代替。
示波器
首先,我們在配置示波器上的觸發(fā)器以開始測量時(shí)遇到了一些麻煩,這是新手(不是新手)的問題。但是,一旦我們有了正確的配置,就只需要將Tx和Rx引腳連接到探針,并運(yùn)行Python腳本來查看發(fā)送和接收的數(shù)據(jù)。
示波器連接
首先,直接使用Launchpad,使用Python腳本和來自CC1352的響應(yīng)驗(yàn)證發(fā)送的消息。發(fā)射臺有一個(gè)CC1352作為貓嗅探器和另一個(gè)MCU,為了我們的目的,可以理解為FTDI。
現(xiàn)在我們可以確定消息是正確發(fā)送的。我們決定再試一次,這次是創(chuàng)建一個(gè)函數(shù)來通過串行監(jiān)聽響應(yīng)。
然后將Arduino Nano RP2040直接連接到Launchpad,斷開FTDI連接,然后將命令直接發(fā)送到CC1352并再次檢查響應(yīng)。在這一點(diǎn)上,我們確認(rèn)在這兩種情況下的反應(yīng)是相同的。
這證實(shí)了向固件發(fā)送外部命令是可能的。
最終代碼
我們決定繼續(xù),回到最初的Arduino代碼。根據(jù)我們所學(xué)的知識做出一些改變。主要是在命令的制作過程中出現(xiàn)了許多小錯誤。此時(shí),我們能做的最好的事情就是直觀地比較來自代碼和Python腳本的消息。
一旦每個(gè)步驟都是相同的,我們決定繼續(xù)在CatSniffer上進(jìn)行測試,繼續(xù)并將Sniffle固件加載到CC1352和我們的自定義廣告固件(鏈接在代碼部分)加載到RP2040。為了進(jìn)行測試,我們在手機(jī)上使用了nRF Connect來檢查我們是否能看到我們正在發(fā)送的數(shù)據(jù)包。在掃描BLE設(shè)備后,我們可以看到一個(gè)列有“CatSniffer”的設(shè)備,它的數(shù)據(jù)包與我們在代碼中定義的相同。
下一個(gè)步驟
處理原本不屬于我們的代碼會帶來一些挑戰(zhàn),尤其是對其進(jìn)行調(diào)整和理解其底層邏輯。然而,這個(gè)過程極大地增強(qiáng)了我們對BLE通信如何工作的理解,特別是當(dāng)涉及到分組構(gòu)建和傳輸時(shí)。
我們的代碼中仍然缺少很多東西。下一步是重點(diǎn)實(shí)現(xiàn)掃描響應(yīng)功能并建立可靠的設(shè)備連接。這將允許對BLE通信過程進(jìn)行更全面的測試和更好的控制,最終更接近于實(shí)現(xiàn)項(xiàng)目的原始目標(biāo)。
本文編譯自hackster.io