قاعدة البرمجيات الثابتة (firmware) ليست كود Android. إنها نظام مضمّن منفصل على النظام الفرعي الراديوي في SoC، بمعالج خاص بها، ونظام تشغيل زمن حقيقي (RTOS) خاص بها، ومساحة ذاكرة خاصة بها، خارج صندوق حماية عمليات Android.

### 2.2 معمارية المودم

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

نظام التشغيل هو Nucleus RTOS، الذي يوفر جدولة المهام، وقوائم انتظار رسائل IPC، ومخصّص ذاكرة قائم على التجمعات (pool-based). لا يوجد فصل صلاحيات بين النواة/المستخدم، ولا فرض لوحدة حماية الذاكرة بين المهام، ولا آلية حماية مكدس عتادية.

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

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

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

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

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

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

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

**التحقق من الجانب الراديوي.** srsRAN 4G مع ZMQ loopback — برمجي فقط، دون انبعاث RF — أكد أن حمولة الاختبار تنجو من ترميز 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، وسلسلة
معالج NB-IoT BCCH — مما أتاح إعادة بناء السلسلة الموجهة دلاليًا.

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

---

## 5. الثغرة الأمنية

### 5.1 الحلقة المعرّضة للثغرة

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

من Ghidra decompile للـ firmware binary الفعلي:```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 مدخلات). كان على البرنامج الثابت فرض
حد أمان الذاكرة في كل طبقة يصبح فيها العدد فهرسًا أو حدًا للحلقة. في
البنية المصابة، انتقل العدد من حقل بث SIB1-NB عبر مُفكِّك ترميز ERRC،
إلى رسالة CPHY_CFG_REQ، عبر حدود IPC إلى مهمة L1، إلى سياق قناة BSS،
وإلى حلقة كتابة على المكدس — دون أن تقيّده أي طبقة.

---

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

### 6.1 الالتباس بين المسارين

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

| المسار | المصدر | قيمة `[+0x99]` | الصلة |
|---|---|---|---|
| المسار A (ERRC → L1 IPC) | يبني ERRC رسالة CPHY_CFG_REQ من SIB1-NB المُفكَّك | `schedulingInfoList.count` من OTA | **المسار المصاب** |
| المسار B (داخلي في L1) | يبني `el1_ch_scs_ind_send` جسم IPC داخلي | قيمة ثابتة `1` | غير مصاب |

أكّد المسار B صيغة الرسالة — البايت `+0x99` هو عدد SI الذي تستهلكه
`el1_ch_nbcch_start`. ولأن عدده دائمًا مثبّت على 1، فلا يمكن أن يفيض. أما
المسار المتأثر خارجيًا فهو المسار A.

### 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 Engine (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

لتأكيد أن حزمة الاختبار تنجو من ترميز NB-IoT PHY وتسليم كتلة النقل، تم استخدام srsRAN 4G مع حلقة ZMQ (بدون انبعاث RF). كانت الحزمة عبارة عن متجه غير مطابق بشكل متعمد — تم تخفيف قيد ASN.1 SIZE على `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 لمحاكاة المرحلة 1 الكاملة،
تكوين الراديو عبر الأثير — غائبة عن قصد.

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

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

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

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

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

---