Skip to content
KitploitKITPLOIT
أدواتالمدونة
إرسال
أدواتالمدونة
إرسال

أدوات الاختراق واختبار الاختراق والأمن السيبراني لترسانتك الأمنية!

Kitploit هو دليل لأدوات الاختراق والأمن السيبراني واختبار الاختراق. اكتشف آخر تحديثات المشاريع للعثور على الثغرات وتحليل الأنظمة وأتمتة الاختبارات وتعزيز أمنك.

··الخلاصات·اتصال·الخصوصية·© 2026 Kitploit

دليل الأدوات

الفئات

عرض جميع الفئات
Loading categories
vulns-2026-fatfs-chance — ثغرات أمنية موثقة في مكتبة نظام الملفات المضمنة FatFs مع تفاصيل CVE، وأداة اختبار بالتشويش (fuzzing harness)، ومُولّد صور الأقراص الاستغلالية، وتحليل تأثير سلسلة التوريد عبر عشرات مشاريع البرامج الثابتة (firmware) التابعة. | Kitploit
أدوات/GitHubGitHub/runzeroinc/vulns-2026-fatfs-chance
أمان الأنظمة المدمجةأمان إنترنت الأشياءتحليل الثغرات الأمنيةالاستغلالالاختبار العشوائيأمن الأجهزةتحليل الملفات الثنائيةأمن سلسلة التوريدالأوراق والأبحاث

الأكثر شعبية

عرض الكل →

اكتشف الأدوات الأكثر استخدامًا من قبل مجتمعنا.

استكشف جميع الأدوات

تصفح مجموعتنا من الأدوات

عرض جميع الأدوات →
مشاركة
التعلم والتعليم
تحليل البرامج الثابتة
GitHubrunzeroinc/vulns-2026-fatfs-chance

vulns-2026-fatfs-chance

ثغرات أمنية موثقة في مكتبة نظام الملفات المضمنة FatFs مع تفاصيل CVE، وأداة اختبار بالتشويش (fuzzing harness)، ومُولّد صور الأقراص الاستغلالية، وتحليل تأثير سلسلة التوريد عبر عشرات مشاريع البرامج الثابتة (firmware) التابعة.

عرض المستودع
41941منذ شهر واحدتمت المراجعة من قبل Kitploit

أبحاث الثغرات في FatFs ELM

يُوثّق هذا المستودع ست ثغرات أمنية مؤكدة في FatFs بالإضافة إلى بيئة اختبار، ومُدقِّق (fuzzer)، ومُولِّد صور أقراص استغلال قائم بذاته.

يمكن العثور على الكود المصدري الأصلي لـ FatFs في دليل FatFs-R0.16.

هذا المشروع هو عودة إلى تقييم أمني من عام 2017، عندما حدد التدقيق اليدوي وجهود المُدقِّق التي استمرت لعدة أيام بعض الأخطاء الأساسية، ولكن غير المثيرة للاهتمام، في مُشغّل FatFs. بعد تسع سنوات، في مارس 2026، عدنا إلى هذا المشروع باستخدام Visual Studio Code، وGitHub Copilot في وضع "auto"، وبعض المطالبات الأساسية، دون أي حلقات أو أدوات تسخير أو مهارات محددة. كانت النتائج مفاجئة - حيث أصبحت الأخطاء التي تم التغاضي عنها أثناء التدقيق اليدوي تافهة للعثور عليها، باستخدام LLM لبناء مُدقِّق تلقائيًا بمدخلات جديدة. لم يجد هذا الجهد أخطاء مثيرة للاهتمام فحسب، بل أتمت أيضًا عملية التحقق من قابلية الاستغلال عبر سيناريوهات التطوير المضمنة المختلفة.

يرجى الاطلاع على الملفات التالية للحصول على ملاحظات مفصلة:

  • 00_INITIAL.md: التحقيق والنتائج الأولية
  • 01_PROJECTS.md: تعداد المشاريع ومسح إصدارات FatFs
  • 02_CRITICAL.md: تحليل المشاريع الأعلى تأثيرًا

ما هو FatFs؟

FatFs هي مكتبة أنظمة ملفات FAT/exFAT محمولة وخالية من حقوق الملكية مكتوبة بلغة C بواسطة ChaN (elm-chan.org). وهي مصممة للأنظمة المضمنة محدودة الموارد دون الاعتماد على نظام تشغيل، وعادةً ما تُجمَّع مباشرةً في البرامج الثابتة. وهي تدعم FAT12 وFAT16 وFAT32 وexFAT، بالإضافة إلى دعم اختياري لـ LFN (أسماء الملفات الطويلة) وقسم GPT.

