Bluetooth mayhem -- part II

In the previous post all kinds of methods have been shown to get hold of the all-important bdaddr or MAC address of the bluetooth devices, so here I am assuming that you have, or know how to obtain, the bdaddr of your test device.

After all the scanning is complete and I have found my test subject... what next ?
Well, as always, get more information !

We can get further information on the device's services and channels by fingerprinting with sdptool;

sdptool -i hci0 browse 6C:9B:02:FF:97:2F

Hectic amount of output there... so what do we actually need ?
From what I have read, we want to get the Service Name, the Service RecHandle and the Channel.

So to simplify the output to get what we want, I will use grep -e (egrep) to make it a little more readable ;

sdptool -i hci0 browse 6C:9B:02:FF:97:2F | egrep 'Service Name|Service RecHandle|Channel'

So at this stage we have the bdaddr of the test device and a list of services and channels which we will use when we prepare for a connection.

Next step is preparing a connection with the device, but first some more preparation;

Editing main.conf

================

nano /etc/bluetooth/main.conf
Edit the line under Default device class to the class you want, in this case I am doing cell phone.

Class = 0x500204

No need to edit anything else.

Editing rfcomm.conf
==================

nano /etc/bluetooth/rfcomm.conf

Edit the rfcomm.conf; enable binding, enter bdaddr of the device you want to connect to, enter channel number of the service you want to access, enter the name of the connection.
Delete the hashes where necessary in the original rfcomm.conf file and finally the file should look something
like the below;

Editing file permissions

====================

Edit the permissions of below files in /etc/bluetooth/;

cd /etc/bluetooth/

chmod 755 {main.conf,networking.conf,rfcomm.conf}

Not sure that editing the main.conf, rfcomm.conf and setting the file permissions is absolutely necessary, as you can set the device class in hciconfig and can enter the rfcomm information directly in the command line... 
But if you can't tell by now... I'm flying as blind as a deaf bat with this ;)

Best to then restart bluetooth service ;

/etc/init.d/bluetooth restart

Configuring your bluetooth interface with hciconfig

Reference: http://linux.die.net/man/8/hciconfig

===========================================

hciconfig -a hci0 up

Opens and initializes the HCI device
hciconfig -a hci0 class 0x500204
Sets the device's class (0x500204 is for Cell Phone)

hciconfig -a hci0 lm accept, master;

Sets link mode to accept baseband connection and
also to ask to become master when connection request comes in.

hciconfig -a hci0 lp rswitch,hold,sniff,park;

Sets the link policies.
hciconfig -a hci0 name TEST
Sets the name of your bluetooth device

There are various posts on which settings should be enabled, some also mention ;

hciconfig -a hci0 auth enable

hciconfig -a hci0 encrypt enable

This however interfered with sdptool's capability to scan devices for info due to an invalid exchange.
(I assume the due to the device then being set to security mode 3: link level enforced security)
http://www.palowireless.com/bluearticles/cc1_security1.asp

Updating the Service Discovery Protocol Database

Reference: http://linux.die.net/man/1/sdptool

==========================================

For instance;

sdptool -i hci0 add --handle=0x10001 --channel=9 OPUSH

sdptool -i hci0 add --handle=0x10002 --channel=10 FTP

sdptool -i hci0 add --handle=0x10003 --channel=1 DUN

The handles and channels for the services may be different for other phones so check all info with sdptool.


OK, so now that's all done, what am I able to do ?
Well, not so much actually.

It turns out that the above configurations haven't helped me in connections, however knowing the processes is always a good thing ;) and might as well document it !


In all connection attempts, I needed to Accept the connection on the cell phone.

Connecting with rfcomm

References: http://linux.die.net/man/1/rfcomm

http://www.palowireless.com/infotooth/tutorial/rfcomm.asp

=======================================

First to try a connection to the OPUSH service which on my cell is on Channel 9.
As all the information has been entered for this in rfcomm.conf I can enter ;

rfcomm bind 0

rfcomm

rfcomm connect 0

If the address already in use error comes up, then release the device or all devices;
rfcomm release hci0 or rfcomm release all and try again.

I have to accept on cell phone to receive data from 'TEST' (name given to bluetooth interface) and then connection is made.

Its probably better practice though to enter the full code in the command line;

rfcomm bind 0 6C:9B:02:FF:97:2F 9

rfcomm

rfcomm connect 0 6C:9B:02:FF:97:2F 9

(I am still obliged to accept data on the cell phone)

The rfcomm connection attempt fails for most services as there are no means I can find included in BackTrack4, to reply to the PIN request from the phone.

To check & verify on the PIN request response issue;
http://www.linuxquestions.org/questions/slackware-14/slackware-13-bluetooth-pan-759274/

After much googling and reading I found a reference to using simple-agent which is included in Bluez-4.32 package.
I just extracted that file (from the 'test' subfolder) and copying the file simple-agent to for instance /etc/bluetooth/ and running it, it returns Agent registered.

When trying to connect with rfcomm to a service prompts a PIN request from the device, such as the below example for OBEX File Transfer, simple-agent returns with RequestPinCode along with the bdaddr where the request came from and prompts for a PIN.

Enter the PIN that was entered in the device (in this case 0000) and pairing is succesful.

Yay ! Connected !

So what have I actually accomplished with all the above ?
Well, it feels like not very much at all, but at least I am a step closer to understanding the connection methods involved.

With a lot, probably a helluva lot, more time on google and various fora, I hope to be able to learn a bit more about bluetooth hacking.

This truly is a slow process ;)

As always, any insightful comments which may help enable the various bluetooth tools in BackTrack4 greatly appreciated.

On to part III ? !