-
Notifications
You must be signed in to change notification settings - Fork 6
BTCrack - Bluetooth PIN and Link-key cracker
License
thierryzoller/BTcrack
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Folders and files
Name | Name | Last commit message | Last commit date | |
---|---|---|---|---|
Repository files navigation
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 ([email protected]) 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:https://www.cobra-basket.de & http:https://blog.zoller.lu Updates to 1.1 ============== + Format String bug (Michael Ossman) + Master ACO was overwritten by the the slave ACO thus impairing decryption ([email protected]) 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:https://www.cobra-basket.de or [email protected] You can contact Thierry Zoller at http:https://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.
About
BTCrack - Bluetooth PIN and Link-key cracker
Resources
License
Stars
Watchers
Forks
Releases
No releases published
Packages 0
No packages published