Skip to content
KitploitKITPLOIT
أدواتالمدونة
إرسال
أدواتالمدونة
إرسال

أدوات الاختراق واختبار الاختراق والأمن السيبراني لترسانتك الأمنية!

Kitploit هو دليل لأدوات الاختراق والأمن السيبراني واختبار الاختراق. اكتشف آخر تحديثات المشاريع للعثور على الثغرات وتحليل الأنظمة وأتمتة الاختبارات وتعزيز أمنك.

··الخلاصات·اتصال·الخصوصية·© 2026 Kitploit

دليل الأدوات

الفئات

عرض جميع الفئات
Loading categories
أدوات/GitHubGitHub/ymsniper/whisper_bully
الاستطلاعأمن البلوتوثالاستغلالجمع المعلوماتأمن الشبكات اللاسلكيةاختبار الاختراقالفريق الأحمر
GitHubymsniper/whisper_bully

Whisper_Bully

استخراج عنوان BDADDR بلوتوث ثلاثي المراحل، رفض الخدمة والاختطاف على أجهزة Fast Pair؛ أوليات غير مصححة خارج نطاق CVE-2025-36911 (لا حاجة لأوبيرتوث)

عرض المستودع
3413منذ شهر واحدتمت المراجعة من قبل Kitploit

الأكثر شعبية

عرض الكل →

اكتشف الأدوات الأكثر استخدامًا من قبل مجتمعنا.

استكشف جميع الأدوات

تصفح مجموعتنا من الأدوات

عرض جميع الأدوات →
مشاركة

Whisper Bully

أداة بحث لاستخراج BDADDR البلوتوث، رفض الخدمة والاختطاف

© 2026 @Ymsniper — لأغراض البحث الأمني المرخص فقط.


نظرة عامة

Whisper Bully هي أداة بحث أمني بلوتوث ثلاثية المراحل تستهدف الأجهزة التي تعلن عن Google Fast Pair (معرف الخدمة fe2c). إنها توضح بدائي هجوم غير مصححين خارج نطاق تصحيح البرامج الثابتة CVE-2025-36911:

  • تسريب BDADDR غير مصحح — عنوان الهوية الدائم يُكشف عبر اتصال BLE عادي، لا حاجة لتفاعل GATT، يعمل على الأجهزة المصححة بالكامل
  • تجاوز مصادقة SMP عبر نافذة إعادة الضبط — إنشاء رابط دائم عبر SMP Just Works القياسي أثناء استرداد مكدس BT بعد فيضان L2CAP، دون أي مصافحة GATT لـ Fast Pair

⚠️ هذه الأداة لا تنفذ بروتوكول 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

مراحل الهجوم

المرحلة 1 — استخراج BDADDR (كشف معلومات غير مصحح)

السبب الجذري: عند إنشاء اتصال BLE، يقوم مكدس مضيف Linux BlueZ بمعالجة حدث LL_CONNECTION_COMPLETE وحل العنوان الخاص القابل للحل (RPA) للجهاز إلى عنوان هويته الدائم، وتخزينه مؤقتًا في جدول أجهزة BlueZ. يحدث هذا على مستوى الطبقة الرابطة / HCI، قبل أي تفاعل مع خدمة GATT. لا يوجد بروتوكول Fast Pair متورط.

ما يفعله الكود فعليًا:

  1. يقوم بمسح BLE نشط (BleakScanner) للأجهزة التي تعلن عن معرف خدمة Fast Pair fe2c — يُستخدم فقط لتحديد الهدف، لا تفاعل بروتوكول
  2. ينشئ اتصال BLE عادي عبر BleakClient.connect() — لا توجد كتابات GATT من أي نوع
  3. يضبط وكيل BlueZ على NoInputNoOutput تحضيرًا للخطوة 4
  4. يتحقق مما إذا كانت خدمة GATT لـ Fast Pair موجودة على الهدف — هذا الفحص استشاري فقط؛ تستمر الأداة بغض النظر عن النتيجة (السطر 452 من wb.py)
  5. يشغّل bluetoothctl pair <rpa_addr> — محاولة اقتران SMP قياسية، وليست Fast Pair
  6. يراقب مخرجات bluetoothctl القياسية للحصول على Bonded: yes، والتي قد تحمل العنوان المربوط
  7. البديل الأساسي: يستدعي bluetoothctl devices ويقارن مع RPA الأولي — أي إدخال بنفس اسم الجهاز ولكن بعنوان مختلف هو عنوان الهوية الدائم، الذي تم تسريبه بواسطة BlueZ في الخطوة 2

