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

Sniff all packets on all channels? #105

Open
johnboy00 opened this issue Nov 29, 2024 · 2 comments
Open

Sniff all packets on all channels? #105

johnboy00 opened this issue Nov 29, 2024 · 2 comments

Comments

@johnboy00
Copy link

I'm interested in being able to sniff on all 40 channels (adv + data). Missing some packets while channel hopping is of no consequence, and I don't care about the type of packet or its payload. I only care about the source and destination MACs. Your python CLI doesn't appear to support this, but can it be modified to support it? If so, can you give me any hints as to where and how? Is the current f/w able to do this? I'm using a SONOFF dongle (CC2652P).

Thanks!
J

@sultanqasim
Copy link
Collaborator

sultanqasim commented Nov 29, 2024

For sniffing advertisements, this is fairly straight forward to achieve with the existing firmware and Python APIs. See the cmd_chan_aa_phy command in particular. You can have a Python script periodically issue this command cycling between channels (and PHY modes if you'd like) while using the access address of 0x8E89BED6 (BLE_ADV_AA) and initial CRC of 0x555555 (BLE_ADV_CRCI).

For sniffing data packets, this is a bit trickier. Specifically, all data packets start with a random connection-specific access address that is not 0x8E89BED6. The radio hardware uses the access address as a sync word, and without a known sync word it doesn't know where packets start. If you know the access address of a connection, you can use cmd_chan_aa_phy with that access address, and just disable CRC validation if the initial CRC is unknown. Also note that data packets do not contain the MAC address of the source or destination, they only have an access address that is associated with the connection.

If you don't know the connection's access address, and/or want to capture packets from all ongoing connections regardless of their access address, then it becomes considerably more difficult. It is possible to synchronize on the eight bit preamble of alternating ones and zeros, but this is unreliable and results in many false synchronizations and off-by-two bit errors. The Ubertooth supports this approach to recover access addresses, though as I said its error-prone with many false syncs and missed syncs. I had an intern implement this on the CC26x2 for me some years ago, but it wasn't working very well and I had not put in time to try to improve its performance.

One other possibility is Software Defined Radio (SDR) based sniffing. I've been working on SDR support for Sniffle with RFNM though that is a work in progress. The RFNM hardware is capable of sniffing everything happening on all 40 channels simultaneously, and SDR allows more control over signal processing, so it would be easier to achieve usable levels of performance/reliability with synchronization on the preamble.

@johnboy00
Copy link
Author

Thank you so much for the quick and thorough response!

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

No branches or pull requests

2 participants