[Ubertooth-general] sniff and decrypt/crack bluetooth 2.0

Hey,

currently I try to sniff and decrypt the communication between a
Bluetooth Keyboard and an old Bluetooth 2.0 Dongle. Sadly I didn't find
any website or blog entry where someone did this before.

ubertooth-rx shows only packages with type NULL,POLL and DM1 but
wireshark shows the handshake with DH5, EV5... So the communication
seems to be encrypted as well.
I found some tools like btcrack or btpincrack to decrypt the stream but
they are incompatible to the pcap(ng) format. Is there any tool out
there which is able to crack this communication or can anyone give me a
hint, how i will be able to achieve this?

Regards
Hannibal

Hannibal,

I was trying to capture packets between two devices using an unencrypted
SPP mode using classic bluetooth.  I only got packets which were 12 bytes
in length.  I'm curious about how you got your results.  Would it be
possible to give some more details on what you did?

On Mon, Dec 14, 2015 at 7:07 AM, Hannibal Smith <h.smith05@...> wrote:

> Hey,
>
> currently I try to sniff and decrypt the communication between a
> Bluetooth Keyboard and an old Bluetooth 2.0 Dongle. Sadly I didn't find
> any website or blog entry where someone did this before.
>
> ubertooth-rx shows only packages with type NULL,POLL and DM1 but
> wireshark shows the handshake with DH5, EV5... So the communication
> seems to be encrypted as well.
> I found some tools like btcrack or btpincrack to decrypt the stream but
> they are incompatible to the pcap(ng) format. Is there any tool out
> there which is able to crack this communication or can anyone give me a
> hint, how i will be able to achieve this?
>
>
> Regards
> Hannibal
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Ubertooth-general mailing list
> Ubertooth-general@...
> https://lists.sourceforge.net/lists/listinfo/ubertooth-general
>

--
John F. Davis
6 Kandes Court
Durham, NC 27713
919-888-8358

独树一帜

John,

nothing special, I just run ubertooth-rx with lap & uap. The packages
shown by wireshark are between 22 and 42 bytes long.

------------------------------
# ubertooth-rx -U0 -l 000830 -u 81 -r sniff.pcapng -q sniff.pcap

systime=1450098845 ch=39 LAP=000830 err=0 clk100ns=863167307
clk1=2235259 s=0 n=-81 snr=81
systime=1450098846 ch=39 LAP=000830 err=0 clk100ns=868336302
clk1=2236086 s=0 n=-82 snr=82
CLK6 = 0x3b found after 2 total pac
1cca8
kets.

Calculating complete hopping sequence.
Hopping sequence calculated.
26536 initial CLK1-27 candidates
systime=1450098848 ch=39 LAP=000830 err=0 clk100ns=895561933
clk1=2240442 s=-21 n=-82 snr=61
systime=1450098848 ch=39 LAP=000830 err=0 clk100ns=895898047
clk1=2240496 s=-16 n=-83 snr=67

Acquired CLK1-27 = 0x03998f6
got CLK1-27
clock offset = 3078902.
systime=1450098851 ch=39 LAP=000830 err=0 clk100ns=895898047
clk1=2240496 s=-16 n=-83 snr=67
Packet decoded with clock 0x40 (rv=2)
Type: DM1
LT_ADDR: 1
LLID: 1
flow: 0
payload length: 12
Data:  49 a3 a3 b2 44 03 4e f1 4d ab 86 63
Type: DM1
LT_ADDR: 1
LLID: 1
flow: 0
payload length: 12
Data:  49 a3 a3 b2 44 03 4e f1 4d ab 86 63
systime=1450098868 ch=74 LAP=000830 err=0 clk100ns=733195114
clk1=3787327 s=-21 n=-76 snr=55
Packet decoded with clock 0x40 (rv=1)
Type: NULL
Type: NULL
systime=1450098868 ch=29 LAP=000830 err=0 clk100ns=737090197
clk1=3787950 s=-16 n=-120 snr=104
Packet decoded with clock 0x40 (rv=1)
Type: NULL
Type: NULL
systime=1450098868 ch= 9 LAP=000830 err=0 clk100ns=739839269
clk1=3788390 s=0 n=-120 snr=120
Packet decoded with clock 0x40 (rv=1)
Type: NULL
Type: NULL
systime=1450098871 ch= 2 LAP=000830 err=0 clk100ns=901735634
clk1=3814293 s=0 n=-59 snr=59
Packet decoded with clock 0x40 (rv=1)
Type: POLL
Type: POLL
---------------
---------------
No.     Time           Source                Destination Protocol Length
Info
4 3.273074000 Bluetooth 22     NULL

Frame 4: 22 bytes on wire (176 bits), 22 bytes captured (176 bits)
Bluetooth BR/EDR Baseband

No.     Time           Source                Destination Protocol Length
Info
5 432.769803600 Bluetooth 34     HV1

Frame 5: 34 bytes on wire (272 bits), 34 bytes captured (272 bits)
Bluetooth BR/EDR Baseband

No.     Time           Source                Destination Protocol Length
Info
6 1275.492969500 Bluetooth 22     NULL

Frame 6: 22 bytes on wire (176 bits), 22 bytes captured (176 bits)
Bluetooth BR/EDR Baseband

No.     Time           Source                Destination Protocol Length
Info
7 1275.882477800 Bluetooth 22     AUX1

