استغلال BootROM الموحد لـ Exynos 990 / Exynos9830

أدوات موحدة لـ CVE-2024-56426 لعائلات Exynos 990 Galaxy S20 وS20 FE وNote20. يقبل الاستغلال جميع أسماء الطرازات العشرة ويقوم بتعيينها على ست عائلات برامج تشغيل أصلية تم التحقق منها.

[!CAUTION] حزمة المفاتيح المتعقبة والصور المُنشأة قابلة للدمج (fusing). الدمج غير قابل للعكس. الهاتف المدمج بمفتاح لا يمكنه تشغيل سوى الصور المتوافقة مع ذلك المفتاح. يمكن أن يؤدي اختيار طراز خاطئ أو مراجعة تراجع أو مجموعة تصحيحات أو حزمة مفاتيح خاطئة إلى ترك الجهاز في حلقة إقلاع مدمجة. استخدم مفاتيح التطوير وحمولة UFS أثناء التكرار. أضف --no-fuse إلى كل أمر تحضير/توقيع ما لم يكن الدمج بمفتاح مخصص مقصودًا صراحةً.

الطرازات المدعومة

يتحكم الطراز المحدد في كل من معرف طراز BL1 ومعرف الطراز الدقيق لملف TSV لتصحيح LK. يتحكم Runtime artifact في البرنامج الثابت الأصلي والصور المقسمة المشفرة المستخدمة بواسطة الفحص المسبق. الأعلام الأربعة غير 5G التي تستخدم أرتيفاكتات وقت تشغيل 5G مقترنة تقوم أيضًا بتصحيح فحص معرف الطراز ومسار برمجة معرف الطراز في LK.

Model flag	Runtime artifact	Runtime firmware	Model ID	EVT	Rollback	Tested
`G780F`	`G780F`	`G780FXXSOFYJ1`	`0x154`	`11`	`24`	❌
`G980F`	`G981B`	`G981BXXSNHYB1`	`0x143`	`11`	`23`	✅
`G981B`	`G981B`	`G981BXXSNHYB1`	`0x13D`	`11`	`23`	❌
`G985F`	`G986B`	`G986BXXSNHYB1`	`0x142`	`11`	`23`	✅
`G986B`	`G986B`	`G986BXXSNHYB1`	`0x13C`	`11`	`23`	✅
`G988B`	`G988B`	`G988BXXSNHYB1`	`0x13E`	`11`	`23`	❌
`N980F`	`N981B`	`N981BXXSIHYH3`	`0x153`	`11`

وضع KVM وEL2 لـ Exynos 990