لماذا لا يصلح التصحيح هذا:

يضيف إصلاح CVE-2025-36911 في البرامج الثابتة فحصًا لوضع الاقتران إلى معالج خاصية Key-Based Pairing GATT لـ Fast Pair على الملحق. هذه الأداة لا تكتب أبدًا إلى تلك الخاصية. يحدث تسرب عنوان الهوية على مضيف Linux للمهاجم عبر ذاكرة التخزين المؤقت الخاصة بـ BlueZ — بالكامل خارج البرامج الثابتة للملحق.

ملاحظات السلوك الرئيسية:

  • يمكن أن ينجح الاستخراج حتى لو فشلت خطوة bluetoothctl pair أو انتهت مهلة
  • فحص وجود خدمة GATT لـ FP في الخطوة 4 لا يحجب الهجوم
  • لا تظهر نافذة تأكيد PIN — NoInputNoOutput تعني عدم وجود تفاعل مستخدم على أي من الجانبين لـ Just Works

المرحلة 2 — فيضان L2CAP (وضع إعادة الاتصال النبضي EMP)

بمجرد معرفة العنوان الدائم، يمكن تنفيذ رفض خدمة L2CAP مستدام باستخدام نسخة معدلة من l2flood.

يتم استخدام وضعين عبر الأداة:

علم -R — وضع EMP (فيضان المرحلة 2) إطلاق ونسيان صامت مع إعادة اتصال نبضية. تقوم جميع الخيوط بمزامنة دوراتها (اتصال ← انفجار ← إغلاق قسري) بحيث يتلقى الهدف تمزيق ACL كامل دوريًا بدلاً من خلط قنوات L2CAP المتداخل الذي يمكنه امتصاصه. يستخدم SO_LINGER {1,0} لتدمير فوري عبر RST عند كل إغلاق. لا ينتج أي مخرجات stdout أثناء التشغيل العادي — يتم كتم أخطاء الاتصال إلى stderr وطباعتها دوريًا فقط.

الوضع العادي (فحص اختطاف المرحلة 3) يُستخدم بدون -R لفحص ما إذا كان الهدف لا يزال يستجيب. تم تحسين هذا الوضع أيضًا — فهو يعالج الآن إعادة الاتصال تلقائيًا ويخرج no response from <addr>: id N عندما يتوقف الهدف عن الاستجابة، وهو ما تراقبه wb.py لبدء الاختطاف.

النتيجة: يصبح الجهاز الهدف غير مستجيب لمحاولات الاتصال العادية أثناء نشاط الفيضان. يتعافى الجهاز بالكامل عندما يتوقف الهجوم — لا ضرر دائم.

سلوك الخيوط المتعددة:

  • تتزامن الخيوط بعد كل دورة انفجار بحيث يصل الضغط على الهدف في وقت واحد
  • فعال حتى حوالي 16 خيطًا على الأجهزة النموذجية؛ عوائد متناقصة بعد ذلك
  • يمكن استخدام محولات HCI متعددة في وقت واحد لزيادة الضغط

المرحلة 3 — الاختطاف عبر SMP Just Works أثناء نافذة إعادة الضبط (تجاوز مصادقة غير مصحح)

السبب الجذري: يتسبب فيضان 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 أثناء استرداد المكدس.

ما يفعله الكود فعليًا:

  1. يرسل مسبار L2CAP (l2flood -c -1 -t 2) لتأكيد أن الجهاز غير مستجيب — يبحث عن no response from <addr>: id N في المخرجات
  2. بمجرد تأكيد الحالة غير المستجيبة، يشغّل bluetoothctl connect <permanent_addr> في حلقة إعادة محاولة
  3. يتفاوض SMP على NoInputNoOutput / NoInputNoOutput ← نموذج اقتران Just Works ← يكتمل الرابط
  4. bluetoothctl connect يُرجع رمز الخروج 0 عند النجاح
  5. يستمر الرابط بعد توقف الهجوم

احتمالية النجاح حسب حالة الجهاز:

