👉🏼 🎅🏾 🆘 حماية القرصنة Xbox 360 (الجزء 3) 🉐 🙏🏿 🔘

في عام 2011 ، بعد 6 سنوات من إصدار وحدة تحكم ألعاب Xbox 360 ، اكتشف الباحثون حقيقة مثيرة للاهتمام - إذا تم إرسال إشارة "0" إلى إخراج RESET للمعالج المركزي لفترة قصيرة جدًا ، فلن يقوم المعالج بإعادة ضبط حالته (كما ينبغي) ، ولكن بدلاً من ذلك تغيير سلوكك! استنادًا إلى هذه "الميزة" ، تم تطوير Reset Glitch Hack (RGH) ، حيث كان من الممكن المساعدة على اختراق حماية Xbox 360 تمامًا ، وتشغيل التعليمات البرمجية غير الموقعة ، وبالتالي فتح الطريق لاختراق النظام نفسه وهزيمة محركات الأقراص DG-16D5S "غير القابلة للكسر" .

دعونا نلقي نظرة فاحصة على كيفية عمل RGH ، وكيف حاول المطورون إصلاح حفرة ، وكيف تمكنت هذه البقع من الالتفاف!

ما هو هجوم خلل؟

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

في الواقع ، تجميع الكود

i = i + 2;

أنت تعتمد على حقيقة أن قيمة المتغير i ستزيد بمقدار 2 بالضبط ، حتى دون إدراك كيف يمكن أن يكون الأمر خلاف ذلك.

هجمات الخلل تنتهك هذه الثقة - هدفهم هو التأكد من أن المعالج "عربات التي تجرها الدواب" وتتصرف بشكل خاطئ. هناك عدة طرق لـ "خلل" المعالج ، على سبيل المثال:

قم بخفض جهد وحدة المعالجة المركزية
لإعطاء دفعة إضافية للتردد المرجعي لوحدة المعالجة المركزية
"تألق" على نسبة الإشعاع

هناك أجهزة خاصة لتنفيذ مثل هذه الهجمات - على سبيل المثال ، يقدم ChipWhisperer مجموعة واسعة من الهجمات في التردد والقوة:

في حالة Xbox 360 ، يحدث "خلل" نتيجة التعرض لخط إعادة الضبط. يبدأ المعالج عملية إعادة الضبط ، ولكن نظرًا لقصر مدة الإشارة ، لا يوجد وقت لإكمالها ويستمر في العمل كما لو لم يحدث شيء. ولكن فقط لهذه اللحظة الوجيزة ، بينما تكون إشارة RESET نشطة ، يتغير سلوكها!

معالج خلل

تقع حماية Xbox 360 على محمل الإقلاع الذي يفحص بعضها البعض في سلسلة. في نهاية المطاف ، يعود التحقق في كل مرحلة إلى استدعاء وظيفة مقارنة مجموع التجزئة مع "النمط". ثم قاموا بتطبيق هجوم الخلل ، مما أجبر المعالج على تجاهل عدم التطابق. دفع إلى خط إعادة الضبط مباشرة بعد استدعاء إجراء memcmp يجبر المعالج على "الانتقال" على طول فرع آخر ومتابعة التحميل ، حتى إذا كان مجموع التجزئة غير صحيح:

تم العثور على أفضل مكان للهجوم في محمل الإقلاع للمرحلة الثانية ، "CB". من الصعب مهاجمة المراحل المتأخرة (وسهلة الإصلاح) ، ولكن في المرحلة الأولى من التحميل ("1BL" ، ROM) فشل الهجوم بسبب بنية مختلفة قليلاً لرمز البرنامج.

يبدو الأمر بسيطًا ، ولكن في الواقع ، عند محاولة تنفيذ هجوم ، تم اكتشاف العديد من الفروق الدقيقة.

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

لحسن الحظ ، في Xbox 360 ، تكون كل خطوة تمهيد مصحوبة بتغيير في القيمة في ناقل التصحيح POST_OUT. علاوة على ذلك ، غالبًا ما يتم ترتيب إخراج التصحيح بحيث يتم تعيين قيمة POST جديدة مباشرة قبل مقارنة مجموع التجزئة:

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