جميع أعلام الطرازات العشرة المدعومة من Galaxy S20 وS20 FE وNote20 لديها ملف تعريف إقلاع KVM اختياري عبر CLI فقط. قم ببناء فرع من نواة Exynos 990 الذي يحتوي اسمه على kvm، وأضف --kvm إلى أمر الطراز الدقيق، على سبيل المثال:```bash python3 exploit/exploit.py --build-sboot --model G985F --no-fuse --kvm

هذا الملف الشخصي يزيل مسار LK H-Arx/UH، ويطلب من EL3 إدخال النواة عند EL2، ويطبق جدول تصحيح EL3 monitor المطابق
المفكوك تشفيره/المعاد تشفيره. ويبقى غير متاح لأوضاع فلاش محمّل الإقلاع المخزّن/العبث به. لا يحتوي مركز التحكم عبر الويب عمدًا على أي تحكم KVM. مع النواة المطابقة
و[WindowsInQemu](https://github.com/Creeeeger/WindowsInQemu)، يمكن تشغيل Windows في QEMU على الهاتف بسرعة كاملة
عبر KVM.

## بدء سريع

لا تتعامل مع كل وضع كتسلسل تثبيت مرقّم واحد. اختر هدفًا:

| الهدف                              | المسار                                                                                                                     |
|-----------------------------------|--------------------------------------------------------------------------------------------------------------------------|
| تثبيت ROM مخصص موقّع       | الطراز/الإعداد الدقيق → EUB → سلسلة مؤقتة `--signed --no-fuse` → وميض المخرجات الموقّعة الكاملة للـ ROM → أول إقلاع UFS |
| اختبار الاستغلال                  | اختياري `--prepare --no-fuse` → EUB → `--signed --no-fuse` → توقف                                                       |
| تطوير سلسلة الإقلاع (CLI فقط) | اختبار no-fuse مؤقت → بناء → وميض SBoot/TZSW/LDFW المولّدة → UFS                                                   |
| تفريغ / استرداد                   | استخدم سير العمل المنفصل الخاص به وفحوصات حالة المصهر                                              |

`--prepare` هو تشغيل تجريبي موصى به، وليس خطوة سابقة إلزامية: `--signed`
يكرر الفحص المسبق. أمر Heimdall المكوّن من ثلاثة أجزاء المولّد هو أداة تطوير سلسلة إقلاع؛ وليس وميض ROM مخصص.

اقرأ [USER_GUIDE.md](https://github.com/creeeeger/cve-2024-56426/blob/exynos990/USER_GUIDE.md) واختر سير العمل المطابق له قبل لمس أي جهاز. يتضمن
تسليم الـ ROM الكامل بالإضافة إلى قواعد الاسترداد للحالة غير المدمجة والمدمجة وغير المؤكدة.

## واجهة مستخدم محلية اختيارية

تستخدم واجهة المتصفح مكتبة Python القياسية فقط وتستدعي واجهة سطر الأوامر الموجودة
`exploit/exploit.py`. يبقى تطوير سلسلة الإقلاع وأمر Heimdall المكوّن من ثلاثة أجزاء المولّد أدوات طرفية فقط.

ابدأها من جذر المستودع:```bash
python3 exynos990_control_center.py

يُقيّد المُشغّل الاتصال بـ 127.0.0.1، ويُنشئ رمز وصول جديدًا، ويطبع عنوان URL المحلي الكامل، ثم يفتحه في المتصفح الافتراضي. استخدم --no-browser عندما لا ينبغي فتح المتصفح تلقائيًا:```bash python3 exynos990_control_center.py --no-browser

توفر الواجهة ما يلي:

- فحوصات خضراء/حمراء للتبعيات وأصول المستودع؛
- اختيار واحد عام لنموذج الهدف وقرارين دمج بالضبط: البقاء غير مدمج أو الدمج؛
- أداة اختيار سير عمل تعرض وترقّم خطوات سير العمل المحدد فقط؛
- سير عمل تثبيت ROM، واختبار الاستغلال، وتفريغ BootROM، واستعادة المخزون؛
- إجراء محمّل معدّل خاص بالنموذج الدقيق يتحقق من UH ويومضه إلى فتحة BOOTLOADER باستخدام Heimdall للدخول إلى
  EUB؛
- تحذير دائم من الدمج وبصمة SHA-256 المكوّنة للمفتاح/eFuse؛
- بطاقة استعادة سلسلة التمهيد المخزنية غير المدمجة فقط، وهي غير متاحة بعد اختيار الدمج؛
- مخرجات العمليات الحية، والإلغاء، وعلامات التحقق لكل مرحلة.

كما يعرض إشعارًا خاصًا بـ Exynos 990 KVM عبر CLI فقط، لكنه لا يعرض خيار KVM عمدًا ولا يمرر `--kvm` إلى أي
إجراء ويب.

يتبع الوصول إلى USB أذونات العملية التي شغّلت مركز التحكم. قم بتكوين أذونات udev/برنامج التشغيل المرفقة قبل تشغيله. لا تطلب الواجهة بيانات اعتماد الامتياز أو تحتفظ بها أو تمررها. أبقِ رمز URL المطبوع خاصًا وأوقف الخادم فورًا بعد الاستخدام.

يمكن لمستخدمي الطرفية تجاهل `exynos990_control_center.py`؛ كل أمر CLI موثق أدناه يبقى دون تغيير ومدعومًا بالكامل.

## المتطلبات

يتطلب Python 3.10 أو أحدث.

Windows 10/11 (PowerShell أصلي):```powershell
.\windows\setup.ps1
. .\windows\activate.ps1
python .\exploit\exploit.py --prepare --model G985F --no-fuse

