Wake and Break

ثغرة استغلال PSP (معالج أمان المنصة) لبطاقات AMD navi31 (سلسلة RX 7900). من المحتمل أن تكون قابلة للتكيّف مع عائلات منتجات أخرى مجاورة أيضًا.

تقوم بتعطيل فحص توقيع البرنامج الثابت الخاص بـ PSP، بحيث ستقوم البطاقة بتحميل برنامج ثابت IP غير موقّع (SMU، SDMA، MEC، IMU، RLC) كانت سترفضه لولا ذلك. فكّر في إدارة طاقة مخصّصة، أو حدود ترددات، أو أي شيء آخر يعيش في برنامج ثابت يوقّعه المورّد وأنت لا تملك توقيعه.

لا يتم وميض أي شيء. يعيش التصحيح في ذاكرة PSP ويُطبَّق أثناء إقلاع دافئ؛ دورة طاقة باردة تمحوه وتعود البطاقة إلى حالتها الأصلية. ذلك الإقلاع الدافئ هو "Wake and Break": تستيقظ البطاقة، ونقنعها بأن تصبح منتشية جدًا على الفور ونُجبرها على تعطيل فحوصات التوقيع. :-)

تم اختباره على بطاقة RX 7900 XTX. راجع الحالة.

ما الذي تحصل عليه

python3 wakebreak.py 25=/path/to/firmware.bin

هذا يزرع التصحيح، ويُقلع البطاقة إقلاعًا دافئًا، ويُرسل صورتك كنوع برنامج ثابت 25. إذا طبعت accepted، فإن PSP قبل صورة كان سيرفضها عادةً.

هل تحتاج إلى شيء لتجربته؟ يسرد ipfw_images.py البرنامج الثابت الذي يُحمّله برنامج التشغيل لديك فعليًا ويكتب زوجًا اختباريًا — صورة أصلية ونسخة مع قلب بت واحد في توقيعها، بحيث يكون البرنامج الثابت نفسه متطابقًا بايتًا ببايت:

python3 ipfw_images.py             # what does this card load?
python3 ipfw_images.py 25          # -> /tmp/fw_25_{ok,bad}.bin
python3 wakebreak.py 25=/tmp/fw_25_bad.bin

يرفض البرنامج الثابت الأصلي fw_25_bad.bin. مع تفعيل التصحيح يتم قبوله. هذا هو العرض بأكمله.

الإعداد

python3 -m venv venv
venv/bin/pip install -r requirements.txt
make verify          # are the shipped artifacts intact?
make selftest        # offline sanity checks, no card touched

تحتاج إلى مضيف Linux مع بطاقة يمكن الوصول إليها عبر برنامج تشغيل AMD الخاص بـ tinygrad (عبر PCIe أو جسر USB الخاص به). راجع requirements.txt للحصول على تصحيح tinygrad واحد يحتاجه مضيفك.

أي بطاقة لديك؟

هناك أربعة إصدارات معروفة من برنامج navi31 الثابت، ويجب أن يتطابق التصحيح معها. الملف التعريفي a هو الافتراضي ويغطي الإصدار الأكثر شيوعًا. إذا كانت لديك نسخة من ذاكرة SPI flash الخاصة ببطاقتك، فسيخبرك identify.py:

python3 identify.py FLASH.bin
# -> sos-build c: wakebreak.py --sos-build c

وإلا فجرّبها فقط. التخمين الخاطئ غير ضار: يتحقق التصحيح مما ينوي تعديله، ويجد شيئًا لا يتعرف عليه، فلا يكتب شيئًا، وتُقلع البطاقة بشكل طبيعي.

python3 wakebreak.py --sos-build c 25=/tmp/fw_25_bad.bin

الحالة

مؤكَّد على البطاقة المُختبَرة (RX 7900 XTX، الملف التعريفي a):

برنامج ثابت معدَّل، بطاقة أصلية	مرفوض
برنامج ثابت معدَّل، مُرقَّع	مقبول
بعد دورة طاقة باردة	مرفوض مجددًا — البطاقة أصلية

ملاحظة: الملفات التعريفية b وc وd مبنية ومفحوصة دون اتصال لكنها لم تُشغَّل على العتاد قط. إذا كانت لديك بطاقة تطابق الملف التعريفي b أو c أو d فيُرجى إبلاغنا إن كانت تعمل!

إعادة البناء

الترقيع نفسه عبارة عن بضع مئات من البايتات من تجميع ARM، في hook/*.S. تُشحَن الكتل المبنية مع المستودع، لذا لا تحتاج إلى مترجم تبادلي لاستخدام هذا. وإذا أردت إعادة بناءها على أي حال:

make rebuild                                  # needs arm-none-eabi binutils
make rebuild CROSS=/path/to/arm-none-eabi-

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

ما يوجد هنا

wakebreak.py        the exploit
identify.py       which --sos-build does this card need?
ipfw_images.py    build a signed/tampered firmware pair to test with
selftest.py       offline checks
hook/             the patch: ARM sources and built blobs
firmware/         two stock AMD firmware images the exploit needs to get in

firmware/ يحتوي على صور AMD الأصلية غير المعدّلة والمنشورة علنًا. إنها إصدارات قديمة، أُبقيت لأن طريقة الوصول تمر عبرها.

كيف يعمل

غير مشروح هنا عن قصد: اقرأ الكود. wakebreak.py يبلغ ~600 سطر معلّق، والتعليقات تشرح الآلية وفحوصات الأمان وسبب ترتيب كل خطوة بالطريقة التي هي عليها. باختصار: يُحمَّل تطبيقان موثوقان من AMD الأصليين، ويُقنَع أحدهما بتشغيل سلسلة قادرة على كتابة ذاكرة PSP، ويُوضع التصحيح في النسخة المقيمة في الـ bootloader، ثم يُعاد تشغيل البطاقة تشغيلًا دافئًا لتحميله.

الترخيص

MIT، انظر LICENSE. افعل به ما تشاء.

إخلاء المسؤولية

استُخدمت مساعدة مكثفة من نماذج اللغة الكبيرة (LLM) في إنتاج هذا العمل. هذا لا يعني أن المؤلف لا يملك أي فكرة عمّا يجري فعليًا هنا. قدر كبير من المقاومة والعمل اليدوي كان مطلوبًا للوصول إلى هذه النقطة. قد لا تعجبك مخرجات بايثون الركيكة أو أيًا كان، لكنك لن تتمكن من مجادلة حقيقة أن بطاقة Navi31 لديك الآن فجأة تحمّل كتل مكوّنات firmware غير موقّعة. شكرًا لاهتمامكم.