How to Hack Devices Using Bluetooth in Kali Linux | by Keshav Xplore

Published in

InfoSec Write-ups

17 min readDec 16, 2023

While Bluetooth has become a ubiquitous part of our daily lives, a majority remain unaware of its inner workings and, more importantly, its susceptibility to hacking. Delving into the realm of Bluetooth hacking provides a direct glimpse into the target’s world. Given that nearly every device is equipped with Bluetooth capabilities, exploiting this wireless technology could potentially grant access to a wealth of personal information stored on phones and tablets.

Despite Bluetooth and Wi-Fi sharing the same 2.4 GHz frequency, their distinct protocols render them different entities in terms of security. Bluetooth’s heightened security measures make conventional Wi-Fi hacking tools ineffective against it.

One notable feature is the continuous frequency hopping employed by Bluetooth devices. When two devices communicate via Bluetooth, they utilize an algorithm that dynamically shifts the frequency multiple times per second. This constant frequency hopping poses a significant challenge for potential attackers attempting to eavesdrop on the communication.

Additionally, Bluetooth differs from Wi-Fi in how it handles key negotiation. While Wi-Fi negotiates a key with every connection, Bluetooth establishes a key only once during the initial connection. Subsequently, this secret key is stored and referenced for subsequent communications with the same device. Unlike Wi-Fi, this approach makes it virtually impossible for an attacker to passively sniff the key, as they would need to be present during the initial communication.

However, this doesn’t mean Bluetooth is impervious. It is still susceptible to tracking nearby devices, extracting information from them, and even manipulating specific characteristics. Conducting reconnaissance becomes crucial, as it may unveil opportunities to seize control, identify vulnerabilities, or discover potential exploits that align with nearby devices.

Understanding the nuances of Bluetooth technology is vital not only for users but also for those tasked with securing these wireless connections in an ever-evolving digital landscape.

Read this article here in detail with user friendly theme: https://www.keshavxplore.in/2023/12/how-to-hack-devices-using-bluetooth-in-kali-linux.html

Preparing for Bluetooth Reconnaissance: A Quick Guide

Embarking on Bluetooth surveillance requires a well-equipped setup. Ensure you have an up-to-date installation of Kali Linux, as we’ll leverage its built-in Bluetooth tools for this endeavor. Keeping it streamlined, we won’t be adding any extra tools; the default Bluetooth toolkit in Kali Linux will suffice.

Key tools included in BlueZ, the default Bluetooth protocol stack in most Linux versions, form the foundation of our exploration. Among these, we’ll delve into hciconfig, hcitool, sdptool, l2ping, and btscanner. Additionally, specialized tools tailored for Bluetooth reconnaissance in Kali Linux will be introduced.

Proximity is a critical factor in Bluetooth hacking. Armed with a reliable Bluetooth adapter, you can target devices in various settings — be it a coffee shop, school classroom, office, or even within close proximity of a neighbor’s house. Ensure your Bluetooth adapter is of high quality to maximize the reach of your Bluetooth reconnaissance.

Activating Bluetooth Adapter: A Primer with hciconfig

Much like ifconfig serves for Wi-Fi, the counterpart for Bluetooth devices is hciconfig. This tool facilitates the activation of your Bluetooth adapter, serving as the initial step in our reconnaissance journey. Familiarize yourself with hciconfig to set the stage for efficient Bluetooth hacking.

~# hciconfig

hci0     Type: Primary Bus: USB
         BD Address: ██:██:██:██:██:██  ACL MTU: 1022:8   SCO MTU: 183.5
         DOWN
         RX bytes:574 acl:0 sco:0 events:30 errors:0
         TX bytes:368 acl:0 sco:0 commands:30 errors:0

Just as ifconfig is synonymous with Wi-Fi, hciconfig takes the lead for Bluetooth devices. In this guide, we’ll navigate the setup of your Bluetooth interface, an essential precursor for efficient Bluetooth hacking. Observe our example, where the Bluetooth interface is currently inactive (down). Follow these steps to bring it to life and initiate your Bluetooth operations. Suppose you are well-acquainted with ifconfig commands. In that case, adapting to hciconfig will be seamless, as they share a structural resemblance. For instance, if you need to activate a Wi-Fi interface, the command is “ifconfig [interface_name] up”. In the realm of Bluetooth, using hciconfig mirrors this process. Explore the hciconfig man page for a comprehensive list of compatible commands.

