Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added a break after having a candidate AA. #5

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

fO-000
Copy link

@fO-000 fO-000 commented Dec 12, 2018

  • 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.

@fO-000 fO-000 changed the title Add a break after having a candidate AA. Added a break after having a candidate AA. Dec 13, 2018
@virtualabs
Copy link
Owner

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
Copy link
Author

fO-000 commented Dec 14, 2018

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
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants