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

### 2.2 بنية المودم

يظهر تحليل الثنائي المستخرج أن معالج المودم يعمل بنظام MIPS32 مع تعليمات مضغوطة MIPS16e2 في وضع endian الصغير. MIPS16e2 هو امتداد ترميز 16 بت لتقليل حجم الكود المضمن — بما يتوافق مع نهج MediaTek للنطاقات الأساسية من جيل Helio، وقد أكدته الأبحاث المنشورة المستقلة حول النطاق الأساسي لهذه العائلة من SoC.

نظام التشغيل هو Nucleus RTOS، الذي يوفر جدولة المهام، وقوائم انتظار الرسائل IPC، وموزع ذاكرة قائم على التجمع. لا يوجد فصل امتيازات بين النواة والمستخدم، ولا تطبيق لوحدة حماية الذاكرة بين المهام، ولا آلية حماية مكدس الأجهزة.

جميع العناوين في هذا المنشور هي عناوين افتراضية، كما تم تحميلها في Ghidra عند القاعدة `0x90000000`.

### 2.3 الإجراءات التخفيفية (الملاحظة في البنية التي تم تحليلها)

| الإجراء التخفيفي | الحالة | التأثير |
|---|---|---|
| ASLR | غائب | عناوين البرامج الثابتة ثابتة ويمكن التنبؤ بها من الصورة |
| حارس المكدس | غائب | `SAVE`/`RESTORE` يخزن السجلات المحفوظة للمستدعي بدون قيمة حارس |
| NX / W^X | غائب | ذاكرة المكدس قابلة للتنفيذ |
| CFI | غائب | عناوين العودة غير موثقة مقابل أي سياسة |

### 2.4 نهج التحليل

ثلاثة مسارات متوازية:

**التحليل الثابت.** حزمة البرامج الثابتة لـ Samsung → استخراج قسم CP → `md1img.img` → Ghidra (MIPS LE 32-bit، القاعدة `0x90000000`) مع رموز هندسة MediaTek المستعادة من قسم تصحيح البرامج الثابتة باستخدام مجموعة أدوات NCC Group `mtk_bp`.

**التحقق الديناميكي.** تم استخدام Unicorn Engine (محاكاة MIPS32) لتنفيذ إجراءات محددة للبرامج الثابتة بشكل منفصل عبر مرحلتين. حاولت المرحلة 1 إثبات النسخ غير المقيد لـ `si_count` إلى سياق القناة من خلال زوج التعليمات الأصلي. نفذت المرحلة 2 الحلقة الضعيفة على بايتات البرامج الثابتة الحقيقية وأكدت أن تعليمات البرامج الثابتة الخاصة بها تفسد عنوان العودة المحفوظ. حيث لم تتمكن المرحلة 1 من العمل بشكل أصلي بالكامل — لأن بيئة كائن الخدمة لنظام RTOS المطلوبة بواسطة مسار إرسال CPHY لم يتم إعادة بنائها — تم نمذجة التأثير الجانبي مباشرة وتم تصنيفه على هذا النحو في جميع المخرجات.

**التحقق من الجانب الراديوي.** قام srsRAN 4G مع حلقة ZMQ — برمجيات فقط، بدون انبعاث ترددات راديوية — بتأكيد أن حمولة الاختبار تنجو من تشفير NB-IoT PHY وتسليم كتلة النقل.

---

## 3. سطح الهجوم: NB-IoT وSIB1-NB

### 3.1 سطح الهجوم قبل الارتباط

NB-IoT (إنترنت الأشياء ضيق النطاق) هو إصدار 3GPP 13، مصمم لتوصيل أجهزة إنترنت الأشياء المحدودة باستخدام طيف LTE المرخص الحالي. يتم تنفيذه في مجموعة واسعة من أنظمة SoC الخلوية الحديثة بما في ذلك تلك الموجودة في الهواتف الذكية الاستهلاكية.

أثناء وجوده في RRC_IDLE، قبل إنشاء أي اتصال RRC، فإن الجهاز الذي يبحث عن خدمة سيقوم بما يلي:

1. المزامنة مع إشارات توقيت الخلية (NPSS/NSSS)
2. فك تشفير كتلة المعلومات الرئيسية عبر NPBCH (نافذة إرسال 640 مللي ثانية)
3. فك تشفير SIB1-NB من NPDSCH (جدول 2560 مللي ثانية)
4. استخدام معلومات الجدولة في SIB1-NB لتحديد موقع كتل معلومات النظام الإضافية

