CC2540: Difference between revisions

From RevSpace
Jump to navigation Jump to search
No edit summary
No edit summary
(7 intermediate revisions by the same user not shown)
Line 12: Line 12:


I have such a "WeBee" dongle that can be found for about E15,- on websites like Aliexpress.
I have such a "WeBee" dongle that can be found for about E15,- on websites like Aliexpress.
It's supposedly a CC2540 (or compatible) dongle, the USB id is 0451:16b3.
Interesting links:
* https://lacklustre.net/bluetooth/wireshark.html
* http://processors.wiki.ti.com/index.php/BLE_sniffer_guide
* https://github.com/andrewdodd/ccsniffpiper


== Analysis ==
== Analysis ==
Line 18: Line 25:


<pre>
<pre>
XXX
Bus 001 Device 009: ID 0451:16b3 Texas Instruments, Inc.
Device Descriptor:
  bLength                18
  bDescriptorType        1
  bcdUSB              2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass        0
  bDeviceProtocol        0
  bMaxPacketSize0        32
  idVendor          0x0451 Texas Instruments, Inc.
  idProduct          0x16b3
  bcdDevice          90.07
  iManufacturer          1 Texas Instruments
  iProduct                2 CC2540 USB Dongle
  iSerial                0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                9
    bDescriptorType        2
    wTotalLength          25
    bNumInterfaces          1
    bConfigurationValue    1
    iConfiguration          0
    bmAttributes        0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                9
      bDescriptorType        4
      bInterfaceNumber        0
      bAlternateSetting      0
      bNumEndpoints          1
      bInterfaceClass      255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0
      Endpoint Descriptor:
        bLength                7
        bDescriptorType        5
        bEndpointAddress    0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type              None
          Usage Type              Data
        wMaxPacketSize    0x0040  1x 64 bytes
        bInterval              5
Device Status:    0x0000
  (Bus Powered)
</pre>
</pre>