~# man hciconfig

HCICONFIG(1)              Linux System Administration             HCICONFIG(1)
NAME
       hciconfig - configure Bluetooth devices
SYNOPSIS
       hciconfig -h
       hciconfig [-a]
       hciconfig [-a] hciX [command [command parameters]]
DESCRIPTION
       hciconfig  is used to configure Bluetooth devices.  hciX is the name of
       a Bluetooth device installed in the system. If hciX is not given,  hci‐
       config  prints  name  and basic information about all the Bluetooth de‐
       vices installed in the system. If hciX  is  given  but  no  command  is
       given,  it prints basic information on device hciX only. Basic informa‐
       tion is interface type, BD address, ACL MTU, SCO MTU, flags (up,  init,
       running, raw, page scan enabled, inquiry scan enabled, inquiry, authen‐
       tication enabled, encryption enabled).
OPTIONS
       -h, --help
              Gives a list of possible commands.
       -a, --all
              Other than the basic info, print  features,  packet  type,  link
              policy, link mode, name, class, version.
COMMANDS
       up                   Open and initialize HCI device.
       down                 Close HCI device.
       reset                Reset HCI device.
       rstat                Reset statistic counters.
       auth                 Enable authentication (sets device to security mode 3).
       noauth               Disable authentication.
       encrypt              Enable encryption (sets device to security mode 3).
       noencrypt            Disable encryption.
       secmgr               Enable security manager (current kernel support is limited).
       nosecmgr             Disable security manager.
       piscan               Enable page and inquiry scan.
       noscan               Disable page and inquiry scan.
       iscan                Enable inquiry scan, disable page scan.
       pscan                Enable page scan, disable inquiry scan.
       ptype [type]         With no type , displays the current packet types. Otherwise, all the packet types specified by type are set.  type  is  a  comma-separated  list of packet types, where the possible packet types are DM1, DM3, DM5, DH1, DH3, DH5, HV1, HV2, HV3.
       name [name]          With no name, prints local name. Otherwise, sets local  name  to name.
       class [class]        With  no class, prints class of device. Otherwise, sets class of device to class.  class is a 24-bit hex  number  describing  the class  of  device,  as specified in section 1.2 of the Bluetooth Assigned Numers document.
       voice [voice]        With no voice, prints voice setting. Otherwise, sets voice  setting  to  voice.   voice  is  a 16-bit hex number describing the voice setting.
       iac [iac]            With no iac, prints the current IAC setting. Otherwise, sets the IAC to iac.
       inqtpl [level]       With  no  level,  prints  out the current inquiry transmit power level. Otherwise, sets inquiry transmit power level to level.
       inqmode [mode]       With no mode, prints out the current  inquiry  mode.  Otherwise, sets inquiry mode to mode.
       inqdata [data]       With  no  name,  prints out the current inquiry data. Otherwise, sets inquiry data to data.
       inqtype [type]       With no type, prints out the current inquiry scan  type.  Otherwise, sets inquiry scan type to type.
       inqparams [win:int]  With no win:int, prints inquiry scan window and interval. Otherwise, sets inquiry scan window to win slots and inquiry scan interval to int slots.
       pageparms [win:int]  With  no  win:int,  prints page scan window and interval. Otherwise, sets page scan window to win slots and page scan  interval to int slots.
       pageto [to]          With no to, prints page timeout. Otherwise, sets page timeout to .I to slots.
       afhmode [mode]       With no mode, prints out the current AFH mode.  Otherwise,  sets AFH mode to mode.
       sspmode [mode]       With no mode, prints out the current Simple Pairing mode. Otherwise, sets Simple Pairing mode to mode.
       aclmtu mtu:pkt       Sets ACL MTU to to mtu bytes and ACL buffer size to pkt packets.
       scomtu mtu:pkt       Sets SCO MTU to mtu bytes and SCO buffer size to pkt packets.
       delkey       This command deletes the stored link key for bdaddr from the device.
       oobdata              Get local OOB data (invalidates previously read data).
       commands             Display supported commands.
       features             Display device features.
       version              Display version information.
       revision             Display revision information.
       lm [mode]            With  no mode , prints link mode.  MASTER or SLAVE mean, respectively, to ask to become master or to remain slave when  a  connection  request  comes  in. The additional keyword ACCEPT means that baseband  connections will be accepted even if there are no listening  AF_BLUETOOTH  sockets.  mode is NONE or a comma-separated list of keywords, where possible keywords are  MASTER  and ACCEPT  .  NONE sets link policy to the default behaviour of remaining slave and not accepting baseband connections when  there are no listening AF_BLUETOOTH sockets. If MASTER is present, the device will ask to become master if a connection  request  comes in.  If  ACCEPT is present, the device will accept baseband connections even when there are no listening AF_BLUETOOTH sockets.
