Kismet and Ubertooth plugin

[sagfed]

Installing the new kismet 2021, on iMac OSX with ubertooth, for Bluetooth scanning. seems to be a problem because the respective plug-in could not be built … and the respective Kismet data source recognizing the ubertooth is therefore doesn’t appearing in kismet I have heard that retrofitting an older version from 2019 (kismet-2019-04-R1.tar.xz) from the kismet site www.kismet wireless.net/code/ should work, but unfortunately 2 files are missing after the tar extraction (the Makefile and the Makefile.inc) So raising impossible at least so far, the ubertooth use with kismet. Any help will be highly appreciated See also Ubertooth on kismet on OSX (issue #476) on the Ubertooth repository

[dragorn]

Makefile and makefile.inc are created as part of the configuration process, make sure to follow the build instructions at https://www.kismetwireless.net/docs/readme/quickstart/ . Those files are never distributed as part of kismet; they are autogenerated on a per-compile basis.

Compiling on MacOS needs extra effort and libraries, which are documented in the link above; extra libraries will be needed to build the ubertooth capture code, including libusb, libbtbb, and libubertooth; you will need to provide all of them and their development headers to be able to compile on macos. You will likely need to provide other libraries as well.

Ubertooth has not been tested under the latest macos versions - it may work, it may not, apple has been restricting access to devices and running non-appstore code to increasing degrees in recent releases, making it a less suitable platform for something that requires direct hardware access.

-m

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, December 3rd, 2021 at 2:49 PM, sagfed @.***> wrote:

Installing the new kismet 2021, on iMac OSX with ubertooth, for Bluetooth scanning. seems to be a problem because the respective plug-in could not be built … and the respective Kismet data source recognizing the ubertooth is therefore doesn’t appearing in kismet I have heard that retrofitting an older version from 2019 (kismet-2019-04-R1.tar.xz) from the kismet site www.kismet wireless.net/code/ should work, but unfortunately 2 files are missing after the tar extraction (the Makefile and the Makefile.inc) So raising impossible at least so far, the ubertooth use with kismet. Any help will be highly appreciated

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[sagfed]

Thank you, but it is strange because some Readme say to use make, and it is what I have used with the Kismet 2021 from GIT, using the following instruction (https://www.kismetwireless.net/docs/howto/osx/), and that version is working fine on iMac OSX, but without the ubertooth because of the missing Data Source option due to the missing driver.

The site here below is also stating that the old version 2019 should work with the Ubertooth, by compiling the correct driver: https://medium.com/@playswithfir3/kali-kismet-and-ubertooth-6452267a986 here also they use a makefile ...

if it is the ./configure that creates these files, then I will check that no errors are spotted during this process, thanks to have reminded me this

[dragorn]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, December 3rd, 2021 at 3:42 PM, sagfed @.***> wrote:

Thank you, but it is strange because some Readme say to use make, and it is what I have used with the Kismet 2021 from GIT, using the following instruction (https://www.kismetwireless.net/docs/howto/osx/), and that version is working fine on iMac OSX, but without the ubertooth because of the missing Data Source option due to the missing driver.

You have to provide all the required libraries to be able to build the ubertooth driver, including, off the top of my head, libtbb, libusb, and libubertooth; you have to install them, the development headers, and have them somewhere your compiler can find them. They are not part of Kismet, they are part of libusb and the ubertooth project, so Kismet does not provide them.

-m

[sagfed]

Yes, you are right ... I did all this, but when the compilation was ending by creating the plugins (with Kismet 2021), I got the following message (see here below) : And looking further on the net, it seems that it is a legacy issue of the kismet version released after 2019 ...

PLUGIN-INSTALL: plugin-ubertooth/ g++ -std=gnu++17 -Wall -Wno-unknown-warning-option -Wno-deprecated-declarations -Wno-format-truncation -Wno-unused-local-typedefs -Wno-unused-function -Wno-infinite-recursion -g -I. -fPIE -g -O2 -O3 -pthread -I/usr/local/Cellar/protobuf/3.17.3/include -DKS_STR_ENCODING_NONE -I/usr/include -I/Users/fredericgasiglia/bluethooth/src/kismet -I../../bluetooth_rxtx -g -fPIC -c packetsource_ubertooth.cc -o packetsource_ubertooth.o packetsource_ubertooth.cc:32:10: fatal error: 'packetsource.h' file not found

include

     ^~~~~~~~~~~~

---

The same plugin source (from Ubertooth) is running with all the Kismet version, until the version 2019, according this article: https://medium.com/@playswithfir3/kali-kismet-and-ubertooth-6452267a986

[sagfed]

Finally, I have recompiled my Kismet last Version 2021 from git (kismet 2021-00-GIT), using libbtbb 1.0 (2018-06-R1) , libubertooth 1.1 (2020-06-R1), then I have bypassed the ubertooth plugin installation because of the error stated above
(ln -s ../../ubertooth-2020-12-R1-2/host/kismet/plugin-ubertooth was executed from the kismet directory and at the sudo make plugins-install, the above error message was still displayed of the missing packetsource.h) Running the kismet in sudo mode, I can however see all the Data Source including the internal WIFI and the uberthooth device as kismet Data Source. (screen capture could be provided as necessary) However when I activate this Ubertooth interface to scan the bluetooth BTLE, I see only one BTLE (probably mine), any idea? Thank you in advance to let me know.

[defencore]

It seems to me that I have something similar with kismet_cap_nrf_51822

[dragorn]

Please remember that wireshark does not classify by device, nor does it validate checksums of incoming packets (for the most part). It certainly doesn't discard junk packets.

Kismet does both these things: Just because wireshark sees a packet, doesn't mean it's a valid packet. Many (if not all) of these capture devices spew garbage noise packets which are not devices, they are corrupted packets modified in-air. I've seen garbage packets on just about every bt capture device which range from "total garbage" to "nearly a packet, but still garbge".

You'll need to confirm the checksum of all packets you think are valid in wireshark, and identify if Kismet is not processing otherwise valid packets. I'm not aware of any endemic lack of processing of otherwise valid packets.

-m

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, December 23rd, 2021 at 2:05 PM, DEFENCORE @.***> wrote:

It seems to me that I have something similar with kismet_cap_nrf_51822

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you commented.Message ID: @.***>

[defencore]

Please remember that wireshark does not classify by device, nor does it validate checksums of incoming packets (for the most part). It certainly doesn't discard junk packets. Kismet does both these things: Just because wireshark sees a packet, doesn't mean it's a valid packet. Many (if not all) of these capture devices spew garbage noise packets which are not devices, they are corrupted packets modified in-air. I've seen garbage packets on just about every bt capture device which range from "total garbage" to "nearly a packet, but still garbge". You'll need to confirm the checksum of all packets you think are valid in wireshark, and identify if Kismet is not processing otherwise valid packets. I'm not aware of any endemic lack of processing of otherwise valid packets.

Thanks for the answer. Most likely it is so, that packets from devices that come far away are damaged and are simply rejected in Kismet. And all the packets in a row come to the Wireshark, although it is possible to extract MAC + RSSI from them. For the sake of experiment, I took my devices to another room, and the kismet did not see them, but the Wireshark sees.

I will probably look for other options on how to transfer data to Kismet.

[sagfed]

Thanks for your analysis, but in my case I have also enabled as test, the bluetooth of my iphone, nearby the antenna of my ubertooth and I believe that Kismet should have detect it ? (even if normal bluetooth and not BLE ?), and it is not ... I have in the meantime ordered the Hollong BLE Sniffer (that will work with a Mac OSX SW provided by shenzee and named ble_snifer that is linked to wireshark), I will keep you inform if it works better ...

[dragorn]

Sniffing bluetooth is exceptionally hard because of the protocol, and no - there's no reason to assume turning on an iphone near an ubertooth - or any other supported sniffer - will detect anything.

Kismet only supports BTLE mode on the ubertooth, and the other BT sniffer hardware is BTLE only as well. As such, it will only detect BTLE advertisements, so it's unlikely anything on the iphone would be generating those.

HCI mode is not sniffing, and uses the bluetooth discovery mode to find nearby devices - but only those in advertising mode, and only if the HCI manages to find them, which is also not a given.

Bluetooth is not wifi and is much less deterministic to detect - and essentially impossible to capture the same way you'd capture wi-fi; I suggest watching some of the talks about the ubertooth by mike ossmann, dominic spill, and mike ryan, to get some idea of the challenges, what the hw can actually do, and what the limits are - among other limitations, the ubertooth in ble mode can only capture a fixed portion of the frame, making it impossible for kismet (or other tools) to parse service definitions or represent the device fully. None of the supported hardware supports following btle connections and capturing data. BT is not wifi and works very differently.

-m

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, December 23rd, 2021 at 4:30 PM, sagfed @.***> wrote:

Thanks for your analysis, but in my case I have also enabled as test, the bluetooth of my iphone, nearby the antenna of my ubertooth and I believe that Kismet should have detect it ? (even if normal bluetooth and not BLE ?), and it is not ... I have in the meantime ordered the Hollong BLE Sniffer (that will work with a Mac OSX SW provided by -shenzee and named ble_snifer that is linked to wireshark), I will keep you inform ...

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you commented.Message ID: @.***>

[sagfed]

Yes, you are right BTLE and Bluetooth are completely different protocol But I retain that in my case it should work on a machine that is not OSX, and that is the OSX the issue, by the way are you aware of this BTLE experiment : https://twitter.com/non_maisdisdonc/status/1454174884448423946?s=24 The video is showing the kismet SW with undertooth running on PC, detecting BTLE on HumanBody !!!

[sagfed]

I have just received the hollong BTLE HW today, using their IMac SW it works fine, it displays at least in between 4 and 5 BTLE MAC address, however I will still investigate the Kismet and Ubertooth one issue