Frame 7: 22 bytes on wire (176 bits), 22 bytes captured (176 bits)
Bluetooth BR/EDR Baseband

No.     Time           Source                Destination Protocol Length
Info
8 1276.157385000 Bluetooth 22     EV5/3-EV5

Frame 8: 22 bytes on wire (176 bits), 22 bytes captured (176 bits)
Bluetooth BR/EDR Baseband

No.     Time           Source                Destination Protocol Length
Info
9 862.850291900 Bluetooth 22     DH5/3-DH5

Frame 9: 22 bytes on wire (176 bits), 22 bytes captured (176 bits)
Bluetooth BR/EDR Baseband
--------------------------

On 14.12.2015 13:53, John Davis wrote:
> Hannibal,
>
> I was trying to capture packets between two devices using an
> unencrypted SPP mode using classic bluetooth.  I only got packets
> which were 12 bytes in length.  I'm curious about how you got your
> results.  Would it be possible to give some more details on what you did?
>
> On Mon, Dec 14, 2015 at 7:07 AM, Hannibal Smith <h.smith05@...
> <mailto:h.smith05@...>> wrote:
>
>     Hey,
>
>     currently I try to sniff and decrypt the communication between a
>     Bluetooth Keyboard and an old Bluetooth 2.0 Dongle. Sadly I didn't
>     find
>     any website or blog entry where someone did this before.
>
>     ubertooth-rx shows only packages with type NULL,POLL and DM1 but
>     wireshark shows the handshake with DH5, EV5... So the communication
>     seems to be encrypted as well.
>     I found some tools like btcrack or btpincrack to decrypt the
>     stream but
>     they are incompatible to the pcap(ng) format. Is there any tool out
>     there which is able to crack this communication or can anyone give
>     me a
>     hint, how i will be able to achieve this?
>
>
>     Regards
>     Hannibal
>
>     ------------------------------------------------------------------------------
>     _______________________________________________
>     Ubertooth-general mailing list
>     Ubertooth-general@...
>     <mailto:Ubertooth-general@...>
>     https://lists.sourceforge.net/lists/listinfo/ubertooth-general
>
>
>
>
> --
> John F. Davis
> 6 Kandes Court
> Durham, NC 27713
> 919-888-8358
>
> 独树一帜
>
>

Doing something similar I get:

davis@...:~/progs$ ubertooth-rx -q sniff.pcap -r sniff.pcapng
systime=1450099810 ch=39 LAP=1b150f err=1 clk100ns=2718876754 clk1=435020
s=-69 n=-77 snr=8
systime=1450099810 ch=39 LAP=54f4c1 err=0 clk100ns=2718988783 clk1=435038
s=-47 n=-77 snr=30
systime=1450099810 ch=39 LAP=5cf4be err=2 clk100ns=2719296862 clk1=435087
s=-50 n=-77 snr=27
systime=1450099811 ch=39 LAP=e2807b err=1 clk100ns=2720689167 clk1=435310
s=-75 n=-78 snr=3
systime=1450099813 ch=39 LAP=a014a9 err=1 clk100ns=2748191823 clk1=439711
s=-67 n=-76 snr=9
systime=1450099814 ch=39 LAP=5cf4be err=2 clk100ns=2756196388 clk1=440991
s=-40 n=-72 snr=32
systime=1450099815 ch=39 LAP=a014a9 err=1 clk100ns=2766517323 clk1=442643
s=-48 n=-74 snr=26
systime=1450099816 ch=39 LAP=5cf4be err=2 clk100ns=2777794350 clk1=444447
s=-67 n=-77 snr=10
systime=1450099816 ch=39 LAP=5cf4be err=2 clk100ns=2777906333 clk1=444465
s=-68 n=-77 snr=9
systime=1450099817 ch=39 LAP=e2807b err=1 clk100ns=2781894844 clk1=445103
s=-76 n=-77 snr=1

If I open the two capture files in wireshark, it has missing columns for
source and destination.  All packets are shown as unkown and are 22 bytes
in length.

On Mon, Dec 14, 2015 at 8:22 AM, Hannibal Smith <h.smith05@...> wrote:

> John,
>
> nothing special, I just run ubertooth-rx with lap & uap. The packages
> shown by wireshark are between 22 and 42 bytes long.
>
> ------------------------------
> # ubertooth-rx -U0 -l 000830 -u 81 -r sniff.pcapng -q sniff.pcap
>
> systime=1450098845 ch=39 LAP=000830 err=0 clk100ns=863167307 clk1=2235259
> s=0 n=-81 snr=81
> systime=1450098846 ch=39 LAP=000830 err=0 clk100ns=868336302 clk1=2236086
> s=0 n=-82 snr=82
> CLK6 = 0x3b found after 2 total packets.
>
> Calculating complete hopping sequence.
> Hopping sequence calculated.
> 26536 initial CLK1-27 candidates
> systime=1450098848 ch=39 LAP=000830 err=0 clk100ns=895561933 clk1=2240442
> s=-21 n=-82 snr=61
> systime=1450098848 ch=39 LAP=000830 err=0 clk100ns=895898047 clk1=2240496
> s=-16 n=-83 snr=67
>
> Acquired CLK1-27 = 0x03998f6
> got CLK1-27
> clock offset = 3078902.
> systime=1450098851 ch=39 LAP=000830 err=0 clk100ns=895898047 clk1=2240496
> s=-16 n=-83 snr=67
> Packet decoded with clock 0x40 (rv=2)
>   Type: DM1
>   LT_ADDR: 1
>   LLID: 1
>   flow: 0
>   payload length: 12
>   Data:  49 a3 a3 b2 44 03 4e f1 4d ab 86 63
>   Type: DM1
>   LT_ADDR: 1
>   LLID: 1
>   flow: 0
>   payload length: 12
>   Data:  49 a3 a3 b2 44 03 4e f1 4d ab 86 63
> systime=1450098868 ch=74 LAP=000830 err=0 clk100ns=733195114 clk1=3787327
> s=-21 n=-76 snr=55
> Packet decoded with clock 0x40 (rv=1)
>   Type: NULL
>   Type: NULL
> systime=1450098868 ch=29 LAP=000830 err=0 clk100ns=737090197 clk1=3787950
> s=-16 n=-120 snr=104
> Packet decoded with clock 0x40 (rv=1)
>   Type: NULL
>   Type: NULL
> systime=1450098868 ch= 9 LAP=000830 err=0 clk100ns=739839269 clk1=3788390
> s=0 n=-120 snr=120
> Packet decoded with clock 0x40 (rv=1)
>   Type: NULL
>   Type: NULL
> systime=1450098871 ch= 2 LAP=000830 err=0 clk100ns=901735634 clk1=3814293
> s=0 n=-59 snr=59
> Packet decoded with clock 0x40 (rv=1)
>   Type: POLL
>   Type: POLL
> ---------------
> ---------------
> No.     Time           Source                Destination
> Protocol Length Info
>       4 3.273074000
> Bluetooth 22     NULL
>
> Frame 4: 22 bytes on wire (176 bits), 22 bytes captured (176 bits)
> Bluetooth BR/EDR Baseband
>
> No.     Time           Source                Destination
> Protocol Length Info
>       5 432.769803600
> Bluetooth 34     HV1
>
> Frame 5: 34 bytes on wire (272 bits), 34 bytes captured (272 bits)
> Bluetooth BR/EDR Baseband
>
> No.     Time           Source                Destination
> Protocol Length Info
>       6 1275.492969500
> Bluetooth 22     NULL
>
> Frame 6: 22 bytes on wire (176 bits), 22 bytes captured (176 bits)
> Bluetooth BR/EDR Baseband
>
> No.     Time           Source                Destination
> Protocol Length Info
>       7 1275.882477800
> Bluetooth 22     AUX1
>
> Frame 7: 22 bytes on wire (176 bits), 22 bytes captured (176 bits)
> Bluetooth BR/EDR Baseband
>
> No.     Time           Source                Destination
> Protocol Length Info
>       8 1276.157385000
> Bluetooth 22     EV5/3-EV5
>
> Frame 8: 22 bytes on wire (176 bits), 22 bytes captured (176 bits)
> Bluetooth BR/EDR Baseband
>
> No.     Time           Source                Destination
> Protocol Length Info
>       9 862.850291900
> Bluetooth 22     DH5/3-DH5
>
> Frame 9: 22 bytes on wire (176 bits), 22 bytes captured (176 bits)
> Bluetooth BR/EDR Baseband
> --------------------------
>
>
>
>
> On 14.12.2015 13:53, John Davis wrote:
>
> Hannibal,
>
> I was trying to capture packets between two devices using an unencrypted
> SPP mode using classic bluetooth.  I only got packets which were 12 bytes
> in length.  I'm curious about how you got your results.  Would it be
> possible to give some more details on what you did?
>
> On Mon, Dec 14, 2015 at 7:07 AM, Hannibal Smith <h.smith05@...>
> wrote:
>
>> Hey,
>>
>> currently I try to sniff and decrypt the communication between a
>> Bluetooth Keyboard and an old Bluetooth 2.0 Dongle. Sadly I didn't find
>> any website or blog entry where someone did this before.
>>
>> ubertooth-rx shows only packages with type NULL,POLL and DM1 but
>> wireshark shows the handshake with DH5, EV5... So the communication
>> seems to be encrypted as well.
>> I found some tools like btcrack or btpincrack to decrypt the stream but
>> they are incompatible to the pcap(ng) format. Is there any tool out
>> there which is able to crack this communication or can anyone give me a
>> hint, how i will be able to achieve this?
>>
>>
>> Regards
>> Hannibal
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Ubertooth-general mailing list
>> Ubertooth-general@...
>> https://lists.sourceforge.net/lists/listinfo/ubertooth-general
>>
>
>
>
> --
> John F. Davis
> 6 Kandes Court
> Durham, NC 27713
> 919-888-8358
>
> 独树一帜
>
>
>
>

--
John F. Davis
6 Kandes Court
Durham, NC 27713
919-888-8358

独树一帜

On 14 December 2015 at 12:07, Hannibal Smith <h.smith05@...> wrote:
>
> currently I try to sniff and decrypt the communication between a
> Bluetooth Keyboard and an old Bluetooth 2.0 Dongle. Sadly I didn't find
> any website or blog entry where someone did this before.

If both the keyboard and dongle support Bluetooth 2.0, then they are
likely paired using Secure Simple Pairing (SSP).  This isn't broken in
the way that 4 digit pin has been, although I believe that some
versions (Just Works?) are known to be vulnerable.

> ubertooth-rx shows only packages with type NULL,POLL and DM1 but
> wireshark shows the handshake with DH5, EV5... So the communication
> seems to be encrypted as well.