AUTHORS
       Written by Maxim Krasnyansky   and  Marcel  Holtmann 
       man page by Fabrizio Gennari 
BlueZ                             Nov 11 2002                     HCICONFIG(1)
Manual page hciconfig(1) line 147/169 (END) (press h for help or q to quit)

The versatility of hciconfig extends beyond mere interface activation; it’s a powerful tool for configuring Bluetooth devices. Whether you have an external Bluetooth device connected, its application encompasses device discovery and configuration. Once familiarized with this aspect, press Q to exit the hciconfig man page. To bring a discovered Bluetooth device online, execute the command `hciconfig [device_name] up`. This step is crucial in preparing the identified Bluetooth device for subsequent operations.

~# hciconfig hci0 up

To see if it worked, run the hciconfig command again:

~# hciconfig

hci0     Type: Primary Bus: USB
         BD Address: ██:██:██:██:██:██  ACL MTU: 1022:8   SCO MTU: 183.5
         UP RUNNING
         RX bytes:1148 acl:0 sco:0 events:60 errors:0
         TX bytes:736 acl:0 sco:0 commands:60 errors:0

Step 2: Scan for Bluetooth Devices with hcitool

Now let’s use hcitool to look for Bluetooth devices that are sending out their discover beacons (in discovery mode). First, let’s check out its man page:

~# man hciconfig

HCITOOL(1)                Linux System Administration               HCITOOL(1)
NAME
       hcitool - configure Bluetooth connections
SYNOPSIS
       hcitool [-h]
       hcitool [-i ] [command [command parameters]]
DESCRIPTION
       hcitool  is  used to configure Bluetooth connections and send some spe‐
       cial command to Bluetooth devices. If no command is given,  or  if  the
       option -h is used, hcitool prints some usage information and exits.
OPTIONS
       -h     Gives a list of possible commands
       -i 
              The  command  is applied to device hciX , which must be the name
              of an installed Bluetooth device. If not specified, the  command
              will be sent to the first available Bluetooth device.
