Reverse Engineering Bluetooth Protocols
1.0.0
تحدد هذه الوثيقة العملية التي مررت بها إلى عكس الهندسة البروتوكول في كوبرا كوبرا IRAD 900. كان هدفي الأولي هو الحصول على واجهة Raspberry Pi 3 مع الجهاز عبر Bluetooth للتعامل مع التنبيهات دون الحاجة إلى استخدام تطبيق iOS/Android ، في النهاية ليكون بمثابة واجهة لطيفة مع Raspberry Pi "Carputer".
من المهم أن نلاحظ أنه لم يكن لدي أي خبرة أولية في بروتوكول البلوتوث ، لكنها كانت تجربة تعليمية ممتعة بشكل عام.
عندما بدأت هذا المشروع لأول مرة ، لم يكن لدي أي فكرة من أين أبدأ ولكن مع Google. كنت أعرف كيفية استنشاق حركة مرور الويب العادية ، لكن بلوتوث كان قليلاً من صندوق أسود بالنسبة لي. مع بعض البحث السريع ، وجدت مكتبة Pybluez وكذلك أمثلة على التواصل من خلال RFCOMM. لقد وجدت أيضًا العديد من الموارد الجيدة ، بما في ذلك منشور المدونة المثير للاهتمام من Travis Goodspeed.
ومع ذلك ، هل سأقوم بتوجيه يذكر حول هذا الموضوع ، كما قضيت وقتًا طويلاً في موارد مثل هذا ، معتقدًا أن Bluetooth LE كان ما كنت أبحث عنه.
أثناء اللعب مع iPhone 5 القديم ، تمكنت من استخدام Btserver لتسجيل حركة مرور Bluetooth المرسلة واستلامها بواسطة جهاز iPhone الخاص بي. كونها محاطة بأجهزة Bluetooth متعددة ، نمت ملفات السجل بسرعة ، على الرغم من أنها لم تكن مشكلة كبيرة. لحسن الحظ ، تم إخراج السجلات كملف .pklg ، مما يجعل من السهل تصفية الحزم ذات الصلة في Wireshark.
باستخدام مرشح الحزمة bluetooth.src == B8:92:1D:00:3F:61 ، يمكن أن أرى الحزم الخام التي كان تطبيق iOS يرسلها إلى كاشف الرادار. أخذت بعض تسجيلات العينات للاتصال بين هاتفي وكاشف الرادار ، وبعضها مع تنبيهات يتم إنشاؤها ، والبعض الآخر بدون.
يتم نقل بيانات Bluetooth عبر بروتوكول RFCOMM. عندما تتصل الأجهزة أولاً ، يرسلون بعض المعلومات ذهابًا وإيابًا ، وربما مجرد مزامنة الإعدادات (المزيد حول هذا لاحقًا). بعد ذلك ، يتبع الجهازان نمطًا يمكن التنبؤ به بين بعضهما البعض. سيرسل كاشف الرادار حزمة RFCOMM عبر البلوتوث على فترات نصف ثانية عادية. مع بعض الوقت والصبر ، تمكنت من فك تشفير هيكل الحمولة النافعة المرسلة من كاشف الرادار إلى iPhone.
هيكل الحمولة النافعة: كاشف الرادار ← iPhone
| غرض | القيمة (HEX) | مقاس |
|---|---|---|
| الديباجة | 55 | 1 بايت |
| حجم الحمولة | xx xx | 2 بايت |
| فعل | xx | 1 بايت |
| محجوز | 00 | 1 بايت |
| seq | xx | 1 بايت |
| محجوز | xx xx xx xx xx xx | 6 بايت |
| يُحذًِر | xx | 1 بايت |
| نوع التنبيه | xx | 1 بايت |
| ... | ... | ... |
أثناء تشغيل كاشف الرادار ، سيتم إرسال حزم بالتنسيق أعلاه. على الرغم من أن شبكات الكمبيوتر ليست مجال خبرتي ، إلا أنني سأحاول شرح أفضل ما أستطيع.
يتم إرسال البايت المرسلة دائمًا مع القيمة 0x55 . يحدد هذا أنها بداية رسالة حمولة جديدة من الجهاز ، بدلاً من الاستمرار من حزمة سابقة. بعد ذلك ، تكون قيمة 2 بايت تحتوي على حجم بقية الرسالة (كل شيء بعد بايت 3 الأول). تحدد قيمة الإجراء نوع المعلومات التي ترسلها الحزمة.
رقم SEQ هو المكان الذي تبدأ فيه الأمور للاهتمام. إذا أخذت فصلًا على الشبكات ، أو تعرف قليلاً عن TCP ، فربما تعرف بالفعل ما هو عليه. سيرسل كاشف الرادار قيمة 1 بايت إلى iPhone ، ويجب أن يستجيب تطبيق iOS برقم ACK بنفس القيمة. خلاف ذلك ، سوف يدرك كاشف الرادار أن هناك شيئًا ما أمرًا ويفصله.
يحدد بايت Alert ما إذا كان يتم تشغيل تنبيه. إذا كان الأمر كذلك ، فسيتم تعيينه من القيمة 0x41 ، ويتم استخدام البايت التالي لتحديد نوع التنبيه الذي يتم إرساله. لم أستطع معرفة الكثير عن القيم لأنني لا أملك مسدس رادار فعلي. رغم ذلك ، قام رجل على Instructables بمحاكاة مدفع Lidar باستخدام Arduino. ساعد ذلك كثيرًا في تحليل الحزم.
من أجل تطبيق iOS للحفاظ على اتصال الجهاز ، يحتاج إلى إرسال استجابة بالتنسيق الصحيح. لحسن الحظ ، فإن الاستجابة لكاشف الرادار أكثر بساطة بكثير ، وهي 9 بايت فقط.
الاستجابة: iPhone → كاشف الرادار
| غرض | القيمة (HEX) | مقاس |
|---|---|---|
| الديباجة | 55 | 1 بايت |
| حجم الحمولة | xx xx | 2 بايت |
| فعل | 02 | 1 بايت |
| محجوز | 00 | 1 بايت |
| ACK | xx | 1 بايت |
| محجوز | 00 42 | 2 بايت |
| عداد | xx | 1 بايت |
كما ذكرنا سابقًا ، يجب أن تكون قيمة ACK بنفس قيمة قيمة SEQ التي تم استلامها مسبقًا ، وإلا سيتم فصل الاتصال. كان ذلك سهلاً بما فيه الكفاية. قد يكون لبعض البروتوكولات الأخرى طرق أقل وضوحًا لفحص العميل ؛ الحمد لله لم يكن هذا هو الحال. ومن المثير للاهتمام ، هناك متغير counter آخر يستخدم. لم أحسب أبدًا ماهية البايت ، لكنه ينخفض بمقدار 1 لكل استجابة للجهاز. كانت كلتا القيمتين سهلة بما يكفي للترويج في نص Python ولم يأخذوا الكثير من العمل على الإطلاق.
كما ذكرت سابقًا ، عندما يتصل تطبيق iOS أولاً بكاشف الرادار ، يتم مزامنة بعض الإعدادات والبيانات ذهابًا وإيابًا. لم تكن حقًا أولوية لي أن أتعرف على تلك الحزم وكسرها ، ولم أكن أرغب في قضاء الكثير من الوقت في هذا الأمر. لقد قمت بتصدير حزمة الحزمة بالكامل في Wireshark كملف XML (data.xml) ، ثم استخدمت برنامج نصي Python (parsedata.py) لمعالجة وتخزين المعلومات لاستخدامها لاحقًا.
عند تحميلها ، سيفتح Radar.py البيانات المسبقة مسبقًا داخل ملف PacketData.dat. ثم يقوم بمسح كاشف الرادار عبر البلوتوث ومحاولة الاتصال به. بمجرد الاتصال ، سيرسل كاشف الرادار على عدد قليل من حزم البيانات إلى الجهاز المتصل. لحسن الحظ ، فهي نفس الحزم الدقيقة في نفس التسلسل الدقيق في كل مرة. سوف يبحث البرنامج النصي Python من خلال البيانات من ملف PacketData.dat للحزمة التي تلقاها. بمجرد أن يجد البرنامج النصي الرئيسي Python حزمة Maching ، فإنه يرسل الاستجابة المقابلة مسجلة مسبقًا إلى كاشف الرادار.
والمثير للدهشة ، لقد نجحت على ما يرام. رغم ذلك ، أتصور أنني سأحتاج إلى تحديث ملف البيانات إذا قمت بتغيير أي إعدادات داخل تطبيق iOS. لم تكن هذه مشكلة كبيرة ، لأنني سأحتاج فقط إلى تكوين الجهاز مرة واحدة ، وربما لا أستخدم التطبيق مرة أخرى.
بالنظر إلى جميع المعلومات التي اكتشفتها ، تمكنت من كتابة نص Python الذي يحاكي اتصال iPhone. إذا لم يتم العثور على حزمة في قاعدة بيانات الاستجابات المسجلة ، فإنها تقوم ببناء حزمة استجابة بالهيكل الذي سبق أن قمت بالتفصيل أعلاه.
إذا نظرنا إلى الوراء ، فقد كان مشروعًا ممتعًا حقًا يفعل شيئًا لم أواجهه أبدًا. بصفته تخصصًا في علوم الكمبيوتر ، كان من المثير للاهتمام القيام بشيء مع الأجهزة لمرة واحدة إلى حد ما غير عادي.
براندون أسونسيون // [email protected]
أي تعليقات/ردود الفعل موضع تقدير!