كما اتضح أنه بسبب التردد العالي للمعالج ، يكاد يكون من المستحيل الوصول إلى اللحظة المناسبة من حيث الدقة والمدة. يجب أن يكون وقت التعرض قصيرًا جدًا ، حسب ترتيب وقت تنفيذ تعليمة واحدة من قبل المعالج. ولكن كلما كان المعالج أبطأ ، كلما طالت الفترة الزمنية التي تناسبنا. لذلك ، نأخذ ونبطئ المعالج!

على جهاز الكمبيوتر العادي ، يتم تعريف تردد وحدة المعالجة المركزية على أنه نتاج التردد "المرجعي" الخارجي والمضاعف:

لذا في Xbox 360 ، الخطوط الخارجية للتردد المرجعي مناسبة للمعالج ، وداخل هذا التردد يتم ضربه بواسطة PLL . وفي المراجعات القديمة "السميكة" لجهاز فك التشفير ، يمكن تعطيل آلية PLL عن طريق إبطاء المعالج حتى 128 مرة:

في إصدارات "Slim" ، لا يمكن عمل خدعة PLL (الخط غير مفصول على السبورة) ، وبما أننا لا نستطيع التأثير على عامل "Slim" ، فسنخفض تردد "المرجع"!

يتم إنشاؤه بواسطة رقاقة HANA ، ويمكن تكوينه عبر ناقل I2C:

لسوء الحظ ، لم يكن من الممكن تقليل الكثير ، "بسرعات منخفضة" ، بدأ تردد المعالج النهائي في "السباحة" بقوة ، مما قلل من فرص النجاح. كان الخيار الأكثر استقرارًا هو تباطؤ 3.17 مرة. ليس 128 مرة ، ولكن على الأقل شيء.

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

لذا ، نحصل على الخوارزمية:

التصحيح SMC
تباطؤ في المئة (عبر PLL أو I2C)
في انتظار مشغل POST
في انتظار N ميكروثانية
إرسال دفعة إلى RESET
تسريع في المئة الى الوراء

للحصول على دقة أكبر للحسابات ، نأخذ التردد من نفس HANA (48 ميجاهرتز):

ونحصل على مثل هذا التصميم على أساس CPLD Xilinx XC2C64A غير مكلفة:

لا تنسى أن تخجل من طول وموقع الأسلاك على RESET (انتبه إلى "الملف" في الجزء السفلي من الصورة) وإلى الأمام ، نأمل أن ينجح الإطلاق في غضون دقيقة.

ولكن هذا فقط على جانب الأجهزة. كيف نقوم بتصحيح برنامج bootloader وحشو الكود الخاص بنا؟

لوادر التصحيح

كما ذكرت ، يتم تحميل محمل التمهيد من المستوى الثاني ، "CB". يتم تشفير محمل الإقلاع هذا بمفتاح ثابت ، وهو نفسه لجميع وحدات التحكم ، ولكن لا يمكن تعديل "CB" فقط ، فنحن نهاجمه فقط. لكن المفتاح التالي مشفر بالفعل بمفتاح CPU فريد لكل جهاز فك التشفير. ولتعديله ، تحتاج إلى معرفة هذا المفتاح ...
أم لا؟

في المراجعات القديمة "السميكة" لجهاز Xbox 360 ، تم دعم ما يسمى بوضع "الإقران الصفري" ، والذي تم استخدامه في مرحلة إنتاج جهاز فك التشفير ، في أداة تحميل التمهيد "CB". يحتوي كل رأس محمل إقلاع عند الإزاحة 0x10 على مجموعة بيانات الاقتران العشوائية التي يتم استخدامها كجزء من مفتاح فك التشفير. وإذا كانت مجموعة البيانات هذه تتكون بالكامل من أصفار ("الإقران الصفري") ، فعندئذٍ تم تجاهل مفتاح المعالج وتم استخدام مفتاح ثابت ، صفر بدلاً منه!