Line 25: Line 79:
* [http://www.ti.com/tool/packet-sniffer SmartRF Protocol Packer Sniffer]
* [http://www.ti.com/tool/packet-sniffer SmartRF Protocol Packer Sniffer]


I've captured a log of the communication over USB while the BLE is capturing bluetooth traffic from some iBeacon:
I've captured a log of the communication over USB while the BLE is capturing bluetooth traffic from some iBeacon, using [http://desowin.org/usbpcap/ USB pcap].
* TODO


In the logs, I cannot see any firmware blobs being downloaded to the stick.
In the logs, I cannot see any firmware blobs being downloaded to the stick.
Probably the stick comes with a pre-loaded firmware of itself to do the BLE sniffing.
Probably the stick comes with a pre-loaded firmware of itself to do the BLE sniffing.
The USB control transfer request codes seem to match up with the code in https://github.com/christianpanton/ccsniffer/blob/master/ccsniffer.py
* 0xC0, GET_IDENT: returns some kind of identifier
* 0xC5, SET_POWER
* 0xC6, GET_POWER
* 0xD0, START
* 0xD1, STOP
* 0xD2, SET CHAN 


== Protocol ==
== Protocol ==
In the windows sniffer software, it seems there are only two things communicated:
* towards the stick: which radio channel to sniff, and some other radio settings
* from the stick: raw sniffed BLE frames
=== Configuring the radio ===
[[File:cc2540_settings.png|right|thumb]]
[[File:cc2540_settings.png|right|thumb]]
This appears to be done using USB control transfers.
Control transfer OUT:
* request type 0x40
* request 197 (0xC5)
* value/index/length 0/4/0
* no data
Control transfer IN: check status?
* request type 0xC0
* request 198 (0xC6)
* value/index 0/0
* data: 0x00
Control transfer IN: read until status is 0x04
* request type 0xC0
* request 198 (0xC6)
* value/index 0/0
* data: 0x04
Control transfer OUT: ???
* request type 0x40
* request 201 (0xC9)
* value/index 0/0
* data: -
Control transfer OUT: to set the radio channel to sniff
* request type 0x40
* request 210 (0xD2)
* value/index 0/0
* data: 0x27
Control transfer OUT: ???
* request type 0x40
* request 210 (0xD2)
* value/index 0/1
* data: 0x00
Control transfer OUT: start capture?
* request type 0x40
* request 208 (0xD0)
* value/index 0/0
* data: -
=== Reading BLE frames ===
[[File:cc2540_packet_details.png|thumb]]
[[File:cc2540_packet_details.png|thumb]]
[[File:cc2540_wireshark.png|thumb]]
[[File:cc2540_wireshark.png|thumb]]
This appears to be done using USB bulk input transfers.


In the windows sniffer software, it seems there are only two things communicated:
I can see a lot of similarities between the USB log and the BLE sniffer log.
* towards the stick: which radio channel to sniff, and some other radio settings
The bulk USB data starts off with two bytes indicating the length of the rest of the data.
* from the stick: raw sniffed BLE frames
 
== Software ==
Preliminary code can be found at
https://github.com/bertrik/cc2540
 
It connects to the dongle and dumps raw USB packets to stdout.


You can see a lot of similarities.
This software requires libusb-1.0-dev
The bulk USB data starts off with two bytes indicating the length of the rest of the data.

Revision as of 21:56, 16 November 2016

Project CC2540
Cc2540 webee.png
Making the CC2540 BLE dongle work
Status Initializing
Contact bertrik
Last Update 2016-11-16

Introduction

This page is about the CC2540 bluetooth low-energy sniffer dongle and getting it to work with Linux. A nice end result could be that it becomes possible to sniff directly in WireShark with this dongle.

I have such a "WeBee" dongle that can be found for about E15,- on websites like Aliexpress.

It's supposedly a CC2540 (or compatible) dongle, the USB id is 0451:16b3.

Interesting links:

Analysis

USB descriptor

When plugging this stick into a Linux machine, you can see it uses only one bulk endpoint.

Bus 001 Device 009: ID 0451:16b3 Texas Instruments, Inc. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        32
  idVendor           0x0451 Texas Instruments, Inc.
  idProduct          0x16b3 
  bcdDevice           90.07
  iManufacturer           1 Texas Instruments
  iProduct                2 CC2540 USB Dongle
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           25
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               5
Device Status:     0x0000
  (Bus Powered)

USB logs from Windows

This USB device does actually work with Windows:

I've captured a log of the communication over USB while the BLE is capturing bluetooth traffic from some iBeacon, using USB pcap.

In the logs, I cannot see any firmware blobs being downloaded to the stick. Probably the stick comes with a pre-loaded firmware of itself to do the BLE sniffing.

The USB control transfer request codes seem to match up with the code in https://github.com/christianpanton/ccsniffer/blob/master/ccsniffer.py

  • 0xC0, GET_IDENT: returns some kind of identifier
  • 0xC5, SET_POWER
  • 0xC6, GET_POWER
  • 0xD0, START
  • 0xD1, STOP
  • 0xD2, SET CHAN

Protocol

In the windows sniffer software, it seems there are only two things communicated:

  • towards the stick: which radio channel to sniff, and some other radio settings
  • from the stick: raw sniffed BLE frames

Configuring the radio

Cc2540 settings.png

This appears to be done using USB control transfers.

Control transfer OUT:

  • request type 0x40
  • request 197 (0xC5)
  • value/index/length 0/4/0
  • no data

Control transfer IN: check status?

  • request type 0xC0
  • request 198 (0xC6)
  • value/index 0/0
  • data: 0x00

Control transfer IN: read until status is 0x04

  • request type 0xC0
  • request 198 (0xC6)
  • value/index 0/0
  • data: 0x04

Control transfer OUT: ???

  • request type 0x40
  • request 201 (0xC9)
  • value/index 0/0
  • data: -

Control transfer OUT: to set the radio channel to sniff

  • request type 0x40
  • request 210 (0xD2)
  • value/index 0/0
  • data: 0x27

Control transfer OUT: ???

  • request type 0x40
  • request 210 (0xD2)
  • value/index 0/1
  • data: 0x00

Control transfer OUT: start capture?

  • request type 0x40
  • request 208 (0xD0)
  • value/index 0/0
  • data: -

Reading BLE frames

Cc2540 packet details.png
Cc2540 wireshark.png

This appears to be done using USB bulk input transfers.

I can see a lot of similarities between the USB log and the BLE sniffer log. The bulk USB data starts off with two bytes indicating the length of the rest of the data.

Software

Preliminary code can be found at https://github.com/bertrik/cc2540

It connects to the dongle and dumps raw USB packets to stdout.

This software requires libusb-1.0-dev