حالة الجهازالنتيجة المتوقعة
نشط في الفيضان / غير مستجيبأعلى نجاح — المكدس في حالة متدهورة أثناء الاسترداد
يتعافى من الفيضاننجاح مرتفع — نافذة إعادة تهيئة SM مؤقتة
تعافى بالكاملنجاح أقل — تم استعادة الأمان الطبيعي
تم إيقاف تشغيلهيفشل

العلاقة بـ CVE-2025-36911


⚠️ تحذير قانوني

هذه أداة بحث عن رفض الخدمة والوصول غير المصرح به.

استخدام هذه الأداة على أجهزة لا تملكها أو بدون إذن كتابي صريح هو جريمة فيدرالية يعاقب عليها بالسجن والغرامات بموجب قانون الاحتيال وإساءة استخدام الكمبيوتر (18 U.S.C. § 1030) والقوانين المماثلة في ولايات قضائية أخرى.

يُسمح لك فقط باستخدام هذه الأداة على:

  • الأجهزة التي تملكها شخصيًا
  • الأجهزة التي لديك إذن كتابي صريح من المالك لإجراء اختبار أمني عليها

المتطلبات

  • لينكس (تم اختباره على Ubuntu 20.04+)
  • صلاحيات الجذر (مطلوبة لـ bluetoothctl والوصول الخام إلى BLE)
  • bluetoothctl / BlueZ مثبت ويعمل
  • Python 3.7+
  • للمرحلة 2/3: l2flood مع دعم OpenMP — انظر kovmir/l2flood

التثبيت

تبعيات النظام

Ubuntu / Debian:

root@kitploit:~
sudo apt update
sudo apt install -y python3 python3-pip libdbus-1-dev libglib2.0-dev bluez

Fedora / RHEL / CentOS:

root@kitploit:~
sudo dnf install -y python3 python3-pip dbus-devel glib2-devel bluez

Arch Linux:

root@kitploit:~
sudo pacman -S python python-pip dbus glib bluez

Alpine Linux:

root@kitploit:~
apk add --no-cache python3 py3-pip dbus-dev glib-dev bluez bluez-openrc

openSUSE:

root@kitploit:~
sudo zypper install -y python3 python3-pip dbus-1-devel glib2-devel bluez

Void Linux:

root@kitploit:~
sudo xbps-install -S python3 python3-pip dbus-devel glib-devel bluez

الاستنساخ والتثبيت

root@kitploit:~
git clone https://github.com/Ymsniper/Whisper_Bully.git
cd Whisper_Bully
pip3 install -r requirements.txt
# مطلوب للمرحلة 2/3 فقط:
make
sudo make install

الاستخدام

المرحلة 1: استخراج BDADDR

root@kitploit:~
# الكشف التلقائي واستخراج جميع أجهزة Fast Pair القريبة
sudo python3 wb.py

# مسح لمدة 20 ثانية، حفظ النتائج
sudo python3 wb.py -s 20 -o targets.json

# مسح لمدة 30 ثانية، ملف مخرجات مخصص
sudo python3 wb.py -s 30 -o extracted.json

ملاحظة: إذا كان الجهاز متصلاً أو مقترنًا سابقًا بهذه الأداة أو يدويًا، فإن BlueZ يعرف بالفعل عنوان هويته. قم بإزالته أولاً ليعمل الاستخراج بشكل نظيف:

root@kitploit:~
sudo bluetoothctl remove <address>

المرحلة 2: فيضان L2CAP (اختياري)

الطريقة 1 — تفاعلية (يتم السؤال بعد الاستخراج)

root@kitploit:~
sudo python3 wb.py -s 20 -o targets.json
# عند الانتهاء: "Run aggressive L2CAP test... (yes/no)" → yes

الطريقة 2 — الأعلام (تخطي الأسئلة)

root@kitploit:~
# المرحلة 1 + المرحلة 2 فقط
sudo python3 wb.py -s 20 -o targets.json --aggressive

# المرحلة 1 + المرحلة 2 + المرحلة 3
sudo python3 wb.py -s 20 -o targets.json --aggressive --hijack

# مع تحديد المدة وعدد الخيوط
sudo python3 wb.py -s 20 -o targets.json --aggressive --hijack -d 120 -t 8

الطريقة 3 — سكريبت فيضان مستقل

root@kitploit:~
# فيضان من ملف الأهداف المستخرجة لمدة 120 ثانية
sudo python3 aggressive_test.py -f targets.json -d 120 -t 4

