翻譯部分內容，備忘加鞏固，好多不清楚或錯誤的地方，望高手指正。
extending the work of Thorsten Schröder and Max Moserof the KeyKeriki v2.0 project. Similar to Bluetooth, the protocols of the Nordic VLSI nRF24L01+ chip are designed such that the MAC address of a network participant doubles as a SYNC field, making promiscuous sniffing difficult both by configuration and by hardware. In this short article, I present a nifty technique for promiscuously sniffing such radios by (1) limiting the MAC address to 2 bytes, (2) disabling checksums, (3) setting the MAC to be the same as the preamble, and (4) sorting received noise for valid MAC addresses which may later be sniffed explicitly. This method results in a rather high false-positive rate for packet reception as well as a terribly high drop rate, but once a few packets of the same address have been captured, that address can be sniffed directly with normal error rates.根據已有資料，我發現了一種針對微軟無線鍵盤（ Microsoft Comfort Desktop 5000）或者類似的2.4GHz無線鍵盤的混雜嗅探方式，這個問題在CanSecWest會議上 Thorsten Schröder 和 Max Moser有相關文檔介紹，以及利用該漏洞的 KeyKeriki v2.0 項目。而我這里使用了一個無線電和一個低端微處理器，不同于該項目的兩個無線電和一個高端微處理器，我的硬件是一個為Next Hope設計制作的會議徽章 ， 使用的 GoodFET 固件 。Part 1: or, Why sniffing is hard. 無線電數據包一般都始于preamble, 然后是同步（SYNC）字段。在 SimpliciTI 協議中，同步字段是0xD391，因此無線數據包開頭應該是 {0xAA,0xD3,0xD91} 或者 {0x55,0xD3,0x91}。 0xAA 或者 0x55 是preamble，在數據包開頭是由0和1交替出現的，表明數據來了，然后是同步字段，確保接下來的數據對齊。在Nordic無線電中，沒有同步字段，取而代之的是MAC地址。所以 OpenBeacon 數據報將以 {0x55, 0x01, 0x02, 0x03, 0x02, 0x01} 開始，而 Turning Point Clicker的數據包將以 {0x55, 0x12, 0x34, 0x56}開始。如果SYNC/MAC的第一bit是0，preamble將是0x55，反之如果是1，preamble則是0xAA。Duang... 問題來了，芯片本身不允許MAC地址小于3個字節，因此人們一直認為必須要知道這么多字節的MAC地址才能用該芯片接收到數據。Moser 和 Schröder 使用 AMICCOM A7125 芯片解決了這個問題，這是一個低端的2FSK收發器，能夠dump出原始數據給ARM處理器，ARM有足夠時間采樣2Mbps的無線電信號，尋找preamble，找到后把剩下的bit位的信息填入寄存器，然后通過USB把他們dump到主機。通過這樣的操作，每一個潛在的MAC地址都將被找到。一旦地址是已知的，KeyKeriki把這個地址用第二個無線電（nRF24L+）開始監聽和注入數據。Michael Ossmann的項目Ubertooth （ 監聽藍牙）有個類似的解決方案。查閱該項目的文檔和 Ossmann's Shmoocon 2011年的視頻，你就知道為什么嗅探一個不知道SYNC的設備是如此困難。Part 2: or, Sniffing on the cheap.關于混雜監聽的一些訣竅，涉及到寄存器的不合法設定以及背景噪音的“期待”，可以查看 goodfet.nrf 客戶端的類AutoTuner()的代碼。首先，要嗅探的地址長度必須短到最短，手冊上說0x03地址的寄存器最低兩bit是負責地址寬度（長度）的，有效的長度值是3字節（01b），4字節（10b）和5字節（11b）。把這個地址設成00b是指2字節寬度，但是當禁用了校驗，結果大量包中出現背景噪音。(Setting this value to 00b gives a 2 byte match, but when checksums are disabled, this results in a deluge of false-positive packets that appear out of background noise.) 其次，有必要在SYNC字段出現之前開始接收，因為Nordic芯片丟棄接收數據包中的地址，只留下payload。通過地址是其最短長度的時候查看返回的噪音，很顯然，背景噪聲包括大量為0x00和0xFF的數據包以及和0xAA和將0x55的數據包，類似內部時鐘的反饋。那么如果地址是0x00AA或0x0055將發生什么？噪音將略先啟動無線電，然后同步到真正的preamble，留下SYNC字段作為payload的開始部分！preamble和SYNC不需要直接相鄰，相反，SYNC能夠遲于preamble好幾個字節，就是為了在嘈雜的無線環境中使用較長的preamble。舉個實際的例子，一個OpenBeacon數據包看起來像下圖那樣，其中SYNC字段是0x0102030201，因此在數據包的這個點之后都會被截斷，0xBEEF是會被返回給應用的所有數據，在那之前都會被切掉。 通過把地址設置成0x0055，禁止校驗，相同的數據包將按圖中下面部分解釋， preamble會被誤認為是SYNC，導致真正的SYNC值被返回作為是payload的開始。這樣一來我就不需要通過其他方法或者暴力方式獲得了SYNC/MAC字段的內容。這取決于preamble前的0x00，一般在背景噪音中而不是攻擊者的廣播。后面tmd沒看懂，This does depend upon the preamble being preceded by 0x00, which occurs often in background noise but is not broadcast by the attacker. So the odds of receiving a packet, while significantly worse than we'd like, are much better than the 1/2^16 you might assume. In experiments, one in twenty or so real packets arrive while a significant number of false positives also sneak in.MAC地址3-5個字節，無線電噪音是相當明顯的，可以通過手動校驗的方法輕松把噪音跟真正的數據包分離，確定是對的數據包或者簡單地統計一下每個地址，取出現最多的那個地址。這里是一個演示的記錄：http://pastebin.com/8CbxHzJ9。 我們會發現，其中0x0102030201是出現最多的MAC地址，這只是OpenBeacon標記測試的地址。不是依賴數據包的轉儲和排序，這個自動調諧的腳本標識網絡參與者以及打印出MAC地址。只要簡單地運行 'goodfet.nrf autotune | tee autotune.txt' 然后喝杯咖啡休息一會，等你回來的時候，你會發現如下記錄，標記了一個離 OpenBeacon 不遠的無線設備。 這段也tmd不知所云。As low data-rate devices require significantly more time than high-rate devices to identify, such devices will either require undue amounts of patience or a real KeyKeriki. In the case of a Nike+ foot pod, I'm resorting to using loud hip hop music to trigger the sensor, which is left inside a pair of headphones. My labmates are not amused, but it is a great way to reveal the radio settings when syringe probes aren't convenient.Part 3: or, Sniffing a keyboard effectively.確定信道和MAC地址是最大的問題，但是依然還有別的問題。首先數據包時加密的，并且加密必須被破解。不用害怕！我們不需要做任何花哨的數學公式來破解加密，因為密鑰在包中至少被包含了一次（這因果關系我tmd也不知道作者啥意思）。Moser 和 Schröder的幻燈片解釋了數據包頭是明文的，payload部分是MAC地址的XOR加密。 沒看懂Applying an XOR to the proper region yields decrypted packets such as the following. Because these contain USB HID events, key-up HID events quite often include long strings of 0x00 bytes. When XOR'ed with the key, those zeroes produce the key, so some packets contain the XOR key not just once, but twice! Finally, the USB HID events need to be deciphered to get key positions. Mapping a few of these yields meaningful text, with bytes duplicated in the case of retransmissions and omitted in the case of lost packets. 禁用校驗將允許丟棄的數據包轉換成字節錯誤的數量更小（你看我該咋翻譯？），而跟蹤序列號將防止重發的鍵被顯示兩次。不管怎樣，結果還是相當鼓舞人心的，%￥&46@%#%……89&^%$看圖吧，鳥語。Disabling checksums will allow the dropped packets to be converted to a smaller number of byte errors, while tracking sequence numbers will prevent retransmitted keys from being displayed twice. Regardless, the results are quite neighborly, as you can make out the sentence typed below in its packet capture. Part 4; or, Reproducing these results.All of the code for this article is available in the GoodFET Project'srepository, as part of GoodFETNRF.py and its goodfet.nrf client script. The hardware used was an NHBadge12, although an NHBadge12B or a GoodFET with the SparkFun nRF24L01+ Transceiver Module will work just as well.To identify a nearby Nordic transmitter, run 'goodfet.nrf autotune'. Keyboards can be identified and sniffed with 'goodfet.nrf sniffmskb', while a known keyboard can be sniffed and decoded by providing its address as an argument, 'goodfet.nrf sniffmskb aa,c10ac074cd,17,09'. The channel--0x17 in this case--will change for collision avoidance, but channel hopping is slow and resets to the same starting channel. Identification of the broadcast channel is faster when the receiver is not plugged in, as that causes the keyboard to continuously rebroadcast a keypress for a few seconds.All code presently in the repository will be refactored and rewritten, so revert to revision 885 or check the documentation for any changes.ConclusionsContrary to prior belief, the nRF24L01+ can be used to promiscuously sniff compatible radios, allowing for keyboard sniffing without special hardware. It's also handy for figuring out the lower levels of the otherwise-documented ANT+ protocol, and for reverse engineering vendor-proprietary protocols such as Nike+.Additionally, it should be emphasized that the security of the Microsoft keyboards in this family is irreparably broken, and has been since Moser and Schröder published the vulnerability at CanSecWest. (It's a shame, because the keyboards are quite nicer than most Bluetooth ones, both in pairing delay and in battery life.) Do not purchase these things unless you want to broadcast every keystroke.While I have not yet written code for injecting new keystrokes, such code does exist in the KeyKeriki repository and would not be difficult to port. Perhaps it would be fun to build stand-alone firmware for the Next Hope badge that sniffs for keyboards, broadcasting Rick Astley lyrics into any that it finds?Please, for the love of the gods, use proper cryptography and double-check the security your designs. Then triple-check them. There is no excuse for such vulnerable garbage as these keyboards to be sold with neither decent security nor a word of warning.
|