COMMANDS
       dev                  Display local devices
       inq                  Inquire  remote  devices.  For each discovered device, Bluetooth device address, clock offset and class are printed.
       scan                 Inquire remote devices. For each discovered device, device  name are printed.
       name         Print  device  name  of  remote  device  with  Bluetooth address bdaddr.
       info         Print device name, version and supported features of remote  device with Bluetooth address bdaddr.
       spinq                Start periodic inquiry process. No inquiry results are printed.
       epinq                Exit periodic inquiry process.
       cmd   [parameters]
                            Submit  an  arbitrary HCI command to local device.  ogf, ocf and parameters are hexadecimal bytes.
       con                  Display active baseband connections
       cc [--role=m|s] [--pkt-type=] 
                            Create baseband connection to remote device with  Bluetooth  address  bdaddr.   Option  --pkt-type  specifies a list of allowed packet types.    is  a  comma-separated  list  of  packet types,  where  the possible packet types are DM1, DM3, DM5, DH1, DH3, DH5, HV1, HV2, HV3.  Default is to allow all packet  types. Option  --role  can have value m (do not allow role switch, stay master) or s (allow role switch, become slave if the  peer  asks to become master). Default is m.
       dc  [reason]
                            Delete baseband connection from remote device with Bluetooth address bdaddr.  The reason can be one of the Bluetooth HCI  error codes.  Default is 19 for user ended connections. The value must be given in decimal.
       sr     Switch role for the baseband connection from the  remote  device to master or slave.
       cpt  
                            Change packet types for baseband connection to device with Bluetooth address bdaddr.  packet types is a comma-separated list of packet types, where the possible packet types are DM1, DM3, DM5, DH1, DH3, DH5, HV1, HV2, HV3.
       rssi         Display received signal strength information for the  connection to the device with Bluetooth address bdaddr.
       lq           Display link quality for the connection to the device with Bluetooth address bdaddr.
       tpl  [type]  Display transmit power level for the connection  to  the  device with  Bluetooth  address bdaddr.  The type can be 0 for the current transmit power level (which is default) or 1 for the  maximum transmit power level.
       afh          Display  AFH  channel  map for the connection to the device with Bluetooth address bdaddr.
       lp  [value]  With no value, displays link policy settings for the  connection to the device with Bluetooth address bdaddr.  If value is given, sets the link policy settings  for  that  connection  to  value. Possible values are RSWITCH, HOLD, SNIFF and PARK.
       lst  [value] With no value, displays link supervision timeout for the connection to the device with Bluetooth address bdaddr.  If  value  is given,  sets the link supervision timeout for that connection to value slots, or to infinite if value is 0.
       auth         Request authentication for the  device  with  Bluetooth  address bdaddr.
       enc  [encrypt enable]
                            Enable  or  disable the encryption for the device with Bluetooth address bdaddr.
       key          Change the connection link key for the device with Bluetooth address bdaddr.
       clkoff       Read  the  clock  offset  for  the device with Bluetooth address bdaddr.
       clock [bdaddr] [which clock]
                            Read the clock for the device  with  Bluetooth  address  bdaddr. The  clock  can  be  0  for the local clock or 1 for the piconet clock (which is default).
       lescan [--privacy] [--passive] [--whitelist]  [--discovery=g|l]  [--duplicates]
                            Start LE scan
       leinfo [--static] [--random] 
                            Get LE remote information
       lewladd [--random] 
                            Add device to LE White List
       lewlrm       Remove device from LE White List
       lewlsz               Read size of LE White List
       lewlclr              Clear LE White List
       lerladd [--local irk] [--peer irk] [--random] 
                            Add device to LE Resolving List
       lerlrm       Remove device from LE Resolving List
       lerlclr              Clear LE Resolving List
       lerlsz               Read size of LE Resolving List
       lerlon               Enable LE Address Resolution
       lerloff              Disable LE Address Resolution
       lecc [--static] [--random]  | [--whitelist]
                            Create a LE Connection
       ledc  [reason]
                            Disconnect a LE Connection
       lecup     
                            LE Connection Update
AUTHORS
       Written  by  Maxim  Krasnyansky  and Marcel Holtmann 
       man page by Fabrizio Gennari 
BlueZ                             Nov 12 2002                       HCITOOL(1)
Manual page hcitool(1) line 154/176 (END) (press h for help or q to quit)

Hcitool proves invaluable in configuring and executing diverse tasks such as scans, inquiries, and name retrieval. However, certain commands necessitate the use of MAC addresses. A fundamental operation is scanning for nearby Bluetooth devices, providing MAC addresses for further inquiries or attempts to extract device names. Initiate a scan with the command hcitool scan. This employs the Bluetooth interface to identify nearby devices, revealing their MAC addresses. This information serves as a gateway for subsequent scans, inquiries, or endeavors to unveil device names.

~# hcitool scan

Scanning ...
        00:1D:A5:00:09:1D       OBDII

Above, we see an OBD2 connector which is connected to a vehicle. That’s pretty interesting. With the MAC address, we can now we can do another command that required us to have a MAC address in the first place. Let’s try getting the name of the device:

~# hcitool name 00:1D:A5:00:09:1D

OBDII

That should allow us to get the name of the device, but we already knew it from that first scan. If we didn’t know it, however, it’ll allow us to be able to learn more about it. To learn more, we can use the inq command:

~# hcitool inq 00:1D:A5:00:09:1D

Scanning ...
        00:1D:A5:00:09:1D       clock offset: 0x21c0    class: ox5a020c

Note that it also displays clock offset and the class. The class indicates what type of Bluetooth device it is, and we can look up the code by going to the Bluetooth site. Or, as we will see later, some tools will do it for us.

Step 3: Scan for Services with sdptool

Exploring the realm of Bluetooth devices demands a meticulous examination of their services. Meet `sdptool`, a versatile companion crafted for precisely this purpose. This tool empowers users to delve into the intricacies of a device’s services, offering profound insights into its functionalities, both expansive possibilities and inherent constraints. Before embarking on the journey of exploration using `sdptool`, it’s essential to acquaint oneself with its command options and diverse functionalities. A robust grasp of available commands ensures a more nuanced and effective exploration experience. Equipped with this knowledge, seamlessly utilize `sdptool` to unravel the array of services extended by a Bluetooth device. This comprehensive exploration not only unveils the device’s properties but also provides a nuanced understanding, enabling informed reconnaissance and strategic interaction.

~# man sdptool

sdptool(1)                  General Commands Manual                 sdptool(1)
NAME
       sdptool — control and interrogate SDP servers
SYNOPSIS
       sdptool [options]  {command}  [command parameters ...]
DESCRIPTION
       sdptool  provides the interface for performing SDP queries on Bluetooth
       devices, and administering a local SDP database.
COMMANDS
       The following commands are available.  In all  cases  bdaddr  specifies
       the  device to search or browse.  If local is used for bdaddr, then the
       local SDP database is searched.
       Services are identified and manipulated  with  a  4-byte  record_handle
       (NOT  the  service  name).  To find a service's record_handle, look for
       the "Service RecHandle" line in the search or browse results
       search [--bdaddr bdaddr] [--tree] [--raw] [--xml] service_name
                 Search for services.. Known service names are DID, SP, DUN, LAN, FAX,  OPUSH,  FTP, HS,  HF,  HFAG,  SAP,  NAP,  GN, PANU, HCRP, HID, CIP, A2SRC, A2SNK, AVRCT, AVRTG, UDIUE, UDITE and SYNCML.
       browse [--tree] [--raw] [--xml] [bdaddr]
                 Browse all available services on the device  specified  by  a Bluetooth address as a parameter.
       records [--tree] [--raw] [--xml] bdaddr
                 Retrieve all possible service records.
       add [ --handle=N --channel=N ]
                 Add a service to the local SDP database. You  can  specify a handle for this record using the --handle option. You can specify a channel to add the  service  on  using  the --channel option. NOTE:  Local  adapters  configuration will not be updated and this command should be used only for SDP testing.
       del record_handle
                 Remove a service from the local SDP database. NOTE: Local adapters configuration will not  be  updated  and this command should be used only for SDP testing.
       get [--tree] [--raw] [--xml] [--bdaddr bdaddr] record_handle
                 Retrieve a service from the local SDP database.
       setattr record_handle attrib_id attrib_value
                 Set or add an attribute to an SDP record.
       setseq record_handle attrib_id attrib_values
                 Set or add an attribute sequence to an SDP record.
OPTIONS
       --help    Displays help on using sdptool.
EXAMPLES
       sdptool browse 00:80:98:24:15:6D
       sdptool browse local
       sdptool add DUN
       sdptool del 0x10000
BUGS
       Documentation needs improving.
AUTHOR
       Maxim  Krasnyansky . Man page written by Edd Dumbill .
                                                                    sdptool(1)
Manual page sdptool(1) line 60/82 (END) (press h for help or q to quit)

Now, equipped with a foundational understanding of `sdptool`, let’s harness its capabilities to delve into the intricacies of service discovery on Bluetooth devices. `sdptool` serves as a versatile tool for configuring, controlling, and interrogating SDP (Service Discovery Protocol) servers. This functionality empowers us to conduct detailed queries on Bluetooth devices, unraveling crucial information about permissions, and gaining insights into potential actions within those services. To embark on this exploration, initiate the command by typing `sdptool browse` followed by the MAC address we previously captured. This command serves as the gateway to a comprehensive understanding of the device’s service landscape, shedding light on permissions, constraints, and possibilities that await discovery.

