翻譯部分內(nèi)容，備忘加鞏固，好多不清楚或錯(cuò)誤的地方，望高手指正。
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.根據(jù)已有資料，我發(fā)現(xiàn)了一種針對(duì)微軟無線鍵盤（ Microsoft Comfort Desktop 5000）或者類似的2.4GHz無線鍵盤的混雜嗅探方式，這個(gè)問題在CanSecWest會(huì)議上 Thorsten Schröder 和 Max Moser有相關(guān)文檔介紹，以及利用該漏洞的 KeyKeriki v2.0 項(xiàng)目。而我這里使用了一個(gè)無線電和一個(gè)低端微處理器，不同于該項(xiàng)目的兩個(gè)無線電和一個(gè)高端微處理器，我的硬件是一個(gè)為Next Hope設(shè)計(jì)制作的會(huì)議徽章 ， 使用的 GoodFET 固件 。Part 1: or, Why sniffing is hard. 無線電數(shù)據(jù)包一般都始于preamble, 然后是同步（SYNC）字段。在 SimpliciTI 協(xié)議中，同步字段是0xD391，因此無線數(shù)據(jù)包開頭應(yīng)該是 {0xAA,0xD3,0xD91} 或者 {0x55,0xD3,0x91}。 0xAA 或者 0x55 是preamble，在數(shù)據(jù)包開頭是由0和1交替出現(xiàn)的，表明數(shù)據(jù)來了，然后是同步字段，確保接下來的數(shù)據(jù)對(duì)齊。在Nordic無線電中，沒有同步字段，取而代之的是MAC地址。所以 OpenBeacon 數(shù)據(jù)報(bào)將以 {0x55, 0x01, 0x02, 0x03, 0x02, 0x01} 開始，而 Turning Point Clicker的數(shù)據(jù)包將以 {0x55, 0x12, 0x34, 0x56}開始。如果SYNC/MAC的第一bit是0，preamble將是0x55，反之如果是1，preamble則是0xAA。Duang... 問題來了，芯片本身不允許MAC地址小于3個(gè)字節(jié)，因此人們一直認(rèn)為必須要知道這么多字節(jié)的MAC地址才能用該芯片接收到數(shù)據(jù)。Moser 和 Schröder 使用 AMICCOM A7125 芯片解決了這個(gè)問題，這是一個(gè)低端的2FSK收發(fā)器，能夠dump出原始數(shù)據(jù)給ARM處理器，ARM有足夠時(shí)間采樣2Mbps的無線電信號(hào)，尋找preamble，找到后把剩下的bit位的信息填入寄存器，然后通過USB把他們dump到主機(jī)。通過這樣的操作，每一個(gè)潛在的MAC地址都將被找到。一旦地址是已知的，KeyKeriki把這個(gè)地址用第二個(gè)無線電（nRF24L+）開始監(jiān)聽和注入數(shù)據(jù)。Michael Ossmann的項(xiàng)目Ubertooth （ 監(jiān)聽藍(lán)牙）有個(gè)類似的解決方案。查閱該項(xiàng)目的文檔和 Ossmann's Shmoocon 2011年的視頻，你就知道為什么嗅探一個(gè)不知道SYNC的設(shè)備是如此困難。Part 2: or, Sniffing on the cheap.關(guān)于混雜監(jiān)聽的一些訣竅，涉及到寄存器的不合法設(shè)定以及背景噪音的“期待”，可以查看 goodfet.nrf 客戶端的類AutoTuner()的代碼。首先，要嗅探的地址長(zhǎng)度必須短到最短，手冊(cè)上說0x03地址的寄存器最低兩bit是負(fù)責(zé)地址寬度（長(zhǎng)度）的，有效的長(zhǎng)度值是3字節(jié)（01b），4字節(jié)（10b）和5字節(jié)（11b）。把這個(gè)地址設(shè)成00b是指2字節(jié)寬度，但是當(dāng)禁用了校驗(yàn)，結(jié)果大量包中出現(xiàn)背景噪音。(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字段出現(xiàn)之前開始接收，因?yàn)镹ordic芯片丟棄接收數(shù)據(jù)包中的地址，只留下payload。通過地址是其最短長(zhǎng)度的時(shí)候查看返回的噪音，很顯然，背景噪聲包括大量為0x00和0xFF的數(shù)據(jù)包以及和0xAA和將0x55的數(shù)據(jù)包，類似內(nèi)部時(shí)鐘的反饋。那么如果地址是0x00AA或0x0055將發(fā)生什么？噪音將略先啟動(dòng)無線電，然后同步到真正的preamble，留下SYNC字段作為payload的開始部分！preamble和SYNC不需要直接相鄰，相反，SYNC能夠遲于preamble好幾個(gè)字節(jié)，就是為了在嘈雜的無線環(huán)境中使用較長(zhǎng)的preamble。舉個(gè)實(shí)際的例子，一個(gè)OpenBeacon數(shù)據(jù)包看起來像下圖那樣，其中SYNC字段是0x0102030201，因此在數(shù)據(jù)包的這個(gè)點(diǎn)之后都會(huì)被截?cái)啵?xBEEF是會(huì)被返回給應(yīng)用的所有數(shù)據(jù)，在那之前都會(huì)被切掉。 通過把地址設(shè)置成0x0055，禁止校驗(yàn)，相同的數(shù)據(jù)包將按圖中下面部分解釋， preamble會(huì)被誤認(rèn)為是SYNC，導(dǎo)致真正的SYNC值被返回作為是payload的開始。這樣一來我就不需要通過其他方法或者暴力方式獲得了SYNC/MAC字段的內(nèi)容。這取決于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個(gè)字節(jié)，無線電噪音是相當(dāng)明顯的，可以通過手動(dòng)校驗(yàn)的方法輕松把噪音跟真正的數(shù)據(jù)包分離，確定是對(duì)的數(shù)據(jù)包或者簡(jiǎn)單地統(tǒng)計(jì)一下每個(gè)地址，取出現(xiàn)最多的那個(gè)地址。這里是一個(gè)演示的記錄：http://pastebin.com/8CbxHzJ9。 我們會(huì)發(fā)現(xiàn)，其中0x0102030201是出現(xiàn)最多的MAC地址，這只是OpenBeacon標(biāo)記測(cè)試的地址。不是依賴數(shù)據(jù)包的轉(zhuǎn)儲(chǔ)和排序，這個(gè)自動(dòng)調(diào)諧的腳本標(biāo)識(shí)網(wǎng)絡(luò)參與者以及打印出MAC地址。只要簡(jiǎn)單地運(yùn)行 'goodfet.nrf autotune | tee autotune.txt' 然后喝杯咖啡休息一會(huì)，等你回來的時(shí)候，你會(huì)發(fā)現(xiàn)如下記錄，標(biāo)記了一個(gè)離 OpenBeacon 不遠(yuǎn)的無線設(shè)備。 這段也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地址是最大的問題，但是依然還有別的問題。首先數(shù)據(jù)包時(shí)加密的，并且加密必須被破解。不用害怕！我們不需要做任何花哨的數(shù)學(xué)公式來破解加密，因?yàn)槊荑€在包中至少被包含了一次（這因果關(guān)系我tmd也不知道作者啥意思）。Moser 和 Schröder的幻燈片解釋了數(shù)據(jù)包頭是明文的，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. 禁用校驗(yàn)將允許丟棄的數(shù)據(jù)包轉(zhuǎn)換成字節(jié)錯(cuò)誤的數(shù)量更小（你看我該咋翻譯？），而跟蹤序列號(hào)將防止重發(fā)的鍵被顯示兩次。不管怎樣，結(jié)果還是相當(dāng)鼓舞人心的，%￥&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.
|