The Ubertooth tools make the assumption that you are sniffing an
existing connection.  As we would always need to sniff the pairing
process to have any chance of decrypting the encrypted packets, the
tools also assume that the connection is unencrypted.

However, the tools also try to decode the packets with the assumption
that the clock value could be slightly off, so they attempt multiple
values and look for evidence, such as CRCs.

In this case, I would expect the NULL/POLL to be keep alive packets
and DM1 packets to be carrying the HID data.  When you say that
Wireshark shows the handshake, which packets do you mean?

> I found some tools like btcrack or btpincrack to decrypt the stream but
> they are incompatible to the pcap(ng) format. Is there any tool out
> there which is able to crack this communication or can anyone give me a
> hint, how i will be able to achieve this?

Those tools only work for the older pin entry method of pairing and
require you to sniff the pairing process, which is very hard to
capture.  Your best option would be to start the connection, sniff
with ubertooth-follow and then initiate the pairing, but I don't
expect this process to be reliable and those tools still will not
support our pcap format, although that is probably fixable.

Dominic,

I believe SSP didn't come out until core version 2.1, so 2.0 devices should
still be using legacy pairing (crackable).

Regards,

Mark

________________________________________
Mark Nichols
President
Spanalytics, LLC
http://www.spanalytics.com
Office: (804) 364-1050
Mobile: (804) 503-0552

-----Original Message-----
From: Dominic Spill [mailto:dominicgs@...]
Sent: Monday, December 14, 2015 8:58 AM
To: Hannibal Smith
Cc: Ubertooth Discussion
Subject: Re: [Ubertooth-general] sniff and decrypt/crack bluetooth 2.0

On 14 December 2015 at 12:07, Hannibal Smith <h.smith05@...> wrote:
>
> currently I try to sniff and decrypt the communication between a
> Bluetooth Keyboard and an old Bluetooth 2.0 Dongle. Sadly I didn't
> find any website or blog entry where someone did this before.

If both the keyboard and dongle support Bluetooth 2.0, then they are likely
paired using Secure Simple Pairing (SSP).  This isn't broken in the way that
4 digit pin has been, although I believe that some versions (Just Works?)
are known to be vulnerable.

> ubertooth-rx shows only packages with type NULL,POLL and DM1 but
> wireshark shows the handshake with DH5, EV5... So the communication
> seems to be encrypted as well.

The Ubertooth tools make the assumption that you are sniffing an existing
connection.  As we would always need to sniff the pairing process to have
any chance of decrypting the encrypted packets, the tools also assume that
the connection is unencrypted.

However, the tools also try to decode the packets with the assumption that
the clock value could be slightly off, so they attempt multiple values and
look for evidence, such as CRCs.

In this case, I would expect the NULL/POLL to be keep alive packets and DM1
packets to be carrying the HID data.  When you say that Wireshark shows the
handshake, which packets do you mean?

> I found some tools like btcrack or btpincrack to decrypt the stream
> but they are incompatible to the pcap(ng) format. Is there any tool
> out there which is able to crack this communication or can anyone give
> me a hint, how i will be able to achieve this?

Those tools only work for the older pin entry method of pairing and require
you to sniff the pairing process, which is very hard to capture.  Your best
option would be to start the connection, sniff with ubertooth-follow and
then initiate the pairing, but I don't expect this process to be reliable
and those tools still will not support our pcap format, although that is
probably fixable.

----------------------------------------------------------------------------
--
_______________________________________________
Ubertooth-general mailing list
Ubertooth-general@...
https://lists.sourceforge.net/lists/listinfo/ubertooth-general

On 14 December 2015 at 14:11, Mark Nichols <mnichols@...> wrote:
>
> I believe SSP didn't come out until core version 2.1, so 2.0 devices should
> still be using legacy pairing (crackable).

You're absolutely right, I was getting confused with my version
numbers.  There's a list in the spec that confirms SSP was added in
2.1. (Vol 1, Part D, Section 1.1).

Thanks for the clarification,
Dominic

> -----Original Message-----
> From: Dominic Spill [mailto:dominicgs@...]
> Sent: Monday, December 14, 2015 8:58 AM
> To: Hannibal Smith
> Cc: Ubertooth Discussion
> Subject: Re: [Ubertooth-general] sniff and decrypt/crack bluetooth 2.0
>
> On 14 December 2015 at 12:07, Hannibal Smith <h.smith05@...> wrote:
>>
>> currently I try to sniff and decrypt the communication between a
>> Bluetooth Keyboard and an old Bluetooth 2.0 Dongle. Sadly I didn't
>> find any website or blog entry where someone did this before.
>
> If both the keyboard and dongle support Bluetooth 2.0, then they are likely
> paired using Secure Simple Pairing (SSP).  This isn't broken in the way that
> 4 digit pin has been, although I believe that some versions (Just Works?)
> are known to be vulnerable.
>
>> ubertooth-rx shows only packages with type NULL,POLL and DM1 but
>> wireshark shows the handshake with DH5, EV5... So the communication
>> seems to be encrypted as well.
>
> The Ubertooth tools make the assumption that you are sniffing an existing
> connection.  As we would always need to sniff the pairing process to have
> any chance of decrypting the encrypted packets, the tools also assume that
> the connection is unencrypted.
>
> However, the tools also try to decode the packets with the assumption that
> the clock value could be slightly off, so they attempt multiple values and
> look for evidence, such as CRCs.
>
> In this case, I would expect the NULL/POLL to be keep alive packets and DM1
> packets to be carrying the HID data.  When you say that Wireshark shows the
> handshake, which packets do you mean?
>
>> I found some tools like btcrack or btpincrack to decrypt the stream
>> but they are incompatible to the pcap(ng) format. Is there any tool
>> out there which is able to crack this communication or can anyone give
>> me a hint, how i will be able to achieve this?
>
> Those tools only work for the older pin entry method of pairing and require
> you to sniff the pairing process, which is very hard to capture.  Your best
> option would be to start the connection, sniff with ubertooth-follow and
> then initiate the pairing, but I don't expect this process to be reliable
> and those tools still will not support our pcap format, although that is
> probably fixable.
>
> ----------------------------------------------------------------------------
> --
> _______________________________________________
> Ubertooth-general mailing list
> Ubertooth-general@...
> https://lists.sourceforge.net/lists/listinfo/ubertooth-general
>

