बिना डोंगल, बिना रूट ब्लूटूथ सुरक्षा मूल्यांकन उपकरण, जो Airoha SDK भेद्यता श्रृंखला (CVE-2025-20700/20701/20702) से प्रभावित वायरलेस ईयरबड्स के लिए है।
संस्करण 1.0.0
Airoha SDK भेद्यता श्रृंखला (CVE-2025-20700 / CVE-2025-20701 / CVE-2025-20702) से प्रभावित वायरलेस ईयरबड्स के लिए Bluetooth सुरक्षा मूल्यांकन उपकरण। आस-पास के डिवाइसों को स्कैन करता है, ज्ञात-प्रभावित Airoha-आधारित चिपसेट की फ़िंगरप्रिंटिंग करता है, और अनधिकृत GATT पहुँच तथा RACE प्रोटोकॉल पहुँच-क्षमता की जाँच करता है - पूरी तरह से OS Bluetooth स्टैक (BlueZ) के माध्यम से bleak द्वारा। किसी बाहरी Bluetooth डोंगल की आवश्यकता नहीं है और root की आवश्यकता नहीं है। परिणाम तकनीकी विवरण के साथ सरल भाषा में रिपोर्ट किए जाते हैं, ताकि आप गहरे Bluetooth ज्ञान के बिना उन पर कार्रवाई कर सकें।
यह उपकरण उन डिवाइसों के मूल्यांकन के लिए है जिनके आप मालिक हैं या जिनके परीक्षण के लिए आपके पास स्पष्ट प्राधिकरण है। GATT और RACE जाँच सक्रिय ऑपरेशन हैं: वे लक्षित डिवाइस से जुड़ते हैं और उसे कमांड भेजते हैं। --gatt, --race, --firmware, --bd-address, --assess, --baseline, --check-drift, या --memory-read को ऐसे डिवाइस के विरुद्ध न चलाएँ जो आपका नहीं है या जिसके परीक्षण की आपको अनुमति नहीं दी गई है। --scan निष्क्रिय है और केवल उन विज्ञापनों को सुनता है जो पहले से ही सार्वजनिक रूप से प्रसारित हो रहे हैं, इसलिए इसे सीमा में मौजूद किसी भी चीज़ के विरुद्ध चलाना सुरक्षित है।
--memory-read अन्य सक्रिय जाँचों से एक कदम आगे जाता है: यह डिवाइस की वास्तविक फ्लैश सामग्री का एक वास्तविक, केवल-पठनीय पृष्ठ (256 बाइट्स) एक निश्चित पते से प्राप्त करता है, जो CVE-2025-20702 की निश्चित पुष्टि के रूप में होता है, जब केवल-पहुँच-क्षमता वाली --race जाँच को कोई प्रतिक्रिया नहीं मिलती। यह केवल-पठनीय है (फ्लैश रीड में लिखने/मिटाने/FOTA कमांड के विपरीत कोई घिसाव या ब्रिकिंग जोखिम नहीं होता, जो यह उपकरण कभी नहीं भेजता), ऑप्ट-इन है, और कुछ भी चलाने से पहले यह वास्तव में क्या करता है इसका वर्णन करने वाले मानक स्वामित्व प्रॉम्प्ट के अतिरिक्त अपनी अलग पुष्टि की आवश्यकता होती है।
किसी भी आस-पास के डिवाइस की जाँच करना केवल नीति संबंधी चिंता नहीं है - इसके वास्तविक दुष्प्रभाव हो सकते हैं। --gatt उसे मिलने वाली हर विशेषता पर रीड या notify-subscribe का प्रयास करता है, और कुछ उपभोक्ता डिवाइस provisioning-शैली की सेवाएँ (जैसे Google की Fast Pair सेवा) उजागर करते हैं जो उस पर प्रतिक्रिया करते हुए लक्षित डिवाइस पर एक वास्तविक पेयरिंग हैंडशेक शुरू कर देती हैं, जो इस उपकरण द्वारा स्पष्ट रूप से अनुरोधित किसी भी चीज़ से स्वतंत्र है। एन्क्रिप्शन की आवश्यकता वाली विशेषता आपके अपने डिवाइस के विरुद्ध भी वही चीज़ ट्रिगर कर सकती है, क्योंकि 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 के विरुद्ध विकसित) और BlueZ चलाने वाली Linux प्रणाली जिसमें चालू Bluetooth एडाप्टर हो।
केवल Linux, और स्वचालित रूप से हर Linux प्रणाली नहीं:
bleak का स्वयं Windows बैकएंड है, लेकिन यह उपकरण केवल bleak पर निर्भर नहीं करता - Bluetooth Classic डिस्कवरी (core/scanner.py) और बॉन्डिंग-स्थिति जाँच (core/gatt.py) दोनों सीधे bluetoothctl को शेल आउट करते हैं, जो एक केवल-BlueZ CLI उपकरण है जो Windows पर मौजूद नहीं है। वे कोड पथ केवल "command not found" के साथ विफल हो जाएँगे।bluetoothctl के साथ BlueZ की आवश्यकता है, केवल किसी भी Linux कर्नेल की नहीं। अधिकांश डेस्कटॉप डिस्ट्रो इसे शिप करते हैं; bluez पैकेज स्थापित किए बिना एक न्यूनतम या सर्वर इमेज में यह आउट ऑफ़ द बॉक्स नहीं होगा। BlueZ 5.86 पर root-मुक्त सत्यापित - अन्य संस्करणों को उसी तरह काम करना चाहिए क्योंकि bleak BlueZ के मानक D-Bus API को लक्षित करता है, लेकिन यह स्वतंत्र रूप से पुनः सत्यापित नहीं है।usbipd-win के माध्यम से Windows से फॉरवर्ड करना आवश्यक है, जो केवल USB-संलग्न एडाप्टरों को फॉरवर्ड करता है। अधिकांश लैपटॉप का अंतर्निहित Bluetooth एक गैर-USB बस (SDIO/PCIe, Wi-Fi के साथ) पर जुड़ा होता है, जिसे usbipd-win आम तौर पर फॉरवर्ड नहीं कर सकता - इसलिए यह पूरी तरह से विशिष्ट हार्डवेयर पर निर्भर करता है।आपको अपनी स्वयं की Linux मशीन की आवश्यकता नहीं है - आपको केवल Linux चाहिए जिसकी Bluetooth रेडियो तक वास्तविक पहुँच हो। इसे पाने के दो व्यावहारिक तरीके हैं:
किसी भी तरह से, नियम समान है: उपकरण स्वयं अपरिवर्तित है - उसे केवल ऐसे Linux की आवश्यकता है जिसमें एक Bluetooth एडाप्टर हो जिस तक BlueZ वास्तव में पहुँच सके।
कई TWS ईयरबड्स बिजली बचाने के लिए निष्क्रियता की अवधि के बाद विज्ञापन बंद कर देते हैं (और किसी भी सक्रिय कनेक्शन को छोड़ देते हैं), और कुछ अपने आप पूरी तरह बंद हो जाते हैं। यदि कोई स्कैन एक मिनट पहले मिले डिवाइस को नहीं ढूँढ पाता है, या कोई जाँच बीच में विफल हो जाती है, तो यह आमतौर पर ईयरबड्स का निष्क्रिय हो जाना होता है, कोई बग नहीं - उन्हें केस से निकालें या पेयरिंग बटन फिर से दबाएँ और पुनः प्रयास करें।
यह पता स्थिरता को भी प्रभावित करता है: इस परियोजना की पुष्टि की गई परीक्षण इकाई (एक Sony WF-1000XM3) ने परीक्षण किए गए हर पावर चक्र में समान BLE पता बनाए रखा, जो कंपेनियन-ऐप पुनः-कनेक्शन के लिए डिज़ाइन किए गए ईयरबड्स के लिए अपेक्षित है - वे आम तौर पर घूमने वाले पते के बजाय एक निश्चित/सार्वजनिक BLE पता उपयोग करते हैं (फ़ोनों के विपरीत, जो निजी पते घुमाते हैं और इसी कारण इस उपकरण के लिए उपयुक्त लक्ष्य नहीं हैं)। हालाँकि, यह हर ईयरबड मॉडल के लिए गारंटीकृत नहीं है - कुछ विक्रेता पूर्व-पेयरिंग/पुनः-कनेक्शन मोड में भी resolvable निजी पते उपयोग करते हैं, जो इस उपकरण जैसे अयुग्मित स्कैनर को हर पावर चक्र के बाद एक अलग पते के रूप में दिखाई देंगे।
GATT जाँच (--gatt, और --assess का GATT चरण) को कई पुनः-कनेक्शनों की आवश्यकता हो सकती है यदि डिवाइस में ऐसी विशेषताएँ हैं जिनके लिए पेयरिंग की आवश्यकता होती है - प्रत्येक स्कैन को फिर से शुरू करने के लिए पुनः-कनेक्ट करने से पहले BlueZ को एक वास्तविक पेयरिंग वार्ता का प्रयास कराता है (और इस उपकरण का अपना एजेंट अस्वीकार कर देता है), और प्रत्येक प्रयास से पहले एक-पंक्ति की स्थिति मुद्रित करता है ताकि धीमा स्कैन हैंग हुआ न लगे। जब ऐसी सदस्यता अस्वीकार कर दी जाती है, BlueZ इरादा बनाए रखता है और उस डिवाइस से हर बाद के कनेक्शन पर इसे फिर से जारी करता है; ऐसा होने से बाद के पुनः-कनेक्शन बिगड़ने से रोकने के लिए, जाँच प्रत्येक पुनः-कनेक्शन से पहले BlueZ का डिवाइस का कैश्ड रिकॉर्ड साफ़ करती है (bluetoothctl remove के बराबर), ताकि हर प्रयास एक स्वच्छ स्थिति से शुरू हो। इसके साथ, पुष्टि किए गए परीक्षण डिवाइस के विरुद्ध बार-बार लगातार स्कैन हर बार समान पूर्ण परिणाम लौटाते हैं। एक पहले का अवलोकन - भारी परीक्षण के सत्र में पूर्णता का क्षीण होना और आराम के बाद पुनः प्राप्त होना - तब से दोहराया नहीं गया है, और ऐसा विश्वास किया जाता है कि वह डिवाइस की थकान के बजाय वही बनाए रखी गई-स्थिति का संचय था।
buds_audit.py
इसे बिना किसी फ़्लैग के चलाने पर एक क्रमांकित मेनू शुरू होता है, बजाय इसके कि आपको पहले से BLE पता या पता हो कि कौन सा फ़्लैग क्या करता है:
1) Full analysis (scan, run the full CVE audit, and save a baseline)
2) Check current state against a saved baseline
3) Scan for spoofed/impersonating devices
4) Exit
विकल्प 1 आस-पास के ज्ञात-प्रभावित डिवाइसों को स्कैन करता है और उन्हें संख्या द्वारा चुनने के लिए सूचीबद्ध करता है (MAC पता टाइप करने के बजाय), पूर्ण CVE ऑडिट चलाता है (--assess के समान, जिसमें BD-address क्वेरी भी शामिल है), और एक बेसलाइन सहेजता है (--baseline के समान) ताकि भविष्य के रन परिवर्तनों का पता लगा सकें। यह वही memory-read प्रश्न भी पूछता है जिसका उत्तर --assess --memory-read अपने पुष्टि प्रॉम्प्ट के माध्यम से देता है - वहाँ हाँ उत्तर देने पर ऊपर वर्णित वही वास्तविक, केवल-पठनीय RACE फ्लैश-पृष्ठ रीड शामिल होता है; नहीं उत्तर देने पर केवल उसके बिना ऑडिट चलता है, यह पूरे विश्लेषण को रद्द नहीं करता। विकल्प 2 उन डिवाइसों को सूचीबद्ध करता है जिन्हें आप पहले ही बेसलाइन कर चुके हैं और आपके द्वारा चुने गए डिवाइस को ड्रिफ्ट के लिए पुनः जाँचता है (--check-drift के समान)। विकल्प 3 --watch है। रेडियो को छूने से पहले हर विकल्प फ़्लैग-आधारित इंटरफ़ेस के समान स्वामित्व पुष्टि से गुजरता है - विज़ार्ड बिल्कुल समान अंतर्निहित जाँचों के ऊपर एक अधिक अनुकूल फ्रंट एंड है, कोई अलग, कम सतर्क मार्ग नहीं।
नीचे दिया गया फ़्लैग-आधारित इंटरफ़ेस स्क्रिप्टेड उपयोग या उन लोगों के लिए अभी भी मौजूद है जो पहले से जानते हैं कि वे किस पते को लक्षित करना चाहते हैं।
सभी कमांड venv/bin/python buds_audit.py के माध्यम से चलाए जाते हैं।
buds_audit.py --help
बिना venv और बिना निर्भरताओं के भी एक साधारण python3 buds_audit.py --help से काम करता है - यह तब तक bleak आयात नहीं करता जब तक कोई ऐसा कमांड नहीं चलाया जाता जिसे वास्तव में रेडियो की आवश्यकता होती है।
buds_audit.py --scan
buds_audit.py --scan --flags-only # only show devices matching the known-affected catalog
buds_audit.py --scan --target AA:BB:CC:DD:EE:FF
आस-पास के BLE और Bluetooth Classic डिवाइसों को निष्क्रिय रूप से स्कैन करता है, निर्माता डेटा और पता उपसर्ग से Airoha चिपसेट की फ़िंगरप्रिंटिंग करता है, और data/affected_devices.json के विरुद्ध क्रॉस-रेफ़रेंस करता है।
इनमें से प्रत्येक को --target ADDR की आवश्यकता होती है और यह उस एक डिवाइस के विरुद्ध एक सक्रिय ऑपरेशन है:
buds_audit.py --gatt --target AA:BB:CC:DD:EE:FF # CVE-2025-20700: unauthenticated GATT access
buds_audit.py --race --target AA:BB:CC:DD:EE:FF # CVE-2025-20702: RACE channel reachability
buds_audit.py --firmware --target AA:BB:CC:DD:EE:FF # CVE-2025-20701: passive firmware/pairing-bypass check
buds_audit.py --bd-address --target AA:BB:CC:DD:EE:FF # Classic BD address via RACE, informational
यदि डिवाइस पहले से युग्मित है तो चारों सफाई से छोड़ देते हैं (कोई त्रुटि नहीं) - एक "अनधिकृत पहुँच" निष्कर्ष एक बॉन्डेड डिवाइस के विरुद्ध अर्थहीन है।
--gatt अब प्रत्येक सफल अयुग्मित रीड या अधिसूचना द्वारा लौटाया गया वास्तविक मान (hex-एन्कोडेड) दिखाता है, न केवल यह कि रीड सफल रही - मान पहले से ही प्राप्त किया जा रहा था, इसलिए यह कोई अतिरिक्त जोखिम नहीं है, बस अब त्यागा नहीं जाता।
--race केवल पहुँच-क्षमता का परीक्षण करता है (एक सुरक्षित SDK-info क्वेरी, कोई मेमोरी एक्सेस नहीं) - एक RACE सेवा मौजूद हो सकती है और लेखन को सफाई से स्वीकार कर सकती है लेकिन फिर भी उत्तर नहीं दे सकती, जो वास्तव में एक अनिर्णायक परिणाम है, किसी ठीक हो चुकी चीज़ का प्रमाण नहीं। निश्चित उत्तर के लिए, नीचे --memory-read देखें।
--bd-address सूचनात्मक है, अपने आप में कोई भेद्यता निष्कर्ष नहीं: यह उसी अनधिकृत RACE चैनल पर डिवाइस के वास्तविक Bluetooth Classic (BR/EDR) पते की क्वेरी करता है, जिसका जोखिम स्वरूप --firmware की buildversion क्वेरी (एक शून्य-पेलोड मेटाडेटा कमांड) के समान है। यदि आप स्वयं Classic-क्षमता वाले रेडियो/डोंगल के साथ CVE-2025-20701 सक्रिय परीक्षण करना चाहते हैं तो उपयोगी है, क्योंकि इस उपकरण का अपना कोई Classic ट्रांसपोर्ट नहीं है - नीचे Hardware requirement अनुभाग देखें।
buds_audit.py --memory-read --target AA:BB:CC:DD:EE:FF
CVE-2025-20702 की निश्चित पुष्टि के लिए एक वास्तविक, केवल-पठनीय RACE फ्लैश-पृष्ठ रीड (256 बाइट्स, एक निश्चित पते से) का प्रयास करता है - उपयोगी तब होता है जब --race RACE सेवा को मौजूद तो पाता है लेकिन अपनी सुरक्षित क्वेरी के प्रति अनुत्तरदायी। यह जानबूझकर ऑप्ट-इन है और --race से अलग है: यहाँ सफलता वास्तविक डिवाइस फ़र्मवेयर सामग्री प्राप्त करती है, न कि केवल इस बारे में हाँ/नहीं संकेत कि चैनल पहुँच योग्य है या नहीं। यह कभी लिखता नहीं, मिटाता नहीं, लिंक कुंजियाँ निकालता नहीं, या RAM/रजिस्टर नहीं पढ़ता (केवल फ्लैश, जिसका कोई रीड दुष्प्रभाव नहीं होता) - पूर्ण तर्क के लिए ROADMAP.md के Phase 8 और Out of Scope अनुभाग देखें। मानक स्वामित्व प्रॉम्प्ट के अतिरिक्त, इसकी अपनी अलग पुष्टि की आवश्यकता होती है, जो वर्णन करती है कि यह वास्तव में क्या करता है।
buds_audit.py --assess --target AA:BB:CC:DD:EE:FF
buds_audit.py --assess --target AA:BB:CC:DD:EE:FF --json result.json
buds_audit.py --assess --target AA:BB:CC:DD:EE:FF --memory-read
उपरोक्त GATT, RACE, firmware, और BD-address जाँचों को एक लक्ष्य के विरुद्ध चलाता है और एक single निर्णय उत्पन्न करता है: PASS, PARTIAL, VULNERABLE, या SUSPECTED_COMPROMISE। निर्णय और प्रत्येक व्यक्तिगत निष्कर्ष तकनीकी विवरण के साथ सरल-भाषा व्याख्या के साथ मुद्रित होते हैं, ताकि परिणाम गहरे Bluetooth ज्ञान के बिना पठनीय हो - यह उपकरण अपने स्वयं के डिवाइसों की जाँच करने वाले किसी भी व्यक्ति के लिए है, न कि केवल सुरक्षा विशेषज्ञों के लिए। --json अतिरिक्त रूप से पूर्ण परिणाम (डिवाइस जानकारी, निर्णय और उसकी सरल-भाषा व्याख्या, साक्ष्य सहित फ़्लैग और उनकी सरल-भाषा टिप्पणी, और उपचार नोट्स) एक फ़ाइल में लिखता है।
--memory-read जोड़ने पर memory-read पुष्टि उसी ऑडिट और निर्णय में शामिल हो जाती है, पहले इसकी अपनी अलग पुष्टि प्रॉम्प्ट के साथ। BD-address क्वेरी --assess के भाग के रूप में स्वचालित रूप से चलती है (कोई अलग फ़्लैग आवश्यक नहीं, कोई अतिरिक्त पुष्टि प्रॉम्प्ट नहीं) क्योंकि यह firmware जाँच के समान ही कम-जोखिम वाली मेटाडेटा-क्वेरी है।
--assess जानबूझकर केवल एकल-लक्ष्य है, व्यक्तिगत जाँचों के समान - कोई "सीमा में हर डिवाइस का मूल्यांकन करें" मोड नहीं है, क्योंकि उसका अर्थ होता उन डिवाइसों की सक्रिय जाँच करना जो आपके नहीं हो सकते।
buds_audit.py --baseline --target AA:BB:CC:DD:EE:FF
buds_audit.py --check-drift --target AA:BB:CC:DD:EE:FF
--baseline पहली बार किसी डिवाइस का मूल्यांकन करने पर उसके लिए एक विश्वसनीय स्नैपशॉट कैप्चर करता है - पहचान (नाम और निर्माता डेटा), GATT तालिका, RACE फ़र्मवेयर बिल्ड, और स्थानीय बॉन्डिंग स्थिति (केवल paired/trusted/bonded बूलियन, कभी भी कुंजी सामग्री नहीं) - और इसे data/device_baselines.json में संग्रहीत करता है। यह कभी स्वचालित रूप से कैप्चर नहीं होता; आपको इसे स्पष्ट रूप से माँगना होता है, और इसे फिर से चलाने पर मौजूदा बेसलाइन अधिलेखित हो जाती है।
--check-drift समान स्नैपशॉट को पुनः कैप्चर करता है और उसे संग्रहीत बेसलाइन के विरुद्ध तुलना करता है, जो भी ड्रिफ्ट पाया जाता है उससे एक निर्णय उत्पन्न करता है: IDENTITY_DRIFT, GATT_TABLE_DRIFT, FIRMWARE_DOWNGRADE, या BOND_STATE_DRIFT। यह इस प्रश्न का उत्तर देता है "क्या इस डिवाइस पर मेरे अंतिम विश्वास के बाद से कुछ बदला है," न कि "क्या यह डिवाइस भेद्य है" - यह एक अनुमानात्मक समझौता संकेत है, फोरेंसिक प्रमाण नहीं। किसी भी ड्रिफ्ट फ़्लैग वाला डिवाइस SUSPECTED_COMPROMISE निर्णय पाता है, जो बाकी सब पर वरीयता लेता है।
buds_audit.py --watch
निश्चित-लंबाई वाली विंडो में लगातार स्कैन करता है (रोकने के लिए Ctrl+C) और नाम तथा निर्माता डेटा द्वारा देखे गए हर विज्ञापन को सहसंबद्ध करता है। यदि दो अलग-अलग पते अतिव्यापी अवलोकन विंडो के साथ समान पहचान प्रसारित करते हैं - अर्थात दोनों उस पहचान के साथ उसी समय हवा में थे - तो यह POSSIBLE_IMPERSONATION फ़्लैग करता है। एक एकल भौतिक डिवाइस जो समय के साथ अपना BLE पता घुमाता है (क्रमिक रूप से देखा गया, समवर्ती नहीं) फ़्लैग नहीं होता; केवल एक वास्तविक दूसरा ट्रांसमीटर फ़्लैग होता है। यह खतरे के मॉडल के अंतिम चरण से मेल खाता है: पीड़ित के फ़ोन के सामने ईयरबड्स का प्रतिरूपण करना।
data/affected_devices.json एक चुनिंदा सूची है, कोई संपूर्ण सूची नहीं। वर्तमान में पुष्टि की गई:
| ब्रांड | मॉडल | Airoha SoC | CVEs | पैच किया गया फ़र्मवेयर |
|---|---|---|---|---|
| Sony | WF-1000XM3 | AB1562 | CVE-2025-20700, CVE-2025-20701, CVE-2025-20702 | कोई जारी नहीं हुआ |
ERNW प्रकटीकरण के अनुसार, Airoha AB1562/AB1565/AB1568-श्रृंखला SoC उपयोग करने वाले अन्य ब्रांड (Bose, Jabra, JBL, Marshall, और पैच-पूर्व Beats मॉडल सहित) भी प्रभावित बताए गए हैं, लेकिन अभी सूची में नहीं हैं क्योंकि उनके सटीक पता उपसर्ग और चिपसेट विवरण की इस परियोजना में वास्तविक हार्डवेयर के विरुद्ध पुष्टि नहीं हुई है। सूची से बाहर का डिवाइस अभी भी --gatt/--race/--firmware/--assess के साथ सक्रिय रूप से जाँचा जा सकता है - सूची केवल निष्क्रिय --scan मिलान और निर्णय भारांकन को प्रभावित करती है, न कि यह कि जाँचें स्वयं क्या परीक्षण करती हैं।
यह उपकरण CVE-2025-20701 (अनुपस्थित Bluetooth Classic पेयरिंग प्रवर्तन) का मूल्यांकन केवल निष्क्रिय रूप से, RACE फ़र्मवेयर build-version जाँच के माध्यम से करता है। यह सक्रिय रूप से परीक्षण करना कि क्या एक मूक पेयरिंग हैंडशेक पूरा किया जा सकता है, Bumble के माध्यम से कच्ची HCI पहुँच और एक समर्पित Bumble-संगत USB Bluetooth डोंगल की आवश्यकता होती है - जो BlueZ/bleak के माध्यम से प्राप्त नहीं हो सकता, यही कारण है कि यह उपकरण इसका प्रयास नहीं करता। तीनों CVE को कवर करने वाले एक इंटरैक्टिव, डोंगल-आधारित संदर्भ कार्यान्वयन के लिए ERNW का race-toolkit देखें।
Airoha SDK भेद्यता श्रृंखला (CVE-2025-20700 / CVE-2025-20701 / CVE-2025-20702) की खोज और प्रकटीकरण ERNW में Dennis Heinze और Frieder Steinmetz द्वारा किया गया। उनका race-toolkit संदर्भ कार्यान्वयन है जिसके आगे यह परियोजना एक no-dongle अंतराल को भरती है, और यहाँ उपयोग किए गए सटीक RACE प्रोटोकॉल GATT UUID और पैकेट फ्रेमिंग सीधे उसके स्रोत से पढ़े गए थे, अनुमान से नहीं - विशिष्टताओं के लिए core/race.py देखें। race-toolkit बिना लाइसेंस है (कोई LICENSE फ़ाइल नहीं, सीधे रिपॉजिटरी के विरुद्ध जाँचा गया) - इसके स्रोत से यहाँ अंतर्निहित प्रोटोकॉल तथ्यों (UUID, struct लेआउट, कमांड कोड) से परे कुछ भी पुनः उपयोग नहीं किया गया है, जो Airoha के स्वयं के प्रोटोकॉल का वर्णन करते हैं और प्रथम स्थान पर लाइसेंस देने योग्य उनके लेखकों की मूल अभिव्यक्ति नहीं हैं।
MIT - LICENSE देखें।
venv/bin/ruff check . --fix && venv/bin/ruff format .
venv/bin/python -m pytest tests/