14.3.4. ملاحظة حول حماية قراءة ذاكرة الفلاش¶

البرنامج الثابت على كاميرا OpenMV المُشحونة قابل للقراءة خارج الصندوق من قبل أي شخص لديه وصول فيزيائي إلى الجهاز. يمكن لمهاجم يحمل الكاميرا أن يوصل مسبار SWD برأس التصحيح، ويتواصل مع واجهة تصحيح وحدة MCU، ويُفرغ ذاكرة الفلاش -- التي تتضمن كل وحدة Python مُجمّدة ومحتويات قسم ROMFS. لا يُفعّل البرنامج الثابت القياسي من OpenMV حماية قراءة الفلاش بشكل افتراضي على الإطلاق.

توثّق هذه الصفحة ذلك صراحةً حتى يعرف الفريق الذي يشحن منتجًا أين تقع المسؤولية.

14.3.4.1. ما تفعله الكاميرا بشكل افتراضي¶

لا يُفعّل محمّل إقلاع الكاميرا ولا بيئة تشغيلها أي ميزة لحماية القراءة في وحدة MCU الأساسية. تبقى واجهة التصحيح مفتوحة، وتبقى ذاكرة الفلاش قابلة للقراءة، ويعمل البناء بالطريقة التي يعمل بها على طاولة المطوّر. هذا هو الإعداد الافتراضي الصحيح لجمهور البرنامج التعليمي -- فالكاميرا التي تُشحن مع تفعيل حماية القراءة هي كاميرا لا يمكن إعادة تحميل برنامجها الثابت عبر الـ IDE، ولا يمكن إعادة تصويرها بعد نشر فاشل، ولا يمكن إنقاذها من قبل أحد سوى فريق البناء.

تتغيّر المفاضلة عندما تنتقل الكاميرا من "جهاز مطوّر" إلى "منتج". فالمنتج الذي تعتمد قيمته على بقاء كود التطبيق خاصًا يجب أن يُفعّل الحماية بنفسه؛ فالبرنامج الثابت من OpenMV لا يفعل ذلك.

14.3.4.2. ما يفعله فريق المنتج¶

يوفّر كل مورّد لوحدات MCU آلية لحماية القراءة. تختلف التفاصيل -- مصاهر على مستوى البت، انتقالات دورة حياة لمرة واحدة، صور فلاش موقّعة -- لكن الشكل المشترك هو:

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

إعداد هذا خاص بوحدة MCU، وتعتمد الخطوات على القطعة الموجودة على الكاميرا المراد حمايتها. دليل المورّد المرجعي هو مصدر الحقيقة؛ ودعم المورّد هو القناة لإنجاز ذلك بشكل صحيح على خط التصنيع.

هذا هو الجزء السهل.

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

REPL في MicroPython. يقبل REPL المتصل عبر USB أي كود Python عشوائي. لا تغيّر حماية القراءة ذلك. يمكن لجلسة REPL قراءة RAM، واستدعاء الدوال، وتسريب كل ما يمكن للتطبيق قيد التشغيل رؤيته -- وعمليًا، فإن REPL قابل للوصول يتجاوز كل ما تشتريه حماية القراءة. تعطيل الوصول إلى REPL هو تغيير في بناء البرنامج الثابت يملكه فريق المنتج.
رفع البرنامج النصي عبر الـ IDE. يستخدم مسار "شغّل هذا البرنامج النصي على الكاميرا" في الـ IDE نفس سطح بروتوكول USB الذي يستخدمه REPL. إغلاق REPL يغلق هذا معه؛ وترك أيٍّ منهما مفتوحًا يترك قناة لتنفيذ كود عشوائي داخل الكاميرا.
اختطاف نقطة الدخول من نظام الملفات. مُغلق بالفعل عند شحن التطبيق عبر تجميد البرامج النصية داخل البرنامج الثابت -- إذ تحلّ بيئة التشغيل ملفّي boot.py و main.py المُجمّدين قبل أي نسخة في نظام الملفات، لذا لا شيء يُسقَط على الفلاش أو بطاقة SD يمكنه تجاوزهما. هذه الحماية مجانية بمجرد أن يكون التطبيق ضمن البناء.
الفلاش الخارجي على الكاميرات الأحدث. الكاميرات التي تخزّن صورة التطبيق في فلاش خارجي تضع تلك الصورة على شريحة موجودة على مرأى من الجميع على لوحة PCB؛ يمكن إزالة لحام الشريحة وقراءتها مباشرةً بأدوات جاهزة، أو قراءتها في مكانها بفحص الناقل. حمايتها تتطلب تشغيل العتاد الموجود على الشريحة الذي يفك تشفير محتويات الفلاش أثناء القراءات، وتوليد مفتاح التشفير، وتزويد الكاميرا بذلك المفتاح، وحرقه بلا رجعة في وحدة التخزين القابلة للبرمجة لمرة واحدة في وحدة MCU. كل عملية من هذه عملية منفصلة تتم لمرة واحدة، وأي واحدة منها تُنفّذ بشكل خاطئ على وحدة إنتاج تُعطّل تلك الوحدة.