نظرًا لأن FatFs صغيرة ومكتفية ذاتيًا ومرخصة بشكل متساهل، فقد أصبحت المعيار الفعلي لتطبيق FAT في البرامج الثابتة للمتحكمات الدقيقة. يتم دمج المكتبة حرفيًا في حزم SDK الرسمية وأنظمة RTOS ومُحملات الإقلاع وأطر التطبيقات - مما يعني أن أي ثغرة أمنية في المنبع تنتشر إلى كل مشروع في المصب قام بنسخ ff.c.

المشاريع الرئيسية

تم تأكيد أن المشاريع التالية تحتوي على إصدار ضعيف من FatFs. راجع 02_CRITICAL.md للحصول على التحليل الكامل ومسارات الانتشار لكل مشروع ومعلومات الاتصال الأمنية.

ملخص CVE

قيمة المُهاجم

ليس لدى FatFs سجل لـ CVE، ولا قائمة بريدية أمنية، ولا آلية إشعار بالتصحيحات. يجب على كل مشروع في المصب يُورِّد ff.c أن يكتشف هذه الثغرات ويُصنِّفها ويُصحِّحها بشكل مستقل، وغالبًا دون معرفة أنه متأثر. هذا يعني أن الفترة بين الإفصاح العام والإصلاح الواسع النطاق ستُقاس بالسنوات، وليس بالأيام. وبالتالي فإن سطح الهجوم العملي ليس تطبيقًا أو خدمة برمجية واحدة، بل عشرات الملايين من الأجهزة عبر عشرات من قواعد الأكواد المستقلة، والعديد منها لن يتلقى تصحيحًا أبدًا.

سيناريو الاستغلال النموذجي هو بطاقة SD الشريرة: يقوم المهاجم الذي لديه بضع ثوانٍ من الوصول المادي بتبديل وسيلة التخزين في جهاز، من كاميرات المستهلكين إلى الطائرات بدون طيار، إلى الطابعات ثلاثية الأبعاد إلى آلاف من عائلات المنتجات الأخرى. كل ثغرة في هذه المجموعة قابلة للتفعيل عن طريق تحميل صورة FAT مُصمَّمة خصيصًا، وهو ما يحدث تلقائيًا تقريبًا عند الإدخال دون أي تفاعل مطلوب من المستخدم. ومع ذلك، فإن الوصول المادي ليس المسار الوحيد.

الأجهزة التي تستوعب حزم تحديثات بتنسيق FAT من مصدر شبكة مثل أطر التحديث عبر الهواء (OTA) وتحديثات مُحمل الإقلاع بالسحب والإفلات، تكون قابلة للاستغلال من قبل أي مهاجم يمكنه تسليم صورة ضارة إلى خط أنابيب التحديث. اختراقات سلسلة التوريد، أو حقن AitM على تغذية تحديث HTTP بنص واضح، أو صورة ضارة منشورة على بوابة توزيع البرامج الثابتة للهواة. مسار OTA هو مسار عن بعد بالكامل على أي جهاز يفتقر إلى التحقق من سلامة المُصادقة من طرف إلى طرف لحاوية التحديث الخاصة به قبل تحميلها باستخدام FatFs.

قيمة المُهاجم حسب CVE

CVE-2026-6682 - تجاوز عدد صحيح يؤدي إلى طول قراءة يتحكم فيه المهاجم

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

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

CVE-2026-6683 - القسمة على صفر في مزامنة exFAT

يمكن للمهاجم الذي يمكنه تسليم وحدة تخزين exFAT مُصمَّمة إلى جهاز يعمل بإصدار FatFs قبل R0.16 أن يضمن تعطلًا عند أي كتابة لاحقة. أضاف FatFs R0.16 حارسًا جزئيًا في وقت التحميل قد يرفض وحدة التخزين المُصمَّمة قبل حدوث الكتابة، لكن الخلل الحسابي الأساسي لم يتم إصلاحه بالكامل. ضد الأجهزة التي تطبق تحديثات البرامج الثابتة عبر الهواء (OTA) عن طريق الكتابة إلى وسيط بتنسيق FAT، يصبح التشغيل الناجح بمثابة تعطيل عن بُعد لمرة واحدة: تتعطل عملية التحديث في منتصف الكتابة وقد يصبح الجهاز غير قابل للإنعاش دون وصول مادي إلى مصحح أجهزة.

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

CVE-2026-6684 - حلقة لا نهائية في فحص قسم GPT

تؤدي تسليم صورة قرص GPT مع حقل واحد مضبوط على قيمته القصوى إلى قيام الهدف بحلقة قراءة قطاعات القرص حتى يتم إزالة الطاقة. ضد مُحمّلات الإقلاع والبرامج الثابتة ذات المعدن العاري التي تعمل دون مؤقت مراقبة (watchdog)، يكون هذا تعطيلًا دائمًا: الجهاز لا يُكمل التشغيل مرة أخرى. تم إصلاح هذه الثغرة في FatFs R0.16، لذا فهي تؤثر فقط على الأجهزة التي تُورِّد إصدارًا أقدم.