يُثبّت الإعداد سلسلة أدوات AArch64 الأصلية المثبّتة، وLZ4، وHeimdall، وبيئة افتراضية للمستودع، ثم يبني جميع الحمولات. برنامج تشغيل WinUSB الخاص بـ BootROM هو خيار صريح للمسؤول لأن شهادته الموقّعة ذاتيًا من المصدر تغيّر مخازن الثقة في الجهاز. راجع WINDOWS.md للإعداد الكامل، وتثبيت برنامج التشغيل، والتمييز بين وضع التنزيل، والتحقق، وعملية استكشاف الأخطاء وإصلاحها.

بعد تنشيط Windows، استخدم python حيثما تعرض الأمثلة المتبقية عبر المنصات python3.

Linux:```bash sudo apt-get update sudo apt-get install -y gcc-aarch64-linux-gnu binutils-aarch64-linux-gnu lz4

macOS:```bash
brew tap messense/macos-cross-toolchains
brew install aarch64-unknown-linux-gnu lz4

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

الفحص المسبق

تعمل أوضاع الإعداد والتوقيع والحمولات عبر نفس الفحص المسبق المدرك للطراز:

حلّ الطراز المحدد إلى عائلة القطع الأثرية الأساسية الخاصة به.
استبدال exploit/extra/images/<model>/ بنسخة نظيفة من الصور المشفرة المقسمة غير المعدّلة.
تطبيق TSV الخاص بـ LK المطابق مع فحوصات صارمة لبايتات المخزون. مع --no-fuse، يتم إنشاء نسخة TSV فعّالة مع تعطيل صفوف الدمج الخمسة أولاً. مع --kvm، يتم أيضاً تفعيل صفوف LK الموسومة بـ kvm، وفك تشفير وتصحيح TSV الخاص بمراقب EL3 المطابق، وإعادة تشفير منطقته المحمية.
بناء mem.bin وloader.bin وExynos990_boot_custom_key.bin.
التأكد من أن EPBL ومراقب EL3 مشفّران، مع إعادة التشفير فقط عند الضرورة.
التحقق من بيانات تعريف طراز/EVT/إصدار الاسترجاع الخاصة بـ FWBL1 المخزون ومن كل تذييل استرجاع لمرحلة Stage2 قبل التوقيع.
توقيع FWBL1 بمعرّف الطراز المحدد وتوقيع جميع مكونات Stage2 بمراجعة الاسترجاع المخزونة.
التحقق من كل توقيع Stage2 مولّد قبل النقل عبر USB.

تتوقف العملية عند أول عدم تطابق في البرامج الثابتة أو التصحيح أو البيانات التعريفية أو التوقيع. ولا تقوم أبداً بتصحيح المصادر غير القابلة للتعديل في مكانها.

أوضاع الاستغلال

تتطلب جميع الأوامر --model.

--no-fuse هو معدِّل وليس وضعاً مستقلاً. يعمل على تعطيل خمسة صفوف OTP محددة للمفتاح المخصص أثناء إعادة بناء LK العامل. استخدمه مع كل أمر يقوم بإعداد أو إرسال أو بناء سلسلة تطوير غير مدمجة. لا يلغي دمجاً قائماً.

يقبل CLI المعدِّل مع أوضاع UFS والتفريغ لأن تلك الأوامر تشغّل الفحص المسبق أيضاً، لكن عمليات USB الخاصة بها لا تنقل LK المعاد بناؤه. إن LK المومض بالفعل على الهاتف يحدد سلوك دمج UFS. وبالتالي، فإن الواجهة لا تقدم عمداً أي تحكم بعدم الدمج لأوضاع UFS أو تفريغ BootROM. يرفض وضعا وميض الإقلاع --no-fuse لأنهما لا ينفذان أي تصحيح أو توقيع لـ LK.

--kvm هو أيضاً معدِّل. يُقبل مع كل سير عمل للطراز الدقيق يشغّل الفحص المسبق. يتم تجاهل صفوف KVM في ملفات TSV ما لم يكن هذا العلم موجوداً، ولا توفره واجهة المتصفح أبداً.

