榪欐剰鍛崇潃鎵弿涓涓畬鏁寸殑棰戠巼鑼冨洿闇瑕佸ぇ綰?5鍒嗛挓錛?and at least several keystrokes must be pressed while we're sniffing within the correct 10 second period. ) 鍦ㄤ粩緇嗗涔犱簡Travis鐨勭爺絀訛紝KeyKeriki 鐨勯」鐩紝浠ュ強嫻嬭瘯浜嗘垜鐨勯敭鐩橈紝鎴戜滑鍙互鍋氫竴浜涙敼榪涳細
鍦ㄦ鏌ヤ簡寰堝閿洏涔嬪悗錛屾垜鍙戠幇鎵鏈夌殑寰蔣閿洏鐨凪AC鍦板潃閮芥槸浠?xCD寮濮嬬殑錛屽洜姝ゆ垜浠殑preamble姘歌繙鏄?code style="line-height: 25.6000003814697px; box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 13.6000003814697px; padding: 0.2em 0px; margin: 0px; border-radius: 3px; background-color: rgba(0, 0, 0, 0.0392157);">0xAA (10101010) 錛?nbsp;after inspecting more keyboards, I found that all Microsoft keyboards begin with 0xCD as the MAC, which tells us that our preamble will always be 0xAA (10101010) 鍥犱負0xAA鍚庨潰姘歌繙璺熺殑鏄? (0xCD 浜岃繘鍒?11001101)浠ヤ繚鎸佹瘮鐗逛綅浜ゆ浛錛岃繖鏍峰張鍔犲揩浜嗕竴鍊嶇殑鎼滅儲閫熷害銆?/li>
Packet type 0x78 = keystroke, 0x38 = idle (key is held down)
Model type 0x06 = keyboard? This is the same HID code for a keyboard
HID code 0x05 = letter 'b' (described in section 7 here)
KeySweeper鐨勮В瀵嗛儴鍒嗕唬鐮?
// decrypt those keyboard packets! void decrypt(uint8_t* pkt) { // our encryption key is the 5-byte MAC address and // starts 4 bytes in (4-byte header is unencrypted) for (int i = 4; i < 15; i++) pkt[i] ^= mac >> (((i - 4) % 5) * 8) & 0xFF; }
]]>Promiscuity is the nRF24L01+'s Dutyhttp://www.tkk7.com/baicker/archive/2015/04/30/424312.html009009Thu, 30 Apr 2015 10:29:00 GMThttp://www.tkk7.com/baicker/archive/2015/04/30/424312.htmlhttp://www.tkk7.com/baicker/comments/424312.htmlhttp://www.tkk7.com/baicker/archive/2015/04/30/424312.html#Feedback0http://www.tkk7.com/baicker/comments/commentRss/424312.htmlhttp://www.tkk7.com/baicker/services/trackbacks/424312.html緲昏瘧閮ㄥ垎鍐呭錛屽蹇樺姞宸╁浐錛屽ソ澶氫笉娓呮鎴栭敊璇殑鍦版柟錛屾湜楂樻墜鎸囨銆?br />extending the work of Thorsten Schröder and Max Moser of 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.
Part 2: or, Sniffing on the cheap. 鍏充簬娣鋒潅鐩戝惉鐨勪竴浜涜瘈紿嶏紝娑夊強鍒板瘎瀛樺櫒鐨勪笉鍚堟硶璁懼畾浠ュ強鑳屾櫙鍣煶鐨?#8220;鏈熷緟”錛屽彲浠ユ煡鐪?nbsp;goodfet.nrf 瀹㈡埛绔殑綾籄utoTuner()鐨勪唬鐮併?/span>
棣栧厛錛岃鍡呮帰鐨勫湴鍧闀垮害蹇呴』鐭埌鏈鐭紝鎵嬪唽涓婅0x03鍦板潃鐨勫瘎瀛樺櫒鏈浣庝袱bit鏄礋璐e湴鍧瀹藉害錛堥暱搴︼級鐨勶紝鏈夋晥鐨勯暱搴﹀兼槸3瀛楄妭錛?1b錛夛紝4瀛楄妭錛?0b錛夊拰5瀛楄妭錛?1b錛夈傛妸榪欎釜鍦板潃璁炬垚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.)
榪欏彇鍐充簬preamble鍓嶇殑0x00錛屼竴鑸湪鑳屾櫙鍣煶涓屼笉鏄敾鍑昏呯殑騫挎挱銆傚悗闈md娌$湅鎳傦紝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鍦板潃銆傚彧瑕佺畝鍗曞湴榪愯 'goodfet.nrf autotune | tee autotune.txt' 鐒跺悗鍠濇澂鍜栧暋浼戞伅涓浼氾紝絳変綘鍥炴潵鐨勬椂鍊欙紝浣犱細鍙戠幇濡備笅璁板綍錛屾爣璁頒簡涓涓 OpenBeacon 涓嶈繙鐨勬棤綰胯澶囥?/span>
榪欐涔焧md涓嶇煡鎵浜戙侫s 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.
娌$湅鎳侫pplying 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. 紱佺敤鏍¢獙灝嗗厑璁鎬涪寮冪殑鏁版嵁鍖呰漿鎹㈡垚瀛楄妭閿欒鐨勬暟閲?/span>鏇村皬錛堜綘鐪嬫垜璇ュ拫緲昏瘧錛燂級錛岃岃窡韙簭鍒楀彿灝嗛槻姝㈤噸鍙戠殑閿鏄劇ず涓ゆ銆備笉綆℃庢牱錛岀粨鏋滆繕鏄浉褰撻紦鑸炰漢蹇冪殑錛?錕?amp;46@%#%……89&^%$鐪嬪浘鍚э紝楦熻銆侱isabling 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.
Conclusions
Contrary 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.
鍘熸枃錛?a target="_blank">Promiscuity is the nRF24L01+'s Duty
]]>OsmocomBB欏圭洰http://www.tkk7.com/baicker/archive/2013/11/13/406293.html009009Wed, 13 Nov 2013 08:27:00 GMThttp://www.tkk7.com/baicker/archive/2013/11/13/406293.htmlhttp://www.tkk7.com/baicker/comments/406293.htmlhttp://www.tkk7.com/baicker/archive/2013/11/13/406293.html#Feedback118http://www.tkk7.com/baicker/comments/commentRss/406293.htmlhttp://www.tkk7.com/baicker/services/trackbacks/406293.html涔嬪墠鐪嬭繃濂藉澶х墰鐜﹐smocomBB欏圭洰錛屾敼涓墜鏈猴紝榪炵數鑴戯紝鐒跺悗緙栬瘧涓鍫嗕笢瑗匡紝鍒版渶鍚庨兘鏄紑涓猚onsole錛屾弧灞忕孩綰㈢豢緇跨殑鏂囧瓧婊氬姩錛岀湅鐫寰堝悐銆? 浣嗛兘涓嶈鏈緇堣兘騫插暐錛屾粴灞忓畬浜嗗氨娌′簡錛屽ぇ鐗涢兘澶綆璋冧簡錛屾渶榪戞湁鏈嬪弸涔熷湪鎼炶繖涓紝浜嗚В浜嗕竴涓嬶紝浠ヤ笅鎻忚堪閮芥槸鎴戞渶榪戞煡闃呯殑澶ч噺楦熸枃璧勬枡鍙婂皯閲忎腑鏂囪祫鏂欎箣鍚庣殑鐞嗚В錛屽鏈夎鏈涙寚鍑恒? OsmocomBB鏄浗澶栦竴涓紑婧愰」鐩紝鏄疓SM鍗忚鏍?Protocols stack)鐨勫紑婧愬疄鐜幫紝鍏ㄧО鏄疧pen source mobile communication Baseband.鐩殑鏄瀹炵幇鎵嬫満绔粠鐗╃悊灞?layer1)鍒發ayer3鐨勪笁灞傚疄鐜般? 榪欓噷璁板綍涓涓嬭繃紼嬶紝浠ヤ究澶囧繕鍜屽叾瀹冩湁闇瑕佺殑绔ラ瀷灝戣蛋寮礬銆? ........
]]>MSSQL 2008 鏃ュ織鍒嗘瀽http://www.tkk7.com/baicker/archive/2013/05/03/398713.html009009Fri, 03 May 2013 02:17:00 GMThttp://www.tkk7.com/baicker/archive/2013/05/03/398713.htmlhttp://www.tkk7.com/baicker/comments/398713.htmlhttp://www.tkk7.com/baicker/archive/2013/05/03/398713.html#Feedback1http://www.tkk7.com/baicker/comments/commentRss/398713.htmlhttp://www.tkk7.com/baicker/services/trackbacks/398713.html--drop function dbo.f_splitBinary
create function dbo.f_splitBinary(@s ... 闃呰鍏ㄦ枃