On 14 December 2015 at 13:33, John Davis <davisjf@...> wrote:
> Doing something similar I get:
>
> davis@...:~/progs$ ubertooth-rx -q sniff.pcap -r sniff.pcapng
> systime=1450099810 ch=39 LAP=1b150f err=1 clk100ns=2718876754 clk1=435020
> s=-69 n=-77 snr=8
> systime=1450099810 ch=39 LAP=54f4c1 err=0 clk100ns=2718988783 clk1=435038
> s=-47 n=-77 snr=30

> If I open the two capture files in wireshark, it has missing columns for
> source and destination.  All packets are shown as unkown and are 22 bytes in
> length.

The source and destination address in Wireshark refer to the source
and destination MAC addresses for Ethernet, they are not relevant to
Bluetooth packets as the packets do not contain a source and
destination address.  All packets contain parts of the address of the
master device.

The packets here are of unknown length because we have not been able
to decode enough about them to read the packet headers.  All that we
know is the LAP and receive time.  This is why the packets are so
short in Wireshark.  If you wish to improve the reception, you can try
using ubertooth-rx with the -s option to scan through different
channels, I usually find that this yields better data.

Dominic

> On Mon, Dec 14, 2015 at 8:22 AM, Hannibal Smith <h.smith05@...> wrote:
>>
>> John,
>>
>> nothing special, I just run ubertooth-rx with lap & uap. The packages
>> shown by wireshark are between 22 and 42 bytes long.
>>
>> ------------------------------
>> # ubertooth-rx -U0 -l 000830 -u 81 -r sniff.pcapng -q sniff.pcap
>>
>> systime=1450098845 ch=39 LAP=000830 err=0 clk100ns=863167307 clk1=2235259
>> s=0 n=-81 snr=81
>> systime=1450098846 ch=39 LAP=000830 err=0 clk100ns=868336302 clk1=2236086
>> s=0 n=-82 snr=82
>> CLK6 = 0x3b found after 2 total packets.
>>
>> Calculating complete hopping sequence.
>> Hopping sequence calculated.
>> 26536 initial CLK1-27 candidates
>> systime=1450098848 ch=39 LAP=000830 err=0 clk100ns=895561933 clk1=2240442
>> s=-21 n=-82 snr=61
>> systime=1450098848 ch=39 LAP=000830 err=0 clk100ns=895898047 clk1=2240496
>> s=-16 n=-83 snr=67
>>
>> Acquired CLK1-27 = 0x03998f6
>> got CLK1-27
>> clock offset = 3078902.
>> systime=1450098851 ch=39 LAP=000830 err=0 clk100ns=895898047 clk1=2240496
>> s=-16 n=-83 snr=67
>> Packet decoded with clock 0x40 (rv=2)
>>   Type: DM1
>>   LT_ADDR: 1
>>   LLID: 1
>>   flow: 0
>>   payload length: 12
>>   Data:  49 a3 a3 b2 44 03 4e f1 4d ab 86 63
>>   Type: DM1
>>   LT_ADDR: 1
>>   LLID: 1
>>   flow: 0
>>   payload length: 12
>>   Data:  49 a3 a3 b2 44 03 4e f1 4d ab 86 63
>> systime=1450098868 ch=74 LAP=000830 err=0 clk100ns=733195114 clk1=3787327
>> s=-21 n=-76 snr=55
>> Packet decoded with clock 0x40 (rv=1)
>>   Type: NULL
>>   Type: NULL
>> systime=1450098868 ch=29 LAP=000830 err=0 clk100ns=737090197 clk1=3787950
>> s=-16 n=-120 snr=104
>> Packet decoded with clock 0x40 (rv=1)
>>   Type: NULL
>>   Type: NULL
>> systime=1450098868 ch= 9 LAP=000830 err=0 clk100ns=739839269 clk1=3788390
>> s=0 n=-120 snr=120
>> Packet decoded with clock 0x40 (rv=1)
>>   Type: NULL
>>   Type: NULL
>> systime=1450098871 ch= 2 LAP=000830 err=0 clk100ns=901735634 clk1=3814293
>> s=0 n=-59 snr=59
>> Packet decoded with clock 0x40 (rv=1)
>>   Type: POLL
>>   Type: POLL
>> ---------------
>> ---------------
>> No.     Time           Source                Destination
>> Protocol Length Info
>>       4 3.273074000
>> Bluetooth 22     NULL
>>
>> Frame 4: 22 bytes on wire (176 bits), 22 bytes captured (176 bits)
>> Bluetooth BR/EDR Baseband
>>
>> No.     Time           Source                Destination
>> Protocol Length Info
>>       5 432.769803600
>> Bluetooth 34     HV1
>>
>> Frame 5: 34 bytes on wire (272 bits), 34 bytes captured (272 bits)
>> Bluetooth BR/EDR Baseband
>>
>> No.     Time           Source                Destination
>> Protocol Length Info
>>       6 1275.492969500
>> Bluetooth 22     NULL
>>
>> Frame 6: 22 bytes on wire (176 bits), 22 bytes captured (176 bits)
>> Bluetooth BR/EDR Baseband
>>
>> No.     Time           Source                Destination
>> Protocol Length Info
>>       7 1275.882477800
>> Bluetooth 22     AUX1
>>
>> Frame 7: 22 bytes on wire (176 bits), 22 bytes captured (176 bits)
>> Bluetooth BR/EDR Baseband
>>
>> No.     Time           Source                Destination
>> Protocol Length Info
>>       8 1276.157385000
>> Bluetooth 22     EV5/3-EV5
>>
>> Frame 8: 22 bytes on wire (176 bits), 22 bytes captured (176 bits)
>> Bluetooth BR/EDR Baseband
>>
>> No.     Time           Source                Destination
>> Protocol Length Info
>>       9 862.850291900
>> Bluetooth 22     DH5/3-DH5
>>
>> Frame 9: 22 bytes on wire (176 bits), 22 bytes captured (176 bits)
>> Bluetooth BR/EDR Baseband
>> --------------------------
>>
>>
>>
>>
>> On 14.12.2015 13:53, John Davis wrote:
>>
>> Hannibal,
>>
>> I was trying to capture packets between two devices using an unencrypted
>> SPP mode using classic bluetooth.  I only got packets which were 12 bytes in
>> length.  I'm curious about how you got your results.  Would it be possible
>> to give some more details on what you did?
>>
>> On Mon, Dec 14, 2015 at 7:07 AM, Hannibal Smith <h.smith05@...>
>> wrote:
>>>
>>> Hey,
>>>
>>> currently I try to sniff and decrypt the communication between a
>>> Bluetooth Keyboard and an old Bluetooth 2.0 Dongle. Sadly I didn't find
>>> any website or blog entry where someone did this before.
>>>
>>> ubertooth-rx shows only packages with type NULL,POLL and DM1 but
>>> wireshark shows the handshake with DH5, EV5... So the communication
>>> seems to be encrypted as well.
>>> I found some tools like btcrack or btpincrack to decrypt the stream but
>>> they are incompatible to the pcap(ng) format. Is there any tool out
>>> there which is able to crack this communication or can anyone give me a
>>> hint, how i will be able to achieve this?
>>>
>>>
>>> Regards
>>> Hannibal
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Ubertooth-general mailing list
>>> Ubertooth-general@...
>>> https://lists.sourceforge.net/lists/listinfo/ubertooth-general
>>
>>
>>
>>
>> --
>> John F. Davis
>> 6 Kandes Court
>> Durham, NC 27713
>> 919-888-8358
>>
>> 独树一帜
>>
>>
>>
>
>
>
> --
> John F. Davis
> 6 Kandes Court
> Durham, NC 27713
> 919-888-8358
>
> 独树一帜
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Ubertooth-general mailing list
> Ubertooth-general@...
> https://lists.sourceforge.net/lists/listinfo/ubertooth-general
>

