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

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

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

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

دليل الأدوات

الفئات

عرض جميع الفئات
Loading categories
whatfiles — سجل الملفات التي يتم الوصول إليها بواسطة أي عملية لينكس. | Kitploit
أدوات/GitHubGitHub/spieglt/whatfiles
أدوات عامةالتحقيق الجنائي الرقميالتحاليل الرقمية الجنائية
GitHubspieglt/whatfiles

whatfiles

سجل الملفات التي يتم الوصول إليها بواسطة أي عملية لينكس.

عرض المستودع
946329منذ يوم واحدتمت المراجعة من قبل Kitploit

الأكثر شعبية

عرض الكل →

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

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

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

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

whatfiles

build and test

Whatfiles هي أداة مساعدة لنظام Linux تسجّل الملفات التي يقرأها/يكتبها/ينشئها/يحذفها برنامج آخر على نظامك. كما تتعقّب أي عمليات (processes) وخيوط (threads) جديدة ينشئها البرنامج المستهدف، وتسجّل ما إذا كانت كل عملية قد نجحت.

المبرّر:

لطالما أُصبت بالإحباط من عدم وجود أداة مساعدة بسيطة لمعرفة الملفات التي يلمسها برنامج ما من main() حتى الخروج. سواء كنت لا تثق بمورّد برمجيات أو كنت قلقًا بشأن البرمجيات الخبيثة، فمن المهم أن تعرف ما يفعله برنامج أو مثبّت (installer) بنظامك. أداة lsof تراقب لحظة زمنية واحدة فقط، وstrace ضخمة ومعقّدة نوعًا ما.

نموذج المخرجات:

root@kitploit:~
mode:   exec, file: /usr/bin/cp, syscall: execve(), PID: 17004, process: sh, result: 0
mode:   read, file: /tmp/demo/copy.txt, syscall: openat(), PID: 17004, process: /usr/bin/cp, result: -1 (No such file or directory)
mode:   read, file: /etc/hostname, syscall: openat(), PID: 17004, process: /usr/bin/cp, result: 3
mode: write+create, file: /tmp/demo/copy.txt, syscall: openat(), PID: 17004, process: /usr/bin/cp, result: 4
mode:  chmod, file: /tmp/demo/copy.txt, syscall: fchmodat(), PID: 17005, process: /usr/bin/chmod, result: 0
mode: rename, file: /tmp/demo/copy.txt, to: /tmp/demo/renamed.txt, syscall: renameat2(), PID: 17006, process: /usr/bin/mv, result: 0
mode:   read, file: /tmp/demo/missing.txt, syscall: openat(), PID: 17007, process: /usr/bin/cat, result: -1 (No such file or directory)
mode: delete, file: /tmp/demo/renamed.txt, syscall: unlinkat(), PID: 17008, process: /usr/bin/rm, result: 0

يذكر كل سطر ما تم فعله بالملف، والملف نفسه، وأي استدعاء نظام (syscall) قام بذلك، وأي عملية وخيط، وما أعاده النواة (kernel). المسارات دائمًا مطلقة: تُحلّ المسارات النسبية مقابل دليل العمل الخاص بالعملية، أو مقابل الدليل الذي مرّرته إلى استدعاء نظام من نوع *at(). قيمة result هي القيمة المُعادة من استدعاء النظام، لذا يمكن التمييز بين الوصول الفاشل والناجح.

إلى جانب الفتح والإنشاء والحذف، تُبلّغ whatfiles عن rename وlink وsymlink وmkdir وrmdir وtruncate وchmod وchown وexec لبرنامج ما. يغطّي SYSCALLS.md ما لم يُبلَّغ عنه بعد وسبب استحقاق كل إضافة.

الاستخدام:

  • الاستخدام الأساسي، يشغّل ls ويكتب المخرجات إلى ملف سجل في الدليل الحالي:

    $ whatfiles ls -lah ~/Documents

  • تحديد موقع ملف المخرجات باستخدام -o:

    $ whatfiles -o MyLogFile cd ..

  • تضمين مخرجات التصحيح، والطباعة إلى stdout بدلًا من ملف السجل:

    $ whatfiles -d -s apt install zoom

  • الارتباط بعملية قيد التشغيل حاليًا (يتطلب صلاحيات الجذر):

    $ sudo whatfiles -p 1234

  • إنهاء البرنامج المتعقَّب إذا قُتلت whatfiles نفسها، بدلًا من تركه يستمر دون تعقّب:

    $ whatfiles -k ./installer.sh

اضغط Ctrl-C في أي وقت: تنفصل whatfiles عن كل ما تتعقّبه، وتترك تلك العمليات قيد التشغيل، وتُنهي كتابة السجل.

التوزيع

توجد ملفات ثنائية جاهزة للاستخدام على صفحة releases! كما أضافها أحدهم بلطف إلى مستودع Arch، وأعدّ letompouce خط أنابيب GitLab أيضًا.

الترجمة (تتطلب gcc وmake):

root@kitploit:~
$ cd whatfiles
$ make
$ sudo make install

تدعم معماريات x86 وx86_64 وARM32 وARM64. يحترم make install المتغيّرين PREFIX وDESTDIR.

يتطلب Linux 3.4 أو أحدث. على Linux 5.3 وأحدث، تسأل whatfiles النواة مباشرة عن كل توقف لاستدعاء نظام، وهذا ما يجعل استدعاءات النظام ذات 32 بت على جهاز 64 بت تُفكّك بشكل صحيح؛ وعلى النوى الأقدم تتراجع إلى قراءة السجلات (registers).

Android