يحتاج المهاجم إلى أن يقوم الهدف بتحميل قرص بتنسيق GPT يتحكم فيه، ويجب أن يعمل الهدف بإصدار FatFs قبل R0.16 مع تمكين دعم LBA 64 بت. لاحظ أن مُحمّلات الإقلاع هي الأهداف الأكثر جاذبية هنا على وجه التحديد لأنها تميل إلى عدم وجود مؤقت مراقبة (watchdog) ولا مسار استرداد.

CVE-2026-6686 - بيانات كتلة قديمة قابلة للقراءة بعد التجاوز بعد نهاية الملف

عندما يتم تمديد ملف عن طريق التجاوز بعد نهايته، لا يقوم FatFs بتصفير التخزين المُخصَّص حديثًا. أي بيانات تمت كتابتها مسبقًا إلى تلك القطاعات بواسطة ملف محذوف تكون قابلة للقراءة بواسطة العملية التالية التي تفتح الملف الممتد. على الأجهزة التي تُدَوِّر صور البرامج الثابتة في منطقة تخزين مؤقتة لـ OTA، أو التي تشارك بطاقة SD بين مُحمّل إقلاع وتطبيق، يمكن أن يؤدي ذلك إلى كشف النقاب عن صور البرامج الثابتة السابقة أو المفاتيح أو أي محتوى حساس لقارئ أقل صلاحية.

يحتاج المهاجم إلى حق الوصول للقراءة إلى ملف على وحدة تخزين FAT للهدف تم تمديده عبر عملية تجاوز. هذا في المقام الأول سيناريو محلي أو وصول مادي.

CVE-2026-6687 - تجاوز سعة المكدس عبر تسمية وحدة تخزين exFAT

يؤدي توفير وحدة تخزين exFAT بتسمية كبيرة جدًا إلى تجاوز FatFs للمخزن المؤقت للتسمية الخاص بالمتصل عندما يستدعي التطبيق f_getlabel(). يُصدر مُولِّد الكود STM32CubeMX الخاص بـ ST حجم المخزن المؤقت الضعيف في كل مشروع يدعم FatFs ينتجه، مما يعني أن هذه الثغرة موجودة في مجموعة هائلة وغير مُفهرسة إلى حد كبير من البرامج الثابتة التجارية لـ STM32. على أجهزة Cortex-M ذات المعدن العاري بدون ملفات تعريف الارتباط الخاصة بالمكدس أو ASLR (الحالة الشائعة) تكون هذه بدائية لتنفيذ التعليمات البرمجية لمرة واحدة.

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

CVE-2026-6688 - تجاوز سعة المخزن المؤقت عبر اسم ملف LFN طويل في قائمة الدليل

من خلال وضع ملف باسم طويل في دليل FAT، يمكن للمهاجم تجاوز المخزن المؤقت الذي يستخدمه تطبيق المتصل لتخزين هذا الاسم عند تكرار الدليل. يكون التجاوز متناسبًا مع طول اسم الملف، حتى 255 بايت. هذه الثغرة موجودة في الكود المتصل، وليس في FatFs نفسه، لذا يختلف التأثير حسب الهدف - ولكن أي تطبيق يُكرِّر دليلًا وينسخ أسماء الملفات في مخزن مؤقت بحجم ثابت دون التحقق من الطول يكون متأثرًا.

يحتاج المهاجم إلى أن يقوم الهدف باجتياز دليل على وحدة تخزين FAT يتحكم فيها. لا يتطلب exFAT؛ هذا يعمل على FAT12 وFAT16 وFAT32. يجب تمكين دعم اسم الملف الطويل (LFN) في تكوين FatFs، وهو الإعداد الافتراضي والموصى به في كل توزيعة رئيسية.

تفاصيل الثغرات

تم تحديد ستة أخطاء مميزة في FatFs R0.16 والإصدارات السابقة.

CVE-2026-6682 - تجاوز عدد صحيح في FAT32 في mount_volume() → finfo.fsize يتحكم فيه المهاجم

الموقع: ff.c mount_volume() - fasize *= fs->n_fats