Hello Dominic,

Many thanks for your reply.  I added the -s option and the results are the
same.  It is still 22 byte packets.

FWIW, I am in the #ubertooth channel if anyone is there to chat.

John

On Mon, Dec 14, 2015 at 9:02 AM, Dominic Spill <dominicgs@...> wrote:

> On 14 December 2015 at 13:33, John Davis <davisjf@...> wrote:
> > Doing something similar I get:
> >
> > davis@...:~/progs$ ubertooth-rx -q sniff.pcap -r sniff.pcapng
> > systime=1450099810 ch=39 LAP=1b150f err=1 clk100ns=2718876754 clk1=435020
> > s=-69 n=-77 snr=8
> > systime=1450099810 ch=39 LAP=54f4c1 err=0 clk100ns=2718988783 clk1=435038
> > s=-47 n=-77 snr=30
>
> > If I open the two capture files in wireshark, it has missing columns for
> > source and destination.  All packets are shown as unkown and are 22
> bytes in
> > length.
>
> The source and destination address in Wireshark refer to the source
> and destination MAC addresses for Ethernet, they are not relevant to
> Bluetooth packets as the packets do not contain a source and
> destination address.  All packets contain parts of the address of the
> master device.
>
> The packets here are of unknown length because we have not been able
> to decode enough about them to read the packet headers.  All that we
> know is the LAP and receive time.  This is why the packets are so
> short in Wireshark.  If you wish to improve the reception, you can try
> using ubertooth-rx with the -s option to scan through different
> channels, I usually find that this yields better data.
>
> Dominic
>
> > On Mon, Dec 14, 2015 at 8:22 AM, Hannibal Smith <h.smith05@...>
> wrote:
> >>
> >> John,
> >>
> >> nothing special, I just run ubertooth-rx with lap & uap. The packages
> >> shown by wireshark are between 22 and 42 bytes long.
> >>
> >> ------------------------------
> >> # ubertooth-rx -U0 -l 000830 -u 81 -r sniff.pcapng -q sniff.pcap
> >>
> >> systime=1450098845 ch=39 LAP=000830 err=0 clk100ns=863167307
> clk1=2235259
> >> s=0 n=-81 snr=81
> >> systime=1450098846 ch=39 LAP=000830 err=0 clk100ns=868336302
> clk1=2236086
> >> s=0 n=-82 snr=82
> >> CLK6 = 0x3b found after 2 total packets.
> >>
> >> Calculating complete hopping sequence.
> >> Hopping sequence calculated.
> >> 26536 initial CLK1-27 candidates
> >> systime=1450098848 ch=39 LAP=000830 err=0 clk100ns=895561933
> clk1=2240442
> >> s=-21 n=-82 snr=61
> >> systime=1450098848 ch=39 LAP=000830 err=0 clk100ns=895898047
> clk1=2240496
> >> s=-16 n=-83 snr=67
> >>
> >> Acquired CLK1-27 = 0x03998f6
> >> got CLK1-27
> >> clock offset = 3078902.
> >> systime=1450098851 ch=39 LAP=000830 err=0 clk100ns=895898047
> clk1=2240496
> >> s=-16 n=-83 snr=67
> >> Packet decoded with clock 0x40 (rv=2)
> >>   Type: DM1
> >>   LT_ADDR: 1
> >>   LLID: 1
> >>   flow: 0
> >>   payload length: 12
> >>   Data:  49 a3 a3 b2 44 03 4e f1 4d ab 86 63
> >>   Type: DM1
> >>   LT_ADDR: 1
> >>   LLID: 1
> >>   flow: 0
> >>   payload length: 12
> >>   Data:  49 a3 a3 b2 44 03 4e f1 4d ab 86 63
> >> systime=1450098868 ch=74 LAP=000830 err=0 clk100ns=733195114
> clk1=3787327
> >> s=-21 n=-76 snr=55
> >> Packet decoded with clock 0x40 (rv=1)
> >>   Type: NULL
> >>   Type: NULL
> >> systime=1450098868 ch=29 LAP=000830 err=0 clk100ns=737090197
> clk1=3787950
> >> s=-16 n=-120 snr=104
> >> Packet decoded with clock 0x40 (rv=1)
> >>   Type: NULL
> >>   Type: NULL
> >> systime=1450098868 ch= 9 LAP=000830 err=0 clk100ns=739839269
> clk1=3788390
> >> s=0 n=-120 snr=120
> >> Packet decoded with clock 0x40 (rv=1)
> >>   Type: NULL
> >>   Type: NULL
> >> systime=1450098871 ch= 2 LAP=000830 err=0 clk100ns=901735634
> clk1=3814293
> >> s=0 n=-59 snr=59
> >> Packet decoded with clock 0x40 (rv=1)
> >>   Type: POLL
> >>   Type: POLL
> >> ---------------
> >> ---------------
> >> No.     Time           Source                Destination
> >> Protocol Length Info
> >>       4 3.273074000
> >> Bluetooth 22     NULL
> >>
> >> Frame 4: 22 bytes on wire (176 bits), 22 bytes captured (176 bits)
> >> Bluetooth BR/EDR Baseband
> >>
> >> No.     Time           Source                Destination
> >> Protocol Length Info
> >>       5 432.769803600
> >> Bluetooth 34     HV1
> >>
> >> Frame 5: 34 bytes on wire (272 bits), 34 bytes captured (272 bits)
> >> Bluetooth BR/EDR Baseband
> >>
> >> No.     Time           Source                Destination
> >> Protocol Length Info
> >>       6 1275.492969500
> >> Bluetooth 22     NULL
> >>
> >> Frame 6: 22 bytes on wire (176 bits), 22 bytes captured (176 bits)
> >> Bluetooth BR/EDR Baseband
> >>
> >> No.     Time           Source                Destination
> >> Protocol Length Info
> >>       7 1275.882477800
> >> Bluetooth 22     AUX1
> >>
> >> Frame 7: 22 bytes on wire (176 bits), 22 bytes captured (176 bits)
> >> Bluetooth BR/EDR Baseband
> >>
> >> No.     Time           Source                Destination
> >> Protocol Length Info
> >>       8 1276.157385000
> >> Bluetooth 22     EV5/3-EV5
> >>
> >> Frame 8: 22 bytes on wire (176 bits), 22 bytes captured (176 bits)
> >> Bluetooth BR/EDR Baseband
> >>
> >> No.     Time           Source                Destination
> >> Protocol Length Info
> >>       9 862.850291900
> >> Bluetooth 22     DH5/3-DH5
> >>
> >> Frame 9: 22 bytes on wire (176 bits), 22 bytes captured (176 bits)
> >> Bluetooth BR/EDR Baseband
> >> --------------------------
> >>
> >>
> >>
> >>
> >> On 14.12.2015 13:53, John Davis wrote:
> >>
> >> Hannibal,
> >>
> >> I was trying to capture packets between two devices using an unencrypted
> >> SPP mode using classic bluetooth.  I only got packets which were 12
> bytes in
> >> length.  I'm curious about how you got your results.  Would it be
> possible
> >> to give some more details on what you did?
> >>
> >> On Mon, Dec 14, 2015 at 7:07 AM, Hannibal Smith <h.smith05@...>
> >> wrote:
> >>>
> >>> Hey,
> >>>
> >>> currently I try to sniff and decrypt the communication between a
> >>> Bluetooth Keyboard and an old Bluetooth 2.0 Dongle. Sadly I didn't find
> >>> any website or blog entry where someone did this before.
> >>>
> >>> ubertooth-rx shows only packages with type NULL,POLL and DM1 but
> >>> wireshark shows the handshake with DH5, EV5... So the communication
> >>> seems to be encrypted as well.
> >>> I found some tools like btcrack or btpincrack to decrypt the stream but
> >>> they are incompatible to the pcap(ng) format. Is there any tool out
> >>> there which is able to crack this communication or can anyone give me a
> >>> hint, how i will be able to achieve this?
> >>>
> >>>
> >>> Regards
> >>> Hannibal
> >>>
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> _______________________________________________
> >>> Ubertooth-general mailing list
> >>> Ubertooth-general@...
> >>> https://lists.sourceforge.net/lists/listinfo/ubertooth-general
> >>
> >>
> >>
> >>
> >> --
> >> John F. Davis
> >> 6 Kandes Court
> >> Durham, NC 27713
> >> 919-888-8358
> >>
> >> 独树一帜
> >>
> >>
> >>
> >
> >
> >
> > --
> > John F. Davis
> > 6 Kandes Court
> > Durham, NC 27713
> > 919-888-8358
> >
> > 独树一帜
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> > _______________________________________________
> > Ubertooth-general mailing list
> > Ubertooth-general@...
> > https://lists.sourceforge.net/lists/listinfo/ubertooth-general
> >
>