قم بالترجمة المتقاطعة باستخدام NDK، ثم ادفع الملف الثنائي إلى الجهاز:

root@kitploit:~
$ make android NDK=~/Android/Sdk/ndk/<version>
$ adb push bin/whatfiles-android /data/local/tmp/whatfiles
$ adb shell chmod 755 /data/local/tmp/whatfiles
$ adb shell /data/local/tmp/whatfiles -o /data/local/tmp/ls.log ls /sdcard

يحدّد ANDROID_ABI القيمة arm64، وهي الافتراضية، أو arm32 أو x86_64 أو x86. ويضبط ANDROID_API الحد الأدنى لمستوى API، وقيمته الافتراضية 21.

تختلف بعض الأمور على الجهاز:

  • ضع الملف الثنائي في /data/local/tmp. فـ /sdcard مُثبَّت بدون صلاحية التنفيذ.
  • دليل العمل في adb shell غير قابل للكتابة، لذا مرّر -o مع مسار تحت /data/local/tmp، أو -s للكتابة إلى stdout.
  • تشغيل أمر تحت whatfiles يعمل كمستخدم shell العادي، وكذلك الارتباط بعملية بدأها ذلك المستخدم. أما الارتباط بأي شيء آخر، كتطبيق مثلًا، فيحتاج صلاحيات الجذر، لذا استخدم adb root على بناء userdebug. على محاكي Android 14 نجح ذلك مع تفعيل SELinux؛ وقد ترفض سياسة جهاز إنتاجي ذلك رغم ذلك.
  • يبني make test-android NDK=~/Android/Sdk/ndk/<version> كلاً من whatfiles وبرامج الاختبار للجهاز المتصل، ويشغّل الفحوصات هناك، ويزيل ما دفعه.
  • يُقرأ تطبيق 32 بت متعقَّب من بناء arm64 بأرقام استدعاءات النظام ذات 32 بت وسجلات الوسائط بدلًا من اعتباره 64 بت. لم يُختبر ذلك المسار على عتاد حقيقي: فالمحاكي المستخدم للاختبار هنا لا يملك ABI ذا 32 بت.

يبني make test البرامج في tests/ ويشغّلها تحت whatfiles للتحقق من سلوكها، بما في ذلك تسليم الإشارات (signals)، وتغطية الخيوط والعمليات الفرعية، ومعالجة المقاطعات.

أسئلة قد تُطرح في مرحلة ما:

  • أليست هذه مجرد إعادة تنفيذ لـ strace -fe trace=creat,open,openat,unlink,unlinkat ./program?

    نعم. لكنها تهدف إلى أن تكون أبسط وأكثر ملاءمة للمستخدم.

  • هل توجد نسخ لـ Mac وWindows؟

    لا. يتطلب تعقّب استدعاءات النظام على Mac استخدام task_for_pid()، وهو ما يتطلب توقيع الشيفرة (code signing)، وهو ما لم أتمكن من تشغيله، وعلى أي حال لا رغبة لي في دفع 100 دولار سنويًا لـ Apple لكتابة برمجيات حرة. يمكن استخدام dtruss على Mac لتتبّع عملية واحدة وأبنائها، رغم أن علم -t يبدو أنه يقبل استدعاء نظام واحدًا فقط للتصفية. ويفعل fs_usage شيئًا مشابهًا رغم أنني لست متأكدًا مما إذا كان يتتبّع العمليات/الخيوط الفرعية. أما Process Monitor لنظام Windows فهو رائع جدًا.

القيود:

  • البرامج التي تُسلّم العمل إلى نسخة من نفسها. المتصفحات خاصةً: إذا كانت هناك نسخة قيد التشغيل بالفعل، فإن النسخة التي تشغّلها تمرّر طلبك إليها وتخرج، فلا يبقى لدى whatfiles شيء لتعقّبه فتتوقف، بينما تأتي النافذة التي طلبتها من النسخة غير المتعقَّبة. تعقّب نسخة منفصلة بدلًا من ذلك، بشيء مثل whatfiles firefox --no-remote --profile ~/ff-trace-profile مع دليل ملف تعريف (profile) غير موجود بعد، أو أغلق النسخة قيد التشغيل أولًا.

  • ليست حدًا أمنيًا. يمكن لبرنامج لا يريد أن يُراقَب أن يعرف أنه متعقَّب، كما أن io_uring ينفّذ عمليات الملفات دون استدعاءات النظام التي تراقبها whatfiles. تعامل مع السجل كوصف لما فعله برنامج، لا كدليل على كل ما كان يمكن أن يفعله.

  • السرعة. كل استدعاء نظام يوقف العملية المتعقَّبة مرتين، لذا تعمل البرامج كثيفة استدعاءات النظام أبطأ عدة مرات من المعتاد. هذه هي التكلفة نفسها التي تدفعها strace عند تتبّع جميع استدعاءات النظام.

  • الارتباط يحتاج صلاحيات. يتطلب -p عمومًا صلاحيات الجذر، أو قيمة مخفّفة لـ /proc/sys/kernel/yama/ptrace_scope. وارتباط مرفوض يترك الهدف يعمل بشكل طبيعي.

  • إذا قُتلت whatfiles مباشرةً بـ SIGKILL، يستمر البرنامج الذي كانت تتعقّبه في العمل، دون تعقّب، إلا إذا كان قد بدأ بـ -k.

الميزات المخطَّطة:

  • لا شيء حاليًا، منفتح على الطلبات وطلبات السحب (PRs).

شكرًا لاهتمامك، ويرجى أيضًا الاطلاع على Cloaker وNestur وFlying Carpet!

تنزيل الأداة