يحدث تجاوز ضرب DWORD عندما يتم تصميم BPB_FATSz32 لإنتاج قيمة كبيرة. مع BPB_FATSz32 = 0x80000001 وNumFATs = 2:```c fasize = 0x80000001; fasize *= 2; // DWORD overflow → 0x00000002

root@kitploit:~
يؤدي `fasize` المبتور إلى وقوع `fs->database` (بداية منطقة البيانات) داخل منطقة FAT. يمكن للمهاجم الذي يتحكم في صورة القرص وضع إدخال دليل مزيف في القطاع المتداخل، مما يتسبب في إرجاع `f_stat()` لـ `finfo.fsize` يتحكم فيه المهاجم. أي تطبيق يقوم بعد ذلك باستدعاء `f_read(fp, buf, finfo.fsize, &br)` دون تقييد العدد مقابل `sizeof(buf)` يؤدي إلى تجاوز سعة المخزن المؤقت الوجهة ببايتات يتحكم فيها المهاجم بالكامل - وهو مسار مباشر إلى RCE.

**تأثير أسوأ حالة:** تنفيذ التعليمات البرمجية عن بُعد (تجاوز سعة الكومة أو المكدس) على أي جهاز مضمن يقرأ حجم ملف من FatFs ويستخدمه كطول قراءة.

---

### CVE-2026-6683 - القسمة على صفر في `sync_fs()` (exFAT)

**الموقع:** `ff.c` `sync_fs()` - `(n_fatent - 2 - free_clst) * 100 / (n_fatent - 2)`

عندما تكون `BPB_NumClusEx = 0`، فإن `n_fatent = 2`، مما يجعل المقسوم عليه `(n_fatent - 2) = 0`. يتم الوصول إلى ذلك في أي عملية كتابة أو مزامنة على وحدة تخزين exFAT مهيأة، مما ينتج عنه SIGFPE / تعطل صارم ويؤدي إلى تحطيم الهدف.

FatFs R0.16 يحمي جزئياً من هذا في وقت التحميل (يفشل التحقق من صحة مجموعة البتات عندما تكون `NumClusEx = 0`). الإصدارات الأقدم - R0.14b (ArduPilot، Mbed OS)، R0.15 (RIOT OS، STM32)، R0.13c (MicroPython) - لا تحتوي على مثل هذا الحماية وتتعطل دون قيد أو شرط.

**تأثير أسوأ حالة:** رفض الخدمة / تعطل النظام على أي كتابة إلى وحدة تخزين exFAT مهيأة. أثناء تحديث OTA، يمكن أن يؤدي ذلك إلى إتلاف الجهاز بشكل دائم.

---

### CVE-2026-6684 - حلقة مسح أقسام GPT غير المقيدة في `find_volume()` (قبل R0.16)

**الموقع:** `ff.c` `find_volume()` - `for (i = 0; i < n_ent; i++) disk_read()`

عندما تكون `FF_LBA64 = 1`، تقوم `find_volume()` بالتكرار على كل إدخال قسم GPT للبحث عن قسم FAT. في إصدارات ما قبل R0.16، يتم أخذ عدد حلقات التكرار مباشرة من حقل `GPTH_PtNum` الموجود على القرص (0–0xFFFFFFFF) بدون حد أعلى. تتسبب صورة GPT مهيأة تحتوي على `GPTH_PtNum = 0xFFFFFFFF` في حوالي مليار قراءة قرص قبل أن تعيد الدالة "لم يتم العثور"، مما يعلق النظام بشكل دائم.

قدم R0.16 `test_gpt_header()` الذي يتحقق من CRC32 ويفرض `PtNum ≤ 128` قبل الدخول في الحلقة.

**تأثير أسوأ حالة:** رفض خدمة دائم في وقت التحميل. على الأجهزة التي لا تحتوي على مؤقت مراقبة (محملات الإقلاع، ذاكرة التمهيد FPGA على المعدن العاري) يؤدي هذا إلى إتلاف النظام بشكل دائم.

### CVE-2026-6686 - بيانات الكتلة غير المهيأة عبر `f_lseek()` بعد نهاية الملف

**الموقع:** `ff.c` `f_lseek()`:```c
if (!FF_FS_READONLY && fp->fptr > fp->obj.objsize) {
    fp->obj.objsize = fp->fptr;   // extend, but never zero-fill
    fp->flag |= FA_MODIFIED;
}

البحث بعد نهاية الملف (EOF) يستدعي create_chain() لتخصيص مجموعات جديدة ولكنه لا يقوم أبدًا بمسح قطاعاتها. أي قراءة لاحقة للمنطقة الممتدة تُعيد بيانات قديمة خام - محتوى من ملفات تم حذفها سابقًا لا يزال في المجموعة المعاد تدويرها.

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


CVE-2026-6687 - تجاوز سعة المخزن المؤقت للمكدس في f_getlabel() عبر exFAT XDIR_NumLabel

