nccgroup / sniffle Goto Github PK

While it’s possible to decrypt after capture with crackle, this has limitations. Connection parameter changes occurring over an encrypted link can’t be handled by the firmware since they’re also encrypted. This can be solved by implementing decryption within the firmware (when LTK is known). The firmware should also report back a flag with every packet indicating whether or not it was decrypted before being sent to the host, and the host can note this in the PCAP (the format supports this).

Planned for version 1.3

it would be great to add sniffle to pypi to ease installation process and increase visibility of this awesome sniffer

Can this or any other software you know of send a LMP message that it lost the pairing secret to force a repairing to other bluetooth devices you are trying to sniff?

Hi!

There are two sticks, one which is based on CC2652R (https://www.tindie.com/products/electrolama/zzh-cc2652r-multiprotocol-rf-stick/) and another which is based on CC2652RB (https://slae.sh/projects/cc2652/), that its form factor is better than TI development boards.

Have you flashed your firmware in those devices or similar ones (I mean not TI development boards)? Do you think it will be hard to support those devices?

Thanks!

I noticed that you always use the same Coding Indicator = 0 (S=8) for S=8 and S=2 coding schemes in those pcap frames where PHY is LE Coded.
Is there a way to get an actual Coding Indicator from the sniffer hardware?

I have seen that the sniffer can write pcaps and they work in wireshark. Would it be possible to have a module in wireshark that speaks with the sniffle firmware directly so we can directly sniff in wireshark?

When I try to build it complains that I do not have jdk7 installed, and I can't get a copy with a rational license for my mac. Can someone suggest what I need to update to make it work with a current version of openjdk?

Including handling of LL_SUBRATE_REQ. Might present some new challenges to sniffing encrypted connections, to be seen.

The ZZH cc2652r stick would be a better format for pentesting in the field. Would you be willing to support that in the future with a release image?

zzh stick on tindie

When I try to capture with Wireshark using the Sniffle 1.7 plugin, it freezes on my Linux setup.

When I use the command-line tools, I can capture into a PCAP that I can load into Wireshark just fine.

Perhaps this is specific to my environment, using:

• Xubuntu 22.04.1 LTS (as a VMware 16.2.4 Guest inside a Windows 11 host)
• Wireshark 3.6.2 (Git v3.6.2 packaged as 3.6.2-2)
• Sniffle 1.7 expanded from .zip (from the release Version 1.7)
• LAUNCHXL-CC26X2R1 with sniffle_cc2652r1.out (from the release Version 1.7)
• Using the instructions from the README.md (tried both the files copied and the symlink approach)

Strange is also that (after first use after install) using the "Sniffle BLE sniffer: sniffle" interface, I recall Wireshark showing a dialog to configure the Sniffle settings. However it doesn't seem to allow me to get into those settings again (though I did see them reflected in ~/.config/wireshark/preferences (for example to select the serial port to be used).

Hi,
the readme mentions that it should be possible to build the firmware for CC1352P, however, some modifications are required. Can you detail those modifications since I have a CC1352P1 Launchpad that I want to use.

Thank you!
Stefan

Don't gatekeep, release it to the public. We want to test!

I found that Sniffle version 1.3 cannot detect packets some time after the connection event. I thought that this was due to the fact that I may have incorrectly assembled the firmware for CC1352P1 and, therefore, I downloaded the ready-made firmware sniffle_cc1352.out for the original TI LAUNCHXL-CC1352R1, which I used for subsequent tests.
The results are the same.
Then I launched two versions of the Sniffle at the same time. Sniffle version 1.1 (CC1352P1) successfully tracked all the packets, Sniffle version 1.3 (LAUNCHXL-CC1352R1) stopped tracking packets some time after the connection.
An archive with pcap files and console output is attached.
sniffle.zip

I traced the advertisements of a specific device by using the MAC address filter:

./sniff_receiver.py -s /dev/cu.usbmodemL1100GTV1 -m d9:76:fd:15:1a:e3 -o 1249_double.pcap

Viewing the pcap file in Wireshark results in having the PDU source and destination being filled with Unknown_0x50655bda, for both, master and slave, while the adverting data and the connection request where filled with the with correct packet source and destination.

When I verify Release 1.4 (both sniffle_cc26x2r.out and
sniffle_cc2652rb.out) before flashing to my Launchpad CC2652R1F (as auto-detected by UniFlash) I get the following errors, first a red pop-up window stating:

Error! File: C:/Users/acer/Downloads/sniffle_cc26x2r.out: a data verification error occurred, file load failed.

And in the UniFlash Console:
[1/8/2021, 11:17:26 PM] [INFO] Cortex_M3_0: GEL Output: Memory Map Initialization Complete.
[1/8/2021, 11:17:30 PM] [INFO] Cortex_M4_0: GEL Output: Memory Map Initialization Complete.
[1/8/2021, 11:17:32 PM] [ERROR] Cortex_M4_0: File Loader: Verification failed: Values at address 0x00000000 do not match Please verify target memory and memory map.

I only installed UniFlash, no sdk or anything and I think I am using the correct firmware (both sniffle_cc26x2r.out and sniffle_cc2652rb.out) I think. Happens both on latest Debian and Windows. Any tips on how to go further? Maybe taking some of the jumpers of the Launchpad could help, or should I just upload and don't care about verifying?

Thank you!

Hi

I am seeing this:
Timestamp: 2.140122 Length: 15 RSSI: -64 Channel: 37 PHY: 1M
Ad Type: ADV_EXT_IND
ChSel: 0 TxAdd: 1 RxAdd: 0 Ad Length: 13
AuxPtr Chan: 5 PHY: 2M Delay: 191250 us
AdvMode: Non-connectable, non-scannable
AdvA: 4A:C9:C9:2E:B2:B0 (RPA) AdvDataInfo: F2 0D
47 0D 0C 19 B0 B2 2E C9 C9 4A F2 0D 05 E7 38
G . J 8

Timestamp: 2.331504 Length: 257 RSSI: -66 Channel: 5 PHY: 2M
Ad Type: ADV_EXT_IND
ChSel: 0 TxAdd: 1 RxAdd: 0 Ad Length: 255
AuxPtr Chan: 6 PHY: 2M Delay: 2490 us
AdvMode: Non-connectable, non-scannable
AdvDataInfo: F2 0D
47 FF 06 18 F2 0D 06 53 20 5D 16 45 23 11 22 33 44 55 66 77 88 99 00 11 22 33 44 55 66 77 88 99 00 11 22 33 44 55 66 77 88 99 00 11 22 33 44 55 66 77 88 99 00 11 22 33 44 55 66 77 88 99 00 11 22 33 44 55 66 77 88 99 00 11 22 33 44 55 66 77 88 99 00 11 22 33 44 55 66 77 88 99 00 11 22 33 44 55 66 77 88 99 00 5D 16 56 34 11 22 33 44 55 66 77 88 99 00 11 22 33 44 55 66 77 88 99 00 11 22 33 44 55 66 77 88 99 00 11 22 33 44 55 66 77 88 99 00 11 22 33 44 55 66 77 88 99 00 11 22 33 44 55 66 77 88 99 00 11 22 33 44 55 66 77 88 99 00 11 22 33 44 55 66 77 88 99 00 11 22 33 44 55 66 77 88 99 00 5D 16 34 12 11 22 33 44 55 66 77 88 99 00 11 22 33 44 55 66 77 88 99 00 11 22 33 44 55 66 77 88 99 00 11 22 33 44 55 66 77 88 99 00 11 22 33 44 55 66 77 88 99 00 11 22 33 44 55 66

But I am still expecting one AUX_CHAIN_IND packet after ADV_EXT_IND.
I use cc1352r1 as sniffer and S10e mobile phone as advertiser with nRF Connect app.

I have a CC2650STK lying around. BLE 5.1 in stead of BLE 5.2 (as for the 2652), and only 20KB of RAM.

Is it worth trying to get Sniffle running on this board, or is that a non-starter?

If I have the choice, which board I buy, which yoard to you recommend to use?

The LAUNCHXL-CC1352P1 or LAUNCHXL-CC1352P-4 also support 1GHz but that's not used by sniffle I guess. However, these boards or on my end the cheapest to get hands on.

Is there a video that I can refer to for the Installation and Configure Sniffle ?
ps:Apart from the steps written in the readme file.

Standalone desktop variant of TI SysConfig (1.4.0+1234) tool for Windows doesn't generate source files from the sniffle.syscfg file. I get an error message:

An attempt to set this to the invalid value cmdBle5GenericRx,cmdBle5Master,cmdBle5RadioSetup,cmdBle5Slave,cmdBleAdv,cmdBle5Initiator,cmdBle5Scanner,cmdFs was blocked. This is most likely due to a backwards compatiblity discrepancy. You can dismiss this error by either accepting the current value, or changing it to another one.

If I accept the current value files are generated but RF_cmdBle5Master etc. are undefined.
The screenshot is attached below:

How did you manage to get SysConfig to generate files? Maybe versions for Windows and for Linux are different?
Could you please shared your SysConfig generated files?

Hi there!

I am using the sniffer to compare the BLE 5.0 Longrange mode and the BLE 5.0 Legacy mode.
The device I am using is a LAUNCHXL-CC26X2R1.

I couldn't receive any messages under a RSSI value of approximately -90dBm.
According to texas Instruments it should be possible to receive signals at -103dBm with the Longrange mode.
Source: https://e2e.ti.com/blogs_/b/process/archive/2017/01/30/how-does-bluetooth-5-increase-the-achievable-range-of-a-bluetooth-low-energy-connection

Does anybody know whether this is possible?
I was only able to find settings, that filter signals greater than a certain RSSI value.
Is there a setting where i can specify that i only want to reveice signals smaller than -90dBm or signals down to -103dBm?

Anyway, thanks for the great piece of software. It worked perfectly otherwise.

The LP-CC2651P3 is listed as a supported hardware platform for Sniffle. I attempt to build Sniffle by following the instructions on the README.md file. But after flashing the built firmware to the LP-CC2651P3 board, I am not able to observe any output when running scanner.py or sniff_receiver.py

Build procedure:

1. Modify makefile, remove the dependency on syscfg
   BEFORE: %.obj: %.c $(CONFIGPKG)/compiler.opt syscfg
   AFTER: %.obj: %.c $(CONFIGPKG)/compiler.opt
2. Run make syscfg, specify PLATFORM = CC2651P31
3. Open the file ti_radio_config.c and comment out the line:
   .extFilterConfig.bAcceptSyncInfo = 0x0 according to: https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1090449/cc2651p3-sysconfig-including-bacceptsyncinfo-parameter-for-cmd_ble5_scanner
4. Run make sniffle.out to build the sniffle.out firmware binary.
5. Flash the file sniffle.out to the LP-CC2651P3 using make load

I receive a "Success" message after running make load

I run some of the python_cli tools scanner.py or sniff_receiver.py but they do not output any information.

I have multiple BLE devices near the LP-CC2651P3 board so I believe that I should see some output when the above tools are run.

Version Information:

DSLite version 12.0.0.2728
ARM GCC Toolchain: gcc version 11.2.1 20220111 (GNU Toolchain for the Arm Architecture 11.2-2022.02 (arm-11.14))
SimpleLink SDK: simplelink_cc13xx_cc26xx_sdk_6_10_00_29
Hardware: LP-CC2651P3

Information about the sniffle.out file:

$ sha1sum sniffle.out
ffb94008161f67ab48b89829d16e4da806111760 sniffle.out
$ file sniffle.out
sniffle.out: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, with debug_info, not stripped

$ ls -la sniffle.out
File size: 1579852 bytes

Any help in debugging this issue is greatly appreciated.

When I tried to flash Release 1.4 sniffle_cc1352r.out onto TI CC1352R1 LaunchPad using TI UniFlash, I was getting the above error. Can you please advise if I am missing something?

Are prebuilt binaries compatible with TI LAUNCHPAD CC1350 board?

https://www.ti.com/tool/LAUNCHXL-CC1350

Thanks!

I was trying to snif some packets between a custom device and a phone but the timestamp seems to skip ahead not sure why...
I attached the pcap. First jump at (12893) 33.86s and then multiple other times.
I see the same time jumps in the output.

I also get the errors below:

C:\Users\S\Sniffle-master\python_cli>python sniff_receiver.py -eH -m 48:55:5c:00:02:16 -s COM10 -o datamotoz2.pcap > datamotoz2.txt
Ignoring message: Incorrect length field!
Traceback (most recent call last):
File "C:\Users\S\Sniffle-master\python_cli\sniffle_hw.py", line 141, in recv_and_decode
return PacketMessage(mbody, self.decoder_state)
File "C:\Users\S\Sniffle-master\python_cli\sniffle_hw.py", line 244, in init
raise SniffleHWPacketError("Incorrect length field!")
sniffle_hw.SniffleHWPacketError: Incorrect length field!
Ignoring message: Incorrect padding
Ignoring message: Incorrect padding
Ignoring message: Incorrect padding
Ignoring message: Invalid base64-encoded string: number of data characters (17) cannot be 1 more than a multiple of 4
Traceback (most recent call last):
File "sniff_receiver.py", line 176, in
main()
File "sniff_receiver.py", line 125, in main
msg = hw.recv_and_decode()
File "C:\Users\S\Sniffle-master\python_cli\sniffle_hw.py", line 138, in recv_and_decode
mtype, mbody, pkt = self.recv_msg()
File "C:\Users\S\Sniffle-master\python_cli\sniffle_hw.py", line 121, in recv_msg
pkt = self.ser.readline()
File "C:\Users\S\AppData\Local\Programs\Python\Python38-32\lib\site-packages\serial\serialwin32.py", line 286, in read
result_ok = win32.GetOverlappedResult(
KeyboardInterrupt

datamotoz2.zip

Any help would be appreciated.

Thank you

Nice feature suggestion from Diana for when we don't know the IRK but have devices with a recognizable advertisement body or scan response body:

Implement scanner flags to specify hex strings to search for in advertisement and scan response data.

These would be extra host side filters. Only advertisers that meet the advertisement data and/or scan response search criteria would be printed out.

From Bluetooth 5.2, can be used for LE audio and other things. Similar to periodic advertising but not the same.

Hi, tried this on my Mac and it failed - here is the screen dump of the attempt to make.

bobtaylor@Bobs-MacBook-Pro Sniffle-master % cd fw
bobtaylor@Bobs-MacBook-Pro fw % make
Running Configuro...
Unable to find any JVMs matching version "1.7".
making package.mak (because of package.bld) ...
gnu.targets.arm.M4F: warning: failed to parse '-dumpversion' output (= ''); check compiler options
gnu.targets.arm.M4F: warning: can't determine gcc version;
Check if /Users/bobtaylor/ti/gcc-arm-none-eabi-9-2019-q4-major/bin/arm-none-eabi-gcc can run on
MacOS.
Also, try explicitly setting the GCCVERS configuration parameter.
gnu.targets.arm.M4F: warning: failed to parse '-v' output (= ''); check compiler options
gnu.targets.arm.M4F: warning: can't determine binutils version;
Check if /Users/bobtaylor/ti/gcc-arm-none-eabi-9-2019-q4-major/bin/arm-none-eabi-ld can run on
MacOS.
Also, try explicitly setting the BINVERS configuration parameter.
generating interfaces for package rtos_build (because package/package.xdc.inc is older than package.xdc) ...
configuring sniffle.xm4fg from package/cfg/sniffle_pm4fg.cfg ...
generating custom ROM library makefile ...
Starting build of library sources ...
making /Users/bobtaylor/ti/Sniffle-master/fw/rtos_build/package/cfg/sniffle_pm4fg.src/sysbios/rom_sysbios.am4fg ...
asmm4fg /Users/bobtaylor/ti/simplelink_cc13x2_26x2_sdk_3_40_00_02/kernel/tirtos/packages/ti/sysbios/family/arm/m3/Hwi_asm_gnu.sv7M ...
gmake[1]: *** [makefile:49: m3_Hwi_asm_gnu.o] Killed: 9
gmake: *** [/Users/bobtaylor/ti/Sniffle-master/fw/rtos_build/package/cfg/sniffle_pm4fg.src/makefile.libs:57: /Users/bobtaylor/ti/Sniffle-master/fw/rtos_build/package/cfg/sniffle_pm4fg.src/sysbios/rom_sysbios.am4fg] Error 2
Build of libraries failed.
error: xdc.cfg.SourceDir: "/Users/bobtaylor/ti/xdctools_3_60_02_34_core/packages/xdc/cfg/SourceDir.xs", line 209: xdc.cfg.SourceDir : Build of generated source libraries failed: exit status = 2:

js: "/Users/bobtaylor/ti/xdctools_3_60_02_34_core/packages/xdc/cfg/Main.xs", line 160: Error: Configuration failed!
gmake: *** [package.mak:218: package/cfg/sniffle_pm4fg.xdl] Error 1
gmake: *** Deleting file 'package/cfg/sniffle_pm4fg.xdl'
gmake: *** [package/cfg/sniffle_pm4fg.xdl] Deleting file 'package/cfg/sniffle_pm4fg.h'
gmake: *** [package/cfg/sniffle_pm4fg.xdl] Deleting file 'package/cfg/sniffle_pm4fg.c'
js: "/Users/bobtaylor/ti/xdctools_3_60_02_34_core/packages/xdc/tools/Cmdr.xs", line 52: Error: xdc.tools.configuro: configuration failed due to earlier errors (status = 2); 'linker.cmd' deleted.
make: *** [rtos_build/linker.cmd] Error 1
bobtaylor@Bobs-MacBook-Pro fw %

does the firmware for LAUNCHXL-CC1352P1 work out of the box on the new LAUNCHXL-CC1352P-4 board?

Hello, i have cc2652p board. Is it supported? What i need to change to build for this?

Hi,
is there a prebuild hex file to simply flash the eval boards?

best regards,
Torsten

As the Electrolama ZZH Stick is out of stock the CC2652RB stick by slaesh is the better alternative:
https://slae.sh/projects/cc2652/.

I guess it is basically the same as the ZZH but I don't know for sure.
It would be great if both, the slaesh stick and the zzh stick work, as they have a much better format than the development boards.

Do you think Sniffle could theoretically support the CC2640R2?

Thanks!

Hi,

unfortunately, I cannot build the firmware. I am getting the following errors:

`stefan@t460s:~/Programs/sources/Sniffle/fw$ make

Generating configuration files...
Running script...
Validating...
Generating Code...
'/ti/drivers/RF' -> '/ti/devices/driverlib'
'/ti/drivers/RF' -> '/ti/drivers'
'/ti/drivers' -> '/ti/devices/driverlib'
Unchanged /home/stefan/Programs/sources/Sniffle/fw/ti_devices_config.c...
Writing /home/stefan/Programs/sources/Sniffle/fw/ti_radio_config.c...
Unchanged /home/stefan/Programs/sources/Sniffle/fw/ti_radio_config.h...
Unchanged /home/stefan/Programs/sources/Sniffle/fw/ti_drivers_config.c...
Unchanged /home/stefan/Programs/sources/Sniffle/fw/ti_drivers_config.h...
Unchanged /home/stefan/Programs/sources/Sniffle/fw/ti_utils_build_linker.cmd.exp...
Unchanged /home/stefan/Programs/sources/Sniffle/fw/syscfg_c.rov.xs...
Building ti_radio_config.obj
ti_radio_config.c:484:6: error: 'rfc_ble5ScannerPar_t' {aka 'struct rfc_ble5ScannerPar_s'} has no member named 'auxChRes'
484 | .auxChRes = 0x00
| ^~~~~~~~
ti_radio_config.c:484:17: warning: excess elements in struct initializer
484 | .auxChRes = 0x00
| ^~~~
ti_radio_config.c:484:17: note: (near initialization for 'ble5ScannerPar')
ti_radio_config.c:556:6: error: 'rfc_ble5InitiatorPar_t' {aka 'struct rfc_ble5InitiatorPar_s'} has no member named 'auxChRes'
556 | .auxChRes = 0x00
| ^~~~~~~~
ti_radio_config.c:556:17: warning: excess elements in struct initializer
556 | .auxChRes = 0x00
| ^~~~
ti_radio_config.c:556:17: note: (near initialization for 'ble5InitiatorPar')
make: *** [makefile:142: ti_radio_config.obj] Error 1
`

Any ideas?

Hello! I like your solution very much and I think it is great!
I have a small question about your project plans.
Are there any plans to implement periodic advertising sniffing in the project?
Thank you

I am using a LAUNCHXL-CC26X2R1 with a CC2652R1, I cannot get the firmware to stay stable for any filtering. The board freezes if I use any filter. If I reset the board it will capture packets but does not apear to reflect the filters, All I can see are advertisements.

Is there anything I can do to make it more stable?

Currently we are after decent audio bluetooth pairs of devices on a consumer level. Such pairs are mainly in-ears and mobiles with android/ios. On our way about the how and why of such pairs we were pretty disenchanted, missing a lot of reasonable information from the vendors.
Without diving too deep into the Bluetooth workings or crafting software ourselves, we would like to learn more with the help of your package plus a CC1352R1 TI board, within the above described context.
Would appreciate if you advise us if answers to the following questions are possible regarding usage of Sniffle. Also, for additional workflow hints regarding tools before and thereafter along the questions, we thank you in advance.

Regarding connection details finding out

• Which BT protocol and version are negotiated between devices
• Which BT Profiles are negotiated between devices
• Which protocol is negotiated between devices
• Which codecs are used, especially any along the following: sbc, mpeg3, ldac, aptx(hd, ll, ad), lhdc in mono, stereo, dual, joint stereo.
• Which bitrate(kbps) are used between devices
• Which samplerate(kHz) are used between devices
• Possibility to trace any manual changes on either side of the devices

Regarding transmission details finding out

• What happens on loss of connection
• What happens on dropouts of transmission(on the audio stream, packet loss)
• Possibility to analyze jitter regarding latency or rate error

I just setup the project as described on a CC26X2R1 by following the instructions but I'm not able to get any output from the board. I tried both, Win10 and Ubuntu and building & flashing seem to work.
Any suggestion, what could went wrong here?

Thanks!

First of all, thank you @sultanqasim for this amazing project, I've seen your Youtube presentation and was very impressed with Sniffle.
I have a few questions:

1. Which one of the three TI Boards works more reliably with Sniffle? I'm leaning towards the TI CC1352R.
2. Would it make sense to get 3 sniffers to guarantee absolute BLE Coverage?
3. If the 2) is yes, how hard would it be to modify the python code for this purpose? Do you mean to support such an application in the future, or accept contributions?

Thanks again for this amazing project!

Hi,
First of all thanks a lot for publishing this excellent work!

I can successfully flash release v1.6 (sniffle_cc2652rb.out) to my LP-CC2652RB. The red LED blinks, and the python cli tools work as intended.

But when I try to build this binary myself, it doesn't work.
I do make clean and make platform=CC2652RB1F load, and the process generates a sniffle.out file, but when I flash that, the red LED stays off and there's no serial output from the board.
I tried this on macOS and Ubuntu, using the exact versions of the ARM compiler and the TI SDK that you mentioned, but both sniffle.out files don't work. I also checked out the v1.6 tag in git, to use the same version that you released, but to no avail.

Is there something special you do additionally, in order to create sniffle_cc2652rb.out?
Or any idea on how to debug this?

Thanks
Michael

Thanks very much for sharing this nice library.

I tried to sniff the below command, and it did not find anything:

# l2ping BTMAC

Can you confirm that l2ping is classic or LE? (I believe it's classic as Sniffle did not catch any packets during the ping).

is it feasible to provide modules for bettercap and kismet to make those work with the sniffle firmware? probably very nice as they have web UIs.

Packets with CRC errors give information about timings when they were transmitted. The CRC ok vs CRC not ok give information about utilization of the channel. Number of CRC errors may also give information on bad design of the transmitter (assuming sniffer is running on dev board from the chip manufacturer - these designs usually are very well designed in terms of antenna and low internal interferences).

I am trying to find out why the sniffer is able to follow the connection only in 44% cases (out of 25 tests). It seems that CONNECT_IND is seen on channels 0 and 39. No CONNECT_IND on channel 12. Maybe there are packets on channel 12 with CRC error ?
Please look at the file attached.
(btle.advertising_header.pdu_type == 0x0) && (btle_rf.channel == 0) gives 600 packets, while for 12 and 39 number of ADV_IND are 527 and 550 respectively. Not sure why, but having an option to see packets with CRC error may solve this mystery. Maybe there is another explanation ?

As of CONNECT_IND, use this filter to check that only channels 0 and 39 are present in the file.
btle.advertising_header.pdu_type == 0x5

Same for SCAN_REQ - no SCAN_REQ packets on channel 12 reported.

sniffer-ti-iphone-to-telink.zip

The scan file was created using Wireshark, with non empty "MAC address" option field. The board was CC1352R1.

The connection sniffing work 100% for NRF52840 board that has 493 us between end of ADV_IND and beginning of another ADV_IND. The Telink TLSR8250 has 880 us. Here are the timings done using a commercial sniffer with precise time measurements.

SimpleLink™ cc13xx_cc26xx SDK 6.20.00.29 removes support for UART in favor of the UART2 driver.

https://software-dl.ti.com/simplelink/esd/simplelink_cc13xx_cc26xx_sdk/6.20.00.29/exports/release_notes_simplelink_cc13xx_cc26xx_sdk_6_20_00_29.html

Sniffle appears to use UART in messenger.c/h files and also the sniffle.syscfg file.

UART is removed from the SimpleLink SDK in 6.20.00.29. Sniffle will not build when using SimpleLInk SDK 6.20.00.29 or newer SDK 6.20.00.29 contains both the UART and UART2 drivers.

It would be nice for the sniffer firmware to be able to resolve RPAs when it knows the IRK. Planned for version 1.3.

I use uniflash to load the 1.5 release file sniffle_cc1352p1.out onto a CC1352-P2 Launchpad. Before that I completely erased the flash using uniflash. After loading the file I verified it successfully.

I see both serial devices as both tty and cu under macOS. The red LED is flashing. The green LED is on.

However, running the python scripts using the first serial gives errors:

-always in the beginning, once: Ignoring message: Incorrect padding
-many of these: Ignoring message due to missing CRLF
-some of these: sniffle_hw.py", line 221, in recv_and_decode; raise SniffleHWPacketError("Unknown message type 0x%02X!" % mtype); sniffle_hw.SniffleHWPacketError: Unknown message type 0x<various>!

No devices are found by scanner.py or sniff_receiver.py
I also tried reset.py and before running scanner or sniff receiver, but it did not solve the problem.

I would love to test your sniffle tool, but it does not seem to work on CC1352-P2

Hi,

after flashing the latest version (1.3) on the CC26X2R1 the only output I get is:

WARNING: invalid message during flush, ignoring...
Ignoring message: Invalid base64-encoded string: number of data characters (37) cannot be 1 more than a multiple of 4
WARNING: invalid message during flush, ignoring...
WARNING: invalid message during flush, ignoring...
WARNING: invalid message during flush, ignoring...
WARNING: invalid message during flush, ignoring...
WARNING: invalid message during flush, ignoring...
WARNING: invalid message during flush, ignoring...
WARNING: invalid message during flush, ignoring...
WARNING: invalid message during flush, ignoring...
Ignoring message: Incorrect padding
....

LED looks normal and active.
If I get back to the V1.2, it's working as usual...

Thanks,
Manuel

Is it possible to use alone CC2652R module without having launch board?
I found this on ebay www.ebay.com/itm/1-8-3-3V-CC2652R-Bluetooth-5-0-ZigBee-Module-2-4GHZ-Wireless-Module-Low-Power/333451099943

If its possible how to program it?

From Bluetooth 5.2, used for LE audio and other things.

Currently Ubertooth has 'experimental' package injection capabilities.

It would be really awesome to have better injection methods so researchers can develop over the air Bluetooth protocol fuzzers and pull off downgrade attacks like KNOB!