buds-audit

الإصدار 1.0.0

أداة تقييم أمان بلوتوث لسماعات الأذن اللاسلكية المتأثرة بسلسلة ثغرات SDK الخاصة بـ Airoha (CVE-2025-20700 / CVE-2025-20701 / CVE-2025-20702). تقوم بمسح الأجهزة القريبة، وتحديد بصمات الشرائح المعروفة المتأثرة القائمة على Airoha، وفحص الوصول غير الموثَّق لـ GATT وقابلية الوصول لبروتوكول RACE - بالكامل عبر مكدس بلوتوث نظام التشغيل (BlueZ) عبر bleak. لا حاجة لدونجل بلوتوث خارجي ولا لجذر. يتم عرض النتائج بلغة واضحة إلى جانب التفاصيل الفنية، حتى تتمكن من التصرف بناءً عليها دون معرفة عميقة بالبلوتوث.

بيان الاستخدام الأخلاقي

هذه الأداة مخصصة لتقييم الأجهزة التي تمتلكها أو لديك إذن صريح باختبارها. فحوص GATT و RACE هي عمليات نشطة: فهي تتصل بالجهاز المستهدف وترسل إليه أوامر. لا تقم بتشغيل --gatt أو --race أو --firmware أو --bd-address أو --assess أو --baseline أو --check-drift أو --memory-read ضد جهاز ليس ملكك أو لم تحصل على إذن لاختباره. --scan هو فحص سلبي ويستمع فقط إلى الإعلانات التي تُبث علنًا بالفعل، لذا فهو آمن للتشغيل ضد أي جهاز في النطاق.

--memory-read يذهب خطوة أبعد من الفحوص النشطة الأخرى: فهو يسترد صفحة واحدة حقيقية وقابلة للقراءة فقط (256 بايت) من محتوى الفلاش الفعلي للجهاز، على عنوان ثابت، كتأكيد قاطع لـ CVE-2025-20702 عندما لا يتلقى فحص --race القائم على قابلية الوصول فقط أي استجابة. وهو قابل للقراءة فقط (قراءات الفلاش لا تحمل أي مخاطر تآكل أو تلف، على عكس أوامر الكتابة/المسح/FOTA، التي لا ترسلها هذه الأداة أبدًا)، واختياري، ويتطلب تأكيدًا منفصلاً خاصًا به يتجاوز المطالبة القياسية بملكية الجهاز التي تصف ما يفعله بالضبط قبل تشغيل أي شيء.

فحص جهاز عشوائي قريب ليس مجرد مسألة سياسة - بل يمكن أن يكون له آثار جانبية حقيقية. يحاول --gatt قراءة أو الاشتراك في الإشعارات لكل خاصية (characteristic) يجدها، وبعض الأجهزة الاستهلاكية تكشف خدمات من نوع الإعداد (مثل خدمة Fast Pair من Google) التي تتفاعل مع ذلك عن طريق بدء مصافحة إقران حقيقية على الجهاز المستهدف، بغض النظر عن أي شيء تطلبه هذه الأداة صراحةً. خاصية تتطلب تشفيرًا يمكن أن تؤدي إلى نفس الشيء حتى ضد جهازك الخاص، نظرًا لأن BlueZ يمكنه توجيه طلب المصادقة هذا بصمت إلى أي وكيل سجلته بيئة سطح المكتب لديك (مثل مطالبة الإقران في KDE) - لذلك يقوم كل أمر نشط أيضًا بتسجيل وكيل BlueZ مؤقت خاص به يرفض تلقائيًا أي طلب من هذا القبيل طوال مدة الفحص، بحيث لا يمكن أن تظهر أي مطالبة إقران على الإطلاق. كل أمر نشط لا يزال يطلب تأكيدًا على أن العنوان المستهدف هو ملكك قبل القيام بأي شيء عبر الراديو؛ مرّر --yes لتخطي المطالبة للاستخدام النصي بمجرد تأكيد أن الجهاز ملكك:

buds_audit.py --assess --target AA:BB:CC:DD:EE:FF --yes