الموقع: ff.c f_getlabel():```c for (si = di = hs = 0; si < dj.dir[XDIR_NumLabel]; si++) { wc = ld_16(dj.dir + XDIR_Label + si * 2); nw = put_utf((DWORD)hs << 16 | wc, &label[di], 4); di += nw; }

root@kitploit:~
يحدد معيار exFAT `XDIR_NumLabel` إلى 11 حرفًا. يقرأ FatFs هذا كـ `BYTE` خام (0–255) دون أي تحقق. يتسبب وحدة تخزين مصمّمة بـ `XDIR_NumLabel = 128` في كتابة `f_getlabel` لـ 128 حرفًا في مخزن المتصل - عادةً `char label[12]` أو `char label[24]` كما يُنشئه STM32CubeMX - مما يؤدي إلى تجاوز سعة المكدس بما يصل إلى 244 بايتًا.

**أسوأ تأثير:** تجاوز سعة مكدس في أي متصل بـ `f_getlabel()` على وحدة تخزين exFAT. النمط الضعيف المعياري (`char label[12]`) يظهر في كل مشروع يتم إنشاؤه بواسطة STM32CubeMX وAN3224 وUM1721.

---

### CVE-2026-6688 - تجاوز سعة مكدس/كومة المتصل عبر اسم ملف طويل LFN

**السبب الجذري:** مع تفعيل `FF_USE_LFN`، يملأ `f_readdir()` حقل `fno.fname` باسم الملف الطويل الكامل - حتى `FF_LFN_BUF` (255) حرفًا. يستخدم المتصلون المصمّمون للعمل بأسماء SFN فقط مخازن ذات حجم ثابت للمسار أو الاسم (مثل `char path[16]`، `char name[14]`) وينسخون `fno.fname` دون التحقق من الحدود.

أنماط ضعيفة شائعة تظهر عبر عدة مشاريع:```c
strcpy(entry->name, fno.fname);          // Zephyr: entry->name[14]
sprintf(path, "0:/%s", fno.fname);       // NodeMCU, ChibiOS demo, StarryPilot
sprintf(&cur_path[n], "/%s", fn);        // Samsung TizenRT

أسوأ تأثير: تجاوز سعة المكدس أو الكومة بما يتناسب مع طول LFN (حتى 255 بايت) في أي اجتياز دليل على وحدة تخزين FAT معدلة. بطاقة SD معدلة تتسبب في تجاوز سعة entry->name[14] بمقدار 241 بايت تؤدي بشكل موثوق إلى إفساد إطار مكدس جدولة Zephyr.


تخطيط المستودع```

├── harness/ Security test harness and exploit tools │ ├── Makefile Build system (see targets below) │ ├── test_ffconf.h FatFs config for the harness (LFN+exFAT+LBA64) │ ├── diskio_ramdisk.c/h In-memory block device (2 MiB RAM disk) │ ├── ffunicode_stub.c Minimal Unicode stub (CP437 pass-through) │ ├── test_harness.c Deterministic per-bug test suite (CVE-2026-6682 through CVE-2026-6688) │ ├── rce_demo.c Standalone CVE-2026-6682 RCE demo: OTA struct-pointer overwrite │ ├── libfuzzer_harness.c libFuzzer / AFL++ entry point │ ├── exploit_disks.c Standalone disk-image generator (see below) │ ├── build/ Compiled binaries │ └── img/ Generated exploit disk images (*.img) │ ├── fuzzer/ Go corpus generator and structural fuzzer │ ├── main.go Corpus builder + Go native fuzz targets │ ├── fat_image.go FAT12/16/32/exFAT/GPT image construction helpers │ └── corpus/ Seed corpus written by make corpus

root@kitploit:~
---

## أهداف بناء أداة الاختبار

جميع الأهداف تُشغّل من الدليل `harness/`.  يتطلب `clang` (أو تعيين `CC=gcc`).

لبناء الهدف `afl` على macOS، استخدم `brew install afl++` ثم `sudo afl-system-config` لتهيئة نظامك.

| الهدف | الوصف |
|--------|-------------|
| `make` / `make test` | بناء وتشغيل مجموعة الاختبارات الحتمية مع ASan + UBSan |
| `make rce_demo` | بناء وتشغيل عرض RCE لـ CVE-2026-6682 (بدون أدوات التعقيم، بدون حماية المكدس) |
| `make exploit_disks` | بناء وتوليد جميع صور الأقراص الـ14 للاستغلال في `harness/img/` |
| `make fuzz_asan` | بناء ثنائي libFuzzer (`build/fuzz_fatfs`) |
| `make afl` | بناء الهدف AFL++ (يتطلب وجود `afl-clang-fast` في `PATH`) |
| `make corpus` | توليد مجموعة البذور عبر مولد Go إلى `harness/corpus/` |
| `make clean` | إزالة `build/` و `img/` |

### بدء سريع```sh
# Run the full deterministic test suite
cd harness && make

# Run the CVE-2026-6682 RCE demo
make rce_demo

# Generate all exploit disk images
make exploit_disks

# Fuzz with libFuzzer (requires clang)
make fuzz_asan
build/fuzz_fatfs -max_len=2097152 corpus/

# Fuzz with AFL++
make corpus afl
afl-fuzz -i corpus/ -o findings/ -- build/afl_fatfs @@