~# sdptool browse 00:1D:A5:00:09:1D

Browsing 00:1D:A5:00:09:1D ...
Service Name: SPP
Service RecHandle: 0x10001
Service Class ID List:
    "Serial Port" (ox1101)
Protocol Descriptor List:
    "L2CAP" (0x0100)
    "RFCOMM" (0x0003)
      Channel: 1

In this context, the output provides additional insights into the realm of communications, unveiling the intricacies of protocols employed by the device. This newfound knowledge becomes pivotal as we navigate the landscape of potential vulnerabilities within the device. By scrutinizing the details, we might uncover vulnerabilities, ascertain the feasibility of direct communication, and even discern whether the device employs security measures such as MAC address randomization. This multifaceted exploration equips us with the information needed to make informed decisions and strategic moves in our Bluetooth reconnaissance endeavors.

Step 4: Ping Bluetooth Devices with l2ping

Now that we’ve acquired the MAC addresses of the nearby devices, we can utilize l2ping to ping them, whether they are in discover mode or not, to assess their reachability. In my case, there’s just one device. Before proceeding, let’s explore the tool’s man page to understand all available options.

~# man l2ping

L2PING(1)                 Linux System Administration                L2PING(1)NAME
       l2ping - Send L2CAP echo request and receive answerSYNOPSIS
       l2ping  [-i  ]  [-s size] [-c count] [-t timeout] [-d delay] [-f]
       [-r] [-v] bd_addrDESCRIPTION
       L2ping sends a L2CAP echo request to the Bluetooth MAC address  bd_addr
       given in dotted hex notation.OPTIONS
       -i         The  command  is applied to device hciX , which must be the name of an installed Bluetooth device (X = 0,  1,  2,  ...)   If  not specified, the command will be sent to the first available Bluetooth device.
       -s size          The size of the data packets to be sent.
       -c count         Send count number of packets then exit.
       -t timeout       Wait timeout seconds for the response.
       -d delay         Wait delay seconds between pings.
       -f               Kind of flood ping. Use with care! It reduces the delay time between packets to 0.
       -r               Reverse  ping  (gnip?).  Send  echo response instead of echo request.
       -v               Verify response payload is identical to request payload.  It  is not  required  for  remote stacks to return the request payload, but most stacks do (including Bluez).
       bd_addr          The Bluetooth MAC address to be pinged in dotted hex notation like 01:02:03:ab:cd:ef or 01:EF:cd:aB:02:03AUTHORS
       Written  by  Maxim  Krasnyansky  and Marcel Holtmann        man  page  by  Nils  Faerber  ,   Adam   Laurie .BlueZ                             Jan 22 2002                        L2PING(1)Manual page l2ping(1) line 32/54 (END) (press h for help or q to quit)

NAME
       l2ping - Send L2CAP echo request and receive answer
SYNOPSIS
       l2ping  [-i  ]  [-s size] [-c count] [-t timeout] [-d delay] [-f]
       [-r] [-v] bd_addr
DESCRIPTION
       L2ping sends a L2CAP echo request to the Bluetooth MAC address  bd_addr
       given in dotted hex notation.
OPTIONS
       -i         The  command  is applied to device hciX , which must be the name of an installed Bluetooth device (X = 0,  1,  2,  ...)   If  not specified, the command will be sent to the first available Bluetooth device.
       -s size          The size of the data packets to be sent.
       -c count         Send count number of packets then exit.
       -t timeout       Wait timeout seconds for the response.
       -d delay         Wait delay seconds between pings.
       -f               Kind of flood ping. Use with care! It reduces the delay time between packets to 0.
       -r               Reverse  ping  (gnip?).  Send  echo response instead of echo request.
       -v               Verify response payload is identical to request payload.  It  is not  required  for  remote stacks to return the request payload, but most stacks do (including Bluez).
       bd_addr          The Bluetooth MAC address to be pinged in dotted hex notation like 01:02:03:ab:cd:ef or 01:EF:cd:aB:02:03
