secdev / secdev/scapy

Bluetooth packets - Missing HCI events

Open
#2,581 8 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

discussion help wanted
Dominant language
Python
Stars
12.6k
Forks
2.2k
Avg merge
1d 4h
Merged PRs (30d)
56

Description

Brief description

Sniffing bluetooth packets and the device's mac address from the raw load of the packets is not the same as the load that i get from hcidump. (The mac address is wrong in the SCAPY bluetooth packets)

Environment
  • Scapy version: Version 2.4.3.dev454
  • Python version: 2.7
  • Operating System: Linux raspberrypi 4.19.75-v7+
How to reproduce

I am using this linux command to make a connection between my raspberry pi and my phone:
sudo hcitool cc 1C:39:47:75:BE:94
Then i sniff the packets with hcidump, and then i try again with the pkts = bt.sniff() too.

Actual result

As a result the device mac address in the raw load of all scapy packets is not correct or is not, what it should be!
Example of packets:

With hcidump the packet is this:
2020-04-09 13:43:23.218009 < HCI Command: Create Connection (0x01|0x0005) plen 13
bdaddr 1C:39:47:75:BE:94 ptype 0xcc18 rswitch 0x01 clkoffset 0x0000
Packet type: DM1 DM3 DM5 DH1 DH3 DH5

With scapy the packet is this:

pkts[0].show()
###[ HCI header ]###
type= Command
###[ HCI Command header ]###
opcode= 0x405
len= 13
###[ Raw ]###
load= '\x94\xbeuG9\x1c\x18\xcc\x02\x00\x00\x00\x01'

Expected result

The problem is the LOAD of the scapy packet:
hcidump -> bdaddr 1C:39:47:75:BE:94 ptype 0xcc18 rswitch 0x01 clkoffset 0x0000
scapy -> \x94\xbe uG9 \x1c \x18\xcc \x02 \x00\x00 \x00\x01
I suppose it should be -> \x94\xbe \x75 \x47 \x39 \x1c
As you can see the mac address is almost the same, but there are some wrong bytes.
Also i tried with another phone, and the result is the same:

With hcidump the packet is this:
2020-04-09 13:54:27.662396 < HCI Command: Create Connection (0x01|0x0005) plen 13
bdaddr B8:C1:11:1F:30:1E ptype 0xcc18 rswitch 0x01 clkoffset 0x0000
Packet type: DM1 DM3 DM5 DH1 DH3 DH5

With scapy the packet is this:

pkts[0].show()
###[ HCI header ]###
type= Command
###[ HCI Command header ]###
opcode= 0x405
len= 13
###[ Raw ]###
load= '\x1e0\x1f\x11\xc1\xb8\x18\xcc\x02\x00\x00\x00\x01'

Again the load is wrong:
hcidump -> bdaddr B8:C1:11:1F:30:1E ptype 0xcc18 rswitch 0x01 clkoffset 0x0000
scapy -> \x1e0\x1f\x11\xc1\xb8 \x18\xcc \x02 \x00\x00\x00\x01

This time only one byte is wrong! ( this -> 30:1E is represented like this -> \x1e0 )

I am not sure, if this is a real bug, but i think that some how the mac address is not correctly extracted. I hope that i am wrong! As i said the mac address is the same in all of the packet, but not correct!!! I hope this is useful for improving your software, if you need some more details just ask :) !

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the Bluetooth connection with hcitool cc 1C:39:47:75:BE:94, then compare hcidump output with packets captured by bt.sniff(). Trace how the HCI Create Connection command payload is decoded, focusing on the Bluetooth address byte order and missing HCI events. Done means Scapy exposes the same address and relevant event data as hcidump for the reported examples.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
networking
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.