Skip to content
KitploitKITPLOIT
أدواتعمليات الاستغلالالمدونة
Log in
إرسال
أدواتعمليات الاستغلالالمدونة
إرسال

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

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

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

دليل الأدوات

الفئات

عرض جميع الفئات
Loading categories
ghostlock-a17 — استغلال نواة لثغرة CVE-2026-43499 على Samsung Galaxy A17 يحقق صلاحيات الجذر (root) عبر تجاوز KDP، واستعادة KASLR، وتنفيذ workqueue مزورة مع shell دائم. | Kitploit
أدوات/GitHubGitHub/mobilehackinglab/ghostlock-a17
أمان أندرويدتصعيد الامتيازاتآليات الاستمراريةالاستغلالما بعد الاستغلالأمن الجوالاستغلال الملفات الثنائية
GitHubmobilehackinglab/ghostlock-a17

ghostlock-a17

استغلال نواة لثغرة CVE-2026-43499 على Samsung Galaxy A17 يحقق صلاحيات الجذر (root) عبر تجاوز KDP، واستعادة KASLR، وتنفيذ workqueue مزورة مع shell دائم.

عرض المستودع
176126منذ 2 أشهرلم تتم المراجعة بعد

الأكثر شعبية

عرض الكل →

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

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

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

عرض جميع الأدوات →
مشاركة

GhostLock — CVE-2026-43499 على Samsung Galaxy A17

سلسلة استغلال كاملة من المستخدم إلى الجذر لثغرة CVE-2026-43499 ("GhostLock") على هاتف Samsung Galaxy A17 SM-A175F، الذي يعمل بنظام Android 16 / GKI 6.12.

تبدأ السلسلة من بدائيات GhostLock العامة وتنتهي بمساعد usermode يُنفَّذ بصلاحيات:

uid=0(root) gid=0(root) groups=0(root)
context=u:r:kernel:s0

كما يبدأ صدفة جذر (root shell) دائمة لكل إقلاع عبر g4d / g4sh ويخرج دون حدوث kernel panic.

📖 الشرح التقني الكامل:
https://www.mobilehackinglab.com/blog/cve-2026-43499-ghostlock-a17-root-shell

ملاحظة بحثية

لم نكتشف CVE-2026-43499. يعود الفضل في الثغرة الأصلية وأبحاث IonStack إلى Nebula Security.

يوثّق هذا المستودع عملية النقل المستقلة التي أجريناها إلى Samsung Galaxy A17، والتغييرات المطلوبة لتناسب حمايات نواة Samsung، ومرحلة استغلال نهائية جديدة.

لأغراض البحث الأمني المصرّح به والأغراض التعليمية فقط.


الهدف

CVECVE-2026-43499 — "ghostlock"
الجهازSamsung Galaxy A17 (SM-A175F, mt6789)
GPUMali-G57
النواة6.12.23-android16-5-abA175FXXS3BZA5-4k
النتيجةuid=0(root) / u:r:kernel:s0
صدفة الجذرخادم g4d + عميل g4sh
الاستمراريةلكل إقلاع
خروج الاستغلالنظيف، دون kernel panic
التخفيفات التي واجهناهاSamsung KDP، DEFEX، SELinux، PANIC_ON_OOPS، arm64 KASLR
البرامج الثابتة المدعومةA175FXXS3BZA5 (kernel 6.12.23) و A175FXXS6CZG1 (kernel 6.12.38، SPL 2026-07-05) — كلاهما مُتحقَّق منه على الجهاز، بنفس السلسلة

ما الذي يجعل عملية النقل هذه مختلفة؟

توفّر أبحاث ghostlock الأصلية البدائيات الأولية للدخول:

pselect reclaim
      ↓
fake rt_mutex_waiter
      ↓
constrained rb-tree pointer write

على Galaxy A17، مع ذلك، لا تعمل النهاية المعتادة لتصحيح بيانات الاعتماد.

يحظر Samsung KDP الكتابة المعتادة لبيانات الاعتماد

يحمي KDP بيانات kernel المتعلقة ببيانات الاعتماد عند EL2.