# فيضان عنوان واحد معروف لمدة 60 ثانية
sudo python3 aggressive_test.py AA:BB:CC:DD:EE:FF -d 60

# فيضان إلى الأبد (Ctrl+C للإيقاف)
sudo python3 aggressive_test.py AA:BB:CC:DD:EE:FF -f

المرحلة 3: الاختطاف (اختياري)

root@kitploit:~
# مدمج — استخراج، فيضان، ثم اختطاف
sudo python3 wb.py -s 20 -o targets.json --aggressive --hijack -d 120

# اختطاف مستقل يدوي على عنوان معروف
sudo python3 wb.py -H AA:BB:CC:DD:EE:FF

تشغيل المراحل الثلاث الكاملة (أمر واحد)

root@kitploit:~
sudo python3 wb.py -s 20 -o targets.json --aggressive --hijack -d 120 -t 4

سير التنفيذ:

  1. مسح لمدة 20 ثانية لأجهزة Fast Pair
  2. استخراج BDADDR الدائم من كل هدف
  3. فيضان جميع الأهداف لمدة 120 ثانية باستخدام 4 خيوط
  4. مراقبة الحالة غير المستجيبة
  5. محاولة اختطاف كل هدف خلال نافذة الاسترداد
  6. حفظ النتائج في targets.json

هجوم متعدد المحولات

root@kitploit:~
# الطرفية 1
sudo python3 wb.py -s 20 -o targets.json --aggressive --hijack -i hci0 -d 120 -t 4 &

# الطرفية 2
sudo python3 wb.py -s 20 -o targets.json --aggressive --hijack -i hci1 -d 120 -t 4

يضاعف ضغط DoS ويزيد احتمالية نجاح الاختطاف خلال نافذة الاسترداد.


أعلام سطر الأوامر


التفاصيل الفنية

المرحلة 1 — لماذا يعمل الاستخراج بدون تفاعل GATT

يتم استخدام معرف خدمة Fast Pair FE2C فقط كمرشح مسح لتحديد الأهداف المحتملة. بمجرد إنشاء اتصال BLE:

  • تكمل الطبقة الرابطة مصافحة الاتصال وتطلق LL_CONNECTION_COMPLETE إلى المضيف
  • يعالج BlueZ هذا الحدث، وإذا كان الجهاز يستخدم عنوانًا خاصًا قابلاً للحل، فإنه يحله مقابل ذاكرة التخزين المؤقت IRK أو ببساطة يسجل عنوان الهوية من معلمات الاتصال
  • يتم تخزين عنوان الهوية مؤقتًا في جدول الأجهزة الداخلي لـ BlueZ
  • يعرض bluetoothctl devices كلاً من RPA الأصلي وعنوان الهوية المسجل حديثًا — نفس اسم الجهاز، عنوان مختلف
  • تقارن الأداة مع RPA الأصلي وتعيد الإدخال الجديد باعتباره BDADDR الدائم

قد تنجح أو تفشل استدعاء bluetoothctl pair الذي يعمل بالتوازي — عادةً ما يكون BDADDR موجودًا بالفعل في الجدول بحلول الوقت الذي يكتمل فيه أمر الاقتران أو يفشل.

المرحلة 2 — وضع EMP (l2flood -R)

يحتوي l2flood المعدل هذا على وضعين اعتمادًا على المرحلة المقصودة:

علم -R — وضع EMP (DoS فقط، بدون اختطاف) يُستخدم عند تشغيل المرحلة 2 بشكل مستقل دون الانتقال إلى المرحلة 3. إطلاق ونسيان صامت مع إعادة اتصال نبضية — جميع الخيوط تزامن دوراتها (اتصال ← انفجار ← إغلاق قسري) لضمان تمزيق ACL كامل دوري. لا ينتج أي مخرجات stdout أثناء التشغيل العادي.

الوضع العادي (DoS + فحص اختطاف) يُستخدم عندما تكون المرحلة 3 مقصودة. تم تحسين الوضع العادي للتعامل مع إعادة الاتصال تلقائيًا ويخرج no response from <addr>: id N عندما يتوقف الهدف عن الاستجابة — هذه هي الإشارة التي تراقبها wb.py لبدء محاولة الاختطاف.

المرحلة 3 — لماذا يستمر الرابط

