ymsniper/whisper_bullyاستخراج عنوان BDADDR بلوتوث ثلاثي المراحل، رفض الخدمة والاختطاف على أجهزة Fast Pair؛ أوليات غير مصححة خارج نطاق CVE-2025-36911 (لا حاجة لأوبيرتوث)
أداة بحث لاستخراج BDADDR البلوتوث، رفض الخدمة والاختطاف
© 2026 @Ymsniper — لأغراض البحث الأمني المرخص فقط.
Whisper Bully هي أداة بحث أمني بلوتوث ثلاثية المراحل تستهدف الأجهزة التي تعلن عن Google Fast Pair (معرف الخدمة fe2c). إنها توضح بدائي هجوم غير مصححين خارج نطاق تصحيح البرامج الثابتة CVE-2025-36911:
⚠️ هذه الأداة لا تنفذ بروتوكول Whisper Pair (Fast Pair GATT). إنها لا تكتب أبدًا إلى خاصية Key-Based Pairing (UUID 1236) أو خاصية Account Key (UUID 1238). سطح الهجوم الموصوف هنا منفصل وغير معالج بواسطة تصحيح فحص وضع الاقتران CVE-2025-36911.
https://github.com/user-attachments/assets/67f2bcb6-38ad-4ba0-80c5-36dbb54f3f11
السبب الجذري: عند إنشاء اتصال BLE، يقوم مكدس مضيف Linux BlueZ بمعالجة حدث LL_CONNECTION_COMPLETE وحل العنوان الخاص القابل للحل (RPA) للجهاز إلى عنوان هويته الدائم، وتخزينه مؤقتًا في جدول أجهزة BlueZ. يحدث هذا على مستوى الطبقة الرابطة / HCI، قبل أي تفاعل مع خدمة GATT. لا يوجد بروتوكول Fast Pair متورط.
ما يفعله الكود فعليًا:
BleakScanner) للأجهزة التي تعلن عن معرف خدمة Fast Pair fe2c — يُستخدم فقط لتحديد الهدف، لا تفاعل بروتوكولBleakClient.connect() — لا توجد كتابات GATT من أي نوعNoInputNoOutput تحضيرًا للخطوة 4wb.py)bluetoothctl pair <rpa_addr> — محاولة اقتران SMP قياسية، وليست Fast Pairbluetoothctl القياسية للحصول على Bonded: yes، والتي قد تحمل العنوان المربوطbluetoothctl devices ويقارن مع RPA الأولي — أي إدخال بنفس اسم الجهاز ولكن بعنوان مختلف هو عنوان الهوية الدائم، الذي تم تسريبه بواسطة BlueZ في الخطوة 2لماذا لا يصلح التصحيح هذا:
يضيف إصلاح CVE-2025-36911 في البرامج الثابتة فحصًا لوضع الاقتران إلى معالج خاصية Key-Based Pairing GATT لـ Fast Pair على الملحق. هذه الأداة لا تكتب أبدًا إلى تلك الخاصية. يحدث تسرب عنوان الهوية على مضيف Linux للمهاجم عبر ذاكرة التخزين المؤقت الخاصة بـ BlueZ — بالكامل خارج البرامج الثابتة للملحق.
ملاحظات السلوك الرئيسية:
bluetoothctl pair أو انتهت مهلةNoInputNoOutput تعني عدم وجود تفاعل مستخدم على أي من الجانبين لـ Just Worksبمجرد معرفة العنوان الدائم، يمكن تنفيذ رفض خدمة L2CAP مستدام باستخدام نسخة معدلة من l2flood.
يتم استخدام وضعين عبر الأداة:
علم -R — وضع EMP (فيضان المرحلة 2)
إطلاق ونسيان صامت مع إعادة اتصال نبضية. تقوم جميع الخيوط بمزامنة دوراتها (اتصال ← انفجار ← إغلاق قسري) بحيث يتلقى الهدف تمزيق ACL كامل دوريًا بدلاً من خلط قنوات L2CAP المتداخل الذي يمكنه امتصاصه. يستخدم SO_LINGER {1,0} لتدمير فوري عبر RST عند كل إغلاق. لا ينتج أي مخرجات stdout أثناء التشغيل العادي — يتم كتم أخطاء الاتصال إلى stderr وطباعتها دوريًا فقط.
الوضع العادي (فحص اختطاف المرحلة 3)
يُستخدم بدون -R لفحص ما إذا كان الهدف لا يزال يستجيب. تم تحسين هذا الوضع أيضًا — فهو يعالج الآن إعادة الاتصال تلقائيًا ويخرج no response from <addr>: id N عندما يتوقف الهدف عن الاستجابة، وهو ما تراقبه wb.py لبدء الاختطاف.
النتيجة: يصبح الجهاز الهدف غير مستجيب لمحاولات الاتصال العادية أثناء نشاط الفيضان. يتعافى الجهاز بالكامل عندما يتوقف الهجوم — لا ضرر دائم.
سلوك الخيوط المتعددة:
السبب الجذري: يتسبب فيضان L2CAP المستدام في تعطل أو إعادة ضبط مكدس البلوتوث للجهاز الهدف. أثناء نافذة الاسترداد — قبل إعادة تسجيل خدمة GATT لـ Fast Pair وقبل إعادة تهيئة مدير الأمان بالكامل — يقبل الجهاز رابط SMP Just Works قياسيًا من NoInputNoOutput دون الحاجة إلى مصافحة GATT لـ Fast Pair التي كانت ستحجب الرابط عادةً. الرابط الناتج دائم: يبقى بعد إعادة ضبط محول BT ويظهر Paired: yes / Bonded: yes في bluetoothctl info.
لماذا هذا اكتشاف منفصل عن CVE-2025-36911:
يفرض تصحيح CVE-2025-36911 فحص وضع الاقتران في معالج خاصية Key-Based Pairing GATT لـ FP. المرحلة 3 لا تلمس تلك الخاصية أبدًا. يتم إنشاء الرابط على طبقة SMP خلال نافذة لم يتم فيها إعادة تهيئة خادم GATT لـ FP، لذلك لا يتم الوصول إلى بوابة أمان Fast Pair حتى. يظل الجهاز المصحح بالكامل عرضة لهذا لأن التصحيح ليس لديه رؤية لطبقة SMP أثناء استرداد المكدس.
ما يفعله الكود فعليًا:
l2flood -c -1 -t 2) لتأكيد أن الجهاز غير مستجيب — يبحث عن no response from <addr>: id N في المخرجاتbluetoothctl connect <permanent_addr> في حلقة إعادة محاولةNoInputNoOutput / NoInputNoOutput ← نموذج اقتران Just Works ← يكتمل الرابطbluetoothctl connect يُرجع رمز الخروج 0 عند النجاحاحتمالية النجاح حسب حالة الجهاز:
| حالة الجهاز | النتيجة المتوقعة |
|---|---|
| نشط في الفيضان / غير مستجيب | أعلى نجاح — المكدس في حالة متدهورة أثناء الاسترداد |
| يتعافى من الفيضان | نجاح مرتفع — نافذة إعادة تهيئة SM مؤقتة |
| تعافى بالكامل | نجاح أقل — تم استعادة الأمان الطبيعي |
| تم إيقاف تشغيله | يفشل |
| CVE-2025-36911 (WhisperPair) | هذه الأداة | |
|---|---|---|
| البروتوكول المستخدم | Fast Pair GATT KBP (كتابة UUID 1236) | لا شيء — اتصال BLE عادي فقط |
| مسار تسريب BDADDR | إشعار KBP مشفر (عنوان BR/EDR) | حل RPA في BlueZ عند LL_CONNECTION_COMPLETE |
| مسار تجاوز المصادقة | فحص وضع الاقتران FP مفقود | SMP Just Works أثناء نافذة استرداد مكدس BT |
| تم تصحيحه بواسطة إصلاح 36911؟ | نعم | لا |
| يعمل على الأجهزة المصححة؟ | لا | نعم |
| CWE | CWE-287 | CWE-200 (المرحلة 1) + CWE-362/CWE-287 (المرحلة 3) |
هذه أداة بحث عن رفض الخدمة والوصول غير المصرح به.
استخدام هذه الأداة على أجهزة لا تملكها أو بدون إذن كتابي صريح هو جريمة فيدرالية يعاقب عليها بالسجن والغرامات بموجب قانون الاحتيال وإساءة استخدام الكمبيوتر (18 U.S.C. § 1030) والقوانين المماثلة في ولايات قضائية أخرى.
يُسمح لك فقط باستخدام هذه الأداة على:
bluetoothctl والوصول الخام إلى BLE)bluetoothctl / BlueZ مثبت ويعملl2flood مع دعم OpenMP — انظر kovmir/l2floodUbuntu / Debian:
sudo apt update
sudo apt install -y python3 python3-pip libdbus-1-dev libglib2.0-dev bluez
Fedora / RHEL / CentOS:
sudo dnf install -y python3 python3-pip dbus-devel glib2-devel bluez
Arch Linux:
sudo pacman -S python python-pip dbus glib bluez
Alpine Linux:
apk add --no-cache python3 py3-pip dbus-dev glib-dev bluez bluez-openrc
openSUSE:
sudo zypper install -y python3 python3-pip dbus-1-devel glib2-devel bluez
Void Linux:
sudo xbps-install -S python3 python3-pip dbus-devel glib-devel bluez
git clone https://github.com/Ymsniper/Whisper_Bully.git
cd Whisper_Bully
pip3 install -r requirements.txt
# مطلوب للمرحلة 2/3 فقط:
make
sudo make install