mikeryan / ice9-bluetooth-sniffer Goto Github PK

Wireshark-compatible all-channel BLE sniffer for bladeRF, with wideband Bluetooth sniffing for HackRF and USRP

License: GNU General Public License v2.0

C 71.26% CMake 0.82% C++ 27.63% Python 0.29%

bladerf ble-sniffer bluetooth bluetooth-le bluetooth-low-energy bluetooth-security bluetooth-sniffer bluetooth-sniffing hacking-tool hackrf information-security usrp wireless-security wireshark

ice9-bluetooth-sniffer's People

Contributors

Stargazers

Watchers

ice9-bluetooth-sniffer's Issues

install ice9-bluetooth-sniffer in bin

Currently the binary installs directly to the extcap directory. I suggest that it either installs to /usr/bin and symlinks to the extcap directory, or vice versa. While it makes sense to have in the extcap directory (duh), it is also useful for users to simply run, and having it in /usr/bin would make that much easier.

ice9-bluetooth crashes with "Illegal instruction: 4" on macOS 14.4.1

Testing how many channels a M1 MacBook Air can handle, and I'm getting the following error:

MacBook-Air:build xeno$ ./ice9-bluetooth -f /dev/random -s -C 20
Illegal instruction: 4

I manually installed libbladeRF from the latest master branch code. And I installed the other prerequisites with "brew install liquid-dsp hackrf uhd" (just incase I also did a brew update and brew upgrade liquid-dsp hackrf uhd just to make sure I was on the latest.

The crash is at the following according to lldb:

MacBook-Air:build xeno$ lldb ./ice9-bluetooth 
(lldb) target create "./ice9-bluetooth"
Current executable set to '/Users/xeno/ice9-bluetooth-sniffer/build/ice9-bluetooth' (x86_64).
(lldb) run -f /dev/random -s -C 20
Process 1823 launched: '/Users/xeno/ice9-bluetooth-sniffer/build/ice9-bluetooth' (x86_64)
warning: libobjc.A.dylib is being read from process memory. This indicates that LLDB could not read from the host's in-memory shared cache. This will likely reduce debugging performance.

Process 1823 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
    frame #0: 0x000000010908a312 libliquid.dylib`liquid_firdes_kaiser + 13
libliquid.dylib`liquid_firdes_kaiser:
->  0x10908a312 <+13>: vmovaps %xmm0, %xmm3
    0x10908a316 <+17>: vmovss 0x409de(%rip), %xmm0      ; liquid_version + 60, xmm0 = mem[0],zero,zero,zero 
    0x10908a31e <+25>: vucomiss %xmm2, %xmm0
    0x10908a322 <+29>: ja     0x10908a388               ; <+131>
Target 0: (ice9-bluetooth) stopped.

I also get the following warning during compilation which also suggests perhaps there's something wrong with brew's liquid-dsp package and brew install liquid-dsp is no longer sufficient?

MacBook-Air:build xeno$ make
[  5%] Generate Help Header
[ 11%] Building C object CMakeFiles/ice9-bluetooth.dir/bladerf.c.o
[ 17%] Building C object CMakeFiles/ice9-bluetooth.dir/bluetooth.c.o
[ 23%] Building C object CMakeFiles/ice9-bluetooth.dir/btbb/btbb.c.o
[ 29%] Building C object CMakeFiles/ice9-bluetooth.dir/burst_catcher.c.o
In file included from /Users/xeno/ice9-bluetooth-sniffer/burst_catcher.c:10:
/usr/local/include/liquid/liquid.h:6380:26: warning: redefinition of typedef 'qdsync_cccf' is a C11 feature [-Wtypedef-redefinition]
LIQUID_QDSYNC_DEFINE_API(LIQUID_QDSYNC_MANGLE_CCCF,
                         ^
/usr/local/include/liquid/liquid.h:6277:32: note: previous definition is here
typedef struct qdsync_cccf_s * qdsync_cccf;
                               ^
1 warning generated.
[ 35%] Building C object CMakeFiles/ice9-bluetooth.dir/fsk.c.o
In file included from /Users/xeno/ice9-bluetooth-sniffer/fsk.c:11:
/usr/local/include/liquid/liquid.h:6380:26: warning: redefinition of typedef 'qdsync_cccf' is a C11 feature [-Wtypedef-redefinition]
LIQUID_QDSYNC_DEFINE_API(LIQUID_QDSYNC_MANGLE_CCCF,
                         ^
/usr/local/include/liquid/liquid.h:6277:32: note: previous definition is here
typedef struct qdsync_cccf_s * qdsync_cccf;
                               ^
1 warning generated.
[ 41%] Building C object CMakeFiles/ice9-bluetooth.dir/hackrf.c.o
[ 47%] Building C object CMakeFiles/ice9-bluetooth.dir/hash.c.o
[ 52%] Building C object CMakeFiles/ice9-bluetooth.dir/help.c.o
[ 58%] Building C object CMakeFiles/ice9-bluetooth.dir/options.c.o
[ 64%] Building C object CMakeFiles/ice9-bluetooth.dir/pcap.c.o
[ 70%] Building C object CMakeFiles/ice9-bluetooth.dir/usrp.c.o
[ 76%] Building C object CMakeFiles/ice9-bluetooth.dir/pfbch2.c.o
[ 82%] Building C object CMakeFiles/ice9-bluetooth.dir/window.c.o
[ 88%] Building C object CMakeFiles/ice9-bluetooth.dir/main.c.o
In file included from /Users/xeno/ice9-bluetooth-sniffer/main.c:20:
/usr/local/include/liquid/liquid.h:6380:26: warning: redefinition of typedef 'qdsync_cccf' is a C11 feature [-Wtypedef-redefinition]
LIQUID_QDSYNC_DEFINE_API(LIQUID_QDSYNC_MANGLE_CCCF,
                         ^
/usr/local/include/liquid/liquid.h:6277:32: note: previous definition is here
typedef struct qdsync_cccf_s * qdsync_cccf;
                               ^
1 warning generated.
[ 94%] Building CXX object CMakeFiles/ice9-bluetooth.dir/vkfft/fft.cc.o
[100%] Linking CXX executable ice9-bluetooth
[100%] Built target ice9-bluetooth

Note: it's working on my 14.4.1 x86-based Mac, just not this M1 Mac. But it's possible and likely that the x86-based Mac has some older not-the-latest versions of software. I can upgrade the x86-based Mac to try and reproduce if needed, but I'd rather keep it in a working state if possible.

Not showing up in Wireshark interface.

I see it as a plugin, but it's not showing up.

Not using all available CPU resources on Ubuntu

I am testing the sniffer connected to an Ubuntu server with 24 cores / 48 threads and 128GB of RAM, because I want to throw as much power at it as possible, to confirm it's not missing packets compared to what other single-channel sniffers like Sniffle see.

lscpu
Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         46 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  48
  On-line CPU(s) list:   0-47
Vendor ID:               GenuineIntel
  Model name:            Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz
    CPU family:          6
    Model:               63
    Thread(s) per core:  2
    Core(s) per socket:  12
    Socket(s):           2
    Stepping:            2
    CPU max MHz:         3100.0000
    CPU min MHz:         1200.0000
...

When I run sudo ./ice9-bluetooth -l -i bladerf0 -s -v -w danger_zone.pcap the sniffer reports that it can't keep up

Channelizer too slow, use fewer channels
ch  39.6 Msamp/sec ( 41% realtime); agc 302.8 Msamp/sec (161% realtime)
Channelizer too slow, use fewer channels
ch  39.2 Msamp/sec ( 41% realtime); agc 299.5 Msamp/sec (159% realtime)
Channelizer too slow, use fewer channels

However, if I run sar -u 1 in parallel, I see that my CPUs are still always at least 77% idle. Here is an example of starting sar and then starting ice9-bluetooth and then canceling ice9-bluetooth (the 100% idle is while it's not running.)

08:23:39 AM     CPU     %user     %nice   %system   %iowait    %steal     %idle
08:23:40 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
08:23:41 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
08:23:42 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
08:23:43 AM     all      0.10      0.00      0.15      0.00      0.00     99.75
08:23:44 AM     all      0.15      0.00      0.23      0.00      0.00     99.62
08:23:45 AM     all     14.20      0.00      2.15      0.00      0.00     83.64
08:23:46 AM     all     19.19      0.00      1.80      0.00      0.00     79.01
08:23:47 AM     all     16.22      0.00      2.23      0.00      0.00     81.55
08:23:48 AM     all     18.91      0.00      1.83      0.00      0.00     79.26
08:23:49 AM     all     18.49      0.00      2.81      0.02      0.00     78.68
08:23:50 AM     all     17.12      0.00      2.54      0.00      0.00     80.35
08:23:51 AM     all     20.74      0.00      1.93      0.02      0.00     77.31
08:23:52 AM     all     20.43      0.00      1.52      0.00      0.00     78.05
08:23:53 AM     all     18.79      0.00      2.12      0.00      0.00     79.09
08:23:54 AM     all     18.72      0.00      1.34      0.00      0.00     79.94
08:23:55 AM     all     18.63      0.00      1.91      0.00      0.00     79.46
08:23:56 AM     all     19.22      0.00      1.73      0.00      0.00     79.06
08:23:57 AM     all     20.45      0.00      1.74      0.00      0.00     77.82
08:23:58 AM     all     20.51      0.00      2.20      0.00      0.00     77.29
08:23:59 AM     all     20.54      0.00      2.04      0.00      0.00     77.42
08:24:00 AM     all     19.41      0.00      2.23      0.00      0.00     78.36
08:24:01 AM     all     21.06      0.00      1.74      0.02      0.00     77.18
08:24:02 AM     all     20.14      0.00      1.89      0.00      0.00     77.97
08:24:03 AM     all     17.42      0.00      2.20      0.02      0.00     80.35
08:24:04 AM     all      0.13      0.00      0.00      0.00      0.00     99.87
08:24:05 AM     all      0.00      0.00      0.27      0.00      0.00     99.73
08:24:06 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
08:24:07 AM     all      0.00      0.00      0.00      0.00      0.00    100.00
08:24:08 AM     all      0.00      0.00      0.00      0.00      0.00    100.00

So basically this issue is to track if there's anything else that can be done to test why it's not parallelizing as much as possible, and thus not able to keep up with the traffic.

Add timestamps to packets

Need to propagate sample number through the receive pipeline and correlate that back to start time of reception.

BT Classic and BLE Sniffing does not record RSSI of packet.

First off, amazing code. Great to use and very easy to get going. Was wondering if this addition could be made.

Using a Bladerf 2.0 device to sniff BLE packets. Successfully able grab packet information such as advertising address, angle of arrival, time of arrival, etc. However, the RSSI recording seems to be missing from the packet information delivered to wireshark. I know that this can be hardware or even protocol dependent, but I believe that Bladerf has the capability to record these values. I am hoping to be able to record the RSSI from packets sent advertising and data channels.

I hope to use this value to approximate the location of a device. Please let me know if this is something that is possible to be added. Thanks!

SCAN_RSP data missing

For all the data I capture, I always see the SCAN_RSP data missing, as shown below:

Is this expected?

40 channel sniffing

Sorry for asking but you mentioned that ICE9 is able to listen to 4-40 channels simultaneously. But neither the HackRF, BladeRF and USRP (cheaper series) support the full 80MHz required for all 40 channels. Can you please elaborate on the 40 channel sniffing and how this could be done?

make install needs permissions on MacOS

I tried to follow the installation instructions on MacOS platform.

But I get this error when doing make install:

[100%] Built target ice9-bluetooth
Install the project...
-- Install configuration: "RelWithDebInfo"
-- Up-to-date: /usr/local/bin/ice9-bluetooth
CMake Error at cmake_install.cmake:41 (file):
  file INSTALL cannot set permissions on "/usr/local/bin/ice9-bluetooth":
  Operation not permitted.

I tried again using sudo make install and got this error message:

[100%] Built target ice9-bluetooth
Install the project...
-- Install configuration: "RelWithDebInfo"
-- Up-to-date: /usr/local/bin/ice9-bluetooth
CMake Error: failed to create symbolic link '/Applications/Wireshark.app/Contents/MacOS/extcap/ice9-bluetooth': Operation not permitted

When I start Wireshark, the ice9-bluetooth interface does not come up as an alternative capture interface.

Is there any know solution to this on MacOS?

Seg Fault with USRP B205Mini

On Ubuntu 22.04 latest source of ice9 sniffer built I'm seeing the following occur. This occurs with or without adding the usrp serial number after usrp-

valgrind ./ice9-bluetooth -l -c 2427 -C 20 -l -i usrp-xxxxxxx
==1706211== Memcheck, a memory error detector
==1706211== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1706211== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==1706211== Command: ./ice9-bluetooth -l -c 2427 -C 20 -i usrp-36CD6592F17E7F1EACB81A5792013E96
==1706211== 
==1706211== Invalid read of size 1
==1706211==    at 0x484ED16: strlen (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1706211==    by 0x5AA5602: strdup (strdup.c:41)
==1706211==    by 0x10FB3A: parse_options (options.c:105)
==1706211==    by 0x10CF1A: main (main.c:426)
==1706211==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==1706211== 
==1706211== 
==1706211== Process terminating with default action of signal 11 (SIGSEGV)
==1706211==  Access not within mapped region at address 0x0
==1706211==    at 0x484ED16: strlen (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1706211==    by 0x5AA5602: strdup (strdup.c:41)
==1706211==    by 0x10FB3A: parse_options (options.c:105)
==1706211==    by 0x10CF1A: main (main.c:426)
==1706211==  If you believe this happened as a result of a stack
==1706211==  overflow in your program's main thread (unlikely but
==1706211==  possible), you can try to increase the size of the
==1706211==  main thread stack using the --main-stacksize= flag.
==1706211==  The main thread stack size used in this run was 8388608.
==1706211== 
==1706211== HEAP SUMMARY:
==1706211==     in use at exit: 611,045 bytes in 5,511 blocks
==1706211==   total heap usage: 10,491 allocs, 4,980 frees, 1,006,240 bytes allocated
==1706211== 
==1706211== LEAK SUMMARY:
==1706211==    definitely lost: 0 bytes in 0 blocks
==1706211==    indirectly lost: 0 bytes in 0 blocks
==1706211==      possibly lost: 0 bytes in 0 blocks
==1706211==    still reachable: 611,045 bytes in 5,511 blocks
==1706211==         suppressed: 0 bytes in 0 blocks
==1706211== Rerun with --leak-check=full to see details of leaked memory
==1706211== 
==1706211== For lists of detected and suppressed errors, rerun with: -s
==1706211== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)

[ERROR @ /privatehost/libraries/libbladeRF/src/board/bladerf2/bladerf2.c:1241] bladerf2_set_frequency: Board state insufficient for operation (current "Firmware Loaded", requires "Initialized")

I just pulled a BladeRF out of the box, connected the antennas and USB, installed the prereqs and built on Mac. When I do

./ice9-bluetooth -l -c 2427 -C 20 -w ble.pcap -i bladerf0
I get

[WARNING @ /privatehost/libraries/libbladeRF/src/board/bladerf2/bladerf2.c:461] FPGA bitstream file not found.
[WARNING @ /privatehost/libraries/libbladeRF/src/board/bladerf2/bladerf2.c:462] Skipping further initialization...
[ERROR @ /privatehost/libraries/libbladeRF/src/board/bladerf2/bladerf2.c:1241] bladerf2_set_frequency: Board state insufficient for operation (current "Firmware Loaded", requires "Initialized").
ice9-bluetooth: Unable to set bladeRF center frequency: Insufficient initialization for the requested operation

Is there an additional setup step that isn't mentioned on the README.md that I should be doing to initialize the bitstream?

Cannot sniff packets while use l2ping

I have a head unit (car) which can pair with iphones using Bluetooth. I started ice9-bluetooth-sniffer with hackrf, it grabbed many packets. Given that, I tried to pair my phone with the head unit, but no packet related to that was captured.

I would assume that the head unit is a nondiscoverable device. Is it possible for ice9-bluetooth-sniffer to capture packets from/to such nondiscoverable device? Any hints/suggestions would be greatly appreciated!

ice9-bluetooth defaults to hackrf

Feel free to close this if you don't agree.

I feel the default of hackrf is less than ideal. I love the hackrf as much as the next person, but I would default to a more capable and likely radio like the bladerf. With a bladerf plugged in and no hackrf plugged in I get an avoidable error:

zero@theprophet ice9-bluetooth-sniffer % ice9-bluetooth -s -l -a                                                                                             (git)-[master] 
ice9-bluetooth: Invalid number of channels for HackRF, must be 20 or fewer

If at all possible, I feel the best user experience would be to automatically pick the most capable available radio, and then error if none are found. Keeping the existing ability for the user to select a radio, and "automagic default" makes more sense than simply defaulting to hackrf.

bug: ice9-bluetooth doesn't actually allow a value of 4 for -C

Per the help, -C should take a value >= 4:

./ice9-bluetooth --help                                                
Usage: ice9-bluetooth <-f <file.fc32> | -l> <-a | -c <center-freq> -C <chan>>
Captures Bluetooth packets using a HackRF, bladeRF, or USRP SDR.

Mandatory arguments:
    -f, --file=FILE         read input from fc32 file (cfile)
    -l, --capture           capture live (cannot combine with -f)

    -a, --all-channels      all-channel sniffing (requires bladeRF 2.0)
            or
    -c, --center-freq=FREQ  center frequency (in MHz)
    -C, --channels=CHAN     number of channels to capture (>= 4, divisible by 4)
snip

This is also indicated when choosing a value not divisible by 4:

./ice9-bluetooth -l -i bladerf0 -w channel_39_only.pcap -s -c 2480 -C 1
ice9-bluetooth: invalid channels, must be between 4 and 96 and divisible by

However, in practice, it does not accept the value of 4, and the lowest value possible is therefore 8.

user@asdf build % sudo ./ice9-bluetooth -l -i bladerf0 -w channel_39_only.pcap -s -c 2480 -C 4
[WARNING @ /privatehost/libraries/libbladeRF/src/board/bladerf2/bladerf2.c:165] FPGA v0.15.0 was detected, which requires firmware v2.5.0 or later. The device firmware is currently v2.4.0. Please upgrade the device firmware before continuing.

[WARNING @ /privatehost/libraries/libbladeRF/src/board/bladerf2/bladerf2.c:916] Oversample feature gain limit reached. RF Gain clamped to 11.
[ERROR @ /privatehost/libraries/libbladeRF/src/board/bladerf2/bladerf2.c:1057] Sample rate outside of OVERSAMPLE feature range
[ERROR @ /privatehost/libraries/libbladeRF/src/board/bladerf2/bladerf2.c:1002] bladerf2_set_rational_sample_rate: dev->board->set_sample_rate(dev, ch, integer_rate, &actual_integer_rate) failed: Provided parameter was out of the allowable range
ice9-bluetooth: Unable to set bladeRF sample rate: Provided parameter was out of the allowable range
user@asdf build % sudo ./ice9-bluetooth -l -i bladerf0 -w channel_39_only.pcap -s -c 2480 -C 8
[WARNING @ /privatehost/libraries/libbladeRF/src/board/bladerf2/bladerf2.c:165] FPGA v0.15.0 was detected, which requires firmware v2.5.0 or later. The device firmware is currently v2.4.0. Please upgrade the device firmware before continuing.

[WARNING @ /privatehost/libraries/libbladeRF/src/board/bladerf2/bladerf2.c:916] Oversample feature gain limit reached. RF Gain clamped to 11.
ch   0.9  samp/sec (  0% realtime); agc  65.1 Msamp/sec (543% realtime)
Channelizer too slow, use fewer channels
ch   8.0 Msamp/sec (100% realtime); agc  63.4 Msamp/sec (528% realtime)
ch   8.0 Msamp/sec (100% realtime); agc  64.9 Msamp/sec (541% realtime)
ch   8.0 Msamp/sec (100% realtime); agc  68.5 Msamp/sec (571% realtime)
snip

Seg fault using latest bladerf

I did a quick test between commit 41ef634 and the latest c123d83 commit from bladerf github's page. I install it using the /usr prefix along with lib/x86_64-linux-gnu cmake options.

With commit c123d83 and the all channels option on 22.04 Ubuntu with the bladeRFxA9 there is an immediate segmentation fault after the program loads and attempts to use the bladerf. With the previous commit 41ef634 it runs fine. This is from gdb with the newer libbladerf in place. Thought maybe it would help, dropping back to the older libbladerf for now.

tarting program: /usr/src/ice9-bluetooth-sniffer/build/ice9-bluetooth -l -i bladerf -a -w /home/dragon/all_channels.pcap
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff55ff640 (LWP 17143)]
[WARNING @ host/libraries/libbladeRF/src/board/bladerf2/bladerf2.c:1185] bandwidth assignements with oversample feature enabled yields unkown results
[New Thread 0x7ffff3bf9640 (LWP 17144)]
[New Thread 0x7ffff33f8640 (LWP 17145)]
[New Thread 0x7ffff2bf7640 (LWP 17146)]
[New Thread 0x7ffff23f6640 (LWP 17147)]
[New Thread 0x7ffff1bf5640 (LWP 17148)]
[New Thread 0x7ffff13f4640 (LWP 17149)]
[New Thread 0x7ffff0bf3640 (LWP 17150)]
[New Thread 0x7fffdbfff640 (LWP 17151)]
[New Thread 0x7fffdb7fe640 (LWP 17152)]
[New Thread 0x7fffdaffd640 (LWP 17153)]
[New Thread 0x7fffda7fc640 (LWP 17154)]
[New Thread 0x7fffd9ffb640 (LWP 17155)]
[New Thread 0x7fffd97fa640 (LWP 17156)]
[New Thread 0x7fffd8ff9640 (LWP 17157)]
[New Thread 0x7fffbbfff640 (LWP 17158)]
[New Thread 0x7fffbb7fe640 (LWP 17159)]
[New Thread 0x7fffbaffd640 (LWP 17160)]
[New Thread 0x7fffba7fc640 (LWP 17161)]
[New Thread 0x7fffb9ffb640 (LWP 17162)]
[New Thread 0x7fffb97fa640 (LWP 17163)]
[New Thread 0x7fffb8ff9640 (LWP 17164)]
[New Thread 0x7fff9bfff640 (LWP 17165)]
[New Thread 0x7fff9b7fe640 (LWP 17166)]
[New Thread 0x7fff9affd640 (LWP 17167)]
[New Thread 0x7fff9a7fc640 (LWP 17168)]
[New Thread 0x7fff99ffb640 (LWP 17169)]
[New Thread 0x7fff997fa640 (LWP 17170)]
[New Thread 0x7fff98ff9640 (LWP 17171)]
[New Thread 0x7fff7bfff640 (LWP 17172)]
[New Thread 0x7fff7b7fe640 (LWP 17173)]
[New Thread 0x7fff7affd640 (LWP 17174)]
[New Thread 0x7fff7a7fc640 (LWP 17175)]
[New Thread 0x7fff79ffb640 (LWP 17176)]
[New Thread 0x7fff797fa640 (LWP 17177)]
[New Thread 0x7fff78ff9640 (LWP 17178)]
[New Thread 0x7fff5bfff640 (LWP 17179)]
[New Thread 0x7fff5b7fe640 (LWP 17180)]
[New Thread 0x7fff5affd640 (LWP 17181)]
[New Thread 0x7fff5a7fc640 (LWP 17182)]
[New Thread 0x7fff59ffb640 (LWP 17183)]
[New Thread 0x7fff597fa640 (LWP 17184)]
[New Thread 0x7fff58ff9640 (LWP 17185)]
[New Thread 0x7fff3bfff640 (LWP 17186)]
[New Thread 0x7fff3b7fe640 (LWP 17187)]
[WARNING @ host/libraries/libbladeRF/src/board/bladerf2/common.c:356] The total sample throughput for the 1 active channel, 96 Msps, is greater than the recommended maximum sample throughput, 80 Msps. You may experience dropped samples unless the sample rate is reduced, or some channels are deactivated.

Thread 46 "ice9-bluetooth" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff3b7fe640 (LWP 17187)]
bladerf_rx_cb (bladerf=<optimized out>, stream=<optimized out>, meta=<optimized out>, samples=0x7ffff6944010, num_samples=393216, user_data=<optimized out>) at /usr/src/ice9-bluetooth-sniffer/bladerf.c:105                                                                                      
105             s->samples[i] = d[i];
(gdb) trace 
Tracepoint 1 at 0x55555555aa60: file /usr/src/ice9-bluetooth-sniffer/bladerf.c, line 105.                                
(gdb) backtrace                                                                                                          
#0  bladerf_rx_cb (bladerf=<optimized out>, stream=<optimized out>, meta=<optimized out>, samples=0x7ffff6944010,        
    num_samples=393216, user_data=<optimized out>) at /usr/src/ice9-bluetooth-sniffer/bladerf.c:105                      
#1  0x00007ffff7e4c239 in lusb_stream_cb () from /lib/x86_64-linux-gnu/libbladeRF.so.2                                   
#2  0x00007ffff6d0c5f5 in ?? () from /lib/x86_64-linux-gnu/libusb-1.0.so.0                                               
#3  0x00007ffff6d0d104 in ?? () from /lib/x86_64-linux-gnu/libusb-1.0.so.0                                               
#4  0x00007ffff6d0d661 in ?? () from /lib/x86_64-linux-gnu/libusb-1.0.so.0                                               
#5  0x00007ffff6d0e4ec in ?? () from /lib/x86_64-linux-gnu/libusb-1.0.so.0                                               
#6  0x00007ffff6d0fcd8 in libusb_handle_events_timeout_completed () from /lib/x86_64-linux-gnu/libusb-1.0.so.0           
#7  0x00007ffff7e4c8db in lusb_stream () from /lib/x86_64-linux-gnu/libbladeRF.so.2                                      
#8  0x00007ffff7e21242 in async_run_stream () from /lib/x86_64-linux-gnu/libbladeRF.so.2                                 
#9  0x00007ffff7e36a73 in bladerf2_stream () from /lib/x86_64-linux-gnu/libbladeRF.so.2                                  
#10 0x0000555555559b14 in bladerf_stream_thread (arg=0x55555560b260) at /usr/src/ice9-bluetooth-sniffer/bladerf.c:147    
#11 0x00007ffff6694b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442                              
#12 0x00007ffff6726a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81                                     
(gdb)

Update Commands in README

The commands under "Running" seem off a little bit from what is available and the capture live flag was missing.

Suggested changes:

./ice9-bluetooth-sniffer -c 2427 -C 20 -w ble.pcap to ./ice9-bluetooth -l -c 2427 -C 20 -w ble.pcap
./ice9-bluetooth-sniffer -f /dev/zero -s -C 20 to ./ice9-bluetooth -f /dev/zero -s -C 20

Segmentation fault while attempting to capture all channels

Thank you for creating this tool. I have encountered a problem while attempting to take it out for a spin.
Below are my SDR details:

mtc@demo:~/git/ice9-bluetooth-sniffer/build$ bladeRF-cli -e info -e version

  Board:                    Nuand bladeRF 2.0 (bladerf2)
  Serial #:                 xxxxxxxxxxxxxxxxxxxxxxxxxxxx
  VCTCXO DAC calibration:   0x1f7d
  FPGA size:                301 KLE
  FPGA loaded:              yes
  Flash size:               128 Mbit
  USB bus:                  2
  USB address:              2
  USB speed:                SuperSpeed
  Backend:                  libusb
  Instance:                 0


  bladeRF-cli version:        1.9.0-git-368f0ac9
  libbladeRF version:         2.5.0-git-368f0ac9

  Firmware version:           2.4.0-git-a3d5c55f
  FPGA version:               0.15.0 (configured by USB host)

I checked out and built this repo, as well as the bladeRF repo yesterday. However when I run this command:
./ice9-bluetooth -l -i bladerf0 -a -w all_channels.pcap
I get a segmentation fault. I rebuilt ice9-bluetooth with debug and got this output:

[WARNING @ host/libraries/libbladeRF/src/board/bladerf2/bladerf2.c:916] Oversample feature gain limit reached. RF Gain clamped to 11.
[WARNING @ host/libraries/libbladeRF/src/board/bladerf2/common.c:356] The total sample throughput for the 1 active channel, 96 Msps, is greater than the recommended maximum sample throughput, 80 Msps. You may experience dropped samples unless the sample rate is reduced, or some channels are deactivated.
=================================================================
==4323==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f69ce455800 at pc 0x5611ef019d94 bp 0x7f69cec54670 sp 0x7f69cec54660
READ of size 1 at 0x7f69ce455800 thread T45
    #0 0x5611ef019d93 in bladerf_rx_cb /home/mtc/git/ice9-bluetooth-sniffer/bladerf.c:104
    #1 0x7f69eb5af158 in lusb_stream_cb (/usr/local/lib/libbladeRF.so.2+0x46158)
    #2 0x7f69ea5ad5f4  (/lib/x86_64-linux-gnu/libusb-1.0.so.0+0xe5f4)
    #3 0x7f69ea5ae103  (/lib/x86_64-linux-gnu/libusb-1.0.so.0+0xf103)
    #4 0x7f69ea5ae660  (/lib/x86_64-linux-gnu/libusb-1.0.so.0+0xf660)
    #5 0x7f69ea5af4eb  (/lib/x86_64-linux-gnu/libusb-1.0.so.0+0x104eb)
    #6 0x7f69ea5b0cd7 in libusb_handle_events_timeout_completed (/lib/x86_64-linux-gnu/libusb-1.0.so.0+0x11cd7)
    #7 0x7f69eb5af7fa in lusb_stream (/usr/local/lib/libbladeRF.so.2+0x467fa)
    #8 0x7f69eb584241 in async_run_stream (/usr/local/lib/libbladeRF.so.2+0x1b241)
    #9 0x7f69eb5998c2 in bladerf2_stream (/usr/local/lib/libbladeRF.so.2+0x308c2)
    #10 0x5611ef01a1d5 in bladerf_stream_thread /home/mtc/git/ice9-bluetooth-sniffer/bladerf.c:146
    #11 0x7f69ea671b42 in start_thread nptl/pthread_create.c:442
    #12 0x7f69ea7039ff  (/lib/x86_64-linux-gnu/libc.so.6+0x1269ff)

0x7f69ce455800 is located 0 bytes to the right of 393216-byte region [0x7f69ce3f5800,0x7f69ce455800)
allocated by thread T45 here:
    #0 0x7f69eb7a4a37 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
    #1 0x7f69eb584649 in async_init_stream (/usr/local/lib/libbladeRF.so.2+0x1b649)

Thread T45 created by T0 here:
    #0 0x7f69eb748685 in __interceptor_pthread_create ../../../../src/libsanitizer/asan/asan_interceptors.cpp:216
    #1 0x5611ef02bc35 in main /home/mtc/git/ice9-bluetooth-sniffer/main.c:581
    #2 0x7f69ea606d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/mtc/git/ice9-bluetooth-sniffer/bladerf.c:104 in bladerf_rx_cb
Shadow bytes around the buggy address:
  0x0fedb9c82ab0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fedb9c82ac0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fedb9c82ad0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fedb9c82ae0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fedb9c82af0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0fedb9c82b00:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fedb9c82b10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fedb9c82b20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fedb9c82b30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fedb9c82b40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fedb9c82b50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==4323==ABORTING

Any clues?

GPU acceleration of channelizer

Lots of questions here. Do we go OpenCL or make separate impls for CUDA, Vulkan, Metal, etc? Are there any good implementations we can use or reference, for example clFFT or VkFFT? One promising example of a full channelizer is from gr-clenabled.

Remove dep on libbtbb

We use it for two things: detecting BR packets and dumping LE packets to PCAP. The second one should be easy, but the first one will require some work.

BLE ADV_IND Packets

On my computer in wireshark with ice9 I successfully catch adv_ind packets. However, I'm working on a project and it requires the get this packet's individual fft images. Is there way to use ice9 for this approach?

Support for USRP

Hi, may I ask what type of USRPs can use this? I tried USRP N310, but it showed unsupported.

Error while compiling

Getting errors while running make command.

/home/star/Documents/ice9-bluetooth-sniffer/bladerf.c: In function ‘bladerf_setup’:
/home/star/Documents/ice9-bluetooth-sniffer/bladerf.c:61:19: error: implicit declaration of function ‘bladerf_enable_feature’; did you mean ‘bladerf_enable_module’? [-Werror=implicit-function-declaration]
if ((status = bladerf_enable_feature(bladerf, BLADERF_FEATURE_OVERSAMPLE, true)) != 0)
^~~~~~~~~~~~~~~~~~~~~~
bladerf_enable_module
/home/star/Documents/ice9-bluetooth-sniffer/bladerf.c:61:51: error: ‘BLADERF_FEATURE_OVERSAMPLE’ undeclared (first use in this function); did you mean ‘BLADERF_ERR_RANGE’?
if ((status = bladerf_enable_feature(bladerf, BLADERF_FEATURE_OVERSAMPLE, true)) != 0)
^~~~~~~~~~~~~~~~~~~~~~~~~~
BLADERF_ERR_RANGE
/home/star/Documents/ice9-bluetooth-sniffer/bladerf.c:61:51: note: each undeclared identifier is reported only once for each function it appears in
/home/star/Documents/ice9-bluetooth-sniffer/bladerf.c: In function ‘bladerf_stream_thread’:
/home/star/Documents/ice9-bluetooth-sniffer/bladerf.c:109:97: error: ‘BLADERF_FORMAT_SC8_Q7’ undeclared (first use in this function); did you mean ‘BLADERF_FORMAT_SC16_Q11’?
if ((status = bladerf_init_stream(&stream, bladerf, bladerf_rx_cb, &buffers, num_transfers, BLADERF_FORMAT_SC8_Q7, channels / 2 * 4096, num_transfers, NULL)) != 0)
^~~~~~~~~~~~~~~~~~~~~
BLADERF_FORMAT_SC16_Q11
cc1: some warnings being treated as errors
CMakeFiles/ice9-bluetooth.dir/build.make:66: recipe for target 'CMakeFiles/ice9-bluetooth.dir/bladerf.c.o' failed
make[2]: *** [CMakeFiles/ice9-bluetooth.dir/bladerf.c.o] Error 1
CMakeFiles/Makefile2:99: recipe for target 'CMakeFiles/ice9-bluetooth.dir/all' failed
make[1]: *** [CMakeFiles/ice9-bluetooth.dir/all] Error 2
Makefile:129: recipe for target 'all' failed
make: *** [all] Error 2

Add support for connection following

This will require some deep surgery:

a comprehensive study of all buffering in firmware, libs, and host code
latency reduction through buffer shrinkage (may require changes to libhackrf)
allow the burst catchers to be reconfigured to different channels
flush all samples on a channel change?
need an algorithm for determining best center channel for hop

Error opening UHD: 11

Finally got around to updating the ice9-bluetooth tool on 22.04 w/ stock uhd and I'm back to now having an issue of using uhd. With the b205mini I get the following

ice9-bluetooth -i usrp-B205mini-xxxxx -l -c 2427 -C 20 -v
[INFO] [UHD] linux; GNU C++ version 11.3.0; Boost_107400; UHD_4.1.0.5-0
ice9-bluetooth: Error opening UHD: 11

Also not usable in wireshark.

parameterize build with cmake

conditionally build libhackrf, libbladerf, etc

(Request) X310 Support

I made a small change in usrp.c to include looking for a match of X300. While this does in fact allow ice9 to find and appear to use the X310, there's zero information going into the pcap file which is not the case for the currently supported b205mini.

I realize the X310 is not advertised as supported, just seeing if it's possible to include such support. With a UBX160 it would seem it could also scan/sniff with just as much bandwidth as the bladeRF overdrive feature.

feature request: scan only BLE advertising channels?

I don't know if this is possible with the BladeRF, but I'm wondering if it's possible to use its FPGA capability to only monitor the advertisement channels of 37, 38, and 39? That seems like it would be better than trying to monitor all channels, which my hardware (and I take it most hardware) can't keep up with.

mikeryan / ice9-bluetooth-sniffer Goto Github PK

ice9-bluetooth-sniffer's People

Contributors

Stargazers

Watchers

Forkers

ice9-bluetooth-sniffer's Issues

Recommend Projects

Recommend Topics

Recommend Org