في هذا البناء، تم إسقاط محاولات تعديل بيانات اعتماد المهام بصمت حتى عندما كانت العناوين المستهدفة صحيحة.

لذلك بدلاً من كتابة بيانات اعتماد root، يجعل هذا المنفذ kernel ينفّذ باستخدام بيانات اعتماد مميزة موجودة.

النهاية الجديدة: تنفيذ workqueue مزوّر

المرحلة النهائية:

constrained kernel write
        ↓
physical read/write channel
        ↓
KASLR slide recovery
        ↓
discover system_wq / cpu_pwq
        ↓
forge work_struct
        ↓
call_usermodehelper_exec_work
        ↓
/system/bin/sh
        ↓
uid=0(root), u:r:kernel:s0

يُوضع عنصر عمل مُزوَّر على تجمّع system_wq المرتبط ويُشغَّل عبر عاصفة تخصيص/تحرير ptmx.

ينفّذ مساعد وضع المستخدم الناتج ببيانات اعتماد init.

لا حاجة إلى استبدال بيانات اعتماد المهمة.


سلسلة الاستغلال

userspace shell (uid 2000)
        │
        ▼
pselect / PI-futex primitive
        │
        ▼
constrained aligned kernel pointer write
        │
        ▼
forged pipe_buffer channel
        │
        ▼
arbitrary physical read/write
        │
        ├── recover KASLR slide
        │
        ├── locate system_wq / cpu_pwq
        │
        └── prepare forged work_struct
        │
        ▼
queue usermode-helper work
        │
        ▼
ptmx storm wakes worker
        │
        ▼
/system/bin/sh runs with init creds
        │
        ▼
uid=0(root)
        │
        ▼
g4d → @ghostlockd → g4sh

تغييرات هندسية رئيسية

بالمقارنة مع منفذ OnePlus العام، أُعيدت هندسة معظم المراحل بعد بدائية الكتابة الأولية.

1. مرحلة جذر جديدة متوافقة مع KDP

استُبدلت المرحلة النهائية الخاصة بترقيع بيانات الاعتماد بعنصر workqueue مُزوَّر يستهدف مسار تنفيذ usermode-helper.

يتجنب هذا كتابة بنى cred المحمية بالكامل.

2. أوراكل إزاحة KASLR جديدة

كان نهج تثبيت أحداث perf السابق غير موثوق على هذا الجهاز.

بدلاً من ذلك، يستخدم الاستغلال ثلاثة مؤشرات مُزاحة من إدخال ctl_table الخاص بـ boot_id:

procname
data
proc_handler

يتم التحقق المتقاطع من الثلاثة جميعًا قبل قبول الشريحة.

3. اكتشاف قائمة انتظار العمل وقت التشغيل

يتم اكتشاف cpu_pwq عبر التنقل في:

system_wq → pwqs

بدلاً من الاعتماد على إزاحة ثابتة خاصة بالجهاز.

4. خروج نظيف من الاستغلال

تترك القناة الأصلية تغييرات جانبية على حالة struct page يمكن أن تُفعّل PANIC_ON_OOPS أثناء الإنهاء.

تتجنب السلسلة الحالية انهيار الإنهاء وقد أُثبت أنها تخرج بشكل نظيف بعد الحصول على صلاحيات الجذر.

5. صدفة الجذر

يبدأ مساعد وضع المستخدم:

g4d

الذي يستمع على مقبس Unix المجرّد:

@ghostlockd

g4sh يتصل به ويوفر إما صدفة جذر تفاعلية أو تنفيذ أمر لمرة واحدة.

/data/local/tmp/a/g4sh
/data/local/tmp/a/g4sh -c "id"

لماذا يُعد Galaxy A17 مثيرًا للاهتمام

يجمع هذا الهدف بين عدة حمايات تُعطّل تقنيات استغلال نواة Android الشائعة:

  • Samsung KDP — يحمي بيانات النواة المتعلقة ببيانات الاعتماد عند EL2
  • DEFEX — يقيّد التنفيذ ذا الامتيازات من المسارات غير الموثوقة
  • SELinux
  • PANIC_ON_OOPS / PANIC_ON_BUG
  • إزاحات KASLR كبيرة على arm64
  • بدائية كتابة مقيّدة بالمؤشرات فقط