--
John F. Davis
6 Kandes Court
Durham, NC 27713
919-888-8358

独树一帜

On 14.12.2015 14:58, Dominic Spill wrote:
>
> If both the keyboard and dongle support Bluetooth 2.0, then they are
> likely paired using Secure Simple Pairing (SSP).  This isn't broken in
> the way that 4 digit pin has been, although I believe that some
> versions (Just Works?) are known to be vulnerable.
Do I need both with 2.0? I thought if only one device supports a higher
version than Bluetooth 2.0, they downgrade each other to 2.0.

>
> In this case, I would expect the NULL/POLL to be keep alive packets
> and DM1 packets to be carrying the HID data.  When you say that
> Wireshark shows the handshake, which packets do you mean?
I just thought these packages are some sort of handshake between the
devices. Wireshark shows packageinfo like EV5, DH3, DH5, AUX1, HV2.. etc

>
> Those tools only work for the older pin entry method of pairing and
> require you to sniff the pairing process, which is very hard to
> capture.  Your best option would be to start the connection, sniff
> with ubertooth-follow and then initiate the pairing, but I don't
> expect this process to be reliable and those tools still will not
> support our pcap format, although that is probably fixable.
ubertooth-follow is not working for me and I still don't get the exact
difference between -rx and -follow.

