0x00 介紹

---

InGuardians作為一家從事資訊保安研究和諮詢的公司，自創立以來不但關注著web應用的滲透測試，網路取證，嵌入式裝置等領域也致力於無線網路的評估方法上面的研究。在期間無線網路評估也從起初單一的企業無線網路部署慢慢地發展到開始涉及一些通用或自定義的藍芽，zigbee等網路的分析。

InGuardians和其它一些企業，安全機構一樣會一直透過參考其它人發表的一些研究結果來擴充自己的知識。在利用別人發表的內容來提高自我水平的同時，他們也從來沒有在分享自己的一些經驗和研究結果上有過止步。如果你有關注BH，DC等會議你們應該有在這些會議上看到過他們的身影。

在尋求充分理解無線電審計背後的技術過程當中，InGuardians意識到市面上缺乏一些一步一步指導人們如何分析無線電訊號的文稿。其中最大的缺口出現在教會人們如何利用GRC（GNU Radio Companion）來對無線電訊號進行徹底地分析，最終再將無線電訊號轉換為更易於我們理解和分析的資料包。雖然我們沒有辦法將個別案例中的分析方法原樣地應用到任意的專案當中，但是瞭解一些分析案例中各個步驟背後的種種不但可以幫助人們開發出更好的工具，在某些時候也可以幫助人們完成其它類似的研究。作為工具 GRC Bit Converter3(GRC Bit Converter: https://github.com/cutaway/grc_bit_converter ) 就是個很好的例子。它可以很好地幫助安全研究人員和無線電愛好者完成他們的專案和工作。

0x01 安裝與配置

---

市面上有很多關於如何購買適合自己的無線電裝置，如何安裝GRC和如何安裝頻譜分析應用的教程。所以再重複敘述那些東西應該是沒有任何意義的。在這裡只給出這些硬體和軟體的相關連結。

. 硬體資源

USRP . http://home.ettus.com/

HackRF Jawbreaker . https://github.com/mossmann/hackrf/wiki (.1)

bladeRF - http://nuand.com/

RTL-SDR . http://en.wikipedia.org/wiki/List_of_software-defined_radios

CC1111EMK - http://www.ti.com/tool/cc1111emk868-915

Ubertooth . http://ubertooth.sourceforge.net/

Atmel RZUSBstick - http://www.atmel.com/tools/rzusbstick.aspx

軟體資源

GNU Radio Companion –

http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioCompanion

SDR# - http://sdrsharp.com/

GQRX – http://gqrx.dk/

Baudline - http://www.baudline.com/

RFcat – http://code.google.com/p/rfcat/

Ubertooth - http://ubertooth.sourceforge.net/

KillerBee - http://code.google.com/p/killerbee/

透過學習並使用GRC(GNU Radio Companion)你可以很輕易地敲開通往無線電世界的大門。GRC十分易用的圖形操作介面可以讓你很輕易地實現一些複雜的無線電功能。GRC中的許多特定操作都重度依賴於那些可配置的模組（block）。透過對不同的block進行連線和配置，最終就可以實現我們想要的功能。市面上有大量的教程教授人們如何使用GRC和它的主要模組來捕捉並顯示我們所需要的無線電訊號。瞭解並探索如何入門GRC對於本文的讀者來說應該是不錯的鍛鍊機會。InGuardians建議大家可以試著用一下我們在上面所列出的那些軟體。使用SDR#，GQRX等軟體可以幫助讀者對無線電傳輸的視覺化和調整有一個初步的瞭解。這也許可以幫助讀者更快地進入GRC的大門。

0x02 管理DC Spike

---

HackRF,BladeRF或其它一些RTL-SDR的使用者在使用一些頻譜分析工具進行調頻時會看到一個很大的尖峰（Spike）。這個尖峰就被稱做DC Spike。(圖2中心處的尖峰)

圖2 DC Spike

當一些使用者第一次看到這些Spike時可能會擔心自己的裝置是否存在缺陷，在這裡可以告訴大家這和你選購的硬體或該硬體所使用的韌體並沒有任何的關係，只要你使用無線電DC Spike就會與你同在。關於DC Spike，在這https://github.com/mossmann/hackrf/wiki/FAQ你可以看到一些很好的解釋。

正如HackRF FAQ當中所描繪的那樣，在多數情況下我們是不需要考慮DCSpike的。但是，你如果想要成功地解調你所捕獲的訊號或捕捉被髮射的訊號你就需要盡力去保證這個訊號是乾淨的。因此，為了避免受到DC Spike的干擾我們可以使用“DC Offset”來解決此類的問題。我們需要做的就是透過正確的GRC模組將接收頻率調至無線電的傳輸頻寬之外。唯一需要注意的是，我們需要選擇一個合理的offset將DC Spike移動到傳輸的訊號之外，但同時要保證不要將offset設定過大導致我們不得不使用我們本不需要的頻寬。

通常確定如何去配置DC Offset的方法有兩種。第一種方法，需要我們對產品手冊中的資料進行分析來確定無線電裝置的效能。在手冊當中你通常可以找到關於通道間隔的標註。簡單的來說，通道間隔就是從中心頻率到兩個不同傳輸區域之間的距離。藉助這個資訊我們就可以很好的調整我們的DC Spike。通道間隔和傳輸的大小沒有必然的聯絡。例如,在觀察wifi的訊號傳輸時我們會發現，Wifi雖然有14條通道，但是在無線電介面卡的傳輸當中會有6條通道被吞噬。除此之外，透過頻譜分析工具對傳輸頻寬進行觀察可以幫助我們調節DCOffset，這也是我們之前提到的兩種方法中的第二個。圖3就是將通道間隔應用到無線網格網路中實現FHSS很好的一個例子。在GRC FFT當中使用“PeakHold”選項，就可以圖中看到DC Spike會出現的位置。

圖3

無線電裝置會透過設定通道間隔來防止通道之間的相互干擾。預設的通道間隔也會因裝置和製造商而異。但幸運的是，因為這些值都是預設的，所以通常我們可以在製造商所提供的文件中找到這些值。如果你無法從產品附屬的手冊或產品供應商那裡獲取這些值，你也許可以在論壇,產品原始碼或一些專利申請中找到你想了解的引數的值。

圖4 DC Spike出現在傳輸訊號內

如果你找到的文件不全或需要驗證通道間隔的值，圖形化分析可以幫助確定一個粗略的通道間隔。圖4就是透過圖形化介面來目測通道間隔很好的例子。其中的藍色尖峰即為DC Spike，綠色波峰為傳輸的訊號，而用紅色標註出來的距離則為頻道的大小。其中出現的個傳輸訊號的邊緣之間間隔就正好是通道間隔。

GRC當中通常會使用變數模組(variable blocks)來對一些值進行修改。在下面的例子當中我們將使用變數模組來定義通道間隔的值。一旦channel_spacing設定完畢我們就可以在其他模組當中使用我們所設定的值。為了使用通道間隔來控制DC Spike，我們將定義另外一個變數模組freq_offset並讓其值等於(channel_spacing / 2) * (channel_spacing * .1)。藉助這個公式我們就可以把DC Spike推移到訊號的邊緣部分。如果我們進一步將此處的1調整到10就可以將DC Spike推移到傳輸訊號之外了（如圖5所示）。圖6中將告訴大家應該如何去設定相關的osmocom Source。

圖5 freq_offset的相關配置

圖6 設定相對應的osmocom Source模組

一旦我們完成了這些模組的配置後，我們將會所對應的區域中看到公式計算厚的結果呈現在其中。被計算後的的結果如圖7所示。

圖7 GRC捕獲配置圖

最後在圖8中可以看到我們已經成功地將DC Spike推移到了傳輸之外。

圖8

0x03 傳輸訊號的分離

---

一旦DC Spike的問題得到解決，我們就可以在不受它干擾的情況下對訊號進行處理了。接下來需要我們去做的就是訊號的分離。GRC當中存在兩個模組可以幫助我們對訊號進行分離。它們分別是Low Pass Filter（LPF）和FrequencyXlating FIR Filter（FXFF）模組。從功能上來將兩者能為我們提供的幾乎是相同的。但是相對於LPF，FXFF為我們提供了更多的選項可以讓我們在分離或對傳輸的訊號進行操作時有一個更好的開始。在這裡我們先對LPF做一個簡單的介紹。

在LPF的配置當中，第一個可調節選項是Decimation。透過對該值進行調節，我們可以修改即將輸入進來的訊號的取樣率（Sampling Rate）。你會在眾多FM解調的GRC例子當中看到Decimation。這個引數的取值通常會和圖5中的freq_offset一樣由計算公式來完成。雖然使用Decimation在有些訊號解調中是需要使用到的，但是在我們這次的例子當中我們不會用到它。所以我們可以讓它保持在預設的值“1”,這樣就不會對我們的取樣率（Sample Rate）有任何的影響。這種做法也能同時保證我們不會去打破取樣定理中提到的每一個正弦週期需要進行兩次取樣的說法。

下一個需要我們去設定的是“Window”這個選項。這個選項的預設值是“Hamming”。但是在Balint Seeber的“Blind signal analysis with GNU Radio”演講當中他曾經提到我們應該將Window的值設定成“BlackMan”，因為這相對於另外一個來說是更優秀的演算法。

在設定完Decimation和Window引數之後，還需要我們設定SampleRate，Cutoff Frequency和Transition Width來完成我們的訊號分離。Sample Rate的設定很簡單，它是輸入取樣率並應當和前面所提到的一樣被預設的設定成“samp_rate”。這裡需要注意的是即使我們使用decimation修改了輸出的取樣率，Sample Rate應當依舊設定成我們的輸入取樣率。Cutoff Frequency為我們之前提到的圖4中所顯示的頻道大小。然而頻道間隔的設定也應當和我們在之前所提到的一樣，應該有同名的變數模組進行設定。

其中最為麻煩的可能就屬Transition Width的設定了。在設定這個值之前我們需要做一些測試來給它賦予一個正確的值。更多的經驗和調查將會對於你在起初如何設定這個值有很大的幫助。當然這也會取決於中心頻率，頻寬，無線電裝置型別等因素的影響。有些時候傳輸的訊號不會恰好地集中在中心頻率。它時常都有可能受到天氣，Power，甚至是其它訊號的干擾。總而言之，該值的不合理設定可能會導致多餘訊號的產生，又或者是訊號的丟失。根據我們的經驗，我們會將該值設定為頻道間隔（Channel Spacing）的４０％～５０％之間的值。在後面我們也會看到這個設定可以為我們帶來最好的結果。在圖9中我們將使用下述的引數來對LPF進行配置。

Frequency Offset 120,000

Channel Spacing 200,000

Channel Transition 80,000

Window BlackMan

當我們用上述的引數觀察我們分離出來的訊號時，我們發現我們的訊號並沒有位於FFT Plot的中心處。然而為了正確地解調訊號我們需要把訊號移動到FFT Plot的中心處。這裡就需要我們使用Frequency Xlating FIRFilter（FXFF）來實現這個操作。

FXFF和我們前面所提到的那樣，和LPF有著許多相似之處。所以在這裡我們可以將Decimation和Sample Rate設定成與之前在LPF中同樣的值。在FXFF當中還有一個叫Center Frequency的變數。這個變數和DC_Offset一樣通常用來矯正訊號並將其調整到中心處。如果在設定過程當中我們沒有使用DC_Offset那麼該值應當設定成０，如果不是它的值應當設定成freq_offset。最後一個需要我們去設定的是Taps變數。對於這個變數的設定，我們使用Dragorn在他的部落格Playing with the HackRF – Keyfobs中所提到的公式：“ firdes.low_pass(1, samp_rate,channel_spacing, channel_trans, firdes.WIN_BLACKMAN, 6.76) ”。（詳見圖10）

對於FXFF進行了上述的設定之後我們就可以在圖11中看到我們所預期的結果。

0x04 實際調解

---

使用LPF和FXFF對訊號進行分離可以幫助我們更有效的對訊號進行解調。Michael Ossmann在他的無線電培訓課程當中講述了從這個點開始應當如何進行解調。在他的課程的當中他不但講述了相關的概念和數學知識，也告訴了我們為了解調不同的ASK（amplitude-shift key）和FSK(frequency-shifykey)所需要的模組。解調ASK我們可以使用“Complex to Mag” 或“Complex to Mag ^ 2”。然而解調FSK（尤其是2FSK和GFSK）我們可以使用“Quadrature Demod”。

在這個例子當中我們需要解調的是透過GFSK傳輸的訊號。在此之前的圖片當中我們所看到的一些結果都是Texas Instrument (TI) Chronos Watch和IChronos black dongle之間的資料傳輸結果。在TI的站點上我們可以找到和這個dongle相關的一些資料，甚至是它的原始碼。最終我們在這個產品的原始碼中看到了我們想了解的資訊（Mudulation=（1）GFSK），如圖12所示。

現在我們已經知道了Modulation type，那麼剩下的就是需要知道Deviation了。這個值我們可以從原始碼中獲取（可以看到在圖12 當中 Deviation=32Khz）。

當我們對在需要解調GFSK索要用到的“Quadrature Demod”模組進行配置時，我們會看到的預設的Gain變數將透過這樣的公式進行計算：samp_rate/(2math.pifsk_deviation_hz/8.0)，這意味著我們還需要新增一個變數模組fsk_deviation_hz 來協助Gain的計算。這個fsk_deviation_hz就正好是我們之前提到的需要我們知道並且設定的第二個變數Deviation（如圖13所示）。這也是為什麼我們會說除了Modulation type之外我們還需要知道Deviation的值。

在圖13當中我們可以看到模組Quadrature Demod處理結果最終會輸出到File Sink模組當中。這是因為從這一步開始我們需要將解調過後的結果放到其它的工具裡來完成我們之後的步驟。在這裡需要提到的一點是，關於檔案的命名和輸出的位置。有時候我們需要在很短的時間內將很大的檔案寫入到磁碟。如果你是Linux使用者，我們建議你將檔案寫入到“/dev/shim”，這樣做會比直接寫入到硬碟會快一些。關於檔案命名你可以參考將一些可能會用到和重要的資訊放到檔名稱當中，方便日後的分析和處理工作。如，

“/tmp/blog_demod_1e6_905.99e6_gfsk_76721_hackrf.cfile.”

在完成了這些設定之後，執行圖13中的GRC會將調節後的訊號儲存到我們預設定的檔案當中。將此檔案匯入到頻譜分析工具Baudline（Baudline:http://www.baudline.com/）中，就可以繼續我們下面的工作了。如果你對此處的一些細節有疑問，可以在Dragorn釋出的Keyfob blog post中看到一些更詳細的解釋（評論中有很多亮點）。圖14所展示的是，我們將檔案匯入到Baudline之後所呈現的FFT和波形圖。

透過使用Baudline我們可以在把無線電訊號轉換成資料包之前對我們得到的結果進行分析和判斷。現在我們將上圖中的波形圖進行放大來進一步觀察。（如圖15 所示）

透過上圖對我們解調過後的訊號進行觀察，我們可以發現一些很有價值的資訊。首先我們可以從圖中，看到我們獲取的訊號並沒有我們預期的那麼幹淨。其次，波形圖整體偏下，且並沒有穿過中心軸（X-axis）.然而這些對於我們將無線電訊號轉換成0和1是十分的不利的。為了實現訊號的轉換我們需要在Quadrature Demodulation和File Sink blocks之間加入另外一個LPF。就像在之前所提到的那樣，這個模組需要我們配置它的“Cutoff Freq”和“Transition Width”變數。然而問題是，現在還並沒有什麼好的文件能告訴我們該如何去設定這個LPF當中的這兩個變數。這些變數的取值一般可能會受到頻率，Modulation和其它一些配置的影響。根據經驗，我們通常會從100,000開始設定“Cutoff Freq”並將“Transition Width”的設定為它一半的值。透過重複調節這些引數並將輸出檔案匯入到Baudline進行觀察，再經過幾輪甚至是更多次的除錯之後我們將會在Baudline當中看到看上去更像是資料的波形圖。圖16中的波形圖，就是我們將“Cutoff Freq”設定成80,000，“Transition Width”設定成50,000後的結果。

現在我們可以看到我們的訊號看上去好了很多。但是波形和中心軸的問題依然沒有得到解決。解決這個問題，只需要我們在LPF和File Sink當中再加入一個Add Const模組來對waveform進行整體上移。關於如何設定AddConst的值，你可以參考之前LPF的調節方式，對其值進行逐步增加，直到出現如圖17所示的畫面（在這裡我們將contast設定為6）。

瞭解如何在不丟失資料的情況下對wave pattern進行操作在我們分析其它的訊號時也十分的重要。舉個例子來說，如果廠商的文件中有提到資料是倒置之後進行傳送的，那麼我們就可以透過設定contast值為-1,來進行反向的資料反轉。

0x05 位計數

---

在完成了解調之後就需要我們從wave中檢測出所有的0和1.在GRC中我們可以使用“Clock Recovery MM”和“Binary Slicer”來實現它。其中的“Clock Recovery MM”負責從wave中找出高位和地位，再由“Binary Slicer”負責將它們轉換成1和0。首先，我們需要配置“Clock Recovery MM”模組。在開啟“Clock Recovery MM”的配置介面後（如圖18所示）你可能會被這些多的有點讓人難受的變數給嚇到。但是實際上其中的“Gain Omega,”“Mu,” “Gain Mu,” ， “Omega Relative Limit”等變數在一般情況下是不需要我們去重新設定的。所以只要讓它們保持預設的值就可以了。 所以在這裡唯一需要我們去設定的是，“Omega”變數。在“Omega”的預設值當中我們可以看到，這樣的設定：samp_per_sym*(1+0.0)。這意味著我們需要和之前一樣新增一個變數模組samp_per_sym來幫助“Clock Recovery MM”計算每幀抽樣次數(Samples Per Symbol)。

這裡的samp_per_sym可以透過公式“int(samp_rate / data_rate)”進行計算（如圖19所示）。samp_rate對我們來說是已知的，但是data_rate呢？這個值我們可以從圖12中找到。所以為了計算出samp_per_sym我們還需要再新增一個變數模組“data_rate”，並將其值設定為圖12中所顯示的76721.191。

最終我們將配好的模組接入到我們之前做好的GRC當中（從圖20中可以看到原始的File Sink處於Disabled狀態）就應該是圖20所呈現的樣子

0x06 分析解調後的資料

---

在我們執行圖20所展現的GRC之後我們會得到一個檔案。透過Linux的xxd或任何平臺上的hex editor開啟我們所獲得檔案後你會看到如圖21的內容。

和我們預期的一樣我們可以在上圖當中看到滿滿的0和1。其中每8個bit可以視作是一個bit的資料。比如第一行的0101 0101 0101 0101 0101 0101 0101 0101就應該是0b1111111111111111或0xff。第三行的0101 01010101 0101 0001 0100 0100 0101就應該是0b1111111101101011或0xff6b。

但這些輸出可能是被傳輸的資料，同時也可能是任何一些可以被0和1所表示的其它一些東西。所以在這裡找出真正的資料將會是我們最大的挑戰。而且根據經驗，圖21中所展現的資料在我們看來和空氣中傳播的雜音（noise）有極高的相似度。在我們現在配置當中“Clock Recovery MM”會將所有的高位和低位扔給“Binary Slicer”進行處理。然而從現在的資料來看和實際資料對比，我們收到了太多的雜音（noise）。也就說我們現在的GRC配置還不具備辨別資料，雜音和來字其它無線電裝置的訊號的功能。也許我們可以透過定位資料包的頭bit來對實際產生的資料進行定位，但是GRC是否有這樣的模組可以實現我們想要的這個功能呢？

除此之外，我們在圖21中看到的資料還只是raw data。所以我們需要將這些資料轉換成byte再去討論如何辨別雜音或找到真實資料的問題。在這裡可以藉助InGuardians開發的GRC Bit Converter（https://github.com/cutaway/grc_bit_converter）將資料轉換成bytes（如圖22所示）。

使用預設設定執行grc_bit_converter.py，指令碼會將每2000個bits轉換成250個bytes並將其標記為一個資料包。這個流程會一直的重複，直到處理完所有的資料。其中的引數“Occurrences”會告訴我們有多少個包內的資料是一模一樣的。這個引數在我們找到資料包之後會有很大的用處。

在完成轉換之後我們需要確定傳輸的資料是如何被格式化的。這將有助於我們從這一坨資料當中找到它們。很多無線電裝置（並不是所有的，大多數都是這樣）在進行資料傳輸之前會傳送前導碼（preamble）和同步碼（SyncWord）。前導碼是一系列從高到低傳輸，如果從binary檔案來看的話它通常會是這樣“0b1010101010101010” 或這樣 “0xaaaa”。前導碼byte數取決與裝置本身或它的相關配置。由於沒有辦法確定前導碼的首位是什麼所以在我們對binary檔案進行過處理之後，你在解析過後的檔案當中看到的前導碼可能已經變成了“0101010101010101”或“0x5555”。 前導碼通常只負責告訴裝置接下來的資料是需要處理的。而真正告訴告訴裝置資料是從哪裡開始責由同步碼負責。在真實世界的無線電傳輸當中最常用的同步碼是“0xd391”。但是就和之前我們提到的前導碼問題一樣，在我們解析完之後“0xd391”很可能已經變成了其它的值。這時就需要我們使用ipython來對這個“0xd391”進行小小的處理了。在圖23中你們會看到可能會變成0xa722, 0x4e44或0x9c88出現在我們解析過後的檔案當中。

在有了一點線索之後，現在讓我們試著從grc_bit_converter.py的輸出結果中查詢我們的同步碼（0xd391）來定位我們的資料包(如圖24所示）。

這下我們好像終於找到了看上去像資料的東西。當然了，我們也可以透過再此回顧圖12中關於同步碼和前導碼的描述來確定我們的操作的準確性。在這裡我們可以看到我們之前所提到的前導碼是“\xaa\xaa\xaa\xaa”這個圖12中敘說的4 bytes完全吻合。然而我們的同步碼“\xd3\x91\xd3\x91”正好是32bits，也和原始碼中描述檢測32bits的同步碼的30位這一說相吻合。然後在原始碼中我們還看到同步碼後面的第一個byte表示整個資料包的長度。從上圖中我們可以看到同步碼後面的第一個byte正好是\x0f也就是15。從這裡開始數15個byte我們會發現還會剩下兩個byte，這兩個byte就是CyclicRedundancy Check (CRC)了。這兩位被稱為資料錯誤，迴圈冗餘檢查通常用於檢查資料的正確性和完整性。

0x07 對資料包進行標記

---

當我們手頭上的資訊十分的有限時，手工或透過指令碼對資料進行解析有時候可能會是我們唯一的出路。但是這個案例當中我們擁有足夠的資訊來運用相關的GRC模組進行資料包的標記。

這個動作可以使用GRC中的“Correlate Access Code”模組完成。“Correlate Access Code”模組需要我們配置其中的兩個變數來完成標記的操作。它們分別是“Access Code” 和 “Threshold”。其中的“Access Code”是我們需要定義的特徵向量來對需要我們進行標記的包進行表示。然而另外一個引數“Threshold”是特徵向量中可能會發生變化的部分的位數。在圖12當中我們看到在檢同步碼時，只會檢測32位當中的30位，這也就意味著其中的兩位可能是不一樣的。那麼我們這裡的“Threshold”的值就應該是2了。特徵向量“Access Code”和我們之前提到的一樣應當填入同步碼所對應的值（如圖25所示）。

和之前所提到的一樣，“Correlate Access Code”標記的是“Binary Slicer”處理後的資料。相關的位置關係將在圖26展示。

在完成檔案的輸出之後，我們可以像之前一樣用xxd或hex editor開啟輸出的檔案，並透過搜尋02或03來查詢我們標記的資料包。（如圖27所示）

就和前面使用grc_bit_converter.py對輸出的檔案進行分析一樣，這次我們同樣可以使用這個指令碼。這次需要我們在指令碼後面增加幾個引數來檢測“Correlate Access Code”模組標記過的資料包，並修改資料包的大小（如圖28所示）。

0x08 驗證

---

在這個例子中的GRC配置對於我們的TI Chronos Watch來說工作的還算不錯。但是文中提到的這些技術是否能同樣的應用到其它的或類似的無線電傳輸當中呢？為了驗證，我們會使用http://lists.gnu.org/archive/html/discussgnuradio/2014-04/msg00097.html中Jay為我們提供的使用DC Offset抓取的包進行驗證。

為了對這個包進行分析我們需要將原來的sources模組替換成“File Source”和“Throttle”模組。在這個案例當中capture rate是500,000，然而DC Offset是200,000 Hz。這個GFSK訊號在903 MHz進行傳輸（如圖29所示）。

從圖29可以看出，我們捕獲到的訊號靠近圖形的左邊緣。我們還可以發現頻道大小從902,950,000 到903,100,000將近為150,000 Hz。隨後再將FXFF中的頻道間隔設定成100,000，“Channel Transition”設定成50,000後我們可以可以在圖30中看到變化。

透過Jay的Post我們還可以知道其它的一些資訊。比如：

. Deviation 16,500

. data rate 19200

在使用這些值完成我們前面所做過的步驟後，我們又可以到可以將訊號匯入到baudline進行調整和分析的步驟了。經過多次的調整我們最終將“CutOffFreq”和“Transition Width”分別設定成了25,000 和 10,000。調整過後的波形圖如圖31所示。

從圖中我們知道波形圖還需要做一些上下的調整。在這裡我們需要將“Add Constant”設定成-6,來讓wave向下進行移動。在完成了wave的調整之後需要我們像之前那樣驗證同步碼，最終得知只會傳送一個"0xd391"。接住這個資訊我們就設定“Correlate Access Code”來對包進行標記。再將包的大小設定為80之後我們再次呼叫grc_bit_converter.py對結果進行觀察（如圖32所示）。

在完成了這些之後下一個步驟將會是對判定在這些資料傳輸中所使用的協議。從包的長度，CRC bytes，是否使用資料白話技術等入手將對我們分析這些資料會有很大的幫助。作為額外的資料捕獲我們還可以嘗試在接上電源，關閉電源，配對開始的情境下進行包的捕獲。捕獲的資料資訊越多,就越有利於我們瞭解它們是如何進行通訊的，是什麼中端在進行資料傳輸，我們應當如何去設定GRC來實現我們所需要的通訊。

0x09 結論

---

透過適當的裝置和軟體我們可以輕易的捕捉到我們想捕捉的訊號。然而理解如何使用GRC來對捕捉到的訊號進行操作會稍微困難一些。這使得對訊號進行解調並轉換成資料包變得更加複雜。但幸運的是，我們可以透過網際網路閱讀許多人分享的分析案例。透過理解這些案例可以使得我們的分析過程變得輕鬆許多。