من لوحة PCB عارية إلى صلاحيات الجذر: اختراق عتاد ZyXEL P-870HN عبر UART

صورتان من الهاتف للوحة راوتر بلا ملصقات → وحدة تحكم تسلسلية → تجاوز مصادقة → شل جذر — إعادة إنتاج السلسلة الحقيقية غير المُصححة حتى الآن CVE-2025-0890 (حساب supervisor مخفي) + CVE-2024-40891 (حقن أوامر CLI) على أجهزة أمتلكها.

بقلم damik0 · 2026-08-13 · دليل عملي خطوة بخطوة لاختراق الأجهزة

  📷 PCB photos ─▶ 🔬 chip recon ─▶ 🏷️  model ID ─▶ 📍 find UART (J2)
       └─▶ 🔌 serial console ─▶ 🚪 hidden account ─▶ ⛓️  break out of CLI
              └─▶ 🐚 root shell ─▶ 🔓 dump + crack every credential

خلاصة سريعة

كانت لدي لوحة راوتر عشوائية على مكتبي. بدون غلاف، بدون ملصق، وبدون أي فكرة عن ماهيتها. بدءًا من لا شيء سوى صورتين لها، قرأت كل شريحة على اللوحة PCB، وحددت الطراز الدقيق، وعثرت على موصل المنفذ التسلسلي (UART)، واتصلت به، ودخلت عبر حساب باب خلفي مصنعي، وخرجت من قائمة بائع مقفلة إلى شل لينكس بصلاحيات جذر، وسحبت كل كلمات المرور من الجهاز — تم كسرها في أقل من ثانية.

لا شيء من هذه الثغرات من اكتشافي. إنها مشاكل ZyXEL موثقة قال البائع إنه لن يصححها. ما يدور حوله هذا المستودع هو الكيفية، من البداية إلى النهاية، والمنطق في كل خطوة.

أولاً وقبل كل شيء: هذا جهاز خاص بي

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

ما الذي كنت أفتش فيه

استخرجت المعرّف من رقم اللوحة المطبوع بالشاشة الحريرية 45-402-000022 والباركود، مع مطابقة مرجعية مع TechInfoDepot وجدول أجهزة OpenWrt ومعرّف FCC I88P870HN51B:

لماذا رقم اللوحة هو المفتاح الذي يفتح كل شيء: بوابات ODM مثل هذه هي تصاميم مرجعية. بمجرد أن يطابق رقم الجزء المطبوع بالشاشة الحريرية لوحة موثقة، فإنك ترث عمل شخص آخر — شريحة الفلاش الدقيقة، موقع UART وترتيب أطرافه، الحسابات الافتراضية. التحديد ليس مجرد إجراء شكلي؛ إنه ما يحوّل الاستطلاع الأعمى إلى هجوم موجّه.

كيف تم ذلك

الخطوة 0 — نقل الصور من هاتفي

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

الخطوة 1 — قراءة اللوحة

فحصت كل شريحة من الصور عالية الدقة. أنواع العبوات تحكي القصة قبل أن تقرأ العلامات حتى: BGA في المنتصف هو العقل، وTSOP-48 دائمًا ما يكون فلاشًا متوازيًا تقريبًا، والعلبة الصغيرة بذيل كابل متحد المحور هي الراديو. كان المعالج مختبئًا تحت درع RF (موجود لأسباب تتعلق بالتداخل الكهرومغناطيسي EMI + كناشر للحرارة)، لذا فتحت العلبة لقراءة العلامة تحتها — Broadcom BCM6368.

اللوحة، مرسومة: (1) معالج BCM6368، (2) ذاكرة DDR2 RAM، (3) WiFi BCM43222، (4) محول خط DSL، (5) مغناطيسيات الإيثرنت، (6) موصلات USB داخلية، (7)(8) علامات اللوحة، (9) موصل وحدة التحكم J2، (10) بصمة لحام JTAG غير محشوة.

الخطوة 2 — إطلاق اسم عليها

طابق رقم طباعة الشاشة الحريرية 45-402-000022 اللوحة الموثقة تمامًا، وكل شريحة — المعالج SoC والفلاش وWiFi وذاكرة الـ 64 ميجابايت — تطابقت قطعة بقطعة مع النسخة -53b. الآن لم أعد أعرف فقط ما هي؛ بل عرفت أين يقع UART الخاص بها وما الحساب الذي سيسمح لي بالدخول.

الخطوة 3 — البحث عن UART

بجوار المعالج SoC تمامًا كان هناك موصل بزاوية قائمة ذو 6 دبابيس مثبَّت، مطبوع عليه بالشاشة الحريرية J2، مع مثلث يشير إلى الدبوس 1. تم التأكيد بالرجوع إلى صفحة OpenWrt لهذا الطراز:

115200 8N1، 3.3V TTL.

كيف تجد UART عندما لا يوجد wiki يخبرك بترتيب الأطراف — الجزء الذي يُظهر أن هذا ليس مجرد اتباع وصفة:

• GND — استمرارية (صفير) مع مستوى الأرضي / الدرع، واللوحة بدون طاقة.
• VCC — خط طاقة يستقر عند ~3.3 V ثابت بعد التشغيل.
• TX — يستقر على المستوى العالي عند ~3.3 V (حالة mark في UART) وينخفض/يومض بشكل مرئي وواضح لحظة إقلاع الجهاز وبدء بث سجله. هذا الوميض هو وحدة التحكم وهي تتحدث.
• RX — عادةً هو الهادئ: عائم أو مسحوب بشكل ضعيف، بدون أي نشاط إقلاع.

وإذا لم تكن تعرف معدل الباود؟ 115200 هو الإعداد الافتراضي في Broadcom CFE، لكن بدون معلومات مسبقة ستجرّب المعدلات الشائعة (9600 → 115200) حتى تتحول البيانات العشوائية إلى ASCII، أو تقيس أقصر فترة بت على راسم الإشارة وتحسب 1 / t.

الخطوة 4 — الحصول على وحدة تحكم

وصّلت محول USB-TTL (HW-597, PL2303) مع ضبط العبور (jumper) على 3.3V. هذا الأمر مهم: UART الخاص بـ BCM6368 هو 3.3 V TTL، وليس RS-232 (±12 فولت) — إذا وصّلت منفذًا تسلسليًا حقيقيًا أو محول 5V به فسوف تحرق الدبوس. الأرضي GND أولاً، ثم عبور RX/TX، مع ترك VCC عائمًا حتى لا يغذي أي شيء اللوحة بالطاقة بشكل عكسي. قبل تشغيل الطاقة تأكدت من GND وVCC بمقياس متعدد، ثم:

screen /dev/ttyUSB0 115200

شغّلته، وراقبت CFE وهو يسلم المهمة إلى النواة، وراقبت BusyBox init وهو يقلع، ووصلت إلى موجه تسجيل الدخول.

الخطوة 5 — الباب الأمامي كان مفتوحًا على مصراعيه · CVE-2025-0890

استسلم موجه تسجيل الدخول إلى حساب مصنعي مخفي لا توثقه ZyXEL أبدًا للمستخدم النهائي:

user:     supervisor
pass:     zyad1234

صلاحيات نظام كاملة. هذا هو جوهر CVE-2025-0890.

الخطوة 6 — كسر قفص البائع · CVE-2024-40891

ذلك التسجيل أوصلني إلى CLI بائع مقفلة بإحكام (consoled، موجه >): لا يوجد sh، ولا أي من أدوات Linux المعتادة — سجن ملفوف حول النظام الحقيقي. لكنها كانت تعرض أداة تشخيص ping، وكانت تلك الأداة تبني وسيطها مباشرةً في سلسلة أوامر شل مع صفر تنقية. لذا أطعمتها حرفًا واصلاً (metacharacter) لأوامر الشل:

> ping 127.0.0.1; sh

