ubertooth-general — General discussion for Project Ubertooth

[Ubertooth-general] shutting down Ubertooth-general

[Michael O. <mi...@os...>]

Thank you to everyone who has been a part of Ubertooth-general.  We at
Great Scott Gadgets appreciate all of the conversations and friendships
that have been forged here.  Over the last few years we have not given
our project-specific mailing lists the attention they deserve; instead
we have been focusing our efforts on Discord and GitHub.

Soon we will disable Ubertooth-general and our other project mailing
lists.  We will continue to operate GSG-announce:

https://pairlist4.pair.net/mailman/listinfo/gsg-announce

A link to the Ubertooth-general list archives will remain available at:

https://greatscottgadgets.com/ubertoothone/

Thank you!

Michael

[Ubertooth-general] Spectrum Analyser

[dolice t. <dol...@ya...>]

Hi,
I am Dolice,
I received a project from the Firme Pierburg and I would like through the spectrum Analyse how to analyze interference.

Sent from my iPhone

[Ubertooth-general] Ubertooth does not show all packets

[Enrique P. <pre...@gm...>]

Hi I bought a ubertooth chipset, and installed all software requirements
(even firmware), but when i sniff with ubertooth-btle -f -c /tmp/pipe (this
is a pipe for wireshark), i dont see any packet than LL LE protocol

[Ubertooth-general] Custom devices - Levolor

[Jason L. <jas...@gm...>]

I'm trying to reverse engineer the Levolor 3 button remotes.  They have a
bluetooth chip in them, but I can't find any bluetooth when they're
transmitting.  (I am able to capture bluetooth using other devices).
Whenever I press the button on the remote, I see a spike in the
waveform analyzer at 2453 mhz, and it is very prominent and repeatable.  It
ONLY ever comes at 2453 mhz.

Is there a way with Ubertooth One or anything, really, to monitor just the
2453 mhz frequency and dump the data out so I can analyze it in something
like Audacity?  I have multiple remotes and it should be VERY easy to
reverse engineer this once I can see just the 2453 mhz frequency.

Any thoughts, abuse, etc are appreciated.

I have this running in my VM and am running the 2020 release.

--Jason

-- 
All messages secured by 2ROT13 encryption.

[Ubertooth-general] Detecting Bluetooth 5 devices

[Vineet M. <vin...@gm...>]

Hi all,

I wanted to use Ubertooth One to detect Bluetooth connected devices. i read
that Ubertooth can sniff BLE devices and "some" Bluetooth classic
connections.

i am confused. Will it be able to detect people using hidden Bluetooth
headphones and mic?

Please advise.

Thank you.
Vineet

[Ubertooth-general] Are cheaper Ubertooth One clones worse than original?

[Alexei C. <ac...@al...>]

Hi, there are sellers on eBay selling new Ubertooth One for $50-$80 which is half of the price at any of the official retailers. I assume these are clones? If so, then two questions:

1. How to tell clones apart from the original (other than by price) -- where is the official Ubertooth One manufactured? China? And, what does the official box look like?
2. What could they have sacrificed to manage such a large reduction in price?

I asked one seller, but didn't get much info beyond that it might be a clone.

[Ubertooth-general] [help needed] BT security mode and level

[Desmond <yam...@ya...>]

Hi all, i am a starter in BT security and would like to ask everyone if anyone knows if i am able to leverage on ubertooth to determine the BT device's supported security mode and level?
Thanks!

Sent from Yahoo Mail on Android

Re: [Ubertooth-general] Transmit Bluetooth Classic

[Tyler T. <tyl...@gm...>]

Using the btbr.dfu file, I was able to successfully perform paging and inquiry commands. Etienne, thank you so much for your contribution and help - this is exactly what I was hoping to find!

