InGuardians作為一家從事信息安全研究和咨詢的公司，自創立以來不但關注著web應用的滲透測試，網絡取證，嵌入式設備等領域也致力于無線網絡的評估方法上面的研究。在期間無線網絡評估也從起初單一的企業無線網絡部署慢慢地發展到開始涉及一些通用或自定義的藍牙，zigbee等網絡的分析。
InGuardians和其它一些企業，安全機構一樣會一直通過參考其它人發表的一些研究結果來擴充自己的知識。在利用別人發表的內容來提高自我水平的同時，他們也從來沒有在分享自己的一些經驗和研究結果上有過止步。如果你有關注BH，DC等會議你們應該有在這些會議上看到過他們的身影。
在尋求充分理解無線電審計背后的技術過程當中，InGuardians意識到市面上缺乏一些一步一步指導人們如何分析無線電信號的文稿。其中最大的缺口出現在教會人們如何利用GRC（GNU Radio Companion）來對無線電信號進行徹底地分析，最終再將無線電信號轉換為更易于我們理解和分析的數據包。雖然我們沒有辦法將個別案例中的分析方法原樣地應用到任意的項目當中，但是了解一些分析案例中各個步驟背后的種種不但可以幫助人們開發出更好的工具，在某些時候也可以幫助人們完成其它類似的研究。作為工具 GRC Bit Converter3(GRC Bit Converter: https://github.com/cutaway/grc_bit_converter ) 就是個很好的例子。它可以很好地幫助安全研究人員和無線電愛好者完成他們的項目和工作。
市面上有很多關于如何購買適合自己的無線電設備，如何安裝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的大門。
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
一旦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中看到我們所預期的結果。
使用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,來進行反向的數據反轉。
在完成了解調之后就需要我們從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所呈現的樣子
在我們運行圖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)了。這兩位被稱為數據錯誤，循環冗余檢查通常用于檢查數據的正確性和完整性。
當我們手頭上的信息十分的有限時，手工或通過腳本對數據進行解析有時候可能會是我們唯一的出路。但是這個案例當中我們擁有足夠的信息來運用相關的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所示）。
在這個例子中的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來實現我們所需要的通訊。
通過適當的設備和軟件我們可以輕易的捕捉到我們想捕捉的信號。然而理解如何使用GRC來對捕捉到的信號進行操作會稍微困難一些。這使得對信號進行解調并轉換成數據包變得更加復雜。但幸運的是，我們可以通過互聯網閱讀許多人分享的分析案例。通過理解這些案例可以使得我們的分析過程變得輕松許多。