مثال:```bash python3 exploit/exploit.py --signed --model N986B --no-fuse

قم بإنشاء أداة تحميل الإقلاع الموقّعة المقابلة دون فتح USB:```bash
python3 exploit/exploit.py --build-sboot --model N986B --no-fuse

يعيد الأمر بناء دليل صور النموذج من مدخلات المخزون النظيفة، ويطبق تصحيح LK، ويوقّع ويتحقق من كل مكوّن، ويدمج sboot.bin، ويفحص المكوّنات المدمجة والذيل، ويطبع حجمه وSHA-256 وأمر Heimdall الذي يرسل sboot.bin وtzsw.img الموقّع وldfw.img الموقّع.

فقط على جهاز معروف بأنه غير مدمج (unfused)، استعد سلسلة الإقلاع الأصلية الدقيقة من أرشيف BL الأصلي للنموذج المحدد:```bash python3 exploit/exploit.py --flash-stock --model N986B --wait

يستخرج الأمر فقط `sboot.bin.lz4` و`tzsw.img.lz4` و`ldfw.img.lz4`، ويفك ضغطها في دليل مؤقت، ويتحقق من وجود المخرجات الثلاثة جميعها وعدم كونها فارغة، ثم يستدعي عملية وميض واحدة عبر Heimdall. تتم إزالة الملفات المؤقتة بعد ذلك. كما أن `--no-reboot` و`--verbose` مدعومان أيضًا. يجب أن يكون الهاتف بالفعل في وضع التنزيل المتوافق مع Heimdall، ويجب أن يطابق الطراز المحدد الجهاز الفعلي تمامًا.

لا يؤدي هذا إلى استعادة Android أو AP أو المودم أو CSC أو بيانات المستخدم أو ROM كامل من المصنع. لا تقم أبدًا بتشغيله على جهاز مدمج بمفتاح مخصص. يتطلب هذا الهاتف إعادة توقيع برنامج قائم على المصنع بالمفتاح المدمج الدقيق؛ ويبقى جذر الثقة المخصص دائمًا. إذا كانت حالة الدمج غير معروفة، فتوقف.

## ملاحظة استعادة FRP / PERSISTENT

> [!CAUTION]
> هذا الإجراء مخصص فقط لجهاز تملكه شخصيًا ومصرح لك بصيانته. استخدامه على جهاز شخص آخر محظور تمامًا. يمكن أن يتسبب مسار قسم خاطئ في فقدان بيانات دائم أو ترك الجهاز غير قادر على الإقلاع. قم بنسخ القسم المستهدف احتياطيًا وتحقق من مسار جهاز الكتلة المُحلَّل وحجمه قبل كتابة أي شيء.

لا يزيل هذا المستودع تلقائيًا حماية إعادة الضبط إلى إعدادات المصنع (FRP). على الأجهزة التي تستخدم `PersistentDataBlockService` في Android، يتم تخزين حالة FRP في القسم المعروف عمومًا باسم `PERSISTENT`. راجع [تنفيذ AOSP](https://android.googlesource.com/platform/frameworks/base/+/bc56632da95b/services/core/java/com/android/server/PersistentDataBlockService.java).

بعد أن يقوم سلسلة الاستغلال بتشغيل استرداد مخصص يوفر `adb` و`dd`، حدد القسم وقم بنسخه احتياطيًا. لا تستبدل مسار جهاز الكتلة الرقمي المُخمَّن:```bash
adb shell ls -l /dev/block/by-name/PERSISTENT
adb shell dd if=/dev/block/by-name/PERSISTENT of=/tmp/PERSISTENT.backup.img bs=4096
adb pull /tmp/PERSISTENT.backup.img