كل بند في هذه القائمة هو حزمة قائمة بذاتها من عمل بناء البرنامج الثابت، وخطوات خط التصنيع، والالتزامات التي لا رجعة فيها. المنتج المُؤمَّن فعليًا هو بناء برنامج ثابت مخصّص، ومحمّل إقلاع مخصّص، وتدفق تصنيع يزوّد المفاتيح لكل وحدة، ومجموعة من الاختبارات التي تثبت أن القفل مغلق فعلًا قبل أن تغادر الوحدة الخط. هذا عمل أشهر لا أيام، وعدم قابلية الرجوع يعني أن الأخطاء تكلّف وحدات.

لماذا الإعداد الافتراضي مفتوح

هذه القائمة هي أيضًا سبب شحن البرنامج الثابت القياسي من OpenMV دون تفعيل حماية القراءة. فالكاميرا التي أُغلق فيها REPL، وعُطّل رفع البرنامج النصي عبر الـ IDE، وقُفل برنامجها الثابت هي كاميرا لا يمكن التطوير عليها على الإطلاق -- سيختفي ببساطة سير العمل الذي يجعل كاميرات OpenMV قابلة للاستخدام في المقام الأول. الإعداد الافتراضي يترك كل شيء مفتوحًا؛ ويختار فريق المنتج أي الأجزاء يُغلق في طريقه إلى وحدة مشحونة.

14.3.4.3. ما يبقى الوصول الفيزيائي قادرًا على تحقيقه¶

حتى مع تفعيل حماية القراءة، يمكن للمهاجم الذي يحمل الكاميرا أن يفعل الكثير:

إعادة تشغيل حركة شبكة الكاميرا عبر التنصّت على مخرجاتها.
ملاحظة سلوكها المرئي واستنتاج كيف تتفاعل مع المدخلات.
في بعض الحالات، استرجاع الأسرار عبر هجمات حقن الأعطال أو هجمات القنوات الجانبية المتخصّصة ضد وحدة MCU المحمية.

ترفع حماية القراءة كلفة الوصول إلى مصدر التطبيق. لكنها لا تلغي الكلفة. "الوصول الفيزيائي = اختراق" هو الافتراض العملي الذي ينبغي أن تبدأ منه مراجعة الأمان؛ وآلية الحماية تحدّد فقط مقدار ما يكلّفه ذلك الاختراق من وقت ومعدّات.

14.3.4.4. ما يأتي به البرنامج الثابت من OpenMV¶

ملخّص، حتى يكون هذا ملموسًا:

لا حماية قراءة مُفعّلة بشكل افتراضي.
لا علم بناء في البرنامج الثابت القياسي يُفعّلها.
لا API على مستوى التطبيق يمكن استدعاؤه من MicroPython.

المنتج الذي يحتاج إلى الحماية يشحن برنامجًا ثابتًا مخصّصًا. يقع ذلك التخصيص في محمّل إقلاع اللوحة وفي تدفق التصنيع، وهو خارج قاعدة كود OpenMV. ينبغي للفرق التي تقوم بهذا لأول مرة أن تخطّط له ضمن الجدول الزمني للتطوير كقطعة عمل منفصلة، لا كشيء يُضاف في النهاية -- فعدم قابلية الرجوع تجعل "أضفه لاحقًا" مكلفًا.