本讨论聚焦于蓝牙2.0设备间的通信捕获与解密，涉及使用Ubertooth工具包进行监听的方法，以及如何尝试解密蓝牙键盘与旧版蓝牙适配器之间的加密通信。讨论中提到了多种蓝牙包类型及其含义，并探讨了Secure Simple Pairing (SSP)等配对方式的安全性。
原文 https://sourceforge.net/p/ubertooth/mailman/ubertooth-general/thread/CAEaoPMgDDb69MaKDgwQ%3D__SgKt1sLni882FcSxjyq_3VjGV%2BxA%40mail.gmail.com/#msg34693718
|
From: Hannibal Smith <h.smith05@gm...> - 2015-12-14 12:07:52
|
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 |
|
From: John Davis <davisjf@gm...> - 2015-12-14 12:53:41
|
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 独树一帜 |
|
From: Hannibal Smith <h.smith05@gm...> - 2015-12-14 13:22:14
|
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@...
> <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
>
> 独树一帜
>
>
|
|
From: John Davis <davisjf@gm...> - 2015-12-14 13:34:06
|
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 独树一帜 |
|
From: Dominic Spill <dominicgs@gm...> - 2015-12-14 13:58:37
|
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. |
|
From: Mark Nichols <mnichols@sp...> - 2015-12-16 18:17:53
|
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 |
|
From: Dominic Spill <dominicgs@gm...> - 2015-12-14 14:20:20
|
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 > |
|
From: Dominic Spill <dominicgs@gm...> - 2015-12-14 14:03:13
|
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 > |
|
From: John Davis <davisjf@gm...> - 2015-12-14 14:16:07
|
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 独树一帜 |
|
From: Hannibal Smith <h.smith05@gm...> - 2015-12-14 14:56:34
|
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? |
|
From: Dominic Spill <dominicgs@gm...> - 2015-12-16 11:43:21
|
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 |
扫一扫
2205
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