فقط بعد سحب النسخة الاحتياطية، قم بمسح القسم إلى صفر واترك أندرويد يقوم بتهيئة بنية كتلة بيانات ثابتة جديدة:```bash adb shell dd if=/dev/zero of=/dev/block/by-name/persistent reboot

هذه الطريقة تم اختبارها وتعمل بنجاح، تمت إزالة FRP وتم فتح قفل الجهاز.

## تصحيحات LK

يتبع اختيار التصحيح تعيين الأرتيفاكت:```text
G780F -> lk_g780f_selected_patches.tsv
G980F -> lk_g980f_selected_patches.tsv  (applied to G981B LK)
G981B -> lk_g981b_selected_patches.tsv
G985F -> lk_g985f_selected_patches.tsv  (applied to G986B LK)
G986B -> lk_g986b_selected_patches.tsv
G988B -> lk_g988b_selected_patches.tsv
N980F -> lk_n980f_selected_patches.tsv  (applied to N981B LK)
N981B -> lk_n981b_selected_patches.tsv
N985F -> lk_n985f_selected_patches.tsv  (applied to N986B LK)
N986B -> lk_n986b_selected_patches.tsv

تحقق من ملف TSV مقابل LK القياسي دون تغييره:```bash python3 external/tools/apply_lk_patches.py
bootLoaderFiles/sbootSplitParts_original/G986B/lk.bin
external/ghidra/lk_g986b_selected_patches.tsv
--check

`external/ghidra/ApplyLkPatches.java` يقبل نفس تنسيق TSV المكوّن من ستة أعمدة، ويفشل الآن عند عدم تطابق البايتات القديمة
بدلاً من تطبيق التصحيح بشكل أعمى. الصفوف التي يكون عمودها الأول `kvm` تتطلب وسيطة سكربت إضافية `--kvm`.
الصفوف القديمة `check_signature` و`check_ext4_signature` التي تُرجع صفرًا تستخدم
الملف الشخصي `0`: فهي توثّق مواقع الالتفاف القديمة ولكنها لا تُطبَّق عمدًا،
لذا يجب أن تلبي الصور المبنية فحوصات توقيع Samsung الحقيقية الخاصة بـ LK.

## التوقيع

يتطلب `external/tools/sign_sboot_images.py` طرازًا ويستمد معرف الطراز وEVT ومراجعة التراجع من
[model_data.py](https://github.com/creeeeger/cve-2024-56426/blob/exynos990/external/tools/model_data.py):```bash
python3 external/tools/sign_sboot_images.py \
  --images-dir exploit/extra/images/G986B \
  --keys-dir external/keys/exynos9830_crecker \
  --model G986B

يتم التحقق من توقيعات المرحلة الثانية بعد التوقيع. لا تقوم الأداة بإعادة توليد بيانات Samsung AVB الوصفية لـ ldfw.img أو tzsw.img؛ تغيير بايتات التمهيد الآمن داخل تلك الحاويات لا يزال يتطلب سياسة AVB المنفصلة المستخدمة من قبل تدفق التمهيد الهدف. يجب أن يستخدم ROM الموقّع الكامل نموذج AVB الدقيق ونفس حزمة المفاتيح، ثم يُومض بحزمة الجيل الكاملة الخاصة به. راجع مستودع CreckerROM وسير عمل التثبيت في USER_GUIDE.md.

أدوات التحميل المعدّلة

تحافظ الحزم المعدّلة المرفقة على كل عضو BL الأصلي باستثناء sboot.bin.lz4. تتم إزالة هذا العضو ويُخزَّن ملف uh.bin غير المضغوط من الحزمة كـ sboot.bin، بما يتوافق مع التخطيط الذي يُطلق آلية EUB.

يمكن للواجهة تنفيذ تدفق Heimdall المقابل مباشرة. تختار الأرشيف المعدّل للنموذج الفعلي الدقيق، وتتحقق من أن sboot.bin مطابق بايتًا ببايت لـ uh.bin.lz4 غير المضغوط، وتومض حمولة UH المُتحقق منها إلى فتحة BOOTLOADER:```bash python3 exploit/exploit.py --flash-tampered --model G986B --wait

هذا يمنع عمدًا الإقلاع الطبيعي ويجبر الإقلاع التالي على الدخول إلى EUB. لا يقوم بوميض الأعضاء المتبقين من
أرشيف BL.

أعد إنشاء حزمة واحدة باستخدام:```bash
python3 external/tools/build_tampered_loader.py \
  bootLoaderFiles/originalBl/G986B/BL_G986BXXSNHYB1.tar \
  bootLoaderFiles/tamperedLoader/G986B/BL_G986BXXSNHYB1_tampered.tar

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

