
# تطبيق GhostLock للتنفيذ بنقرة واحدة (CVE-2026-43499)
中文: README_ZH.md
uname -r بالضبط ويرفض البناءات غير المدعومة، مع عرض الحالة في الأعلى. توجد الملفات التعريفية المدمجة في app/src/main/assets/kernel_profiles/: ملف HOCON واحد لكل إصدار، وindex.conf كفهرس وقت التشغيل، وقوالب عائلة الإصدار <major.minor>-template.conf.للاطلاع على سير عمل نقل الأجهزة الكامل، وروابط قوالب عائلة النواة، وأسباب الضبط، راجع دليل نقل ملفات تعريف النواة.
الصفوف المعلَّمة صراحةً بـ Shizuku required تعمل عبر UserService في الصدفة. شغّل Shizuku باستخدام ADB وانقر على بطاقة الحالة لمنح الوصول؛ أما جميع الصفوف الأخرى فتستخدم مسار التنفيذ العادي للتطبيق.
افتح GhostLock وانقر على Run. يوفّر KernelSU (me.weishu.kernelsu) أو ReSukiSU (com.resukisu.resukisu) أو KowSU (com.kowx712.supermanager) الأمر ksud لتحميل الوحدات؛ وبدونه، يمنح W1/W2 معرّف المستخدم 0 لكن دون تحميل أي وحدة.
سلسلة التنفيذ عبارة عن خط أنابيب من ثلاثة مكوّنات: واجهة أمامية (بدء/تسليم root_child)، وخلفية (بدائية futex الخاصة بـ CVE-2026-43499)، ومسار برمجية وسيطة. تُنشأ التوليفات المفهرسة في وقت البناء؛ ويحدد الملف التعريفي المُستنتَج أيّها يعمل. يسابق المسار نواتين: على نوى 6.6/6.12 ذات tree-waiter يطرق الخيط الرئيسي select بينما يعكّر خيط المستهلك أولوية المنتظر؛ وعلى نوى 6.1 ذات compact-waiter يقود getsockopt(TCP_ZEROCOPY_RECEIVE) عبر صفحة مثقوبة؛ أما نوى 5.15 فتستخدم منتظر multicast. كما يأتي زوج المعالجات من الملف التعريفي المُستنتَج.
لا يحتوي adb/shell على مرشّح seccomp، لذا يتم تخطي W3 - وهو أمر مفيد للتحقق السريع:
make -C src ghostlock
./gradlew exportKernelProfiles
adb push build/native/ghostlock /data/local/tmp/ghostlock
adb push build/kernel-profiles/<release>.bin /data/local/tmp/profile.bin
adb shell chmod 755 /data/local/tmp/ghostlock
adb shell /data/local/tmp/ghostlock --load-prebuilt-profile /data/local/tmp/profile.bin
يستخرج tools/extract_rs الإزاحات من boot.img (مع xbl_config.img الاختياري)، أو من ملف OTA ZIP كامل، أو من رابط http(s) يشير إلى أحدهما. تأتي kallsyms من --kallsyms أو تُستعاد من الجدول المضمّن في الصورة. يُشتق pselect_waiter_shift وoff_slide_loggers_0_1 بواسطة المفكّك المدمج لـ arm64. لا تحتوي صور MediaTek على xbl_config.img وعادةً لا تحتوي على BTF: يُشتق عنوان التحميل الفيزيائي من _text في kallsyms (يمكن تجاوزه بـ --phys).
Push-Location tools/extract_rs
cargo build --release
Pop-Location
build/extract/release/ghostlock-extract.exe boot.img --xbl-config xbl_config.img --format conf --out profile.conf
build/extract/release/ghostlock-extract.exe OTA.zip --format conf --out profile.conf
--format conf هو مخرَج المستخرِج: ملف تعريفي مسطّح ومكتفٍ ذاتيًا (بدون أسطر include، مع تضمين ثوابت بيانات الاعتماد/KernelSnitch المشتركة للإصدار 6.x، والمسار المختار من أدلة --analysis ما لم يتجاوزه --route). يُصدر المستخرِج كل حقل تنتجه الصورة فعليًا ويحذف الباقي؛ ولا يملأ الفجوات أبدًا من تخمينات عائلة نواة مجاورة (6.6 غير الموثّقة، أو الافتراضي -2، أو ثوابت multicast للإصدار 5.15، أو قيمة phys افتراضية). كل مخرَج هو مرشّح غير موثّق: قابل للاستيراد والتحليل، مع حجب الحقول المفقودة أو غير الصالحة بواسطة التحقق قبل التنفيذ في التطبيق، لذا لا يعني التشغيل الناجح أبدًا دعم الجهاز. على الإصدار 5.x يشتق أيضًا إصلاح مرجع بيانات الاعتماد من init_cred وهندسة multicast من BTF (راجع docs/analysis/extractor-5x-derivation-plan.md). يبقى --format json لمسار الاستيراد v1. لإضافة ملف تعريفي مدمج، أكمل ووثّق قالب عائلة الإصدار المطابق، واحفظه كملف .conf مستقل، وأضفه إلى kernel_profiles/index.conf. سجل offsets.h القديم بلغة C مهجور ومحذوف.
لا تحتوي صور MediaTek على xbl_config.img وعادةً لا تحتوي على BTF مضمّن، لذا
لا يستطيع المستخرِج اشتقاق العنوانين الفيزيائيين (kernel_phys_load،
kernel_phys_offset) من الصورة ويتركهما null. ثم يتراجع وقت التشغيل
إلى صيغة SoC، والتي تفشل عند W1 على MediaTek. املأ كليهما بتشغيل
مستخرِج tools/mtk-phys/ المنفصل على جهاز مُروّت (يقرأ
/proc/iomem) ولصق القيم في التجاوزات المتقدمة في التطبيق. راجع
MEDIATEK.md.
يفكّك المستخرِج remove_waiter() قبل استخراج الإزاحات. تُرفض النوى التي تحتوي على الإصلاح برمز خروج 6؛ ولا تستمر سوى النوى القابلة للاستغلال.
يمكن تحليل ملف OTA كامل بالكامل على الهاتف: يُستخرج boot مع xbl_config
تلقائيًا. مرّر --work-dir كدليل قابل للكتابة من التطبيق عند
التشغيل داخل بيئة التطبيق المعزولة. الترجمة المتقاطعة والدفع:
rustup target add aarch64-linux-android
$ndk = "$env:ANDROID_HOME\ndk\<version>\toolchains\llvm\prebuilt\windows-x86_64\bin"
$env:CC_aarch64_linux_android = "$ndk\aarch64-linux-android35-clang.cmd"
$env:AR_aarch64_linux_android = "$ndk\llvm-ar.exe"
$env:CARGO_TARGET_AARCH64_LINUX_ANDROID_LINKER = $env:CC_aarch64_linux_android
Push-Location tools/extract_rs
cargo build --release --target aarch64-linux-android
Pop-Location
adb push build/extract/aarch64-linux-android/release/ghostlock-extract /data/local/tmp/
adb shell /data/local/tmp/ghostlock-extract /sdcard/OTA.zip
لم تعد النوى الجديدة بحاجة إلى إعادة بناء التطبيق: انقر على Import offsets.conf (HOCON)
واختر ملف .conf المسطّح من المستخرِج، أو استخدم Import offsets.json (v1)
لتقرير JSON أقدم. يُحوَّل v1 JSON داخل التطبيق، لذا لا حاجة لدفع أي شيء
إلى الجهاز: تبدأ البرمجية الأصلية دائمًا من مستند GLK1 الذي يرسله التطبيق
على stdin، وتطابق uname -r الحالي مع الملف التعريفي المُستنتَج
قبل رفض النواة. تدمج عمليات الاستيراد عبر الملفات؛ ويُطلب التأكيد قبل الكتابة فوق إصدار مخزّن مسبقًا.
يمكن للتطبيق أيضًا توليد الملف التعريفي بنفسه — Parse OTA link (رابط OTA ZIP
كامل) وParse image (boot.img + xbl_config.img الاختياري) يشغّلان
المستخرِج داخل العملية ويكتبان ملف .conf مسطّحًا في دليل بيانات التطبيق عند
النجاح:
# GhostLock kernel profile: 6.12.38-android16-5-g844001fb8721-ab14552068-4k (HOCON, self-contained).
release = "6.12.38-android16-5-g844001fb8721-ab14552068-4k"
schema_version = 1
kernel_major = 6
recommend_shizuku = 0
kernel_phys_load = 0xC7800000
route {
select_stack {
waiter_shift = 0
}
}
fallback {
to = "none"
}
kernelsnitch {
collisions = 4
}
task_struct {
prio = 148
cred = 2304
}
cred {
caps_offset = 48
copy_size = 136
usage_value = 1
caps_count = 5
caps_value = -1
}
offset {
init_task = 37801728
init_cred = 37891184
}
استنادًا إلى المشاريع التالية، المرخّصة بموجب Apache License 2.0 (راجع LICENSE):