وقد فرض ذلك استراتيجية استغلال مختلفة عن المعتاد:

arbitrary RW → patch cred → disable SELinux

بدلاً من ذلك:

arbitrary RW → recover runtime state → forge kernel work → execute usermode helper

البناء

يتطلب Android NDK حديثًا.

make        # BZA5 firmware (kernel 6.12.23)
make czg1   # CZG1 firmware (kernel 6.12.38): per-target slide anchors,
            # offsets are uname-keyed at runtime

ينتج:

ghostlock   # exploit (ghostlock-czg1 for the CZG1 build)
g4d         # static root-shell daemon
g4sh        # root-shell client

التشغيل

ادفع الملفات الثنائية:

adb push ghostlock /data/local/tmp/a/g4
adb push g4d /data/local/tmp/a/g4d
adb push g4sh /data/local/tmp/a/g4sh

adb shell 'chmod 755 /data/local/tmp/a/g4 /data/local/tmp/a/g4d /data/local/tmp/a/g4sh'

شغّل حلقة الاستغلال المدركة لإعادة التشغيل:

./scripts/rr_loop4.sh

بعد ROOTED:

adb shell /data/local/tmp/a/g4sh

أو نفّذ أمرًا واحدًا:

adb shell '/data/local/tmp/a/g4sh -c "id"'

النتيجة المتوقعة:

uid=0(root) gid=0(root) groups=0(root) context=u:r:kernel:s0

الموثوقية

البدائية احتمالية وتعتمد بشدة على ظروف الإقلاع.

قد يتطلب الاستغلال الناجح محاولات متكررة. يتولى السكربت rr_loop4.sh المرفق إعادة المحاولات ودورات إعادة التشغيل تلقائيًا.

هذا استغلال بحثي، وليس أداة تجذير فورية تُنفَّذ بضغطة واحدة.


التحقق عبر QEMU

يحتوي qemu-e2e/ على أداة تحقق من طرف إلى طرف باستخدام نواة Samsung المستخرجة.

استُخدمت الأداة لاختبار:

  • تغييرات سلسلة الاستغلال
  • التعامل مع KASLR
  • تزوير workqueue
  • تنفيذ usermode-helper
  • إنهاء الاستغلال بشكل نظيف
  • رحلات الذهاب والإياب لـ g4d / g4sh

صورة نواة Samsung نفسها غير مضمّنة.

انظر:

qemu-e2e/

لتعليمات الإعداد.


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

Makefile
src/                  exploit source and device profiles
src/daemon/           g4d root daemon + g4sh client
docs/OFFSETS.md       validated device offsets
docs/PORTING.md       porting notes
examples/             proof-of-root artifacts
scripts/rr_loop4.sh   reboot-aware exploit loop
qemu-e2e/             end-to-end QEMU validation

أبحاث ذات صلة

أبحاث GhostLock / IonStack الأصلية

NebuSec:

https://nebusec.ai/research/ionstack-part-3/

https://github.com/NebuSec/CyberMeowfia/tree/main/IonStack

منفذ OnePlus

https://github.com/JoinChang/ghostlock-oneplus

مقال Mobile Hacking Lab

نظرة أعمق على منفذ Samsung Galaxy A17، وقيود KDP، واستعادة KASLR، والمرحلة النهائية القائمة على workqueue، وتنفيذ root-shell:

https://www.mobilehackinglab.com/blog/cve-2026-43499-ghostlock-a17-root-shell


إثبات الحصول على root

تتوفر مخرجات الأجهزة الحقيقية تحت:

examples/

بما في ذلك سجلات الاستغلال والتحقق من سياق الجذر.

مثال:

uid=0(root)
gid=0(root)
groups=0(root)
context=u:r:kernel:s0

إخلاء المسؤولية

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

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

تنزيل الأداة