ضع في اعتبارك أنه إذا قمت بدمج الجهاز، فستحتاج إلى وميض ملف uh.bin موقّع إلى فتحة BOOTLOADER الخاصة بك، نظرًا لأن ملف uh المخزّن موقّع حاليًا بالمفتاح الخاطئ.

أدوات التحليل

تقسيم ودمج:```bash python3 exploit/split.py sboot.bin -o /tmp/G986B-splits python3 exploit/merge.py /tmp/G986B-splits

المدمج المستقل يتطلب `tzsw.img` و `ldfw.img` في دليل الأجزاء ويطبع أمر Heimdall المكوّن من ثلاثة أجزاء المقابل. استخدم هذا الأمر فقط عندما تكون هاتان الصورتان قد تم توقيعهما بالفعل للطراز المحدد؛
`--build-sboot` يقوم بتنفيذ والتحقق من ذلك التوقيع تلقائيًا.

استخراج سجلات LDFW الفردية:```bash
python3 external/tools/extract_ldfw.py ldfw.img -o LDFWs

التخطيط المقسّم المعطى يعيد بناء كل نسخة أصلية من sboot.bin بايتًا ببايت. كما أن فك/إعادة تشفير EPBL و EL3 monitor يعملان أيضًا بايتًا ببايت لجميع عائلات البرامج الثابتة عندما تُترك رأسية EPBL دون تغيير.

توافق الحمولة

تشترك جميع الهواتف المدعومة في نفس BootROM الخاص بـ Exynos 990. تستخدم الحمولات نقاط دخول وعناوين IRAM مشتركة في BootROM بدلاً من إزاحات LK الخاصة بالطراز. تُحلّ الملفات الثنائية المُولَّدة إلى نقاط الدخول هذه:

يقتصر السلوك الخاص بالطراز على TSV الخاص بـ LK ومعرّف طراز FWBL1 ومراجعة التراجع عن التحديث الأصلية.

تخطيط الصورة

الإشادات والإسناد

Chimera Tool: أول اكتشاف معروف واستخدام عملي لهذا الاستغلال، حوالي 2021–2022.
إشعار Samsung حول CVE-2024-56426: يوثّق الثغرة المستخدمة في هذا المشروع.
Christopher Wade: أبلغ Samsung عن CVE-2024-56426.
Umer Uddin (halal-beef)، عبر halal-beef/hubble: الكود الخلفي المستخدم في exploit/exploit.py؛ وتخطيط SoC المستخدم في exploit/split.py و exploit/merge.py؛ وrun_exploit()، الذي ينفّذ عملية الكتابة فوق العنوان.
VDavid003 (David)، عبر VDavid003/exynos-usbdl: الهيكل الأساسي للحمولة الذي اشتُقّت منه حمولة المفتاح المخصص لـ Exynos990.

