開始

這個項目一開始的意圖是利用BLE門鎖的漏洞來繞過訪問碼。我們計劃使用CatSniffer板來實現(xiàn)這一點，因為它支持許多物聯(lián)網(wǎng)協(xié)議，包括BLE(低功耗藍(lán)牙)。

同樣，我們主要嘗試尋找可能存在安全問題的廉價中國門鎖。由于網(wǎng)上沒有太多關(guān)于有安全問題的門鎖的信息，我們想買一堆然后全部測試一下。

在研究了很多門鎖后，我們發(fā)現(xiàn)大多數(shù)門鎖只會使用BLE進行初始配對。之后，大多數(shù)人會切換到Wi-Fi進行實際通信。這將使它幾乎不可能打開門鎖一旦它已配置。

在此之后，項目的重點發(fā)生了變化，但是門鎖項目發(fā)送包裹的部分并沒有被丟棄，而是我們決定從發(fā)送包裹的例子開始。

Sniffle

Sniffle是一個專注于嗅探藍(lán)牙5和4.x的BLE項目。最近他們增加了對廣告的支持。這激起了我們的興趣，因為這個項目與CatSniffer兼容。該項目已經(jīng)有了一個Python腳本，該腳本發(fā)布了一個帶有默認(rèn)設(shè)備名稱的默認(rèn)包。我們想嵌入這個，這樣它就可以在不使用主機的情況下在貓嗅探器上工作。

另一個促使我們與Sniffle項目合作的因素是，最近CatSniffer被添加為官方支持的主板。在此之前，我們必須自己編譯項目才能在CatSniffer上使用它。

現(xiàn)在我們既可以直接編譯項目，也可以使用Catnip工具直接獲取最新版本。

Sniffle固件通過使用Python腳本從計算機向兼容的TI CC1352/CC26x2 MCU發(fā)送命令來使用。Python腳本在計算機上運行，并向運行Sniffle固件的MCU發(fā)送UART命令。我們想找到一種直接在黑板上完成所有這些的方法。CatSniffer有一個TI CC1352和一個RP2040。為了實現(xiàn)這一目標(biāo)，我們決定用Arduino IDE在RP2040上編碼，將命令發(fā)送到CC1352。RP2040與PC通信使用Serial0，與CC1352通信使用Serial1。

Python腳本

分析發(fā)送命令的Python腳本，我們注意到有幾個不同的腳本用于不同的任務(wù)，我們選擇了廣告商.py來滿足我們的需求。

Python代碼相對簡單。首先，為BLE通信配置不同的參數(shù)。

代碼的重要部分在后面。廣告和掃描響應(yīng)數(shù)據(jù)在代碼的這一部分中定義。然后使用cmd_advertise函數(shù)處理廣告掃描響應(yīng)數(shù)據(jù)，進入廣告人模式。

使用print語句，我們檢查了如何格式化和生成信息。

Sniffle HW

Python代碼的主要部分是一個名為sniffle_hw.py的程序。在終端上運行的所有其他腳本都與這個腳本通信。然后該程序?qū)ART消息發(fā)送到CC1352上的C代碼。

cmd_advertise函數(shù)生成廣告和掃描響應(yīng)數(shù)據(jù)的填充版本。數(shù)據(jù)包需要31個字節(jié)，所以它們被檢查，如果它們更短，就用0填充。如果數(shù)據(jù)包較長，它們將被截斷。此函數(shù)還檢查模式中的錯誤。我們不斷使用print語句檢查數(shù)據(jù)。

填充數(shù)據(jù)后，使用send_cmd將其發(fā)送到C代碼。send命令由所有其他腳本和函數(shù)共享，用于與C代碼通信。

send命令通過組合兩個數(shù)據(jù)包并添加它們的長度來構(gòu)建消息。最后，消息用base64編碼并通過UART發(fā)送。

RP2040代碼

我們決定直接跳入并嘗試使用Arduino制作相同的代碼，使用Arduino RP2040進行測試，正如Python腳本一樣一步一步地復(fù)制創(chuàng)建消息的整個過程。許多部分都是硬編碼的，以避免目前代碼的復(fù)雜性，因為它是一個測試。

定義

首先，我們添加了一些必要的庫，創(chuàng)建了要發(fā)送的數(shù)據(jù)和數(shù)組的大小變量，最后定義了advertise和send函數(shù)。我們還從存儲庫中為一些Cat Sniffer引腳定義添加了Serial Pass Through頭文件。

在設(shè)置中，代碼初始化串行通道，等待打開串行監(jiān)視器，并設(shè)置一些必要的引腳進行通信。然后，它將一些值打印到串行中，以便能夠?qū)λ鼈冞M行比較。最后，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。在這一部分中，代碼變得有點長，因為您必須獲得數(shù)組的長度并將它們添加為數(shù)組的第一個值，這在C中有點繁瑣。

最后，最后的消息用base64編碼并通過串行1發(fā)送。

