Analysing Bluetooth Keyboard Traffic with hcidump
I own a RocketFish RF-BTMKY bluetooth keyboard and I really like it. Today, I tried using hcidump to dump the bluetooth traffic from my keyboard and see if I could find a pattern. hcidump is trivial to use, and can display packets in various formats. You can also dump the packets to a file that can then be read by Wireshark. hcidump requires root access to be able to capture the packets. Here is a sample capture, took while I was typing the word "test":
debian:/home/aghaster/bt# hcidump -x
HCI sniffer - Bluetooth packet analyzer ver 1.42
device: hci0 snap_len: 1028 filter: 0xffffffffffffffff
> ACL data: handle 11 flags 0x02 dlen 14
L2CAP(d): cid 0x0040 len 10 [psm 0]
A1 01 00 00 17 00 00 00 00 00
> ACL data: handle 11 flags 0x02 dlen 14
L2CAP(d): cid 0x0040 len 10 [psm 0]
A1 01 00 00 00 00 00 00 00 00
> ACL data: handle 11 flags 0x02 dlen 14
L2CAP(d): cid 0x0040 len 10 [psm 0]
A1 01 00 00 08 00 00 00 00 00
> ACL data: handle 11 flags 0x02 dlen 14
L2CAP(d): cid 0x0040 len 10 [psm 0]
A1 01 00 00 00 00 00 00 00 00
> ACL data: handle 11 flags 0x02 dlen 14
L2CAP(d): cid 0x0040 len 10 [psm 0]
A1 01 00 00 16 00 00 00 00 00
> ACL data: handle 11 flags 0x02 dlen 14
L2CAP(d): cid 0x0040 len 10 [psm 0]
A1 01 00 00 00 00 00 00 00 00
> ACL data: handle 11 flags 0x02 dlen 14
L2CAP(d): cid 0x0040 len 10 [psm 0]
A1 01 00 00 17 00 00 00 00 00
> ACL data: handle 11 flags 0x02 dlen 14
L2CAP(d): cid 0x0040 len 10 [psm 0]
A1 01 00 00 00 00 00 00 00 00
Quick observation reveals that there is direct equivalence between a code and a key that has been typed:
T: 0x17
E: 0x08
S: 0x16
T: 0x07
I've heard of wireless keyboards that scramble the codes, but this one apparently doesn't. The packets where the code is set to 0 are probably used to indicate that a key has been released. I didn't take the time to figure out all the codes, but here are the codes for letters and numbers:
A to Z: 0x04 to 0x1D
1 to 9: 0x1E to 0x26
0: 0x27 (the digits are in the same order as on the keyboard, so 0 comes after 9)
Just for fun, I made a perl script that calls hcidump, analyses the packets and outputs the corresponding characters:
#!/usr/bin/perl
@keys =
(
"", "", "", "",
"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
"1", "2", "3", "4", "5", "6", "7", "8", "9", "0"
);
use IO::Handle;
open("BT", "hcidump -x |") or die("Can't start hcidump");
while($line = ) {
# Sample packet:
# A1 01 00 00 CC 00 00 00 00 00
# Where CC is the code for the key
if($line =~ m/\s+A1/) {
@bytes = split(/ /, $line);
$code = hex($bytes[10]);
if($code != 0) {
printf("%02X\t%s\n", $code, $keys[$code]);
}
}
}
close("BT");
And here is sample output:
debian:/home/aghaster/bt# perl btkbdsniff.pl
17 T
08 E
16 S
17 T
2C
1E 1
1F 2
20 3
Don't forget to run the script as root so that hcidump can capture the packets. Even though it is trivial to figure out the keys from the packet capture, one still needs to be able to capture the bluetooth traffic. hcidump requires root access, so there is nothing to worry about (I would worry more about someone having unauthorized root access before worrying about him keylogging me).