استغلال صور القرص

make exploit_disks ينتج 14 صورة قرص خام في harness/img/، واحدة لكل مجموعة مشروع/ثغرة. يتم اختبار كل صورة ذاتيًا وقت التوليد عن طريق تحميلها باستخدام FatFs المضمن. يمكن كتابة الصور على بطاقة SD فعلية:```sh dd if=harness/img/exploit_bug1_espidf.img of=/dev/sdX bs=512

root@kitploit:~
| الصورة | الثغرة | المشروع (المشاريع) المستهدفة | التأثير |
|-------|-------|-------------------------------|----------|
| `exploit_bug1_fat32.img` | CVE-2026-6682 | عام | يمرر حمولة بحجم المؤشر عبر `f_read` |
| `exploit_bug1_espidf.img` | CVE-2026-6682 | espressif/esp-idf | `finfo.fsize=16 MB` → تجاوز سعة الكومة في `malloc`/`fread` |
| `exploit_bug1_stm32.img` | CVE-2026-6682 | STMicro stm32-mw-fatfs | `finfo.fsize=1 MB` → تجاوز سعة مخزن البرمجيات الثابتة بحجم 1 كيلوبايت |
| `exploit_bug1_keystone3.img` | CVE-2026-6682 | KeystoneHQ wallet | `finfo.fsize=512 KB` → تجاوز سعة مخزن OTA |
| `exploit_bug1_ardupilot.img` | CVE-2026-6682 | ArduPilot / Mbed OS / RIOT / MicroPython | `finfo.fsize=2 MB` → تجاوز سعة مخزن قراءة السجل |
| `exploit_bug2_exfat.img` | CVE-2026-6683 | ArduPilot / Mbed OS / MicroPython / RIOT | `BPB_NumClusEx=0` → قسمة على صفر في `sync_fs` (SIGFPE على الإصدارات التي تسبق R0.16) |
| `exploit_bug3_gpt.img` | CVE-2026-6684 | vivado-risc-v / tinyuf2 / circle | `GPTH_PtNum=0xFFFFFFFF` → حلقة لا نهائية عند الإقلاع (قبل R0.16) |
| `exploit_bug5_stale.img` | CVE-2026-6686 | RT-Thread / tinyuf2 / ArduPilot / RIOT | توسيع `f_lseek` يكشف بيانات عناقيد محذوفة ببذرة `0xAA` |
| `exploit_bug6_stm32.img` | CVE-2026-6687 | STMicro stm32-mw-fatfs | `XDIR_NumLabel=128` → تجاوز سعة بمقدار 117 بايت لـ `label[12]` من CubeMX |
| `exploit_bug6_zephyr.img` | CVE-2026-6687 | Zephyr / ArduPilot / RIOT / MicroPython | `XDIR_NumLabel=255` → تجاوز سعة بمقدار 216 بايت لـ `label[24]` |
| `exploit_bug7_max255.img` | CVE-2026-6688 | NodeMCU / ChibiOS / StarryPilot / TizenRT | اسم ملف طويل (LFN) مكون من 255 حرفًا يتجاوز أي مخزن ثابت حجمه < 255 بايتًا |
| `exploit_bug7_zephyr.img` | CVE-2026-6688 | Zephyr | LFN مكون من 14 حرفًا → تجاوز NUL بمقدار بايت واحد لـ `entry->name[14]` |
| `exploit_bug7_grblhal.img` | CVE-2026-6688 | grblHAL | خطأ بمقدار واحد: يقوم الحارس بفحص الإدخال السابق؛ LFN مكون من 11 حرفًا يتجاوز `dirent.name[12]` ببايت NUL واحد |

---

## مجموعة الاختبارات الحتمية (`test_harness.c`)

تقوم مجموعة الاختبارات بفحص ست ثغرات باستخدام صور أقراص مصنوعة يدويًا ومبنية في الذاكرة، ثم تؤكد أن مسار الكود الضعيف قد تم الوصول إليه:

- **CVE-2026-6682** - تقوم ببناء صورة FAT32 بحيث تكون `BPB_FATSz32=0x80000001`، وتركيبها، وتؤكد أن `fs.database` يقع داخل منطقة FAT؛ ثم تنفذ سلسلة RCE الكاملة (إدخال دليل مزيف → `f_read` لمؤشر دالة مزروع → استدعاء `rce_proof_of_execution()`).
- **CVE-2026-6683** - توثق المقسوم `(n_fatent-2)` وتؤكد مسار العمليات الحسابية؛ وتتحقق من أن R0.16 يرفض الصورة عند التركيب.
- **CVE-2026-6684** - تقوم ببناء صورة GPT بحيث تكون `GPTH_PtNum=0xFFFFFFFF` وتؤكد أن R0.16 يرفضها خلال ≤ 3 قراءات للقرص عبر `test_gpt_header()`.
- **CVE-2026-6686** - تقوم مسبقًا ببذر جميع عناقيد البيانات بقيمة `0xAA`، وتكتب ملفًا قصيرًا، وتوسعه عبر `f_lseek`، وتقرأه مرة أخرى لتؤكد أن البايتات القديمة مرئية.
- **CVE-2026-6687** - تقوم ببناء صورة exFAT بحيث تكون `XDIR_NumLabel=128`، وتستدعي `f_getlabel` في مخزن اختبار، وتحسب التجاوز بعد البايت 24.
- **CVE-2026-6688** - تقوم ببناء دليل FAT16 باسم ملف طويل مكون من 50 حرفًا، وتقرأه عبر `f_readdir`، وتؤكد أن طول `fno.fname` يتجاوز حجم المخازن النموذجية للمتصل.

---

## عرض RCE لـ CVE-2026-6682 (`rce_demo.c`)

عرض توضيحي مستقل وواقعي لسلسلة استغلال CVE-2026-6682 المصممة على غرار تحديث البرمجيات الثابتة OTA المضمنة. يتم تعريف بنية تحتوي على مخزن رأس بحجم ثابت يليه مباشرة مؤشر دالة رد اتصال:```c
typedef struct {
    uint8_t  fw_header[128];   // buffer the developer reads into
    uint32_t crc32;
    uint32_t version;
    void   (*on_apply)(void);  // callback - attacker target
} ota_ctx_t;