Tyler
On Aug 3 2020, at 7:21 am, Etienne Helluy-lafont <eti...@un...> wrote:
> Actually the btbr firmware is totally different from bluetooth_rxtx and provides a different set of features.
>
> You need to compile the firmware and flash btbr.dfu.
>
> Then to get back the original ubertooth behavior, you'll have to flash bluetooth_rxtx.dfu again.
>
> Etienne
>
> De: "Tyler Tucker" <tyl...@gm...>
> À: "Etienne Helluy-lafont" <eti...@un...>, "ubertooth-general" <ube...@li...>
> Envoyé: Vendredi 31 Juillet 2020 19:25:35
> Objet: Re: [Ubertooth-general] Transmit Bluetooth Classic
>
>
> Ahh, I see this commit was made after the 2018-12-R1 release that I was using. I have downloaded and built the current master branch of ubertooth and now see the ubertooth-btbr script. However, whenever I send a command to the Ubertooth such as 'inquiry', I see a message like this:
> 12:53:46 | INFO | Starting BTCtlInquiryCmd
> without any LEDs coming on or further notification that anything is running. When I try to exit the ubertooth-btbr prompt using 'exit', it seems to hang and will only exit after I give it multiple ctrl+c inputs. The next time I run the script, I only get these two lines:
> 12:56:00 | INFO | Rx thread started
> 12:56:00 | INFO | USB connected
> and it never gets to the user prompt. The only way to get that prompt again is to unplug the ubertooth and plug it back in, then run ubertooth-btbr again. My ubertooth is currently using the 'bluetooth_rxtx.dfu' file, so I know that it has the ability to transmit. I can play around with reinstalling and checking permissions, but I wanted to share this in case anyone has dealt with something similar.
>
> Tyler
> On Jul 30 2020, at 9:09 am, Etienne Helluy-lafont <eti...@un...> wrote:
> > Hello folks,
> >
> > Sorry for the mis-threading, I just subscribed to that list.
> >
> >
> > For all your Bluetooth Classic transmitting needs, take a look at the btbr firmware.
> > It can do inquiries and paging both as slave and master, and even maintain a link-layer connection.
> >
> >
> > You can take a look at the READMEs here and here :
> > https://github.com/greatscottgadgets/ubertooth/tree/master/firmware/btbr/ (https://link.getmailspring.com/link/7CF...@ge.../0?redirect=https%3A%2F%2Fgithub.com%2Fgreatscottgadgets%2Fubertooth%2Ftree%2Fmaster%2Ffirmware%2Fbtbr%2F&recipient=dWJlcnRvb3RoLWdlbmVyYWxAbGlzdHMuc291cmNlZm9yZ2UubmV0)
> >
> >
> > https://github.com/greatscottgadgets/ubertooth/tree/master/host/python/ubtbr (https://link.getmailspring.com/link/7CF...@ge.../1?redirect=https%3A%2F%2Fgithub.com%2Fgreatscottgadgets%2Fubertooth%2Ftree%2Fmaster%2Fhost%2Fpython%2Fubtbr&recipient=dWJlcnRvb3RoLWdlbmVyYWxAbGlzdHMuc291cmNlZm9yZ2UubmV0)
> >
> >
> > Regards,
> > Etienne
> >
> >
> > _______________________________________________
> > Ubertooth-general mailing list
> > Ube...@li...
> > https://lists.sourceforge.net/lists/listinfo/ubertooth-general
>
>
>

Re: [Ubertooth-general] Transmit Bluetooth Classic

[Etienne Helluy-l. <eti...@un...>]

Actually the btbr firmware is totally different from bluetooth_rxtx and provides a different set of features. 
You need to compile the firmware and flash btbr.dfu. 

Then to get back the original ubertooth behavior, you'll have to flash bluetooth_rxtx.dfu again. 

Etienne 


De: "Tyler Tucker" <tyl...@gm...> 
À: "Etienne Helluy-lafont" <eti...@un...>, "ubertooth-general" <ube...@li...> 
Envoyé: Vendredi 31 Juillet 2020 19:25:35 
Objet: Re: [Ubertooth-general] Transmit Bluetooth Classic 

Ahh, I see this commit was made after the 2018-12-R1 release that I was using. I have downloaded and built the current master branch of ubertooth and now see the ubertooth-btbr script. However, whenever I send a command to the Ubertooth such as 'inquiry', I see a message like this: 
12:53:46 | INFO | Starting BTCtlInquiryCmd 
without any LEDs coming on or further notification that anything is running. When I try to exit the ubertooth-btbr prompt using 'exit', it seems to hang and will only exit after I give it multiple ctrl+c inputs. The next time I run the script, I only get these two lines: 
12:56:00 | INFO | Rx thread started 
12:56:00 | INFO | USB connected 
and it never gets to the user prompt. The only way to get that prompt again is to unplug the ubertooth and plug it back in, then run ubertooth-btbr again. My ubertooth is currently using the 'bluetooth_rxtx.dfu' file, so I know that it has the ability to transmit. I can play around with reinstalling and checking permissions, but I wanted to share this in case anyone has dealt with something similar. 

