[Kali Rolling] No working bluetooth adatpter (altough with good health and alive)

Hi folks,

first of all, I'd like to send my regards to the OffSec Kali crews. Since I've opened the door of curiosity on computers, years ago as a teenager, I have never seen so much effort in the spread of quality hacking. You're at The Hackers Choice level, for sure ;D

Well, as Kali Linux being release to its 16.1 version, my USB/Bluetooth adapter (Empire Bluetooth 4.0 USB JC-F-1193 3640) stopped working. So I can go back to my Metallica-inspired hacking sessions, here are the things I've been trying to get my interesting problem solved:

1) Verifying I/O
root@ThinkIsMyCrime:~# dmesg | tail
[ 6716.510642] Bluetooth: RFCOMM ver 1.11
[ 7616.039665] usb 2-1.1: USB disconnect, device number 6
[ 7644.442120] usbcore: deregistering interface driver btusb
[ 7694.315780] usb 2-1.1: new full-speed USB device number 7 using ehci-pci
[ 7694.459484] usb 2-1.1: New USB device found, idVendor=0a12, idProduct=0001
[ 7694.459494] usb 2-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 7694.476728] usbcore: registered new interface driver btusb
[ 7694.661559] Bluetooth: RFCOMM TTY layer initialized
[ 7694.661577] Bluetooth: RFCOMM socket layer initialized
[ 7694.661592] Bluetooth: RFCOMM ver 1.11

2) Checking bluetooth related modules
root@ThinkIsMyCrime:~# lsmod | grep bluetooth
bluetooth 516096 29 bnep,btbcm,btrtl,btusb,rfcomm,btintel
rfkill 24576 8 cfg80211,acer_wmi,bluetooth
crc16 16384 2 ext4,bluetooth

3) More bluetooth information
root@ThinkIsMyCrime:~# hciconfig
hci0: 00:15:83:D1:B0:54 Type: BR/EDR Bus: USB
BD Address: ACL MTU: 310:10 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN
RX bytes:706 acl:0 sco:0 events:53 errors:0
TX bytes:2514 acl:0 sco:0 commands:50 errors:0

4) root@ThinkIsMyCrime:~# hcitool scan
Scanning ...

Hum...it seem nothing was found. The bluetooth interface is up, though. Playing with hcitool options, the device was not found. And as well as hcitool scan, blueman-manager fails in the device discovery process.

If the modules were loaded right, things were supposed to work. Right? Let's look at bluetooth services status:

5) root@ThinkIsMyCrime:~# service bluetooth status
● bluetooth.service - Bluetooth service
Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: disabled)
Active: active (running) since Sun 2016-09-04 02:25:09 BRT; 30min ago
Docs: man:bluetoothd(8)
Main PID: 7261 (bluetoothd)
Status: "Running"
Tasks: 1 (limit: 4915)
CGroup: /system.slice/bluetooth.service
└─7261 /usr/lib/bluetooth/bluetoothd

Sep 04 02:34:07 ThinkIsMyCrime bluetoothd[7261]: Sap driver initialization failed.
Sep 04 02:34:07 ThinkIsMyCrime bluetoothd[7261]: sap-server: Operation not permitted (1)
Sep 04 02:34:08 ThinkIsMyCrime bluetoothd[7261]: RFCOMM server failed for Headset Voice gateway: rfcomm_bin
Sep 04 02:34:08 ThinkIsMyCrime bluetoothd[7261]: RFCOMM server failed for Headset Voice gateway: rfcomm_bin
Sep 04 02:34:08 ThinkIsMyCrime bluetoothd[7261]: Endpoint registered: sender=:1.125 path=/MediaEndpoint/A2D
Sep 04 02:34:08 ThinkIsMyCrime bluetoothd[7261]: Endpoint registered: sender=:1.125 path=/MediaEndpoint/A2D
Sep 04 02:34:08 ThinkIsMyCrime bluetoothd[7261]: Endpoint registered: sender=:1.123 path=/MediaEndpoint/A2D
Sep 04 02:34:08 ThinkIsMyCrime bluetoothd[7261]: Endpoint registered: sender=:1.123 path=/MediaEndpoint/A2D
Sep 04 02:34:08 ThinkIsMyCrime bluetoothd[7261]: Endpoint registered: sender=:1.119 path=/MediaEndpoint/A2D
Sep 04 02:34:08 ThinkIsMyCrime bluetoothd[7261]: Endpoint registered: sender=:1.119 path=/MediaEndpoint/A2D

Again, everything seems allright, except for the rfcomm server.

Another way to manipulate bluetooth devices is by bluetoothctl.

6) [bluetooth]# show
Controller 00:15:83:D1:B0:54
Name: ThinkIsMyCrime
Alias: ThinkIsMyCrime
Class: 0x0c010c
Powered: yes
Discoverable: yes
Pairable: yes
UUID: Headset AG (00001112-0000-1000-8000-00805f9b34fb)
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb)
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
UUID: Audio Source (0000110a-0000-1000-8000-00805f9b34fb)
UUID: Audio Sink (0000110b-0000-1000-8000-00805f9b34fb)
Modalias: usb:v1D6Bp0246d0524
Discovering: no

7) Finally, the blueman-manager events seek and sucessfully find the adapter, but no device at all is detected.


I have stopped here. Tomorrow I will dive into rfcomm server situation, where maybe lies the answer. If someone experienced the same problem while migrating from last Kali to Rolling version, please raise your finger.

One interesting fact aroused from the investigations is the possibility of use the own bluetooth managing tools to attack related devices. Anyone interested in python + bluetooth hacking? ;D

See you guys and happy hacking ;D

Hello lucasrosa!