في الخطوة 3، يقوم المودم بمعالجة رسالة من كيان لم يصادق عليه، قبل أي اتصال أو تفاعل للمستخدم. سيتم معالجة جهاز إرسال مارق يحقق شروط اختيار الخلية العادية.```
+------------------+                   +---------------------+
|  Rogue Base Stn  |                   |  Target UE (Modem)  |
+--------+---------+                   +----------+----------+
         |                                        |
         |   NPSS/NSSS sync                      |
         |--------------------------------------->|
         |   MIB-NB (640 ms cycle)                |
         |--------------------------------------->|
         |   SIB1-NB (malformed, si_count > 8)    |
         |--------------------------------------->|   ← vulnerability triggered
         |   [no RRC connection established]      |

تم فك ضغط قسم التصحيح CATI وتحليله باستخدام `mtk_dbg_extract.py symbols`، ثم استيراده إلى Ghidra عبر `ImportSymbolsScript.py`. وكانت النتيجة هي أسماء الدوال الداخلية الكاملة عبر مجموعة مودم الراديو — طبقة ERRC، إدارة قناة L1، النظام الفرعي IPC، وسلسلة معالج BCCH الخاص بـ NB-IoT — مما سمح بإعادة بناء السلسلة بناءً على الدلالات.

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

---

## 5. الثغرة

### 5.1 الحلقة الضعيفة

`el1_ch_nbcch_resume_req` (`0x90213940`) تعالج حدث استئناف قناة البث الخاصة بـ NB-IoT. مقدمتها الوظيفية بلغة MIPS16e2:```asm
90213940:  save  0xE8, ra, s0-s1

من تفكيك Ghidra للبرنامج الثنائي الفعلي للبرنامج الثابت:```c
for (uVar6 = 0; uVar6 < (byte)param_2[0x40a]; uVar6 = uVar6 + 1) {
    si_type_arr[uVar6]  = /* SI type byte */;          // 1 byte/iter, base new_sp+0x78
    si_sched_arr[uVar6] = /* SI schedule halfword */;  // 2 bytes/iter, base new_sp+0x98
}

يبدأ Stream B (يكتب البايت `sb`) عند `new_sp+0x78` وسيحتاج إلى التكرار 108 للوصول إلى فتحة RA:```
new_sp + 0x78 + i = new_sp + 0xE4
i = 0xE4 - 0x78 = 108

### 5.4 باني ERRC — الطبقة A