--watch هو أمر سلبي، مثل --scan - فهو يستمع فقط إلى الإعلانات التي تُبث بالفعل ولا يتصل بأي شيء أبدًا، لذلك لا يطلب تأكيدًا.

التثبيت

python3 -m venv venv
venv/bin/pip install -r requirements.txt

يتطلب Python 3.10+ (طُوِّر ضد 3.14) ونظام Linux يعمل بـ BlueZ مع محول بلوتوث قيد التشغيل.

دعم المنصات

لينكس فقط، وليس بالضرورة كل نظام لينكس:

• Windows غير مدعوم. bleak نفسه لديه خلفية لنظام Windows، لكن هذه الأداة لا تعتمد على bleak فقط - اكتشاف البلوتوث الكلاسيكي (core/scanner.py) وفحوص حالة الإقران (core/gatt.py) كلاهما يستدعيان مباشرة bluetoothctl، وهي أداة CLI خاصة بـ BlueZ غير موجودة على Windows. تلك المسارات البرمجية ستفشل ببساطة مع "الأمر غير موجود."
• يتطلب BlueZ مع وجود bluetoothctl في PATH، وليس مجرد أي نواة لينكس. معظم توزيعات سطح المكتب تأتي بهذا؛ الصورة الخفيفة أو الخادم بدون حزمة bluez المثبتة لن تحتوي عليه افتراضيًا. تم التحقق من أنه يعمل بدون جذر على BlueZ 5.86 - الإصدارات الأخرى يجب أن تعمل بنفس الطريقة لأن bleak يستهدف واجهة D-Bus القياسية لـ BlueZ، ولكن لم يتم إعادة التحقق بشكل مستقل.
• WSL يعتمد على الأجهزة، وليس نعم مضمونة. يمكن لـ WSL2 تشغيل BlueZ مثل أي نظام لينكس، لكن الوصول إلى راديو بلوتوث حقيقي يتطلب توجيهه من Windows عبر usbipd-win، الذي يوجه فقط المحولات المتصلة عبر USB. معظم أجهزة اللابتوب المزودة ببلوتوث مدمج موصولة عبر ناقل غير USB (SDIO/PCIe، بجانب Wi-Fi)، والذي لا يمكن لـ usbipd-win توجيهه بشكل عام - لذا فهذا يعتمد كليًا على الأجهزة المحددة.

تشغيلها من Windows أو macOS

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

• الإقلاع من Fedora عبر USB حي (الأسهل، موصى به). يوفر USB حي لـ Fedora نظام تشغيل كاملًا يعمل من الذاكرة دون تثبيت أي شيء، على العتاد الفعلي - لذلك لديه وصول مباشر إلى كل أجهزتك، بما في ذلك بلوتوث اللابتوب المدمج. أقلع منه، قم بتثبيت التبعيات (انظر التثبيت)، شغّل الأداة، ثم أعد الإقلاع إلى نظام التشغيل العادي عند الانتهاء. لا يُكتب شيء على قرصك. هذا هو الخيار الأقل تعقيدًا للتحقق من أجهزتك الخاصة من حين لآخر.
• جهاز افتراضي Fedora مع دونجل بلوتوث USB مُمرَّر. إذا كنت تفضل تثبيتًا دائمًا، شغّل Fedora في جهاز افتراضي (VirtualBox مع Extension Pack، أو VMware Workstation/Fusion - هذه تتعامل مع تمرير USB لكل جهاز بشكل نظيف؛ Hyper-V لا تفعل ذلك). العائق هو المحول: لا يمكن للجهاز الافتراضي عمومًا استعارة بلوتوث اللابتوب المدمج، لذا مرّر دونجل بلوتوث USB خارجي رخيص (4.0+، شريحة متوافقة مع لينكس مثل CSR8510 أو Realtek RTL8761B أو Intel) بدلاً من ذلك. بمجرد أن يرى Fedora هذا الدونجل، يقوده BlueZ مباشرة وتعمل الأداة تمامًا كما على العتاد الفعلي. على أجهزة Mac المزودة بـ Apple Silicon، شغّل بناء ARM64 من Fedora (الأداة غير مرتبطة بالمعمارية) واستخدم برنامج hypervisor يدعم تمرير USB، مثل UTM.