Tyler 

On Jul 30 2020, at 9:09 am, Etienne Helluy-lafont <eti...@un...> wrote: 



Hello folks, 
Sorry for the mis-threading, I just subscribed to that list. 

For all your Bluetooth Classic transmitting needs, take a look at the btbr firmware. 
It can do inquiries and paging both as slave and master, and even maintain a link-layer connection. 

You can take a look at the READMEs here and here : 
[ https://github.com/greatscottgadgets/ubertooth/tree/master/firmware/btbr/ | https://github.com/greatscottgadgets/ubertooth/tree/master/firmware/btbr/ ] 
[ https://github.com/greatscottgadgets/ubertooth/tree/master/host/python/ubtbr | https://github.com/greatscottgadgets/ubertooth/tree/master/host/python/ubtbr ] 

Regards, 
Etienne 
_______________________________________________ 
Ubertooth-general mailing list 
Ube...@li... 
https://lists.sourceforge.net/lists/listinfo/ubertooth-general 

Re: [Ubertooth-general] Transmit Bluetooth Classic

[Tyler T. <tyl...@gm...>]

Ahh, I see this commit was made after the 2018-12-R1 release that I was using. I have downloaded and built the current master branch of ubertooth and now see the ubertooth-btbr script. However, whenever I send a command to the Ubertooth such as 'inquiry', I see a message like this:
12:53:46 | INFO | Starting BTCtlInquiryCmd
without any LEDs coming on or further notification that anything is running. When I try to exit the ubertooth-btbr prompt using 'exit', it seems to hang and will only exit after I give it multiple ctrl+c inputs. The next time I run the script, I only get these two lines:
12:56:00 | INFO | Rx thread started
12:56:00 | INFO | USB connected
and it never gets to the user prompt. The only way to get that prompt again is to unplug the ubertooth and plug it back in, then run ubertooth-btbr again. My ubertooth is currently using the 'bluetooth_rxtx.dfu' file, so I know that it has the ability to transmit. I can play around with reinstalling and checking permissions, but I wanted to share this in case anyone has dealt with something similar.

Tyler
On Jul 30 2020, at 9:09 am, Etienne Helluy-lafont <eti...@un...> wrote:
> Hello folks,
>
> Sorry for the mis-threading, I just subscribed to that list.
>
>
> For all your Bluetooth Classic transmitting needs, take a look at the btbr firmware.
> It can do inquiries and paging both as slave and master, and even maintain a link-layer connection.
>
>
> You can take a look at the READMEs here and here :
> https://github.com/greatscottgadgets/ubertooth/tree/master/firmware/btbr/
>
> https://github.com/greatscottgadgets/ubertooth/tree/master/host/python/ubtbr
>
> Regards,
> Etienne
>
>
> _______________________________________________
> Ubertooth-general mailing list
> Ube...@li...
> https://lists.sourceforge.net/lists/listinfo/ubertooth-general

[Ubertooth-general] Transmit Bluetooth Classic

[Etienne Helluy-l. <eti...@un...>]

Hello folks, 
Sorry for the mis-threading, I just subscribed to that list. 

For all your Bluetooth Classic transmitting needs, take a look at the btbr firmware. 
It can do inquiries and paging both as slave and master, and even maintain a link-layer connection. 

You can take a look at the READMEs here and here : 
[ https://github.com/greatscottgadgets/ubertooth/tree/master/firmware/btbr/ | https://github.com/greatscottgadgets/ubertooth/tree/master/firmware/btbr/ ] 
[ https://github.com/greatscottgadgets/ubertooth/tree/master/host/python/ubtbr | https://github.com/greatscottgadgets/ubertooth/tree/master/host/python/ubtbr ] 

Regards, 
Etienne 

Re: [Ubertooth-general] Transmit Bluetooth Classic

[Tyler T. <tyl...@gm...>]

For my experiment, I can assume that all devices are connectable. I wanted to be able to provide a channel number because as far as I know, connectable devices follow a specific order of channels when in page scanning mode and would therefore hit that channel number if I had previously sniffed a paging request for that connectable device on that frequency. With the rate of hopping on Bluetooth however, I could probably get away with naively hopping channels while transmitting until I'm able to sniff a response from an SDR.
I have an SDR that is able to monitor multiple Bluetooth channels (currently 8 but I think I could get more), so I'm thankfully a little better off than monitoring one channel at a time. I initially planned on having my SDR as a Bluetooth sniffer and an Ubertooth as a transmitter, but it seems that while the Ubertooth has the ability to transmit, little code exists out there using that feature. I'll probably end up replacing the Ubertooth with a Linux-capable Bluetooth module, using BlueZ to send my commands, to avoid programming the Ubertooth from scratch. I'll give RedFang a look as well. Thank you for your advice, Mark.

Tyler
On Jul 27 2020, at 4:11 pm, mni...@sp... wrote:
> Without doing any research, my two cents: the other device needs to be connectable, regardless of discoverability. If it’s connectable and you know the lap, then yes, that should work in terms of an initial physical connection. See RedFang. You can muck with the scanning windows and timing with a stack like BlueZ, but you can’t pick a specific transmit channel via a standard HCI call. You would need a Vendor Specific Command, or an SDR to select a specific channel (and send out the paging packet).
>
>
> Not sure what picking a specific channel will buy you, as the other device (if it’s in page scanning mode; i.e. connectable), will be hopping through channels listening for its Device Access Code. Albeit at a much slower rate then the paging device (3200 hops/sec).
>
> Catching the connection, etc. with an Ubertooth is problematic as you may know the device address(es), but not the channel they will end up connecting on (a priori). However, if you do it enough times, and maybe have more then one Ubertooth, you should see the connection at some point. Or, back to the wide band SDR idea, like the fancy PCAP test equipment out there.
>
> Hope that helps,
>
> Mark
>
> From: Tyler Tucker <tyl...@gm...>
> Sent: Monday, July 27, 2020 3:01 PM
> To: mni...@sp...; ube...@li...
> Subject: Re: [Ubertooth-general] Transmit Bluetooth Classic
>
>
>
>
> Yeah I've been looking at BlueZ as another option. Essentially what I'd like to do is carry out a paging request replay attack where I would give a script an LAP and perhaps a channel number and it would send out paging requests on that channel for that LAP in the hopes that the device with that LAP would respond, revealing its position near the receiver. As far as I understand, this could be done to detect Bluetooth classic devices which are set in non-discoverable mode, given that you already know the LAP, which I can assume to have prior knowledge of for my experiment. Do you know if BlueZ offers this level of control?
>
>
> Thanks,
>
>
> Tyler
>
>
> On Jul 24 2020, at 1:45 pm, mni...@sp... (https://link.getmailspring.com/link/FCE...@ge.../0?redirect=mailto%3Amnichols%40spanalytics.com&recipient=dWJlcnRvb3RoLWdlbmVyYWxAbGlzdHMuc291cmNlZm9yZ2UubmV0) wrote:
> > Tyler,
> >
> >
> >
> >
> > Why not simply use a commercial Bluetooth dongle with BlueZ to connect to a device? Connecting would be sending paging packets.
> >
> >
> >
> > Unless I’m missing the point. But, as you point out, Ubertooth does not transmit AFAIK.
> >
> >
> >
> > Regards,
> >
> >
> >
> > Mark
> >
> >
> >
> >
> > From: Tyler Tucker <tyl...@gm... (https://link.getmailspring.com/link/FCE...@ge.../1?redirect=mailto%3Atylermtucker%40gmail.com&recipient=dWJlcnRvb3RoLWdlbmVyYWxAbGlzdHMuc291cmNlZm9yZ2UubmV0)>
> > Sent: Friday, July 24, 2020 1:30 PM
> >
> > To: ube...@li... (https://link.getmailspring.com/link/FCE...@ge.../2?redirect=mailto%3Aubertooth-general%40lists.sourceforge.net&recipient=dWJlcnRvb3RoLWdlbmVyYWxAbGlzdHMuc291cmNlZm9yZ2UubmV0)
> >
> > Subject: [Ubertooth-general] Transmit Bluetooth Classic
> >
> >
> >
> >
> >
> >
> >
> > Hey all,
> >
> >
> >
> >
> > I'm interested in using the Ubertooth One to transmit Bluetooth Classic paging packets. However, there doesn't seem to be any recent examples of transmitting with the Ubertooth that I can find. Is anyone familiar with existing code that could help me out?
> >
> >
> >
> >
> > Thanks,
> >
> >
> >
> >
> > Tyler

Re: [Ubertooth-general] Transmit Bluetooth Classic

[<mni...@sp...>]

Without doing any research, my two cents: the other device needs to be connectable, regardless of discoverability.  If it’s connectable and you know the lap, then yes, that should work in terms of an initial physical connection.  See RedFang.  You can muck with the scanning windows and timing with a stack like BlueZ, but you can’t pick a specific transmit channel via a standard HCI call.  You would need a Vendor Specific Command, or an SDR to select a specific channel (and send out the paging packet).

 

Not sure what picking a specific channel will buy you, as the other device (if it’s in page scanning mode; i.e. connectable), will be hopping through channels listening for its Device Access Code.  Albeit at a much slower rate then the paging device (3200 hops/sec).

 

Catching the connection, etc. with an Ubertooth is problematic as you may know the device address(es), but not the channel they will end up connecting on (a priori).  However, if you do it enough times, and maybe have more then one Ubertooth, you should see the connection at some point.  Or, back to the wide band SDR idea, like the fancy PCAP test equipment out there.

 

Hope that helps,

 

Mark

 

From: Tyler Tucker <tyl...@gm...> 
Sent: Monday, July 27, 2020 3:01 PM
To: mni...@sp...; ube...@li...
Subject: Re: [Ubertooth-general] Transmit Bluetooth Classic

 

Yeah I've been looking at BlueZ as another option. Essentially what I'd like to do is carry out a paging request replay attack where I would give a script an LAP and perhaps a channel number and it would send out paging requests on that channel for that LAP in the hopes that the device with that LAP would respond, revealing its position near the receiver. As far as I understand, this could be done to detect Bluetooth classic devices which are set in non-discoverable mode, given that you already know the LAP, which I can assume to have prior knowledge of for my experiment. Do you know if BlueZ offers this level of control?

 

Thanks,

 

Tyler

 

On Jul 24 2020, at 1:45 pm, mni...@sp... <mailto:mni...@sp...>  wrote:

Tyler,

 

 

 

Why not simply use a commercial Bluetooth dongle with BlueZ to connect to a device?  Connecting would be sending paging packets. 

 

 

 

Unless I’m missing the point.  But, as you point out, Ubertooth does not transmit AFAIK.

 

 

 

Regards,

 

 

 

Mark

 

 

 

 

 

From: Tyler Tucker <tyl...@gm... <mailto:tyl...@gm...> >

Sent: Friday, July 24, 2020 1:30 PM

To: ube...@li... <mailto:ube...@li...> 

Subject: [Ubertooth-general] Transmit Bluetooth Classic

 

 

Hey all,

 

 

I'm interested in using the Ubertooth One to transmit Bluetooth Classic paging packets. However, there doesn't seem to be any recent examples of transmitting with the Ubertooth that I can find. Is anyone familiar with existing code that could help me out?

 

 

Thanks,

 

 

Tyler

  <https://link.getmailspring.com/open/8F3...@ge...?me=99d3312a&recipient=bW5pY2hvbHNAc3BhbmFseXRpY3MuY29t> 

Re: [Ubertooth-general] Transmit Bluetooth Classic

[Tyler T. <tyl...@gm...>]

Yeah I've been looking at BlueZ as another option. Essentially what I'd like to do is carry out a paging request replay attack where I would give a script an LAP and perhaps a channel number and it would send out paging requests on that channel for that LAP in the hopes that the device with that LAP would respond, revealing its position near the receiver. As far as I understand, this could be done to detect Bluetooth classic devices which are set in non-discoverable mode, given that you already know the LAP, which I can assume to have prior knowledge of for my experiment. Do you know if BlueZ offers this level of control?

Thanks,
Tyler
On Jul 24 2020, at 1:45 pm, mni...@sp... wrote:
> Tyler,
>
>
> Why not simply use a commercial Bluetooth dongle with BlueZ to connect to a device? Connecting would be sending paging packets.
>
> Unless I’m missing the point. But, as you point out, Ubertooth does not transmit AFAIK.
>
> Regards,
>
> Mark
>
>
> From: Tyler Tucker <tyl...@gm...>
> Sent: Friday, July 24, 2020 1:30 PM
> To: ube...@li...
> Subject: [Ubertooth-general] Transmit Bluetooth Classic
>
>
>
>
> Hey all,
>
>
> I'm interested in using the Ubertooth One to transmit Bluetooth Classic paging packets. However, there doesn't seem to be any recent examples of transmitting with the Ubertooth that I can find. Is anyone familiar with existing code that could help me out?
>
>
> Thanks,
>
>
> Tyler

Re: [Ubertooth-general] Transmit Bluetooth Classic

[<mni...@sp...>]

Tyler,

 

Why not simply use a commercial Bluetooth dongle with BlueZ to connect to a device?  Connecting would be sending paging packets.  

 

Unless I’m missing the point.  But, as you point out, Ubertooth does not transmit AFAIK.

 

Regards,

 

Mark

 

 

From: Tyler Tucker <tyl...@gm...> 
Sent: Friday, July 24, 2020 1:30 PM
To: ube...@li...
Subject: [Ubertooth-general] Transmit Bluetooth Classic

 

Hey all,

 

I'm interested in using the Ubertooth One to transmit Bluetooth Classic paging packets. However, there doesn't seem to be any recent examples of transmitting with the Ubertooth that I can find. Is anyone familiar with existing code that could help me out?

 

Thanks,

 

Tyler

  <https://link.getmailspring.com/open/04B...@ge...?me=99d3312a&recipient=dWJlcnRvb3RoLWdlbmVyYWxAbGlzdHMuc291cmNlZm9yZ2UubmV0> 

[Ubertooth-general] Transmit Bluetooth Classic

[Tyler T. <tyl...@gm...>]

Hey all,

I'm interested in using the Ubertooth One to transmit Bluetooth Classic paging packets. However, there doesn't seem to be any recent examples of transmitting with the Ubertooth that I can find. Is anyone familiar with existing code that could help me out?
Thanks,
Tyler

[Ubertooth-general] BLE sniffing the pairing process...no LL_ENC_RSP but LL_ENC_REQ is there

[black h. <bl4...@gm...>]

Dear all, I would be glad to have some suggestions on the following
scenario concerning BLE sniffing and cracking.

During a capture I’m able to see the LL_ENC_REQ but the slave is not
responding with LL_ENC_RSP despite the subsequent LL_START_ENC_REQ (ref.
screenshot attached). It’s quite strange in my humble opinion. Do you have
any suggestions?

The master is an iphone7, the slave is a bluetooth keyboard, the sniffer hw
is an ubertooth one with latest updates.

Additionally, I would like to emphasize that the pairing process finish
correctly and I’m able to type on the phone by using the ble keyboard. Any
help will be experienced with gratitude.

Kindest Regards,
Gian

[Ubertooth-general] ubertooth-btle stops getting packet from ubertooth one hardware

[Uddin, M. (N. - US/Holmdel) <mos...@no...>]

When I run the following command
Ubertooth-btle -A37 -n
After some period of time I don't see any packet captured by the ubertooth one.
I did some debugging, It seems after certain time/or for certain cause ubertooth firmware packet queue gets empty. Therefore ubertooth-btle doesn't get any packet from the ubertooth one. I was wondering can there be an issue of handling unexpected size packet in DMA handler at 'le_DMA_IRQHandler' ??

Regards
Mostafa

[Ubertooth-general] increase FFT for ubertooth-specan-ui

[Nathan T. <nat...@gm...>]

Is there a way to increase the FFT of the specan-ui?  Im doing testing to
see if the ubertooth can be used as a good spectrum survey tool for mobile
uses, that said the current FFT is pretty low and Id like it somewhat more
defined to pick out signals.

[Ubertooth-general] Ubertooth jamming BLE and Bluetooth

[<aro...@we...>]

Hello,

I've been experimenting with the Ubertooth for some time now. I am currently focusing on jamming Bluetooth and Bluetooth low energy (BLE). The Ubertooth successfully follows my BLE connection but the jamming doesn't work with the ubertooth -p -i command.
This is a bug in the firmware. I already tested some firmware versions (also 2017-03-R2) but nowhere does jamming work.

My Idea is now to let the Ubertooth follow a Connection and etablish the jamming part separately. Does anyone know a way to accomplish that?
I'm Pretty new to that topic so excuse for the noobish question.

Thanks,
Aron

Re: [Ubertooth-general] FHS packet

[Cinaed S. <cin...@gm...>]

On 1/21/19 6:17 PM, Cathy Zanetti wrote:

> Another question, are there any plans to resurrect the gr-bluetooth code? In
> terms of covering EDR, I know that the Ubertooth cannot do that because
> of the DQPSK/DPSK. With HackRF also being on the market, I was just
> wondering if there were efforts looking to port back to gnuradio to
> capture the EDR traffic as well? 

gr-bluetooth builds and installs under the current version of gnuradio
3.7.13.4.

It might not build in the next major revision to 3.8.

I had to play with my build environment variables - even after I
modified the FindBTBB file and passed the environment variables to Cmake
and modified the pkconfig path.

And the 'make test' commands fails because the paths in the qa script
are rooted in /home/chris, the swig file needs to be renamed from
_gr_bluetooth.so to _gr_bluetooth, and the import line in the python
test script needs to be changed to match the swig filename.

Unfortunately, I haven't had time to do anything with it - I'm still
trying to learn bluetooth.

-- Cinaed

Re: [Ubertooth-general] FHS packet

[Dominic S. <dom...@gm...>]

On Mon, 21 Jan 2019 at 19:18, Cathy Zanetti <cat...@gm...> wrote:
>
> Thanks for taking time to answer my questions. I'm a big fan. So, from
reading the specs, it looks like the FHS packet should be sent each time a
new connection is made, regardless of whether pairing needs to occur. It
looks like that packet is part of the paging sequence. So, it would occur
even if devices knew one another already (or am I missing something?).

I believe you are correct.  If you could set up two devices to connect and
disconnect repeatedly, you may be lucky enough to catch one.

> The reason I'm so interested in this packet is that it identifies the
BD_ADDR of the master device, which would be really helpful in sniffing
traffic between the master and slave, if I have a priori knowledge of the
slave. Ideally, if I could capture the paging interaction, I could start
hopping along with the master.

It's definitely a straight forward way to get the address of the master
device, but Ubertooth will also get you that information.  However, the
really useful information is the master device's clock value so that we can
calculate the hopping pattern.

> Another question, are there any plans to resurrect the gr-bluetooth code?

Mikeand I were talking about this a few days ago (in relation to your first
email), we were surprised that nobody had tried to use multiple SDRs or a
single ~100 MHz wide SDR to capture all Bluetooth channels.  This is the
most likely scenario for us to resurrect gr-bluetooth. I'm not sure if we'd
build it as a GNU radio block in the future, as it only relies on a small
subset of GNU Radio features, although a multi-channel one may use many
more.

> In terms of covering EDR, I know that the Ubertooth cannot do that
because of the DQPSK/DPSK. With HackRF also being on the market, I was just
wondering if there were efforts looking to port back to gnuradio to capture
the EDR traffic as well?

A wide band, all channel, SDR based approach would have the advantage of
supporting BR, EDR, and BLE simultaneously.  It's certainly an attractive
prospect in that sense, but there are some hurdles to overcome.

Thanks,
  Dominic

> On Mon, Jan 21, 2019 at 5:21 PM Dominic Spill <dom...@gm...> wrote:
>>
>> Hi Cathy,
>>
>> I can't remember if I've seen an FHS packet or not, but if I have it was
only once or twice.  You're right, there is code to decode it in libbtbb,
and I believe it should work if you come across one.
>>
>> While the hopping pattern whole pairing is different from normal
operation, we could see it if we happen to be on the right channel at the
right time, i.e. if we don't try to hop with the connection but stay on a
single channel.  The problem is that they packets are so infrequent because
they only appear in the pairing process.  It may be possible to force a
pair of devices to forget each other and re-pair repeatedly until they
happen to do so on the channel that you're monitoring.
>>
>> Thanks,
>>   Dominic
>>
>> On Fri, 18 Jan 2019 at 11:58, Cathy Zanetti <cat...@gm...>
wrote:
>>>
>>> Has anyone successfully received a FHS packet using Ubertooth? I know
it has an alterred hopping pattern and a longer period between hopping. I
searched the archives but wasn't sure if there was a way to do it? I know
there are functions in libbtbb to decode it, but does that require firmware
changes to even receive it? Thanks!
>>>
>>> Cathy
>>> _______________________________________________
>>> Ubertooth-general mailing list
>>> Ube...@li...
>>> https://lists.sourceforge.net/lists/listinfo/ubertooth-general

Re: [Ubertooth-general] FHS packet

[Cathy Z. <cat...@gm...>]

Hi Dominic,

Thanks for taking time to answer my questions. I'm a big fan. So, from
reading the specs, it looks like the FHS packet should be sent each time a
new connection is made, regardless of whether pairing needs to occur. It
looks like that packet is part of the paging sequence. So, it would occur
even if devices knew one another already (or am I missing something?). The
reason I'm so interested in this packet is that it identifies the BD_ADDR
of the master device, which would be really helpful in sniffing traffic
between the master and slave, if I have a priori knowledge of the slave.
Ideally, if I could capture the paging interaction, I could start hopping
along with the master. Another question, are there any plans to resurrect
the gr-bluetooth code? In terms of covering EDR, I know that the Ubertooth
cannot do that because of the DQPSK/DPSK. With HackRF also being on the
market, I was just wondering if there were efforts looking to port back to
gnuradio to capture the EDR traffic as well?

Thanks again for answering me!
Best,
Cathy

On Mon, Jan 21, 2019 at 5:21 PM Dominic Spill <dom...@gm...> wrote:

> Hi Cathy,
>
> I can't remember if I've seen an FHS packet or not, but if I have it was
> only once or twice.  You're right, there is code to decode it in libbtbb,
> and I believe it should work if you come across one.
>
> While the hopping pattern whole pairing is different from normal
> operation, we could see it if we happen to be on the right channel at the
> right time, i.e. if we don't try to hop with the connection but stay on a
> single channel.  The problem is that they packets are so infrequent because
> they only appear in the pairing process.  It may be possible to force a
> pair of devices to forget each other and re-pair repeatedly until they
> happen to do so on the channel that you're monitoring.
>
> Thanks,
>   Dominic
>
> On Fri, 18 Jan 2019 at 11:58, Cathy Zanetti <cat...@gm...>
> wrote:
>
>> Has anyone successfully received a FHS packet using Ubertooth? I know it
>> has an alterred hopping pattern and a longer period between hopping. I
>> searched the archives but wasn't sure if there was a way to do it? I know
>> there are functions in libbtbb to decode it, but does that require firmware
>> changes to even receive it? Thanks!
>>
>> Cathy
>> _______________________________________________
>> Ubertooth-general mailing list
>> Ube...@li...
>> https://lists.sourceforge.net/lists/listinfo/ubertooth-general
>>
>

Re: [Ubertooth-general] FHS packet

[Dominic S. <dom...@gm...>]

Hi Cathy,

I can't remember if I've seen an FHS packet or not, but if I have it was
only once or twice.  You're right, there is code to decode it in libbtbb,
and I believe it should work if you come across one.

While the hopping pattern whole pairing is different from normal operation,
we could see it if we happen to be on the right channel at the right time,
i.e. if we don't try to hop with the connection but stay on a single
channel.  The problem is that they packets are so infrequent because they
only appear in the pairing process.  It may be possible to force a pair of
devices to forget each other and re-pair repeatedly until they happen to do
so on the channel that you're monitoring.

Thanks,
  Dominic

On Fri, 18 Jan 2019 at 11:58, Cathy Zanetti <cat...@gm...> wrote:

> Has anyone successfully received a FHS packet using Ubertooth? I know it
> has an alterred hopping pattern and a longer period between hopping. I
> searched the archives but wasn't sure if there was a way to do it? I know
> there are functions in libbtbb to decode it, but does that require firmware
> changes to even receive it? Thanks!
>
> Cathy
> _______________________________________________
> Ubertooth-general mailing list
> Ube...@li...
> https://lists.sourceforge.net/lists/listinfo/ubertooth-general
>

[Ubertooth-general] FHS packet

[Cathy Z. <cat...@gm...>]

Has anyone successfully received a FHS packet using Ubertooth? I know it
has an alterred hopping pattern and a longer period between hopping. I
searched the archives but wasn't sure if there was a way to do it? I know
there are functions in libbtbb to decode it, but does that require firmware
changes to even receive it? Thanks!

Cathy