AUTHORS
       Written  by  Maxim  Krasnyansky  and Marcel Holtmann 
       man  page  by  Nils  Faerber  ,   Adam   Laurie .
BlueZ                             Jan 22 2002                        L2PING(1)
Manual page l2ping(1) line 32/54 (END) (press h for help or q to quit)

We don’t need to do anything fancy here, just ping the Bluetooth device as so:

~# l2ping 00:1D:A5:00:09:1D

Ping: 00:1D:A5:00:09:1D from ██:██:██:██:██:██ (data size 44) ...
44 bytes from 00:1D:A5:00:09:1D id 0 time 37.57ms
44 bytes from 00:1D:A5:00:09:1D id 1 time 27.23ms
44 bytes from 00:1D:A5:00:09:1D id 2 time 27.59ms
44 bytes from 00:1D:A5:00:09:1D id 3 time 27.31ms
44 bytes from 00:1D:A5:00:09:1D id 4 time 40.99ms
44 bytes from 00:1D:A5:00:09:1D id 5 time 48.77ms
44 bytes from 00:1D:A5:00:09:1D id 6 time 59.93ms
44 bytes from 00:1D:A5:00:09:1D id 7 time 48.84ms
44 bytes from 00:1D:A5:00:09:1D id 8 time 67.59ms

This indicates that the device is within range and reachable.

Step 5: Scan for Bluetooth Devices with btscanner

Now, let’s shift our focus to the final tool in our arsenal — a full-fledged graphical user interface designed for Bluetooth device discovery. It goes by the name btscanner. To initiate it, simply type btscanner. Before proceeding, let’s quickly review the man pages for this tool as well.

~# man btscanner

BTSCANNER(1)                General Commands Manual               BTSCANNER(1)NAME
       btscanner - ncurses-based scanner for Bluetooth devicesSYNOPSIS
       btscanner [--help] [--cfg ] [--no-reset]DESCRIPTION
       This  manual page was written for the Debian GNU/Linux distribution be‐
       cause the original program does not have a manual page.       btscanner is a tool designed specifically to extract as  much  informa‐
       tion  as  possible  from  a Bluetooth device without the requirement to
       pair. A detailed information screen extracts HCI and  SDP  information,
       and  maintains an open connection to monitor the RSSI and link quality.
       btscanner is based on the BlueZ Bluetooth stack, which is included with
       recent  Linux kernels, and the BlueZ toolset. btscanner also contains a
       complete listing of the IEEE OUI numbers and class lookup tables. Using
       the information gathered from these sources it is possible to make edu‐
       cated guesses as to the host device type.OPTIONS
       --help           Show a help text and exit.
       --cfg      Use  as the config file.
       --no-reset       Do not reset the Bluetooth adapter before scanning.BUGS
       Please report any bugs to Tim Hurman .LICENCE
       btscanner is covered by the GNU General Public License (GPL).SEE ALSO
       kismet(1).AUTHORS
       Tim Hurman        This manual page was written by Uwe Hermann  ,  for
       the Debian GNU/Linux system (but may be used by others).                                April 22, 2006                    BTSCANNER(1) Manual page btscanner(1) line 23/45 (END) (press h for help or q to quit)

As you can observe, there isn’t much to btscanner in terms of command-line parameters. This is because btscanner is a graphical user interface (GUI) tool, and its functionality becomes evident once the tool is executed. Let’s go ahead and run btscanner to unveil its capabilities.

~# btscanner

Opening the OUI database
Reading the OUT database

Although many use Bluetooth daily, its workings and vulnerabilities often remain unknown. Hacking Bluetooth provides access to vast personal data stored on phones and tablets. Unlike Wi-Fi, Bluetooth devices hop frequencies, making it challenging for attackers to intercept communication. Additionally, Bluetooth negotiates a key once, enhancing security. With built-in tools on Kali Linux, Bluetooth reconnaissance becomes accessible. Tools like hciconfig, hcitool, sdptool, l2ping, and btscanner enable device discovery, service exploration, and ping tests. Bluetooth hacking demands proximity, and a compatible adapter enhances reach. Execute these steps responsibly, respecting legal and ethical boundaries.