على أي حال، القاعدة هي نفسها: الأداة نفسها لم تتغير - إنها تحتاج فقط إلى لينكس مع محول بلوتوث يمكن لـ BlueZ الوصول إليه فعليًا.

ملاحظة حول حالة طاقة الجهاز

العديد من سماعات TWS اللاسلكية تتوقف عن الإعلان (وتقطع أي اتصال نشط) بعد فترة من عدم النشاط لتوفير الطاقة، وبعضها ينطفئ تمامًا من تلقاء نفسه. إذا لم يتمكن الفحص من العثور على جهاز وجده قبل دقيقة، أو فشل الفحص في منتصف الطريق، فهذا عادةً ما يكون بسبب ذهاب السماعات إلى حالة الخمول، وليس خطأ - أخرجها من العلبة أو اضغط على زر الإقران مرة أخرى وأعد المحاولة.

يؤثر هذا أيضًا على استقرار العنوان: وحدة الاختبار المؤكدة لهذا المشروع (Sony WF-1000XM3) احتفظت بنفس عنوان BLE عبر كل دورة طاقة تم اختبارها، وهو أمر متوقع للسماعات المصممة لإعادة الاتصال بتطبيق الرفيق - فهي عادةً ما تستخدم عنوان BLE ثابت/عام بدلاً من عنوان متغير (على عكس الهواتف، التي تغير العناوين الخاصة وليست هدفًا مناسبًا لهذه الأداة لهذا السبب). لكن هذا ليس مضمونًا لكل موديل سماعة - بعض البائعين يستخدمون عناوين خاصة قابلة للحل حتى في وضع ما قبل الإقران/إعادة الاتصال، مما سيظهر كعنوان مختلف بعد كل دورة طاقة لماسح ضوئي غير مقترن مثل هذه الأداة.

فحص GATT (--gatt، ومرحلة GATT من --assess) قد يحتاج إلى عدة إعادة اتصالات إذا كان الجهاز يحتوي على خصائص تتطلب إقرانًا - كل واحدة منها تجعل BlueZ يحاول (ويقوم وكيل هذه الأداة برفض) مفاوضات إقران حقيقية قبل إعادة الاتصال لاستئناف الفحص، ويطبع سطر حالة واحد قبل كل محاولة حتى لا يبدو الفحص البطيء وكأنه معلق. عندما يتم رفض هذا الاشتراك، يحتفظ BlueZ بالقصد ويعيد إصداره في كل اتصال لاحق بهذا الجهاز؛ لمنع ذلك من عرقلة إعادة الاتصالات اللاحقة، يقوم الفحص بمسح السجل المخبأ لـ BlueZ للجهاز (مكافئ لـ bluetoothctl remove) قبل كل إعادة اتصال، بحيث تبدأ كل محاولة من حالة نظيفة. مع ذلك، تعيد عمليات الفحص المتكررة المتتالية ضد جهاز الاختبار المؤكد نفس النتيجة الكاملة في كل مرة. ملاحظة سابقة - أن الاكتمال يبدو أنه يتدهور على مدار جلسة اختبار مكثفة ويتعافى بعد الراحة - لم تتكرر منذ ذلك الحين، ويُعتقد أنها كانت نفس تراكم الحالة المحتجزة وليس إرهاق الجهاز.

الوضع التفاعلي

buds_audit.py

تشغيلها بدون أي علامات يطلق قائمة مرقمة بدلاً من مطالبتك بمعرفة عنوان BLE بالفعل أو أي علامة تفعل ماذا:

1) تحليل كامل (مسح، تشغيل تدقيق CVE الكامل، وحفظ خط أساس)
2) التحقق من الحالة الحالية مقابل خط أساس محفوظ
3) مسح الأجهزة المزيفة/المنتحلة
4) خروج