`bootLoaderFiles/originalBl/<model>/`	حزم `BL_<firmware>.tar` النظيفة الخاصة بالطراز الدقيق لجميع الطرازات العشرة.
`bootLoaderFiles/sbootSplitParts_original/<model>/`	أجزاء SBoot المشفرة الأصلية غير المعدّلة الخاصة بالطراز الدقيق، و`ldfw.img`، و`tzsw.img`، والبيان، والذيل.
`bootLoaderFiles/exynos9830Decrypted/<model>/`	ملفات تحليل EPBL وEL3 وTZSW وLDFW المفكوكة الخاصة بالطراز الدقيق.
`bootLoaderFiles/tamperedLoader/<model>/`	حزم BL المحفّزة لـ EUB الخاصة بالطراز الدقيق.
`bootLoaderFiles/MODEL_COMPARISON.md`	مقارنة البرامج الثابتة الدقيقة مقابل المقترنة وملاحظات توافق التصحيح.
`bootLoaderFiles/exynos990Bootrom/`	تفريغ BootROM المشترك لمعالج Exynos 990.
`bootromNotes/`	ملاحظات مشتركة حول تدفق BootROM وسياق USB.
`drivers/windows/winusb/`	حزمة WinUSB المثبّتة من Houston لنظام Windows لـ BootROM/EUB `04e8:1234`.
`windows/`	إعداد Windows الأصلي، وتفعيل البيئة، ومثبّت برنامج التشغيل مع فحص التجزئة.
`exploit/extra/images/<model>/`	مخرجات الفحص المسبق المؤقتة الخاصة بالطراز.
`external/ghidra/`	ملفات TSV الخاصة بـ LK وKVM EL3 للطراز الدقيق بالإضافة إلى سكربت تصحيح Ghidra.
`external/decompiled_G985F/`	ملفات مرجعية مفكوكة خاصة بـ G985F فقط.
`exynos990reverseEng_G985F/`	مشروع Ghidra خاص بـ G985F فقط.
`external/keys/exynos9830_crecker/`	حزمة المفاتيح المخصصة المشتركة.
`exploit/exploit.py`	نقطة دخول CLI مستقرة ومنسّق سير العمل.
`exploit/build_payloads.py`	باني الحمولات الأصلي متعدد المنصات المستخدم في الفحص المسبق على Windows وLinux وmacOS.
`exploit/preflight.py`	إعداد صورة العمل، وتصحيح LK، والتوقيع، والتحقق من الدمج.
`exploit/usb_transport.py`	تأطير PyUSB، واكتشاف الأجهزة، والكتابة فوقها، ونقل التفريغ.
`exploit/tampered_loader.py`	استخراج UH للطراز الدقيق، والتحقق من المحمّل المعدّل، ووميض EUB عبر Heimdall.
`exploit/stock_restore.py`	استخراج أرشيف المخزون للطراز الدقيق وبناء أوامر Heimdall.
`control_center/`	إجراءات الواجهة الخلفية للمتصفح، وفحوصات التبعيات، والمهام، وواجهة HTTP API.
`external/tools/*_crypto.py`	بدائيات تشفير/توقيع AES وECDSA المشتركة لـ EPBL/EL3.

`--prepare`	تشغيل الفحص المسبق دون فتح USB.
`--build-sboot`	تشغيل الفحص المسبق وبناء `sboot.bin` موقّع ومتحقق منه في دليل صورة الطراز.
`--signed`	إرسال حمولة المفتاح المخصص وسلسلة الإقلاع الموقعة من EUB.
`--ufs`	بدء مسار إقلاع UFS باستخدام `loader.bin`.
`--dump`	تشغيل `mem.bin` وتفريغ `0x20000` بايت من BootROM.
`--flash-tampered`	التحقق من UH للطراز الدقيق ووميضه إلى BOOTLOADER لفرض EUB.
`--flash-stock`	استخراج ووميض SBoot وTZSW وLDFW المخزون للطراز الدقيق من أرشيف BL الأصلي.

`fwbl1.img`	المفتاح الخاص لـ BL1 بالإضافة إلى كتل TEE/REE العامة من المرحلة الثانية
`epbl.img`, `el3_mon.img`	TEE من المرحلة الثانية
`bl2.img`, `lk.bin`	REE من المرحلة الثانية
`ldfw.img`, `tzsw.img`	TEE من المرحلة الثانية، تذييلات المرحلة الثانية الداخلية والخارجية

`mem.bin`	`0x02022010`	`0x02022010`
`loader.bin`	`0x02022010`	`0x02022010`
`Exynos990_boot_custom_key.bin`	`0x02022000`	المرحلة 1 المستقلة عن الموضع

`fwbl1.img`	`0x000000`	`0x003000`
`epbl.img`	`0x003000`	`0x016000`
`bl2.img`	`0x016000`	`0x082000`
`lk.bin`	`0x0DB000`	`0x35B000`
`el3_mon.img`	`0x35B000`	`0x39B000`

BL1	`0x02022000`
EPBL	`0x02026000`
BL2	`0x15600000`
LK	`0xE8000000`
EL3 monitor	`0xBFE80000`

CVE-2024-56426

الأكثر شعبية