باستخدام هذه الحيلة ، كان من الممكن تجميع صورة مع "CB" الأصلي ، وتشفير محمل الإقلاع التالي ، "CD" (برمزه الخاص) بمفتاح صفر وتشغيله باستخدام RGH!

في لوحات المفاتيح "Slim" لف هذه الحيلة ، وإزالة وضع "Zero-Pairing" وتقسيم "CB" إلى قسمين. هنا ، تم تقسيم "CB" إلى "CB_A" بسيط جدًا وصغير وتم تشفيره بواسطة مفتاح المعالج "CB_B":

لكن التشفير بخوارزمية RC4 (أي CB_B مشفر بهذه الخوارزمية) له خصوصية واحدة. في عملية التشفير بناءً على المفتاح ، يتم إنشاء دفق بيانات عشوائية زائفة يقوم الثنائي "بإضافة" (العملية "حصرية" أو "xor") مع البيانات الأصلية. عند فك التشفير ، وفقًا لذلك ، يحدث نفس الشيء ، إضافة بنفس التدفق العشوائي الزائف يعيد البيانات إلى قيمتها الأصلية:

لكن عملية الإضافة الثنائية هي عملية تبادلية ونقابية ، مما يعني أنه يمكننا تعديل البيانات المشفرة دون معرفة المفتاح ، فقط لـ xor ' والشفرة المشفرة مع التصحيح الذي نحتاجه!

ونتيجة لذلك ، يمكننا تشفير "CB_A" ، وتصحيح "CB_B" المشفر (بحيث لا يقوم بفك التشفير على الإطلاق) ووضع نص عادي "CD" مع رمزه!

باختصار ، إذا قمت
بتجميعها ، فإن الإطلاق يبدو شيئًا مثل هذا: (XeLL هو محمل إقلاع homebrew ، Linux ، ويعرض أيضًا مفاتيح وحدة المعالجة المركزية)

ضربات مايكروسوفت مرة أخرى

بالطبع ، حاولت Microsoft تصحيح كل شيء.

في تحديث النظام الجديد ، تم نقل جميع وحدات التحكم القديمة إلى تمهيد "منفصل" من "CB_A" و "CB_B" ، مما أدى في النهاية إلى إغلاق وضع "الإقران صفر". على Slim ، تم تحديث برامج تحميل التشغيل أيضًا. تم تعديل لوادر الإقلاع الجديدة بشكل خطير للحماية من RGH ، مع التركيز الأكبر على حماية CB_A:

تمت إزالة إخراج التصحيح تمامًا في POST
تم إعادة التحقق من التجزئة وتكرارها من أجل الموثوقية
خلال الكود ، تم ضبط وضع السكون () لفترة عشوائية (حسب مفتاح وحدة المعالجة المركزية !!)
تمت إضافة فحص دمج CBLDV لإلغاء CB_A

قائمة الابتكارات لا تترك أي فرصة لـ RGH. ولكن دعنا ننتبه إلى العنصر الأخير في القائمة - قبل ذلك ، لم يكن هناك فحص دمج في CB_A! خطأ فادح. علاوة على ذلك ، كما نتذكر ، فإن مفتاح المعالج لا يشارك في فك تشفير "CB_A". وهذا يعني أنه يمكن تشغيل أداة تحميل CB_A المعرضة لـ RGH على أي وحدة تحكم ، ولا يمكن حظر ذلك.

ولكن من أجل أن تبدأ شيئًا بمساعدة "CB_A" الضعيفة ، تحتاج إلى المراوغة قليلاً. إذا لم نكن نعرف مفتاح وحدة المعالجة المركزية ، فكل ما تبقى لنا هو تصحيح "CB_B" الموجود. ولكن ماذا لو بدلنا عن محمل الإقلاع بالكامل بدلاً من تعديل الأقسام الفردية؟ وبسبب هذا ، "اكتب" محمل الإقلاع القديم ، الذي نعرف بالفعل كيفية تصحيحه ، لاستبدال الجديد؟ لذلك فعلوا:

نقوم بتشفير CB_A الضعيفة بنفس الطريقة كما في الصورة الأصلية
XOR CB_B لدينا مع الجديد ، والحصول على "الفرق"
نضعه على "CB_B" المشفر!

كل شيء ، مرة أخرى ، دون معرفة المفتاح ، نجحنا في استبدال المحتوى المشفر ، ووضعنا أيضًا أداة تحميل التمهيد الضعيفة. لوحات المفاتيح الإختراق ، تفاجأ مايكروسوفت.

عمل المطورون بجد ، وفي التحديث التالي للنظام ... غيروا قليلاً طريقة التشفير "CB_B" ، والآن أصبح مفتاح التشفير أيضًا معتمدًا على إصدار "CB_A":

الآن ، عند محاولة xor 'ودفع البيانات إلى "CB_A" الضعيفة من الإصدار القديم ، قام برنامج bootloader بفك تشفير القمامة بسبب الاختلافات في المفاتيح. ولا يمكن اختراق أداة تحميل التشغيل الجديدة ، فهي محمية بشكل جيد من هجمات glich. حتى الآن ، انتصار لمايكروسوفت!

يلقي الاكليل المشاكل

وفي الوقت نفسه ، دخلت مراجعة جديدة لأجهزة Xbox 360 ، Corona ، السوق ، وجلبت مشاكل للمراجعين:

لا توجد رقائق كافية على اللوحة ، هل يمكنك العثور عليها؟ هذا صحيح ، رقاقة HANA كانت "مخفية" في الجسر الجنوبي. لا يوجد مكان آخر لأخذ تردد 48 ميجاهرتز لشريحة التعديل ، لا تعمل أوامر تباطؤ I2C السابقة. ولكن ما هو ، تم استبدال ذاكرة فلاش NAND بسعة 16 ميجابايت ، والتي كانت بمثابة تخزين نظام Xbox 360 طوال هذه السنوات ، بشكل خائن بشريحة 4 جيجابايت بواجهة eMMC! (صحيح ، فقط في الإصدار الأرخص من وحدة التحكم ، ولكن لا يزال):

ولكن لا شيء ، تم التعامل مع كل شيء. اكتشفنا كيفية قراءة / كتابة ذاكرة فلاش من خلال قارئ بطاقات:

تم العثور على أوامر تباطؤ I2C جديدة ، تم استبدال مذبذب بلوري 48 ميجاهرتز خارجي بـ HANA:

اكتملت سكريبتات الإنشاء ، ودعم إضافي لـ 4 جيجابايت NAND ...

لكن مايكروسوفت واصلت وضع العصي في العجلات. على سبيل المثال ، في اللوحات الجديدة ، اختفت بعض المقاومات ، والتي بدونها توقفت رقاقة التعديل عن العمل:

صحيح ، تم إصلاح ذلك عن طريق تثبيت وصلات العبور بمكواة لحام:

أصبحت الأمور أكثر خطورة عندما اختفت مسارات POST_OUT من اللوحة:

ولكن هنا لم تكن مايكروسوفت محظوظة ، كانت "كرات" وحدة المعالجة المركزية اللازمة لـ RGH في الصف الشديد:

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

ثم أطلق الصينيون إطارًا بإبرة محملة بنابض ، وتستريح بالضبط على الكرة ، وتم حل المشكلة للجميع:

آخر المعاقل

بعد هزيمة "التاج" ، كانت هناك مشكلة واحدة - الإصدارات الجديدة من النظام لم تستسلم للقرصنة. لبدء RGH ، تحتاج إلى معرفة مفتاح CPU ، ولمعرفة مفتاح CPU ، تحتاج إلى تشغيل RGH مرة واحدة على الأقل. مشكلة الدجاج والبيض بشكل عام.

ثم نشأت فكرة - ودعونا لا نتحقق من مصادقة "خلل" فحسب ، بل سنتخطى أيضًا فك التشفير! إذا نجح الأمر ، فلن نحتاج إلى معرفة المفتاح ، ضع “CB_B” في مكانه ، هذا كل شيء. شكلت هذه الفكرة أساس الاختراق المزدوج (DGX):

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