It looks to me as if I am having pretty much same problem as you do. Since I have been using Kali / Backtrack since release BT5-something, I have seen my Bluetooth functionality coming and going on pretty much the same laptop. I'm using Panasonic Toughbooks (CF-19) for most of my Kali work which according to my information are equipped with Alps UGTZ4 Bluetooth modules.

In the previous version of Kali (before migrating to Kali Rolling) my Bluetooth setup worked just beautifully, both for transferring files to and from my phone (a Sony Xperia Z3 Compact which I usually use as WAN interface through WIFI) .

I was also able to use my phones BT as bnep0 and as a WAN access point the other day when I was experimenting with a "rogue access point" MITM attack but today I can't even get the phone to connect properly as a WAN interface. I've noticed that since upgrading to Kali Rolling I haven't been able to transfer files over BT when I tried so I reverted to different methods for file transfer and have't bothered to look into the issue, hoping for an update would fix it eventually.

Now I need to use the BT as a network access point for further work with a rogue access point attack. This situation became devastating after my USB cable broke and I couldn't use the usb0 as WAN interface anymore. This since I'm stranded in pretty much nowhere with no spare USB-cables after the last one became toast. There are also Polar Bears around so USB-cables aren't my biggest concern at the moment though :)



Here are a few diagnostic dumps from my laptop for comparison:

root@cf-19:~/# hciconfig -a
hci0: Type: BR/EDR Bus: USB
BD Address: 00:21:4F:61:85:2B ACL MTU: 310:10 SCO MTU: 64:8
UP RUNNING PSCAN
RX bytes:11362 acl:79 sco:0 events:657 errors:0
TX bytes:6966 acl:100 sco:0 commands:445 errors:0
Features: 0xff 0xff 0x8f 0xfe 0x9b 0xf9 0x00 0x80
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
Name: 'cf-19'
Class: 0x02010c
Service Classes: Networking
Device Class: Computer, Laptop
HCI Version: 2.0 (0x3) Revision: 0xc5c
LMP Version: 2.0 (0x3) Subversion: 0xc5c
Manufacturer: Cambridge Silicon Radio (10)


[bluetooth]# show
Controller 00:21:4F:61:85:2B
Name: cf-19
Alias: cf-19
Class: 0x02010c
Powered: yes
Discoverable: no
Pairable: yes
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
UUID: NAP (00001116-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
Modalias: usb:v1D6Bp0246d0524
Discovering: no


root@cf-19:~/# service bluetooth status
● bluetooth.service - Bluetooth service
Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: disabled)
Active: active (running) since mån 2016-10-03 09:29:58 CEST; 50min ago
Docs: man:bluetoothd(8)
Main PID: 3203 (bluetoothd)
Status: "Running"
CGroup: /system.slice/bluetooth.service
└─3203 /usr/lib/bluetooth/bluetoothd

okt 03 09:29:58 cf-19 bluetoothd[3203]: Not enough free handles to register service
okt 03 09:29:58 cf-19 bluetoothd[3203]: Not enough free handles to register service
okt 03 09:29:58 cf-19 bluetoothd[3203]: Sap driver initialization failed.
okt 03 09:29:58 cf-19 bluetoothd[3203]: sap-server: Operation not permitted (1)
okt 03 09:29:58 cf-19 systemd[1]: Started Bluetooth service.
okt 03 09:29:58 cf-19 systemd[1]: Started Bluetooth service.
okt 03 10:06:13 cf-19 bluetoothd[3203]: connected
okt 03 10:06:14 cf-19 bluetoothd[3203]: bnep0 disconnected
okt 03 10:06:52 cf-19 bluetoothd[3203]: bnep%d connected
okt 03 10:06:52 cf-19 bluetoothd[3203]: bnep0 disconnected


root@cf-19:~/# dmesg | grep -i bluetooth
[ 13.902307] Bluetooth: Core ver 2.20
[ 13.902345] Bluetooth: HCI device and connection manager initialized
[ 13.902353] Bluetooth: HCI socket layer initialized
[ 13.902359] Bluetooth: L2CAP socket layer initialized
[ 13.902373] Bluetooth: SCO socket layer initialized
[ 135.932611] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 135.932618] Bluetooth: BNEP filters: protocol multicast
[ 135.932630] Bluetooth: BNEP socket layer initialized


root@cf-19:~/# lsmod |grep -i bluetooth
bluetooth 512000 24 bnep,btbcm,btrtl,btusb,btintel
rfkill 24576 7 cfg80211,bluetooth
crc16 16384 2 ext4,bluetooth


root@cf-19:~/# hciconfig
hci0: Type: BR/EDR Bus: USB
BD Address: 00:21:4F:61:85:2B ACL MTU: 310:10 SCO MTU: 64:8
UP RUNNING PSCAN
RX bytes:11353 acl:79 sco:0 events:655 errors:0
TX bytes:6958 acl:100 sco:0 commands:444 errors:0


root@cf-19:~/# hcitool scan
Scanning ...

Pretty much the same results from my scanning... NOTHING.


As this now has become a serious problem for me I need to investigate the issue further. Having it functioning the other day (without really realizing what a big deal it was) I know that it is possible to get it to work on my hardware, with my current setup. I just don't know what's causing the problem and where to start looking to solve it. I am a bit reluctant to do a system upgrade at this point since the last few upgrades have brought me increasing problems. Most I have been able to solve but it has mostly been "convenience issues" like sound not working etc. Adapters refusing to start or behaving erratically I can't have and risking that a vital one refuses to start I'm not willing to do at the moment because of my location / situation.

I will keep an eye at this thread nd I promise to come back and post if I find a solution before anyone else does.

Keep hacking!


// C0RE