الرابط الناتج ليس اتصالاً عابرًا — إنه رابط SMP كامل مخزن بواسطة BlueZ:

  • يُظهر bluetoothctl info <addr> Paired: yes, Bonded: yes, Trusted: no
  • يبقى الرابط بعد دورات bluetoothctl power off/on
  • يبقى الرابط بعد إعادة تشغيل جهاز المهاجم (مخزن في /var/lib/bluetooth/)
  • يقبل الجهاز الاتصالات اللاحقة من محول المهاجم دون إعادة الاقتران

القيود المعروفة

المرحلة 1

  • يتطلب لينكس مع BlueZ / bluetoothctl
  • يجب ألا يكون الهدف موجودًا بالفعل في جدول أجهزة BlueZ تحت RPA (قم بإزالته أولاً إذا لزم الأمر)
  • يمكن أن يتسبب تغيير العنوان أثناء نافذة الاتصال في مشاكل توقيت — أعد التشغيل إذا فشل الاستخراج

المرحلة 2

  • يتطلب معرفة العنوان الدائم (من المرحلة 1 أو وسائل أخرى)
  • يجب أن يكون الهدف قيد التشغيل وفي النطاق
  • يتعافى الجهاز بالكامل عندما يتوقف الفيضان — لا تأثير دائم

المرحلة 3

  • يتطلب دخول الجهاز في حالة غير مستجيبة (اعتماد على المرحلة 2)
  • النجاح يعتمد على التوقيت — يجب أن يقع الاختطاف خلال نافذة الاسترداد
  • لا يعمل إذا تم إيقاف تشغيل الجهاز أثناء الفيضان

استكشاف الأخطاء وإصلاحها

لم يتم العثور على أجهزة

  • تحقق من عمل bluetoothctl: sudo bluetoothctl list
  • زد وقت المسح: -s 30

فشل اتصال BLE / فشل الاستخراج

  • قم بإزالة الجهاز من BlueZ أولاً: sudo bluetoothctl remove <addr>
  • أعد التشغيل — يمكن أن يسبب تغيير RPA مشاكل توقيت

الفيضان ليس له تأثير

  • زد عدد الخيوط: -t 16
  • استخدم محولات متعددة في وقت واحد
  • تحقق من أن العنوان الدائم (وليس RPA) هو المستهدف

رفض الإذن

  • شغّل مع sudo
  • تأكد من أن المستخدم في مجموعة bluetooth أو شغّل كجذر

خطأ استيراد bleak

  • Debian/Ubuntu: sudo apt install libdbus-1-dev libglib2.0-dev
  • Fedora: sudo dnf install dbus-devel glib2-devel
  • Arch: sudo pacman -S dbus glib

أخطاء D-Bus

  • sudo systemctl start dbus && sudo systemctl start bluetooth

الإسناد

  • @kovmir لـ l2flood
  • KU Leuven COSIC للبحث الأصلي WhisperPair / CVE-2025-36911

الترخيص

MIT. انظر LICENSE للتفاصيل.

إخلاء المسؤولية

هذه الأداة مخصصة للاختبارات الأمنية المصرح بها والبحث الدفاعي فقط. الوصول غير المصرح به إلى أجهزة البلوتوث غير قانوني. استخدم فقط على الأجهزة التي تملكها أو لديك إذن كتابي صريح لاختبارها. المؤلف لا يتحمل أي مسؤولية عن الاستخدام غير المصرح به أو غير القانوني.

تنزيل الأداة
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؟نعملا
يعمل على الأجهزة المصححة؟لانعم
CWECWE-287CWE-200 (المرحلة 1) + CWE-362/CWE-287 (المرحلة 3)
العلمالوصف
-s, --scan-timeمدة مسح BLE بالثواني (الافتراضي: 10)
-o, --outputحفظ العناوين المستخرجة في ملف JSON
--aggressiveتخطي الأسئلة، تشغيل المرحلة 2 مباشرة (يتطلب إذن كتابي مسبق)
-H, --hijackمحاولة اختطاف المرحلة 3 بعد المرحلة 2 (يتطلب --aggressive أو نعم تفاعلي)
-d, --durationمدة الفيضان بالثواني (الافتراضي: 60) أو f للأبد
-t, --threadsخيوط فيضان L2CAP المتوازية (الافتراضي: عدد وحدات المعالجة)
-i, --hciمحول HCI المستخدم (مثل hci0, hci1)