خلال الأسبوعين الماضيين كنت أجرّب شيئًا بسيطًا في فكرته، لكنه أخذني إلى أماكن لم أتوقعها. بدأت أستخدم وكلاء ذكاء اصطناعي لتنفيذ الهندسة العكسية للأجهزة الطرفية الموجودة حرفيًا حولي وعلى مكتبي.
النتيجة كانت أغرب مما توقعت. حصلت على Command Shell كامل بنص واضح داخل الميكروفون، وتمكنت من تعطيل مؤشر التسجيل في كاميرا ويب بينما تستمر في التصوير، واكتشفت إضاءة مكتبية تسمح لأي شخص على شبكة WiFi بتنفيذ عمليات كتابة في الذاكرة.
اتضح لي أن الأجهزة الطرفية هدف مثالي للهندسة العكسية المدفوعة بالوكلاء. هذه الأجهزة في النهاية حواسيب صغيرة متصلة بحاسوبك، لديها قناة اتصال مباشرة مع النظام وغالبًا آلية لتحديث الـFirmware، وهذا يعطي الوكيل مساحة ممتازة للتحليل والتجربة والتحقق.
والنتيجة النهائية بالنسبة لي كانت فهمًا أعمق لما يحدث فعلًا داخل الأجهزة المتصلة بجهازي، وقدرة أكبر على التحكم بها.
#كيف كانت العملية؟
تقريبًا اتبعت الأسلوب نفسه مع كل جهاز. أحصل على نسخة من الـFirmware وأداة التحديث الرسمية من الشركة المصنعة، ثم أضعها داخل بيئة الهندسة العكسية الخاصة بي، وأعطي Claude Opus 5 الأهداف التي أريد الوصول إليها، ثم أتركه يعمل.
الأهداف تختلف قليلًا من جهاز إلى آخر، لكنها غالبًا كانت تدور حول شيء قريب من التالي:
In this directory is the firmware and update utility for ___. The device is also attached to this computer, and you may interact with it in non-mutating ways. Exhaustively document and cross-validate the entire firmware, including the following goals:
* reverse engineer the firmware update format and update protocol
* implement our own update utility
* determine the security properties of the update protocol, including checksums, signature validation, secure boot
* use static and dynamic analysis to determine all protocol surfaces and completely enumerate functionality
* find any hidden or debug functionality in the product and how to access it
بعد ظهور النتائج يبدأ المسار بالتفرع حسب كل جهاز. لكن الفكرة العامة واحدة: نفهم طريقة عمل الجهاز، نعيد بناء بروتوكولاته، ثم نختبر ما إذا كانت الحواجز الأمنية الموجودة حقيقية أم مجرد طبقة شكلية.
كل جهاز في القائمة التالية يحتوي على رابط لمستودع GitHub مليء بالمستندات والسكربتات الناتجة عن عملية التحليل. أغلب هذه النتائج تم التحقق منها عمليًا على أجهزة حقيقية.
أضفت أيضًا مقدار الجهد الذي استغرقه كل جهاز اعتمادًا على جلسات Claude Code. كلمة "Churn" هنا تعني الوقت الفعلي الذي كان Claude يعمل خلاله بعد استبعاد فترات التوقف الطويلة، أما "Prompts from me" فهي كل رسالة كتبتها له حتى لو كانت مجرد كلمة أطلب منه فيها الاستمرار.
عند جمع الأجهزة الخمسة وصلت النتيجة إلى نحو 13 ساعة من العمل الفعلي و98 Prompt موزعة على أمسيات أسبوعين.
#كل ما أملكه تقريبًا أصبح هدفًا للتحليل
#كاميرا Insta360 Link
مستودع GitHub | 3.7 ساعات عمل و33 Prompt مني
أستخدم كاميرا Insta360 Link، وهي كاميرا PTZ صغيرة مثبتة على Gimbal وتدعم تتبع الوجه لكي تضبط الإطار تلقائيًا أثناء التصوير. السؤال الذي أردت الإجابة عنه كان بسيطًا: هل يمكن العبث بمؤشر النشاط وإطفاؤه بينما تستمر الكاميرا في التسجيل؟
الفكرة ليست جديدة تمامًا. شيء مشابه ظهر سابقًا في استغلال iSeeYou، لذلك أردت معرفة ما إذا كان السيناريو ما زال ممكنًا على جهاز حديث.
من اللحظة الأولى كان واضحًا أن داخل هذه الكاميرا عالمًا كاملًا. الجهاز يشغل نظام تشغيل لحظي RTOS من نوع ThreadX قادم من مزود الـSoC نفسه، وهو Ambarella.
هذا النظام يستضيف عدة نماذج رؤية صغيرة مسؤولة عن ميزات مثل تتبع الوجه والتعرف على الإيماءات المستخدمة للتحكم بالإعدادات. كمية التعقيد الموجودة داخل كاميرا ويب بهذا الحجم مثيرة فعلًا، لكنها تعني شيئًا آخر أيضًا: مساحة هجوم أكبر بكثير مما قد تتوقعه.
عبر واجهة USB Video Class توجد تعليمة XU أو Extension Unit تستطيع نقل الجهاز إلى وضع "Mass Storage". بعدها يمكن رفع تحديث Firmware مرحلي إلى نظام الملفات FAT الداخلي، ثم يقوم الجهاز بتطبيقه عند إعادة التشغيل.
المسار الأول يحتاج إلى تدخل المستخدم لفصل الكاميرا وإعادة توصيلها. لكن توجد قناة أوامر أخرى تكشف إمكانية القراءة والكتابة العشوائية للملفات، إضافة إلى أمر لإعادة التشغيل عبر USB Vendor Class.
بهذا أصبح بالإمكان إعادة برمجة الجهاز بالكامل دون أي تدخل من المستخدم. وبعد وصول الـFirmware إلى المكان المطلوب لا توجد فعليًا آلية Anti-Tamper حقيقية، بل مجرد قيمة MD5 مضافة للتحقق من سلامة الملف.
مؤشر النشاط نفسه يعتمد على مجموعة منظمة من الأنماط داخل الـFirmware. هذه الأنماط تحدد اللون وطريقة الوميض والسلوك المرتبط بكل حالة من حالات الجهاز.
طلبت من Claude كتابة أداة تعدل قيمة الجدول الخاصة بنشاط الكاميرا، ثم تعيد حساب قيمة التحقق وتكتب الـFirmware المعدل على الجهاز.
الاختبار كان مباشرًا. بدأت الكاميرا التسجيل، لكن الضوء الأخضر الذي يفترض أن يعمل أثناء التصوير لم يضئ.
وهنا تصبح الفكرة مزعجة فعلًا.
في هذه الكاميرا تحديدًا يتحرك الـGimbal إلى الأسفل عندما لا تكون الكاميرا قيد الاستخدام، لذلك العملية ليست خفية بالكامل. مع ذلك، القدرة على فصل مؤشر التسجيل عن حالة التسجيل نفسها ليست شيئًا مريحًا.
سلوك مؤشر LED قبل التعديل وبعده.
#شاشة ASUS ROG Swift PG42UQ
مستودع GitHub | 1.2 ساعة عمل و13 Prompt مني
هذه الشاشة كانت في الحقيقة نقطة البداية لكل الموضوع. السبب لم يكن ثغرة أمنية ولا مشروع بحث كبير، بل نافذة مزعجة تظهر من وقت إلى آخر وتطلب مني تشغيل ميزة "Pixel Cleaning".
أنا لا أشغّل Pixel Cleaning يدويًا، ولا أريد تشغيله، وكل ما كنت أريده أن تختفي الرسالة إلى الأبد. فكرت أن الشاشة ربما تحتوي على Debug Menu يسمح بتعطيلها، وفي أسوأ الحالات يمكن تعديل فرع داخل الـFirmware لإيقافها.
ما وجده Claude كان أبسط من المتوقع وأقل طمأنينة أيضًا. الـFirmware يكاد لا يحتوي على أي حماية حقيقية.
هناك نظام A/B بفتحتين وChecksum بسيط، لكن في النهاية يمكننا كتابة ما نريد تقريبًا على الجهاز. تحديثات الـFirmware نفسها تمر عبر ناقل I2C يتم تمريره من خلال USB.
أما رسالة Pixel Cleaning فاتضح أنه لا توجد طريقة أصلية لتعطيلها. ستظهر بعد ثماني ساعات من التشغيل مهما فعلت.
لكن Claude تمكن من تحديد الموضع المناسب للتعديل لإيقاف هذه الوظيفة بالكامل.
حتى الآن لم أتحمس بما يكفي لكتابة Firmware معدل على الشاشة فعلًا. الشاشة غالية، وليس لدي رغبة كبيرة في تحويلها إلى قطعة ديكور بسبب Patch سيئ، لكن غالبًا سأجرب ذلك في مرحلة ما.
أحد الجوانب الممتعة الأخرى كان تحليل واجهة DDC/CI. هذه هي قناة التحكم التي تمر عبر كابل الشاشة نفسه وتسمح للنظام بتغيير مصدر الإدخال وبعض الإعدادات الأخرى.
أعتقد أن ASUS توفر الوصول لهذه الوظائف من خلال أداة DisplayWidget على Windows، لكن ذلك لا يفيدني كثيرًا على Linux.
لذلك أصبح لدي الآن Shell Script يستطيع التحكم في بعض وظائف DDC/CI مثل مؤشر التصويب المدمج، والتكبير، وعداد FPS، والمؤقت التنازلي.
وقد أحول بعضها لاحقًا إلى اختصارات مباشرة من لوحة المفاتيح.
#ميكروفون Shure MV7
مستودع GitHub | 4.2 ساعات عمل و32 Prompt مني
عند هذه المرحلة لم يعد لدي سبب عملي قوي لمواصلة فتح هذه الأجهزة وتحليلها. الفضول أصبح هو المحرك الأساسي.
الميكروفون الذي أستخدمه هو Shure MV7. يتصل عبر USB ويحتوي بوضوح على قدر من المعالجة الداخلية، مثل التحكم الرقمي بمستوى الصوت وبعض الإعدادات الأخرى الموجودة داخل الجهاز نفسه.
اتضح أن الـFirmware مخفي داخل برنامج MOTIV Mix على Windows. لذلك قام Claude بتثبيت البرنامج عبر Wine، ثم عثر على خادم التحديث وسحب الـFirmware منه.
وبما أن الميكروفون لدي لم يكن يعمل على آخر إصدار، ظهر هنا سبب عملي إضافي للمشروع: تحديث الميكروفون من Linux دون الحاجة إلى Windows.
بعد التحليل، تبين أن حزمة الـFirmware تحتوي على Firmware خاص بالـDSP وآخر خاص بالـMCU. من هذه الناحية لم يكن هناك شيء مثير جدًا، والأهم أنه مرة أخرى لم تكن هناك حماية فعلية قوية على عملية كتابة الـFirmware نفسها.
لكن المفاجأة ظهرت في بروتوكول التحديث.
الجهاز بالكامل يتواصل عبر بروتوكول USB HID من فئة Vendor Class، وداخله يوجد Command Shell كامل بنص واضح يحتوي على 48 أمرًا مختلفًا.
وبما أنه HID، يمكن الوصول إليه من صفحة ويب عبر WebHID في Chrome. لذلك طلبت من Claude بناء واجهة ويب تسمح باستخدام هذا الـShell مباشرة.
الواجهة كشفت عددًا كبيرًا من الإعدادات. هناك قرابة اثني عشر متغيرًا للـDSP، وقراءة وكتابة عشوائية للذاكرة، وتحكم في LED، ونظام صلاحيات مستخدمين مكوّن من أربع طبقات.
المشكلة أن آلية المصادقة بالكامل ليست أكثر من مقارنة نصية باسم مستوى الصلاحية الذي تطلبه.
الأمر su sup يعمل ببساطة.
أعلى مستوى من الصلاحيات يستطيع تعطيل لوحة اللمس، بحيث لا تتمكن من كتم الميكروفون من الجهاز نفسه. ويمكنه أيضًا التحكم في مؤشر الكتم بشكل منفصل تمامًا عن حالة الكتم الحقيقية.
نفس خدعة ضوء الكاميرا، لكن هذه المرة داخل ميكروفون.
وطبعًا، العبث بهذه الواجهة دون معرفة ما تفعله قد يؤدي بسهولة إلى تعطيل الجهاز.
واجهة WebHID Shell. عناصر التحكم بالـDSP على اليسار هي إعدادات الجهاز نفسه، بينما الكونسول على اليمين هو Command Shell النصي الذي يتواصل عبر HID.
#جهاز Elgato Cam Link 4K
مستودع GitHub | 1.5 ساعة عمل و10 Prompts مني
Elgato Cam Link 4K في النهاية مجرد جهاز التقاط فيديو HDMI، ومن ناحية كثيرة كانت القصة مشابهة لما سبق.
الجزء المختلف هنا أنني تركت العملية تعمل دون متابعة تمامًا. بدأت المهمة قبل النوم، وعندما استيقظت كان أمامي تحليل للجهاز وأداة Firmware Updater تعمل بالفعل.
الـFirmware يحتوي على صورة MCU وFPGA Bitstream مسؤولة عن التعامل الفعلي مع HDMI. نظريًا يمكن فعل أشياء مثيرة جدًا بالـFPGA إذا تعمقت بما يكفي في الهندسة العكسية.
لكن من ناحية الأمان، مسار تحديث الـFirmware لا يحتوي على حماية حقيقية.
تمكنت أيضًا من استخراج جميع بيانات EDID المستخدمة في التفاوض على خصائص الفيديو.
بهذا أصبح من الممكن معرفة الدقات ومعدلات التحديث ومساحات الألوان وخيارات Chroma Subsampling التي يعرضها الجهاز للأطراف المتصلة به بشكل دقيق.
بروتوكول HID الخاص بالشركة يوفر كذلك وصولًا نفقيا إلى ناقل I2C الداخلي.
وهذا يعني أنه يمكن الوصول إلى سجلات مستقبل HDMI الداخلي والتعامل معها مباشرة، وهي نافذة صغيرة لكنها مثيرة إلى ما يحدث داخل الجهاز.
#إضاءة Elgato Key Light Mini
مستودع GitHub | 2.4 ساعات عمل و10 Prompts مني
في النهاية انتقلت إلى جهاز لا يتصل عبر USB أصلًا، بل عبر WiFi. هذه المرة كان الهدف Elgato Key Light Mini.
والجهاز كان أكثر إثارة مما توقعت بكثير.
من بين كل الأجهزة التي حللتها كان هذا الوحيد الذي يحتوي على حماية ذات معنى لسلامة الـFirmware. تقوم Elgato بتوقيع تحديثات الـFirmware باستخدام Ed25519 فوق قيمة SHA-512 لمحتوى الـFirmware، ويرفض الجهاز أي تحديث لا يجتاز التحقق.
وهذا منطقي. الجهاز يتصل بشبكة WiFi ثم يوفر وصولًا غير موثق لأي شخص على الشبكة نفسها، لذلك نموذج التهديد هنا مختلف عن جهاز USB متصل مباشرة بحاسوب واحد.
لكن الحماية لديها مشكلة كبيرة.
التحقق من التوقيع يحمي الـFirmware في لحظة واحدة فقط: أثناء عملية التحديث.
لا يوجد تحقق عند الإقلاع يفرضه الـBootloader، ولا يوجد Secure Boot فعلي يضمن أن الكود الذي يبدأ الجهاز بتشغيله ما زال موثوقًا.
والأسوأ أن أداة التحديث تعمل بينما بقية مكونات الجهاز ما زالت تعمل هي الأخرى. هذا يفتح مساحة هجوم كبيرة لمحاولة تعطيل عملية التحقق نفسها قبل أن تنتهي.
طلبت من Claude البحث عن طريقة يمكن أن تحقق ذلك، وكانت النتيجة قوية جدًا.
وجد طلب HTTP POST يستطيع تمرير Payload مباشرة إلى UART الداخلي. ومن ضمن الأوامر المتاحة هناك أمر يسمح بالكتابة في الذاكرة.
النتيجة أن طلب HTTP POST واحد يحتوي على:
ATSE=0200ED94,0E001009
يجعل التحقق من التوقيع بلا تأثير فعلي.
بعدها يصبح من الممكن تحديث الجهاز باستخدام Firmware لا يحمل توقيعًا شرعيًا.
اختبرت ذلك عمليًا باستخدام Patch بسيط يغيّر اسم الجهاز، ونجح.
باختصار، لا تضع هذه الأجهزة على شبكة لا تثق بمن فيها.
#والآن أصبحت الصورة أكبر من مجرد أجهزة على مكتبي
لدي مشاعر متناقضة تجاه كل ما حدث هنا.
من جهة، وكما كتبت سابقًا في مارس، ما يحدث مذهل من ناحية قابلية التشغيل البيني وإصلاح الأجهزة التي لا تعمل بالطريقة التي نريدها.
العتاد أصبح في كثير من الحالات "مفتوحًا" للتجربة أكثر من أي وقت مضى. بضع ساعات من العمل المؤتمت إلى حد كبير أصبحت كافية لفهم Firmware جهاز كامل وإضافة وظائف أو تعديل سلوكيات كانت سابقًا تتطلب وقتًا وخبرة أكبر بكثير.
وأتطلع فعلًا إلى مستقبل قريب أستطيع فيه إضافة ميزة إلى Firmware الكاميرا بالسهولة نفسها التي أعدل بها برنامجًا يعمل على جهاز Linux الخاص بي.
لكن عندما أنظر إلى الموضوع بعين أمنية، الصورة تصبح أقل راحة بكثير.
أصبحت أتعامل مع أي جهاز متصل بالحاسوب على أساس أنه قد يكون قادرًا نظريًا على حمل Firmware Implant خبيث.
قبل سنوات، تنفيذ شيء كهذا كان يتطلب استثمارًا كبيرًا في تحليل كل موديل على حدة، وغالبًا كان هذا النوع من القدرات مرتبطًا في الأذهان بجهات متقدمة أو بما يسمى State Actors.
الآن حاجز التكلفة والوقت بدأ ينخفض.
أنظمة التشغيل نفسها ليست مجهزة جيدًا للتعاون مع المستخدم والتأكد من أن "الميكروفون سيبقى ميكروفونًا".
من الناحية النظرية، ماذا لو تحول جهاز طرفي في لحظة ما إلى لوحة مفاتيح، نفذ Win+R، ثم أسقط Payload على النظام لسرقة البيانات عندما يعتقد أن المستخدم لا يراقب الشاشة؟
وجود تقنيات مثل WebUSB وWebHID وWebBluetooth يزيد المشكلة تعقيدًا. في بعض الأجهزة، وبحسب نوع الـClass المستخدم، قد تكون لحظة واحدة من قبول المستخدم لنافذة صلاحيات كافية لفتح قناة يمكن استغلالها لتعديل جهاز طرفي بشكل دائم.
أما الأجهزة المتصلة بالشبكة فالوضع يبدو أكثر سوءًا.
هناك أجهزة أخرى اختبرتها ولم أوثقها هنا. تمكنت مثلًا من الحصول على Root Shell على شاشة Dell تجارية، كما وصلت إلى Remote Code Execution على جهاز UPS من Eaton.
من الطبيعي أن السماح لأجهزة غير موثوقة بالتواصل مع هذه الأنظمة لم يكن يومًا ممارسة جيدة. لكن العامل الجديد الآن هو السرعة والحجم اللذان يمكن تنفيذ هذا النوع من التحليل بهما.
وهذا يرفع مستوى المخاطرة بشكل واضح.
#ماذا لو امتلكت الدودة نفسها مهندسًا عكسيًا؟
هذا هو الجزء الذي يصعب علي تجاهله.
ما الذي يمكن أن تفعله اليوم دودة Malware ذاتية الانتشار إذا كانت مزودة بقدرة ذكاء اصطناعي تنفذ الهندسة العكسية تلقائيًا؟
القفزة المطلوبة لتخيل السيناريو ليست كبيرة جدًا.
يمكن تصور برمجية خبيثة ذاتية النسخ تستكشف البيئة المحيطة بها، وترسل نتائج الاستطلاع إلى بنية Command and Control ذكية، ثم تبدأ تلك البنية بتحليل الأجهزة الموجودة حول النظام المصاب ومحاولة إيجاد طريق إلى الملحقات وأجهزة IoT والمعدات الصناعية القريبة.
تاريخيًا كان هناك حاجزان كبيران أمام سيناريو كهذا.
الأول أن كل موديل من الأجهزة يحتاج إلى عملية هندسة عكسية خاصة به.
والثاني أن التحقق من النتائج يحتاج غالبًا إلى وجود الجهاز الحقيقي أمام الباحث.
الحاجز الأول هو بالضبط نوع العمل الذي بدأت للتو بتسليمه إلى Agent.
أما الحاجز الثاني، فالبرمجية الخبيثة الموجودة أصلًا على جهاز مصاب تملك العتاد أمامها مجانًا.
لن أتفاجأ كثيرًا إذا كان شيء قريب من هذه الفكرة موجودًا بالفعل في مكان ما.
وفي كل الأحوال، السنوات القادمة في هذا المجال ستكون مثيرة جدًا للاهتمام.
