BTCrack v1.01
=============
Authors : Eric Sesterhen & Thierry Zoller
BTCrack is part of the Backtrack Distribution since 2008

Updates to 1.01
================
+ Format String bug (Michael Ossman)
+ Master ACO was overwritten by the the slave ACO thus impairing decryption (carl.dunhamm@hotmail.com)

Introduction
============
BTCrack is the worlds first Bluetooth Pass phrase (PIN) brute-force tool, BTCrack will brute-force the Passkey and the Link key from captured pairing exchanges.
To capture the pairing data it is necessary to have a Professional Bluetooth Analyzer : FTE (BPA 100, BPA 105, others), Merlin OR to know how to flash a CSR based consumer USB dongle with special firmware.

Example of an Attack scenario :
-Attacker reconstructs BD_ADDR of both Master and Slave through passive (reconstructing through a preamble sniff, even when the device is in hidden mode) or active means (redfang)
-Attacker changes his BD_ADDR to the one of the Slave device
-Attacker asks to pair with the Master indicating it has no key, the Master will more then often trash the old pairing data and request a new link key from the genuine slave
-Attacker now captures the key (pairing) exchange taking place between the two devices as the users try to re-establish a connection
-Attacker exports data to CSV format and imports into BTCrack
-Attacker can now compromise Master and Slave Bluetooth device through usage of the cracked Linkkey and is able to decrypt the data transmitted between the bluetooth devices

The PIN is not so important as the Linkkey
-------------------------------------------
An Attacker will focus on recovering the Linkkey and not the PIN, here's why :

The Link-key allows remote connections without the victim noticing
The Link-key allows and attacker to connect to devices in non-pairing mode and non discoverable mode
The Link-key allows decryption of the data

History
=======
Olly Whitehouse - 2003 - Presented theoretic weaknesses in the implementation of the pairing exchange.
Shaked and Wool - 2005 - Present their logic to break pairing exchanges.
Thierry Zoller - 2006 - First public release of a complete optimised implementation of the Shaked and Wool logic. Optimisations done by Erik Sesterhenn.
David Hulton / Thierry Zoller - 2007 - Worlds first FPGA based Implementation



Original Readme :




BTCrack OSS 1.1
===============
License : GPL3 see LICENSE
Authors : Eric Sesterhen & Thierry Zoller
Contact : http://www.cobra-basket.de & http://blog.zoller.lu

Updates to 1.1
==============
+ Format String bug (Michael Ossman)
+ Master ACO was overwritten by the the slave ACO thus impairing decryption (carl.dunhamm@hotmail.com)

Updates left to the reader (Courtesy  of Carl Dunhamm) : 
=======================================================
> line 446: It is not correct to always use bp->bdaddr_s for the in_bdaddr parameter of KeyInit. 
It is wrong to assume that INRAND always comes from the Master, sometimes it comes from the slave.
Indeed it depends whether the slave or the master actually sent the IN_RAND. If its the master then 
bdaddr_s has to be used, but if it's the slave then bdaddr_m has to be used.  

Suggested patch :
Detect whether inrand comes from Master or Slave and adjust the KeyInit call, alternatively
take appropriate parameter from the command-line to decide.

Details on the Patch of Carl Dunhamm
====================================
"GetSRES(bp->kab, bp->au_rand_s, bp->bdaddr_m, bp->calc_sres_m, bp->calc_aco_m);"
It shall be "bp->calc_aco_s" instead of "bp->calc_aco_m". 
With the orinigal version the master ACO is overwritten by the one of the slave.
This is not imparing the finding of the PIN or link key, but if master ACO has 
to be reused for some reason, one will get the wrong one when refering to calc_aco_m.

About
=====
This is a straight forward linux port of Thierry Zollers' BTCrack.
Should work with most other unixes too, code is nearly ansi clean, 
except for strdup(), but I guess every OS should have this by now.

Compiling was tested so far with
	- gcc version 4.1.1 (Gentoo 4.1.1-r3) on i686-pc-linux-gnu
	- gcc version 4.3.0-alpha20061216 on i586-pc-linux-gnu
	- gcc version 3.3.6 on i586-pc-linux-gnu
	- gcc version 3.4.6 on i586-pc-linux-gnu
	- gcc version 2.95.4 20011002 (Debian prerelease) on i686-pc-linux-gnu
	- gcc version 4.0.3 on sparc-sun-solaris2.8
	- icc Version 9.1 Build 20060706Z on i686-pc-linux-gnu
	- Sun WorkShop 6 update 2 C 5.3 Patch 111679-11 2003/04/02

Test it with the provided csv file:
./btcrack 1 00:11:9F:C4:F3:AE 00:60:57:1A:6B:F1 ./Pin_654321.csv

Contact
=======
You can contact Eric Sesterhen at http://www.cobra-basket.de or snakebyte@cccmz.de
You can contact Thierry Zoller at http://blog.zoller.lu

Comments 
========
Interestingly there is nearly no difference between icc and gcc on my 2400+ Sempron
box, the gcc seems slightly (~5%) faster. And only ~10% between -O3 and -Os. On my K6 the code
compiled with an mid-december gcc 4.3 snapshot is twice as fast as the 3.3.6 version :-)
On the solaris box, the sun compiler generated better code than the gcc (~15-20%)
The dual P3 box, gave me a 1 1/2 speedup of gcc 4.1 to gcc 2.95, 3.4 was only marginally
faster (~10%) than 2.95.