翻译部分内容，备忘加巩固，好多不清楚或错误的地方，望高手指正。
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.
根据已有资料，我发现了一种针对微软无线键盘（ 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's repository, 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.
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.
根据已有资料，我发现了一种针对微软无线键盘（ 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's repository, 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.
原文： Promiscuity is the nRF24L01+'s Duty