تقوم النسخة التوضيحية ببناء صورة قرص مصممة حيث DIR_FileSize = sizeof(ota_ctx_t)، وتزرع عنوان rce_win() في الإزاحة الصحيحة في قطاع الحمولة، ثم تشغل مدقق OTA. يكتب f_read بعد fw_header إلى on_apply، واستدعاء ctx.on_apply() اللاحق يستدعي rce_win()، مما يعين rce_canary = 0xDEAD.

Build and run: cd harness && make rce_demo


المزعزع (fuzzer/)

يحتوي المزعزع بلغة Go على وضعين:

  1. مولد المجموعة (go run . -out ./corpus أو make corpus): يكتب 18 صورة بذرة منظمة تغطي ست فئات من الأخطاء، وثلاثة متغيرات FAT جميعها، وGPT عادي ومشوه، و50 تحورًا عشوائيًا بأحرف مفردة من صورة FAT32 صالحة.

  2. المزعزع الأصلي بلغة Go (go test -fuzz=FuzzFAT32BPB): مزعزعة هيكلية لقيم حقول BPB باستخدام المزعزع المدمج في Go؛ يتحقق من صحة علاقات الحقول دون استدعاء C.

تغذي المجموعة البذرية كلاً من ثنائي libFuzzer (build/fuzz_fatfs) وهدف AFL++ (build/afl_fatfs).

ESP-IDF عبر QEMU

يتضمن هذا المستودع حالة اختبار Docker ذاتية الاحتواء توضح نمط تجاوز سعة المتصل ذي الصلة بـ ESP32 لـ CVE-2026-6688 باستخدام اجتياز الدليل FatFs على برنامج ESP-IDF الثابت داخل محاكي Espressif QEMU ESP32.

صورة PoC الحالية هجينة عن قصد:

  • إنها تحافظ على هندسة FAT32 المصممة على غرار CVE-2026-6682 بحيث يمكن التحكم في الدليل الجذر المزور بشكل موثوق.
  • إنها تضم اسم ملف VFAT طويل يتم إرجاعه بواسطة readdir().
  • ثم يعكس التطبيق أنماط كود ESP32 العامة (تجميع مسار strcpy / strcat) وينسخ اسم الملف الطويل في مخزن مؤقت ثابت بحجم 32 بايت.

هذه النسخة النهائية هي الحالة على غرار CVE-2026-6688: تجاوز سعة من جانب المتصل عبر استخدام غير محدود لأسماء الملفات الطويلة.``` cd esp32-qemu-test ./run.sh

root@kitploit:~
أو بدلاً من ذلك:```
docker build -t fatfs-esp32-vuln-test esp32-qemu-test/
docker run --rm fatfs-esp32-vuln-test

لماذا يتوافق هذا مع CVE-2026-6688

يمكن أن ترجع f_readdir() أسماءً طويلة (LFN) يصل طولها إلى 255 حرفًا. لا يزال العديد من المتصلين المدمجين الحقيقيين ينسخون الأسماء في مخازن مؤقتة ثابتة أصغر. تتضمن الأمثلة العامة لـ ESP32 أنماطًا تعادل:

#include <stdio.h> // Example pattern``` strcpy(fn, entry->d_name); strcat(path, "/"); strcat(path, entry->d_name);

