Added a break after having a candidate AA.

[fO-000]

• After getting a candidate AA from rx_buffer in SNIFF_AA mode, we can break the loop which shifts rx_buffer right by one bit once and twice.
• Corrected comments of the loop, shit -> shift.

[virtualabs]

I'm not sure this modification improves access address detection, as we would miss a candidate access address if the first pass in this loop matches an existing one. It definitely needs more testing with this fix to check if it improves Btlejack's AA scanning, but I'm not convinced yet.

Besides this, this comment was pretty bad I have to admit, thank you for having spotted it.

[fO-000]

Thank you for your reply!

To be honest I'm confused about the loop commented
with /* Shfit right by one bit once and twice */:

• If we fail to check the BLE LL empty PDU for the first time during case SNIFF_AA,
  why we should enter the loop to continue checking instead of just waiting another radio packet?

• Why the loop runs two times and it would find a candidate AA in both times? (so we
  would miss a candidate AA, if break in the first pass.)

I will very appreciate if you help me to understand this.

[virtualabs]

I see. Btlejack relies on a hack found by Travis Goodspeed to turn the nRF51822 into a sniffer, an operation mode that is normally not possible. This trick is simple and clever: if you set the address field to be 2 bytes long and put 0x00 0xAA in it, then the transceiver will consider a legitimate packet preamble as our address, and will process the following bytes as a payload.

But there is a problem here: we don't know the access address value. The Bluetooth specs states that the preamble must be 0x55 if the MSB of the access address if not set, and 0xAA otherwise. So basically, we may match a preamble with our 0xAA value, but it may also be a 0x55 preamble in the original packet. That's why we try to shift right bit by bit in order to keep in memory at least two candidates per packet received.

So, why shifting twice instead of one ? Since we cannot enable the nRF51822's CRC check (as we don't know the CRC initial value for a given connection), we may match a preamble a bit too late. This technique was also used by Mousejack, where the same approach is implemented (see https://github.com/BastilleResearch/nrf-research-firmware/blob/02b84d1c4e59c0fb98263c83b2e7c7f9863a3b93/src/radio.c, line 292 for more information).

Waiting for another packet will require more time and a bit of luck (again), as we need to be on the right channel at the right time to capture packets.

Hope this helps.