Ymsniper/BBF

# BBF --- BD_ADDR(UAP) 暴力破解工具 在已知 LAP 的情况下，通过 `l2ping` 所有可能的值，对目标蓝牙 `BD_ADDR` 中一个未知字节（UAP）进行暴力破解。 当部分地址已知时（通过先前的扫描、OUI 查询、嗅探流量等）， 这对于定位不可发现的设备非常有用。 如果命令行中没有提供 LAP，`bbf` 会转而驱动一个交互式的 `ubertooth-rx` 调查，在空中寻找候选地址， 然后让你选择一个输入到扫描中。 UAP 空间只有 256 个值，因此一次完整的扫描也就几百次 串行 l2ping 调用，在使用默认 pageto 的情况下最坏大约需要 5 分钟。 通常会更快，因为大多数候选地址在超时之前很久就会失败。 ## 名称解析 任何时候只要 `bbf` 获得了完整的地址（即已知的 UAP），无论是 直接从调查中获得的“可直接使用”的结果，还是通过扫描确认在线的 地址，它现在都会对其运行 `hcitool name` 并报告 结果。这是一个独立于 `l2ping`/寻呼的无线电交换过程，并且 它甚至适用于 `bbf` 本身从未明确 ping 过的地址： Remote_Name_Request 不需要配对/绑定，因此任何 支持寻呼扫描的设备 —— 大多数设备，即使是处于 “不可发现”模式的设备 —— 通常也会对此做出响应。 ``` Resolving names for 2 known-UAP address(es) from the survey... [survey] 00:00:be:b4:f1:3f -> Redmi Note 14 5G [survey] 00:00:5c:06:3e:0f -> JBL TUNE BEAM ``` `(no name response)` 结果本身就是包含信息的，而不仅仅是一个未命中 — 它可能意味着该地址已确认在线，但其协议栈针对未经身份验证的名称公开进行了强化（一些较新的协议栈会对此进行限流或限制，作为一种追踪缓解措施），而这可能正是你要审计的那种不一致性。 使用 `--save FILE` 还可以将每个已解析（或已尝试）的结果 追加到 TSV 日志中，格式为 `timestampaddressnamesource`，其中 `source` 为 `survey` 或 `sweep`，具体取决于 UAP 是如何得知的。 如果文件不存在则会创建，并且只会进行追加操作，因此在不同 LAP/会话中的重复 运行会累积到一个日志中。使用 `--no-resolve-names` 可以完全跳过名称解析并获得旧的 仅限地址行为；`--name-timeout`（默认 20s）限制了每次 `hcitool name` 调用可以阻塞的时间，与 `--pageto` 无关。 ## 合法 / 道德使用 仅对你拥有或获得明确授权的设备运行此操作 （例如，作为你获得书面许可的测试任务的一部分）。 暴力破解设备的地址会攻破蓝牙的不可发现 模式，而有些人正是依赖此模式来保护隐私。未经同意定位或指纹识别 他人的设备在你的司法管辖区可能属于非法行为，这 也不是本工具的预期用途。 大多数蓝牙设备都已配对并设置为不可发现，因为大多数人和操作系统在初始设置完成后都会关闭常规发现扫描，但不可发现模式仅会阻止扫描，并不会阻止连接。L2CAP 是面向连接的，本身没有发现机制；l2ping/l2flood 都会直接调用 connect() 并且只需要 LAP+UAP（不需要 NAP，不需要确切完整的 BD_ADDR），而这正是 bbf + ubertooth 所做的工作。因此，bbf 使得针对真实目标的 flood 工具变得更加容易。 ## 环境要求 - 带有 BlueZ 的 Linux（`l2ping`、`hciconfig`）— `sudo apt install bluez` - 已安装 l2flood-emp-mode https://github.com/Ymsniper/l2flood/tree/emp-mode（已随 BBF 打包）**原始版本：https://github.com/kovmir/l2flood ** - `sudo` 权限（`l2ping` 和 `hciconfig pageto` 都需要 root） - 一个已启动的蓝牙适配器（`hciconfig hci0 up`） - 可选，仅用于调查前端：一个 [Ubertooth One](https://github.com/greatscottgadgets/ubertooth) 并且 `PATH` 中存在 `ubertooth-rx` — `sudo apt install ubertooth` ## 安装 ``` git clone https://github.com/Ymsniper/BBF cd BBF pip install . # 如果需要，运行 (pip install . --break-system-packages) # 可选的 DOS attack 运行方式： cd l2flood-emp-mode make # Use `make serial` to build upstream l2ping. sudo make install ``` 此操作会安装一个 `bbf` 命令。对于本地开发，请连同测试依赖项一起以 可编辑模式安装： ``` pip install -e ".[dev]" ``` ## 用法 ``` bbf [known_octets] [--prefix XX:XX] [--hcidev hci0] [--pageto SLOTS] [--no-pageto-override] [--no-retry] [--retries N] [--only BYTES] [--scan-time SECONDS] [--save FILE] [--no-resolve-names] [--name-timeout SECONDS] ``` | 选项 | 默认值 | 含义 | |---|---|---| | `known_octets` | *(无)* | 3 个已知的尾随字节 (LAP)，例如 `1E:B7:E4`。如果省略，则首先运行交互式 `ubertooth-rx` 调查。 | | `--prefix` | `00:00` | 2 个已知的前导字节 (NAP)。 | | `--hcidev` | `hci0` | 要调整的 HCI 适配器。 | | `--pageto` | `1600` | 扫描期间使用的控制器寻呼超时（以 slot 为单位，1 slot = 0.625 ms），因此失效的地址不会长时间占用控制器。在重新检查阶段之前会恢复此设置。 | | `--no-pageto-override` | off | 保持适配器的寻呼超时设置不变。 | | `--no-retry` | off | 完全跳过串行重新检查阶段。 | | `--retries` | `2` | 重新检查阶段每个地址的额外尝试次数（因此默认总共尝试 3 次）。 | | `--only` | *(无)* | 直接测试以逗号分隔的十六进制字节，而不是扫描 `00..ff`，例如 `5c` 或 `04,5c,a1`。 | | `--scan-time` | *(提示输入，30s)* | 交互式调查的 `ubertooth-rx -t` 持续时间。仅在省略 `known_octets` 时使用。 | | `--save` | *(无)* | 将每个已知 UAP 地址的 `timestamp`、`address`、`name`、`source` (TSV) 追加到此文件中，无论来自调查还是扫描。如果不存在则创建，从不截断。 | | `--no-resolve-names` | off | 完全跳过 `hcitool name` 解析；仅报告地址（旧行为）。 | | `--name-timeout` | `20` | 每次 `hcitool name` 调用的子进程级超时时间（以秒为单位），与 `--pageto` 无关。 | ### 示例 针对已知的 LAP 扫描所有 256 个可能的 UAP 值： ``` bbf 1E:B7:E4 # 针对 XX in 00..FF，探测 00:00:XX:1E:B7:E4 ``` 直接测试一个特定的候选字节，跳过扫描： ``` bbf 1E:B7:E4 --only 5c # 仅测试 00:00:5c:1E:B7:E4 ``` 尚未知道 LAP — 运行交互式 `ubertooth-rx` 调查，从结果中 选择一个目标，然后对其进行扫描： ``` bbf ``` ## 工作原理 ### 调查（当省略 `known_octets` 时） `bbf` 运行 `ubertooth-rx -z -t `，实时流式传输其输出 并解析最后的“Survey Results”部分。每一行都是 以下之一： ``` ??:??:BE:B4:F1:3F UAP resolved (BE). Nothing left to sweep — this is already a complete candidate modulo the assumed NAP. Listed as "ready to use". ??:??:??:C5:9D:87 UAP unresolved (extra ??). LAP (C5:9D:87) is offered as a numbered sweep target. ``` ### 扫描 探测严格按照串行方式运行，一次只进行一个 `l2ping`，这是 有意为之，而不是为了简化。针对典型适配器的 `btmon` 捕获显示 每个 Create Connection 命令都有 `Num_HCI_Command_Packets` (`ncmd 1`)， 这意味着控制器只会向主机授予一个未完成的 寻呼尝试信用。在此之下，Link Controller 只有一个 基带和一个 RF 前端，因此无论如何它一次只能占用一个 目标的跳频序列的寻呼状态。`--pageto` 是 真正能改变总扫描时间的唯一旋钮。 `l2ping` 探测本身没有外部超时 — 每个地址 都会阻塞，直到 `l2ping` 自行退出，这受限于控制器自身的 寻呼超时（`--pageto`）。如果你需要手动退出，Ctrl-C 依然 有效。 在第一次扫描之后，任何返回“否”的地址都会进行串行 **重新检查阶段**：此时会恢复原始（较大的）寻呼超时， 并且每个地址最多获得 `--retries` 次额外尝试， 因为蓝牙设备仅在其自身的寻呼扫描窗口期间监听寻呼 — 即使针对完全正确的地址，一次未命中也可能仅仅意味着 尝试没有落在该窗口内。 ## 开发 ``` pip install -e ".[dev]" pytest ``` # 致谢 感谢 [@kovmir](https://github.com/kovmir) 提供的 l2flood，以及 感谢 [@Great Scott Gadgets](https://github.com/greatscottgadgets) 提供的 ubertooth ## 许可证 MIT — 查看 [LICENSE](LICENSE)。

标签：PoC, 插件系统, 暴力破解, 蓝牙安全, 逆向工具