root@kitploit:~
مع صورة FAT محملة تحتوي على اسم ملف طويل، تفيض هذه النسخ على مخزن المتصل المؤقت.

### سلسلة إثبات المفهوم (PoC) في هذا المستودع

| الخطوة | الوصف | العلامة |
|--------|--------|---------|
| 1 | يتم تحميل صورة تخزين محملة وإرجاع إدخالات دليل يتحكم فيها المهاجم | (يتم التحميل بنجاح) |
| 2 | يتم نسخ اسم الملف الطويل إلى `char name[32]` عبر مسار نسخ غير آمن بنمط عام | `[VULN-BUG7-CONFIRMED]` |
| 3 | يتم تسجيل تلف الحارس، يليه تعطل بيانات التحكم في QEMU | `guard=0x61616161`, `Guru Meditation Error` |

لا يزال إثبات المفهوم يحتفظ بمسار استبدال استدعاء OTA على غرار CVE-2026-6682 القديم للسياق وإخراج العلامة (`PWNED-UART`)، ولكن الإثبات الخاص بالخلل هنا هو علامة تجاوز المتصل لاسم الملف الطويل المذكورة أعلاه.

مخرجات تمثيلية:```
I (...) fatfs_vuln: PoC: CVE-2026-6688 long-LFN caller overflow probe (ESP32 public-pattern copy path)
...
PWNED-UART
E (...) fatfs_vuln: [VULN-BUG7-CONFIRMED] guard corrupted after filename copy
E (...) fatfs_vuln: entry='esp32_lfn_trigger_aaaa...aaaa.bin' len=78 guard=0x61616161
Guru Meditation Error: Core  0 panic'ed (...)

ملاحظة حول ترقيم CVE

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

شكرًا لديفيد براون على لفت انتباهنا إلى التقرير المتنازع عليه. لحالة المنبع وإرشادات التصحيح، اتبع صفحة تصحيحات ChaN الرسمية لـ FatFs: https://elm-chan.org/fsw/ff/patches.html

تنزيل الأداة
ProjectStarsFatFs VersionBugs
espressif/esp-idf17,655R0.16CVE-2026-6682
STMicroelectronics/stm32-mw-fatfsall STM32CubeR0.15 w/p2CVE-2026-6682, CVE-2026-6683, CVE-2026-6686, CVE-2026-6687
zephyrproject-rtos/zephyr14,820R0.16CVE-2026-6683, CVE-2026-6687, CVE-2026-6688
micropython/micropython21,583R0.13c (2019)CVE-2026-6682, CVE-2026-6683, CVE-2026-6684, CVE-2026-6686, CVE-2026-6687
ArduPilot/ardupilot14,743R0.14bCVE-2026-6682, CVE-2026-6683, CVE-2026-6686, CVE-2026-6687
RT-Thread/rt-thread11,862R0.16CVE-2026-6683, CVE-2026-6686
nodemcu/nodemcu-firmware7,903variesCVE-2026-6688
RIOT-OS/RIOT5,701R0.15CVE-2026-6682, CVE-2026-6683, CVE-2026-6686, CVE-2026-6687
ARMmbed/mbed-os4,837R0.14bCVE-2026-6682, CVE-2026-6683, CVE-2026-6686
sbabic/swupdate1,780R0.16CVE-2026-6683
rsta2/circle2,222tbdCVE-2026-6684
hugen79/NanoVNA-H695R0.15CVE-2026-6683
ChibiOS/ChibiOS833variesCVE-2026-6688
Samsung/TizenRT643R0.16CVE-2026-6683, CVE-2026-6688
adafruit/tinyuf2447tbdCVE-2026-6684, CVE-2026-6686
grblHAL/Plugin_SD_card475R0.16CVE-2026-6688
JcZou/StarryPilot315R0.16CVE-2026-6688
KeystoneHQ/keystone3-firmware199R0.16CVE-2026-6682
flysight/flysight44variesCVE-2026-6682, CVE-2026-6688
eugene-tarassov/vivado-risc-v1,061tbdCVE-2026-6684
CVE IDShort TitleCWE
CVE-2026-6682Integer Overflow in FAT32 Volume MountCWE-190: Integer Overflow or Wraparound
CVE-2026-6683Divide-by-Zero in exFAT SyncCWE-369: Divide By Zero
CVE-2026-6684Infinite Loop in GPT Partition ScanCWE-835: Loop with Unreachable Exit Condition
CVE-2026-6686Use of Uninitialized Clusters After Seek Past EOFCWE-908: Use of Uninitialized Resource
CVE-2026-6687Stack Buffer Overflow via Uncapped exFAT Label LengthCWE-121: Stack-based Buffer Overflow
CVE-2026-6688Buffer Overflow via Unbounded LFN Filename CopyCWE-120: Buffer Copy without Checking Size of Input