secdev/scapy

Bluetooth packets - Missing HCI events

Open

#2,581 opened on Apr 9, 2020

View on GitHub
 (8 comments) (0 reactions) (0 assignees)Python (9,312 stars) (1,949 forks)batch import
discussionhelp wanted

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

Tech stack
python
Domain
backendapi
Issue type
bug
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-3 hours
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
stale
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
mostly clear
Prerequisites
understanding of Bluetooth HCIPythonfamiliarity with Scapy layers
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
25
Research direction
The issue reports that Scapy's HCI command parsing produces incorrect MAC addresses compared to hcidump. The raw load shows bytes that are shifted or misaligned. To fix, examine the Bluetooth HCI layer definitions in scapy/layers/bluetooth.py, specifically the HCI Command Hdr or related classes. Compare the byte order and field mapping with the HCI specification. The example shows that the MAC address bytes are present but in wrong order/misplaced. A contributor should verify the parsing of the 'bdaddr' field and ensure it matches the little endian byte order expected by Bluetooth. Also check if there is a missing dissector for the Create Connection command payload. The issue has 8 comments; review them for any additional clues or partial fixes.