يتم بناء مخزن CPHY_CFG_REQ المؤقت في طبقة ERRC من SIB1-NB المفكوك. الدالة
`errc_chm_l1_set_bcch_si_reception` تكتب `IPC_msg[+0x99]`:```c
// errc_chm_l1_set_bcch_si_reception — Layer A
// Loop bound: decoded schedulingInfoList entry count from SIB1-NB

while (bVar3 < *(byte *)(param_3 + 0x44) && (param_2 != 0)) {
    bVar3++;
    if (uVar2 != param_2) {
        *param_5 = *param_5 + 1;   // CPHY_CFG_REQ[+0x99]++ — no upper bound check
    }
}

### 5.6 غياب التثبيت ثلاثي الطبقات

| الطبقة | الوظيفة | العنوان | هل يوجد تثبيت؟ |
|---|---|---|---|
| A — منشئ ERRC | `errc_chm_l1_set_bcch_si_reception` | نطاق ERRC | **لا يوجد** |
| B — نسخة L1 | `el1_ch_nbcch_start` | `0x90213444` | **لا يوجد** |
| C — حلقة L1 | `el1_ch_nbcch_resume_req` | `0x90213940` | **لا يوجد** |

أي فحص واحد في أي طبقة كان سيكسر السلسلة.

### 5.7 السبب الجذري

ثابت واحد تم انتهاكه:

> يجب ألا يتجاوز عدد إدخالات جدولة SI أبدًا سعة المصفوفة الوجهة.

يوفر 3GPP حد البروتوكول المقصود (8 إدخالات). كان على البرنامج الثابت (firmware) فرض حد أمان الذاكرة في كل طبقة حيث يصبح العداد فهرسًا أو حد حلقة. في البناء الضعيف، انتقل العداد من حقل البث SIB1-NB عبر مفكك ERRC، إلى رسالة CPHY_CFG_REQ، عبر حدود IPC إلى مهمة L1، إلى سياق القناة BSS، وإلى حلقة كتابة المكدس — دون أي طبقة تثبته.

---

## 6. سلسلة الاستدعاء — كيف تم اكتشافها

### 6.1 الارتباك ذو المسارين

يمكن لمسارين متشابهين هيكليًا ولكن متميزين توصيل مخزن تكوين بحجم 0x760 بايت إلى `el1_ch_nbcch_main`:

| المسار | المصدر | قيمة `[+0x99]` | الصلة |
|---|---|---|---|
| المسار أ (ERRC ← L1 IPC) | يبني ERRC CPHY_CFG_REQ من SIB1-NB المفكوك | `schedulingInfoList.count` من OTA | **المسار الضعيف** |
| المسار ب (داخلي L1) | `el1_ch_scs_ind_send` يبني جسم IPC داخلي | قيمة ثابتة `1` | غير ضعيف |

أكد المسار ب تنسيق الرسالة — البايت `+0x99` هو عدد SI الذي تستهلكه `el1_ch_nbcch_start`. نظرًا لأن عدده دائمًا ثابت بقيمة 1، فلا يمكنه التجاوز. المسار المتأثر خارجيًا هو المسار أ.

### 6.2 البحث عن الكاتب

أنتج البحث عن الأنماط في البرنامج الثابت عن أي تعليمة تكتب إلى الإزاحة `+0x99` ضوضاء:
T1 (مباشر `sb`، ~100 نتيجة)، T2 (قاعدة مقسمة، 5 نتائج)، T3 (إزاحة محسوبة، 0)، T4
(متداخلة `sh`/`sw`، ~465). كانت وظائف إدارة قناة ERRC غائبة عن قائمة المراجع المتقاطعة
`msg_send6` لأن ERRC يستخدم `errc_com_send_msg`. أكد مسبار المحاكاة أن الكتابة كانت من جانب
ERRC: تشغيل أداة Unicorn من موزع L1 ومراقبة عمليات الكتابة إلى إزاحة `+0x99` من المخزن لم يلتقط
شيئًا من جانب L1.```
[RUN] dispatcher=0x90214418  watching IPC_msg+0x99

NO writes to IPC_msg+0x99 caught from dispatcher.
Write happened before el1_ch_nbcch_main — confirmed ERRC-side.

## 7. التحقق

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

**تم إثباته بشكل ثابت.** يحتوي ثنائي البرنامج الثابت على زوج التعليمات الضعيف. يتم إعادة بناء سلسلة الاستدعاء من الرموز والمراجع المتقاطعة وهيئات الدوال المفككة.

**تم تنفيذه بشكل أصلي في المحاكاة.** تم تشغيل الحلقة داخل `el1_ch_nbcch_resume_req` على بايتات البرنامج الثابت الحقيقية لـ MediaTek في محرك Unicorn (MIPS32). قامت تعليمة `sh` الخاصة بالبرنامج الثابت عند `0x90213B02` بكتابة الفتحة المحفوظة لعنوان الإرجاع. قامت تعليمة `RESTORE` بتحميل القيمة التالفة إلى `$ra`، وقامت `jrc ra` بنقل التحكم.

**تم تصميمه بشكل صريح.** لم يكن من الممكن تشغيل نسخة `lbu`/`sb` في `el1_ch_nbcch_start` بشكل أصلي بالكامل لأن مسار توزيع جدول استدعاء RTOS داخل `el1_ch_nbcch_cphy_cfg_req_process` توقع كائنات كومة Nucleus الحية التي لم يوفرها المحاكي المسطح. يقرأ معالج الاستئناف (`el1_ch_nbcch_resume_req`) في المرحلة 2 فقط من سياق القناة المقيم في BSS ولا يصادف نفس مسار التوزيع، ولهذا السبب تم تشغيل المرحلة 2 بشكل أصلي دون الحاجة إلى نفس الدعم. تم تصميم التأثير الجانبي للمرحلة 1 — بايت واحد من `IPC_msg[+0x99]` مكتوب إلى `ch_ctx[+0x40A]` — مباشرة وتم تسميته `[PHASE1-MODEL]`.

**غير مُدَّعَم.** نسخ كامل من الأجهزة عبر الهواء من طرف إلى طرف.

### 7.1 مكافحة العبث