لم يكن DGX مناسبًا لفترة طويلة ، بعد 3 أشهر ألقى الصينيون في إصدار "DGX RIP" مع الصور التي تعمل على أي جهاز فك التشفير ، وعملوا مع RGH القياسي ، وبطبيعة الحال ، بدأوا أكثر استقرارًا:

احتوت هذه الصور على إصدار خاص من محمل الإقلاع CB_A المستخدم في إنتاج Xbox 360 ، وهو في الواقع نظير كامل لوضع "الإقران صفر" القديم الجيد. بدلاً من مفتاح المعالج ، قام "CB_A_mfg" هذا بفك تشفير "CB_B" بمفتاح فارغ ثابت:

وهنا مايكروسوفت. في إصدار "الخدمة" هذا من "CB_A" لم يكن هناك أي فحص للانصهار وكان من المستحيل حظره. كان يكفي تسجيل الصورة وفقًا لمراجعة جهاز Xbox 360 ، ولحام الشريحة - وعمل كل شيء.

وينشستر!

تم إصلاح RGH بالكامل فقط في المراجعة الجديدة لوحدة التحكم ، التي تحمل الاسم الرمزي Winchester. لأول مرة ، تم دمج معالجات CPU و GPU في شريحة واحدة ، تم تبسيط اللوحة قدر الإمكان:

لم تتم إزالة مسارات POST_OUT فقط. حتى لو قمت بلحام النظام الأساسي تحت المعالج:

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

على POST_OUT ، يظهر نبض واحد فقط عند بدء تشغيل وحدة التحكم. تأمين الحافلة:

علاوة على ذلك ، يتم حظره فقط في مرحلة الإنتاج. إذا كنت تأخذ معالجًا "نظيفًا" من مصنع لم تحرق فيه الصمامات بعد ، فإن POST_OUT يعمل عليه!

لكن RGH عليه لم يعد يعمل. بغض النظر عن كيفية محاولة إعطاء نبض RESET ، يقوم المعالج بإعادة التعيين بشكل صحيح ، أو يتجاهل الإشارة الخاصة بك بسبب مدتها القصيرة جدًا. على ما يبدو ، تمت إضافة وحدة منطقية خاصة إلى المعالج ، وتصفية خط RESET وبالتالي إصلاح خطأ الأجهزة.

بعد البرنامج النصي

اتضح أن أحدث مراجعة لجهاز Xbox 360 مستحيل الاختراق؟

نعم و لا. في الوقت الحالي ، هناك طريقة واحدة معروفة لتشغيل نظام معدل على مراجعات Winchester.

تحتوي مجموعة تطوير البرامج (XDK) على مفاتيح خاصة مختلفة لتوقيع التعليمات البرمجية المترجمة. وهكذا اتضح أن مفتاح التوقيع "shadowboot" ، وهو محمل إقلاع من المستوى الثالث لأنظمة XDK ، فوضى. ومع ذلك ، يمكنك جمع صورة موقعة مشروعة مع البرامج الثابتة المعدلة. مجرد العمل على لوحات المفاتيح "مخزن" العادي ، لن يفعل. نحتاج إلى معالج بإصدار XDK من وحدة التحكم ، أو وحدة معالجة مركزية "نظيفة" مزودة بمصهرات غير منصهرة (يمكنك رؤيتها على Aliexpress):

وعندها فقط ستتاح لك الفرصة للتفكير في مثل هذا النقش في "معلومات النظام" الخاصة بالصدفة المخصصة:

و هذا كل شيء! كالعادة ، أنا على استعداد للإجابة على أسئلتك في التعليقات :)

الحماية والاختراق Xbox 360 ، الجزء 1
الحماية والاختراق Xbox 360 ، الجزء 2
الحماية والاختراق Xbox 360 ، الجزء 3

حماية القرصنة Xbox 360 (الجزء 3)