雖然這段代碼可以正確地創(chuàng)建要發(fā)送的數(shù)據(jù)，但它無法與Sniffle的C代碼建立通信。

永遠(yuǎn)不可能得到代碼來響應(yīng)發(fā)送給它的廣告。由于這不起作用，我們嘗試了一些更簡單的方法，直接發(fā)送sniffle會發(fā)送的base64編碼的數(shù)據(jù)幀。這也沒有奏效。

我們還嘗試了另一個Sniffle Python腳本，即reset腳本，并獲得了類似的結(jié)果。

發(fā)送的Python數(shù)組被復(fù)制。

在代碼中，我們創(chuàng)建了一個函數(shù)來發(fā)送同步命令，然后以與Python腳本相同的方式重置命令5次。

不幸的是，無論我們發(fā)送什么，董事會都不會采取任何行動。

Bus Pirate

由于發(fā)送值不工作，我們必須找到一種方法來逐位查看數(shù)據(jù)幀。由于這是一個數(shù)字信號，我們考慮使用邏輯分析儀。我們決定用“巴士海盜”，因為我們身邊就有一輛。安裝這些工具來使用Bus Pirate本身就是一個挑戰(zhàn)。Windows上有個bug，我們必須報告才能使軟件正常工作。我們在Bus Pirate論壇上報告了這個漏洞，他們修復(fù)了它，但這花了幾天時間。該漏洞主要影響了Bus Pirate用于圖形化顯示數(shù)據(jù)并解碼數(shù)據(jù)的Pulse View工具，這正是我們需要做的。Bus Pirate團隊真的很好，很快就幫我們解決了問題。

一旦修復(fù)了錯誤，我們使用Arduino對程序進行了一些測試，以學(xué)習(xí)如何使用它，并成功解碼了兩個Arduino之間的UART通信。

在這之后，希望又回來了!因為我們可以看到幀上的比特。我們嘗試了同樣的事情，但在發(fā)射臺CC1352P7-4上使用Sniffle，但這揭示了另一個問題。

大多數(shù)來自Sniffle的Bus Pirate數(shù)據(jù)都是不完整或有錯誤的，這是因為Bus Pirate的最大采樣率是135 ks/s，而Sniffle固件的運行速度是1M或2M。試圖改變固件的速度，但將其降低到1M以下會導(dǎo)致它崩潰。由于這些原因，我們決定使用示波器代替。

示波器

首先，我們在配置示波器上的觸發(fā)器以開始測量時遇到了一些麻煩，這是新手(不是新手)的問題。但是，一旦我們有了正確的配置，就只需要將Tx和Rx引腳連接到探針，并運行Python腳本來查看發(fā)送和接收的數(shù)據(jù)。

示波器連接

首先，直接使用Launchpad，使用Python腳本和來自CC1352的響應(yīng)驗證發(fā)送的消息。發(fā)射臺有一個CC1352作為貓嗅探器和另一個MCU，為了我們的目的，可以理解為FTDI。

現(xiàn)在我們可以確定消息是正確發(fā)送的。我們決定再試一次，這次是創(chuàng)建一個函數(shù)來通過串行監(jiān)聽響應(yīng)。

然后將Arduino Nano RP2040直接連接到Launchpad，斷開FTDI連接，然后將命令直接發(fā)送到CC1352并再次檢查響應(yīng)。在這一點上，我們確認(rèn)在這兩種情況下的反應(yīng)是相同的。

這證實了向固件發(fā)送外部命令是可能的。

最終代碼

我們決定繼續(xù)，回到最初的Arduino代碼。根據(jù)我們所學(xué)的知識做出一些改變。主要是在命令的制作過程中出現(xiàn)了許多小錯誤。此時，我們能做的最好的事情就是直觀地比較來自代碼和Python腳本的消息。

一旦每個步驟都是相同的，我們決定繼續(xù)在CatSniffer上進行測試，繼續(xù)并將Sniffle固件加載到CC1352和我們的自定義廣告固件(鏈接在代碼部分)加載到RP2040。為了進行測試，我們在手機上使用了nRF Connect來檢查我們是否能看到我們正在發(fā)送的數(shù)據(jù)包。在掃描BLE設(shè)備后，我們可以看到一個列有“CatSniffer”的設(shè)備，它的數(shù)據(jù)包與我們在代碼中定義的相同。

下一個步驟

處理原本不屬于我們的代碼會帶來一些挑戰(zhàn)，尤其是對其進行調(diào)整和理解其底層邏輯。然而，這個過程極大地增強了我們對BLE通信如何工作的理解，特別是當(dāng)涉及到分組構(gòu)建和傳輸時。

我們的代碼中仍然缺少很多東西。下一步是重點實現(xiàn)掃描響應(yīng)功能并建立可靠的設(shè)備連接。這將允許對BLE通信過程進行更全面的測試和更好的控制，最終更接近于實現(xiàn)項目的原始目標(biāo)。

本文編譯自hackster.io