開始

這個(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)于有安全問題的門鎖的信息，我們想買一堆然后全部測(cè)試一下。

在研究了很多門鎖后，我們發(fā)現(xiàn)大多數(shù)門鎖只會(huì)使用BLE進(jìn)行初始配對(duì)。之后，大多數(shù)人會(huì)切換到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)目。最近他們?cè)黾恿藢?duì)廣告的支持。這激起了我們的興趣，因?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代碼相對(duì)簡(jiǎn)單。首先，為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ù)還檢查模式中的錯(cuò)誤。我們不斷使用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)行測(cè)試，正如Python腳本一樣一步一步地復(fù)制創(chuàng)建消息的整個(gè)過程。許多部分都是硬編碼的，以避免目前代碼的復(fù)雜性，因?yàn)樗且粋€(gè)測(cè)試。

定義

首先，我們添加了一些必要的庫，創(chuàng)建了要發(fā)送的數(shù)據(jù)和數(shù)組的大小變量，最后定義了advertise和send函數(shù)。我們還從存儲(chǔ)庫中為一些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ā)送給它的廣告。由于這不起作用，我們嘗試了一些更簡(jiǎn)單的方法，直接發(fā)送sniffle會(huì)發(fā)送的base64編碼的數(shù)據(jù)幀。這也沒有奏效。

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

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

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

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

Bus Pirate

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

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

在這之后，希望又回來了!因?yàn)槲覀兛梢钥吹綆系谋忍?。我們嘗試了同樣的事情，但在發(fā)射臺(tái)CC1352P7-4上使用Sniffle，但這揭示了另一個(gè)問題。

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

示波器

首先，我們?cè)谂渲檬静ㄆ魃系挠|發(fā)器以開始測(cè)量時(shí)遇到了一些麻煩，這是新手(不是新手)的問題。但是，一旦我們有了正確的配置，就只需要將Tx和Rx引腳連接到探針，并運(yùn)行Python腳本來查看發(fā)送和接收的數(shù)據(jù)。

示波器連接

首先，直接使用Launchpad，使用Python腳本和來自CC1352的響應(yīng)驗(yàn)證發(fā)送的消息。發(fā)射臺(tái)有一個(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é)的知識(shí)做出一些改變。主要是在命令的制作過程中出現(xiàn)了許多小錯(cuò)誤。此時(shí)，我們能做的最好的事情就是直觀地比較來自代碼和Python腳本的消息。

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

下一個(gè)步驟

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

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

本文編譯自hackster.io