…وسقطت في شل BusyBox بصلاحيات جذر (#).

لماذا تكفي فاصلة منقوطة واحدة: معالج CLI يقوم بما يعادل system("ping " + userinput). الفاصلة المنقوطة ; تُنهي أمر ping وتبدأ أمرًا ثانيًا — sh — الذي يرث stdin/stdout الخاص بوحدة التحكم، فتحصل على شل تفاعلي. كان الحساب بالفعل uid 0؛ كان CLI هو الشيء الوحيد الذي يفصل بيني وبين شل حقيقي، والمدخلات غير المنقاة هدمت ذلك الجدار. ربط حقن CLI مُصادَق عليه بالحساب المخفي هو بالضبط النمط المتتبع باسم CVE-2024-40891.

الخطوة 7 — التقاط الغنيمة

بصلاحيات الجذر، نظرت إلى النظام والفلاش:

# cat /proc/version
Linux version 2.6.30 ... (Buildroot 2010.02) #1 Mon Jun 11 2012

# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 004f5000 004f5000 "Physically mapped flash"     # 5,197,824 bytes = the whole firmware

ما يخبرك به /proc/mtd: الفلاش هو NOR متوازٍ مُعنون في الذاكرة — تراه وحدة المعالجة المركزية كنطاق عناوين مسطح (حتى حوالي 0xB8000000 في MIPS KSEG1)، مكشوفًا كقسم MTD واحد. هذه أخبار ممتازة لعملية التفريغ: قراءته تعود نظيفة، بدون أي من البايتات الاحتياطية/OOB وغرابة ECC التي تصارعها في NAND. /dev/mtdblock0 هو صورة البرنامج الثابت.

ثم كلمات المرور. لا يوجد /etc/shadow — التجزئات موجودة مباشرة في /etc/passwd، باستخدام تشفير DES crypt القديم:

supervisor:SuO7vycdWI/rU:0:0:Administrator:/:/bin/sh
support:xoKf506EVkGKw:1:0:Technical Support:/:/bin/sh
user:QWOftoXez8Goo:2:0:Normal User:/:/bin/sh
admin:OJGXQ9dWyb9m2:100:0:Administrator:/:/bin/sh

سحبتها وكسرتها دون اتصال باستخدام John the Ripper (--format=descrypt). سقطت الستة جميعًا في أقل من ثانية:

لماذا تتلاشى هذه فورًا: DES crypt(3) استخدم دائمًا أول 8 أحرف فقط من كلمة المرور وملحًا بطول 12-بت (12-bit salt)، عبر 25 جولة من DES. على معالج حديث، أداة كسر DES بتقنية bitslice تلتهم عشرات الملايين من المرشحين في الثانية — لذا كلمات المرور المصنعية التافهة مثل admin أو support لا تُحتسب حتى كعمل يُذكر. هذا المخطط عفا عليه الزمن منذ عقود؛ العثور عليه في برنامج ثابت يُشحن فعليًا هو الاكتشاف الحقيقي.

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

ما هو معطل بالفعل

السلسلة كاملة، في سطر واحد:

PCB photo → ID the SoC → find the UART (J2) → serial console
   → hidden account (F-1) → locked CLI → command injection (F-2)
   → root shell → dump + crack every credential (F-3)

"ثغرة 0-day رائعة يا صاح" — كلا، وهذه هي النقطة

لم أكتشف أيًا من هذا. إنه إعادة إنتاج، عبر وصول فيزيائي، لثغرات عامة وذات صلة حاليًا:

• CVE-2025-0890 — بيانات اعتماد ضعيفة/مخفية، تتضمن صراحةً supervisor:zyad1234، على أجهزة ZyXEL القديمة من فئة DSL CPE. → F-1
• CVE-2024-40891 — حقن أوامر CLI مُصادَق عليه؛ أوامر تُمرَّر دون فحص إلى شل؛ استُغلت متسلسلة مع CVE-2025-0890. → F-2
• سلالة حقن ping الأقدم في ZyXEL: CVE-2015-6018، CVE-2017-6884. → F-2

تصيب هذه أجهزة نهاية العمر التي أعلنت ZyXEL أنها لن تصلحها، وقد شوهد استغلالها في البرية — وهو بالضبط سبب أهمية التطبيق العملي المباشر لهذه الآليات. القيمة هنا ليست ثغرة جديدة؛ إنها سير العمل الكامل من السيليكون إلى الشل، منفذًا وموثقًا.

كيف يمكنك إصلاح هذا فعليًا

• اقضِ على الحسابات المكتوبة بشكل ثابت (hardcoded). بيانات اعتماد فريدة لكل جهاز، وتغيير إجباري عند أول إقلاع.
• نقِّ كل مدخلات التشخيص — اعتمد قائمة سماح للأحرف، ولا تضمّن أبدًا مدخلات المستخدم في أمر شل (استخدم execve مع متجه وسائط، وليس system()).
• انقل تخزين كلمات المرور إلى /etc/shadow مع تجزئة حديثة (bcrypt / SHA-512-crypt)، وليس DES.
• بالنسبة للأجهزة التي بلغت نهاية العمر ولن يصلحها البائع: استبدلها.

أعمال غير مكتملة

• نفّذ تفريغًا للبرنامج الثابت من mtd0 (/dev/mtdblock0، 5,197,824 بايت) عبر شبكة WiFi الخاصة بالراوتر نفسه + nc، ثم فك التعبئة باستخدام binwalk (توقع رأس CFE + نواة مضغوطة بـ LZMA + نظام ملفات جذر SquashFS + nvram). الطريقة الكاملة في evidence/dump-methods.md.
• نقّب في nvram/الإعدادات عن أسرار مزود خدمة الإنترنت (PPPoE، WiFi PSK، رابط TR-069 ACS، VoIP).

العتاد الذي استخدمته

تحليل PCB من الصور (ImageMagick)، ومقياس متعدد، ومحول USB-TTL PL2303 (HW-597) عند 3.3V، وscreen لوحدة التحكم التسلسلية (115200 8N1)، وJohn the Ripper (descrypt) للتجزئات. تم التحديد عبر OpenWrt وTechInfoDepot وقاعدة بيانات FCC.

المصادر والمراجع

تحديد الجهاز

• TechInfoDepot — ZyXEL P-870HN-51b (رقم اللوحة 45-402-000022، الفلاش MX29LV640EBTI-70G)
• TechInfoDepot — ZyXEL P-870HN-53b (نسخة 64 ميجابايت RAM)
• OpenWrt — ZyXEL P-870HN-5xb (صفحة الجهاز + ترتيب أطراف المنفذ التسلسلي)
• معرّف FCC I88P870HN51B

الثغرات

• CVE-2025-0890 — حساب supervisor المخفي
• CVE-2024-40891 — حقن أوامر CLI مُصادَق عليه · سياق التقرير
• CVE-2015-6018 · CVE-2017-6884 — حقن أوامر ping الأقدم في ZyXEL

الأجهزة والتقنية

• ورقة بيانات Macronix MX29LV640E (PDF)
• OpenWrt — مرجع وحدة التحكم التسلسلية
• River Loop Security — الحصول على شل جذر عبر UART
• Secure Ideas — إيجاد ترتيب أطراف UART على لوحات PCB
• SparkFun — دليل توصيل CP2102 من USB إلى تسلسلي

الأدوات

• John the Ripper · binwalk

مرة أخرى، للتوثيق

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