To capture the traffic I start ubertooth-rx with lap & uap on master,
then search for the keyboard and pair with it.

Is there a way to force no encryption between the devices?

On 14 December 2015 at 14:56, Hannibal Smith <h.smith05@...> wrote:
> On 14.12.2015 14:58, Dominic Spill wrote:
>
> Do I need both with 2.0? I thought if only one device supports a higher
> version than Bluetooth 2.0, they downgrade each other to 2.0.

Correct, they will use the most secure method that they both support,
unless you force them to do otherwise from the host software.

My point was that if both were 2.0, they would use SSP rather than the
older, broken, pairing method.  However, as was pointed out, SSP is
from the 2.1 spec, so your devices will likely use 4 digit pin.

>> In this case, I would expect the NULL/POLL to be keep alive packets
>> and DM1 packets to be carrying the HID data.  When you say that
>> Wireshark shows the handshake, which packets do you mean?
>
> I just thought these packages are some sort of handshake between the
> devices. Wireshark shows packageinfo like EV5, DH3, DH5, AUX1, HV2.. etc

This is Wireshark displaying the pcap recorded with ubertooth-follow?
It's highly likely that some of the packet types are spurious due to
decoding, etc.

> ubertooth-follow is not working for me and I still don't get the exact
> difference between -rx and -follow.

ubertooth-rx is the basic tool to listen for Bluetooth packets.  You
can stay on one channel or sweep channels, you can promiscuously sniff
for all piconets or provide a LAP to target just one.  IF you provide
a LAP, it will attempt to calculate the UAP and CLK then try to hop
along with the piconet.

ubertooth-follow tries to shortcut this process by using a Bluetooth
device to conenct to the piconet and retrieve the CLK value without
having to calculate it.  There are still timing issues, encryption and
EDR to deal with, but in some cases, such as with BT 1.2 mice with no
encryption, it can be quite accurate.

> To capture the traffic I start ubertooth-rx with lap & uap on master, then
> search for the keyboard and pair with it.
>
> Is there a way to force no encryption between the devices?

If your host is a linux system, then you can use hciconfig to set
parameters.  "hciconfig noencrypt" will disable encryption, and some
of the other settings may be of use to you too, such as setting the
allowed packet types.

I've seen varying levels of success with these settings. It seems that
existing connections can override your settings, so I'd suggest making
the changes before establishing the connection.

Dominic