فرضت أداة التثبيت قاعدة واحدة: لم يُسمح لأي خطاف بكتابة علامة الإثبات في الفتحة المحفوظة لعنوان الإرجاع. تم تتبع كل كتابة في الذاكرة غير تابعة للبرنامج الثابت.```
[PROOF-W] saved_RA write: pc=0x90213b02  addr=new_sp+0xE4  value=0xbeef
[PROOF-W] saved_RA write: pc=0x90213b02  addr=new_sp+0xE6  value=0xdead
[ANTI-TAMPER] no hook wrote RA=0xDEADBEEF — firmware only
anti_tamper_fail = False

### 7.3 تسليم ZMQ

لتأكيد أن حمولة الاختبار تنجو من تشفير الطبقة المادية (PHY) لـ NB-IoT وتسليم كتلة النقل، تم استخدام srsRAN
4G مع حلقة ارتداد ZMQ (بدون انبعاث ترددات لاسلكية). كانت الحمولة متجهًا غير مطابق عمدًا — تم تخفيف قيد SIZE الخاص بـ ASN.1 على `schedulingInfoList` للسماح بـ 40 إدخالاً، مع فك الترميز الدائري لـ pycrate لتأكيد حقل العدد عند البايت 14.```
SIB1 received
SIB2 activated
exit 0

`ch_ctx[0x40A]` يعيش في BSS ويحتفظ بقيمة المهاجم حتى يتم إعادة تعيين المودم أو تكوين قناة لاحق يستبدلها.

### 8.2 إطار المكدس```
old_sp  (= new_sp + 0xE8)
new_sp + 0xE4   saved ra
new_sp + 0xE0   saved s1
new_sp + 0xDC   saved s0
new_sp + 0x98   si_sched_arr  [34 halfwords = 68 bytes]
new_sp + 0x78   si_type_arr   [32 bytes]

سوف يظهر فحص الحدود ذو السطر الواحد كبضعة تعليمات مضافة داخل دالة موجودة عند نفس العنوان. ما تظهره النسخة الثنائية المصححة هو مراجعة معمارية: تم إعادة تصميم مسار جدولة NBCCH بحيث لم يعد نمط `si_count`-كحد للحلقة موجودًا في أي مكان في المسار.

### 10.4 إسناد CVE

تتطابق الثغرة الموصوفة هنا مع CVE-2024-20154 كما نشرتها MediaTek في 6 يناير 2025. أساس التأكيد:

- عائلة البرامج الثابتة المتأثرة (LR12A) تتطابق مع نشرة MediaTek.
- فئة الثغرة — تجاوز سعة المكدس، عدم وجود فحص الحدود، تنفيذ التعليمات البرمجية عن بعد من محطة قاعدة خبيثة، بدون تفاعل المستخدم — تتطابق مع وصف CVE وسجل NVD.
- البرنامج الثابت المصحح يزيل بالضبط بنيات التعليمات البرمجية التي تم تحديدها على أنها ضعيفة.
- تم تأكيد معرف التصحيح MOLY00720348 من نشرة MediaTek ونشرة أمان Android (A-376809176).
- قام التحليل بمساعدة الذكاء الاصطناعي بشكل مستقل بمطابقة النمط المعاد بناؤه مع CVE-2024-20154 قبل التأكيد اليدوي.

---

## 11. الأخلاقيات والإفصاح المسؤول

### 11.1 ما لا يحتويه هذا المنشور

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

### 11.2 لماذا الحلقة العكسية ZMQ والمحاكاة هما النهج الأخلاقي

يعني الحلقة العكسية ZMQ عدم إرسال أي إشارة عبر الهواء على الإطلاق. لم يتم استهداف أي جهاز حقيقي. لم تشارك أي شبكة ناقل. يعمل الإثبات بالكامل في بيئة برمجية محصورة على أجهزة يملكها المحلل. هذا هو النهج الصحيح للتحقق من ثغرة راديو قبل الارتباط — إرسال بث مشوه سيؤثر على أي جهاز ضمن النطاق.

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

### 11.3 الملكية الفكرية لـ MediaTek

تم إجراء جميع التحليلات على برامج ثابتة تم الحصول عليها بشكل قانوني من جهاز استهلاكي ومن حزم البرامج الثابتة التي أصدرتها Samsung علنًا. لم يتم استخدام أي وثائق مملوكة. يتم وصف تعريفات الهياكل الداخلية لـ MediaTek وتنسيقات رسائل IPC فقط بالقدر اللازم لشرح فشل سلامة الذاكرة. لم يتم نشرها كمواصفات.

---