شرح Process Monitor: افهم NAME NOT FOUND وACCESS DENIED بدل ما تضيع بين آلاف الأحداث

ضغطت حفظ داخل تطبيق التدريب فظهرت رسالة عامة: «تعذر الحفظ». ملف الإعداد موجود، والمجلد يفتح، والحساب يقدر يشوفه. هنا مشاهدة العملية في Process Explorer أو قراءة ACL وحدها قد لا تجاوبك: وش العملية التي حاولها التطبيق فعلًا، وعلى أي مسار، وبأي نتيجة؟ هذا النوع من الأسئلة يناسب Process Monitor، المعروف أيضًا باسم Procmon.

خلنا نمسك محاولة واحدة في لاب ويندوز مصرح، ونتتبع نشاطها خلال وقت قصير. بنقرأ الأحداث كأدلة تحتاج سياقًا، مو كقائمة أخطاء وكل سطر فيها ثغرة. لا نعدل صلاحيات حقيقية ولا نضع ملفات بديلة في مسارات تطبيقات؛ المثال مخصص لتشخيص سلوك برنامج تدريب وملفات وهمية.

قبل الالتقاط: اكتب المشكلة في سطر يحدد التجربة

«التطبيق ما يشتغل» وصف واسع. الأفضل مثلًا: «حساب التدريب يفتح ملف report.txt من مجلد اللاب، لكن الضغط على حفظ يرجع رسالة رفض». هذا السطر يحدد المستخدم والوظيفة والمورد المتوقع. بعده اكتب نسخة التطبيق، ووقت التجربة، وهل المشكلة تتكرر في كل محاولة أو بدأت بعد تغيير معروف.

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

احصل على Procmon من صفحة Sysinternals الرسمية، وراجع متطلبات الإصدار على نظام لابك ومساعدته. الأداة تراقب نشاطًا على مستوى النظام، لذلك تشغيلها يتبع تجهيز وصلاحيات جهة التدريب. إذا كانت البيئة لا تسمح بها، اطلب من مسؤولها التقاطًا معتمدًا بدل إيقاف حماية أو تثبيت أدوات جانبية بلا سبب.

جهّز ملفًا وهميًا وتطبيقًا معروف السلوك. اكتب النتيجة المتوقعة قبل القياس: هل يفترض حفظ الملف نفسه؟ أم إنشاء نسخة؟ أم كتابة ملف مؤقت ثم استبدال الأصلي؟ إن لم تعرف، اجعلها فرضيات تحتاج التتبع. لا تفترض أن زر حفظ يعني بالضرورة كتابة مباشرة إلى الملف الذي أمامك.

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

فلتر العملية يساعدك تشوف، لكنه ما يعيد كتابة الواقع

Procmon يدعم فلاتر على خصائص الأحداث، ومنها هوية العملية والمسار والنتيجة. ابدأ بتحديد عملية التطبيق التدريبي أو معرف النسخة الحالية منه. اسم متكرر قد يشمل أكثر من نسخة، وPID قد يتغير إذا أعدت تشغيل التطبيق. سجل ما استخدمته في الفلتر حتى يستطيع مسؤول اللاب إعادة القراءة.

لا تبدأ بفلتر يعرض الرفض فقط. لو أخفيت كل الأحداث الناجحة، فقد تفوتك قراءة تبين أن التطبيق وجد الملف في مسار ثانٍ بعد محاولة فاشلة عادية. اجمع أولًا سياق الوظيفة ضمن حدود معقولة، ثم استخدم التصفية لتحليل سؤال محدد. الفشل والنجاح حوله قد يشرحان بعضهما.

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

خلنا نفترض تطبيقًا يطلق مساعدًا عند الحفظ. تصفية عملية الواجهة وحدها قد لا تُظهر ما فعله المساعد. هذا ليس دليلًا أن الكتابة لم تحدث؛ قد تكون طلبت منظورًا ناقصًا. راجع العلاقة بالعملية الأخرى داخل فترة التجربة، وأضفها إلى التحليل إذا كانت ضمن النطاق، بدل توسيع الالتقاط إلى كل النظام بلا خطة.

اكتب مع الدليل: الفلاتر، وبداية الفترة ونهايتها، وأي أحداث أو عمليات استبعدتها. هذه معلومات تؤثر في الاستنتاج. عبارة «ما وجدنا كتابة» تصبح أدق إذا قلت إن البحث شمل العملية المحددة والفترة المحددة، أما النفي الكامل فيحتاج تغطية لا يوفرها فلتر ضيق دائمًا.

اقرأ السطر كحدث: العملية والمسار والنتيجة والتفاصيل

الأعمدة المعتادة تساعدك تربط الوقت والعملية والعملية التقنية التي نفذتها والمسار ونتيجتها. لكن اسم Operation يحتاج تفسيرًا. ظهور CreateFile لا يعني تلقائيًا أن التطبيق أنشأ ملفًا جديدًا؛ واجهة CreateFile في ويندوز تستخدم أيضًا لفتح موارد موجودة وفق خيارات الطلب. المعنى يتحدد بالتفاصيل والنتيجة.

لذلك عندما ترى حدثًا يتعلق بملف التقرير، افتح تفاصيله واقرأ نوع الوصول المطلوب وطريقة الفتح والمعلومات المناسبة للسؤال. قد يطلب التطبيق قراءة، أو كتابة، أو حقوقًا أوسع من الوظيفة التي تتوقعها. كلمة SUCCESS وحدها تقول إن الحدث المحدد نجح، ولا تقول إن وظيفة الحفظ كاملة انتهت بنجاح.

وبعد فتح مورد قد تأتي عمليات قراءة أو كتابة أو استعلام وإغلاق. العلاقة الزمنية تفيدك، لكن لا تخترع كمية بيانات مكتوبة أو محتواها من وجود handle أو طلب فتح. إذا تحتاج إثبات كتابة محددة، اقرأ حدثها وتفاصيله ضمن التغطية المتاحة. أدوات التتبع تعرض عمليات، وليست بديلًا عن معرفة غرض التطبيق.

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

في تمرينك، اختر حدثًا واحدًا ثم اكتب تفسيره بجملة كاملة: «العملية المحددة حاولت فتح المورد المحدد بالحقوق الظاهرة، وكانت النتيجة كذا عند هذا الوقت». إذا ما قدرت تصيغ الجملة بدون تخمين، فهناك معلومة تحتاج القراءة أو التحقق. هذه العادة تحول آلاف الصفوف إلى أدلة مترابطة بدل صور مليانة تفاصيل لا تشرح شيئًا.

NAME NOT FOUND: فشل طلب معين، مو فشل التطبيق كله

قد يبحث التطبيق عن ملف إعداد اختياري ثم يكمل باستخدام إعداد افتراضي. وقد يجرب مسارًا ثم يجد المورد في مكان آخر. لذلك ظهور NAME NOT FOUND لا يعني وحده أن النظام معطل، ولا أن ملفًا يجب إنشاؤه في ذلك المكان. اربط الحدث بالسلوك الذي تحاول تفسيره.

اسأل ثلاثة أسئلة: ما المورد الذي طُلب؟ هل كان وجوده متوقعًا في تصميم التطبيق؟ وماذا فعل التطبيق بعد النتيجة؟ إذا جاء نجاح مناسب بعده واستمرت الوظيفة، فقد تكون المحاولة جزءًا طبيعيًا من البحث. أما إذا انتهت الوظيفة برسالة وتؤكد وثيقة التطبيق حاجته للمورد، فالملاحظة تحتاج مراجعة المسار والتثبيت.

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

وإذا كان الاسم يتعلق بمكتبة DLL، لا تحوله مباشرة إلى إثبات DLL Hijacking. ترتيب البحث وتكوين التطبيق والمسارات والحقوق وشروط التحميل مهمة. وجود محاولة باسم مفقود نقطة تحتاج تفسيرًا، وليس سلسلة استغلال مثبتة. لا تضع مكتبة بديلة لتجربة الأثر على برنامج حقيقي دون نطاق وخطة معتمدين.

نتيجة جيدة قد تقول: «ظهرت محاولة بحث فاشلة عن الملف الاختياري، ثم نجحت قراءة الملف البديل واستمرت الوظيفة. لم يثبت أن المحاولة سبب رسالة الحفظ». هذه النتيجة تستبعد تفسيرًا خاطئًا، وهذا مفيد. مو كل تحليل لازم يطلع ثغرة؛ أحيانًا أهم نتيجة أنك توقفت عن مطاردة حدث طبيعي.

ACCESS DENIED: أي حق طُلب، وأي جهة كانت تطلبه؟

الرفض يحدد أن الطلب المعين لم يُسمح به في ظروفه، لكنه لا يقول إن الحساب لا يملك أي وصول إلى الملف. قد يملك القراءة ويرفض طلب كتابة، أو يستطيع التعامل مع ملف ويمنع من مورد آخر. اقرأ تفاصيل العملية والحقوق المطلوبة قبل توصية تمنح Full Control لمجلد واسع.

إذا زار المستخدم المجلد في المستكشف ونجح، فهذا لا يثبت أن التطبيق يطلب الحقوق نفسها. التطبيق قد يحفظ بإنشاء ملف مؤقت أو إعادة تسمية أو استبدال، وتلك خطوات تختلف عن عرض الاسم أو قراءة المحتوى. التتبع هنا يساعد تربط الرسالة بالعملية الفعلية بدل الاكتفاء بقول «أنا أقدر افتح المجلد».

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

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

والسبب لا ينحصر دائمًا في DACL يمكن توسيعها. قد تدخل حماية أو سياسة أو حالة مورد أخرى بحسب العملية والبيئة. اعرض الدليل على مسؤول اللاب مع الطلب والمسار والهوية، وراجع السجلات ذات الصلة. تعطيل الحماية حتى ينجح الحفظ يخفي السؤال الأمني الذي كان يفترض أنك تفهمه.

تجربة حفظ قصيرة: ربط السلوك بالحدث بدون تغيير عشر أشياء

حدد ملف report.txt وهميًا في مساحة تدريب، ثم تأكد من الحالة الأولية مع مسؤول اللاب. ابدأ التقاطًا معتمدًا محدود المدة، واضغط حفظ مرة واحدة، وسجّل وقت ظهور الرسالة. أوقف الالتقاط بعد الفترة اللازمة. لا تنفذ خمس محاولات بإعدادات مختلفة داخل أثر واحد ثم تحاول فصلها من ذاكرتك.

ابدأ التحليل من عملية التطبيق والمسارات التي تتصل بالملف والغرض. اقرأ ما وقع قبل الرسالة وبعدها ضمن الفترة المناسبة. قد تكتشف أن التطبيق لم يحاول أصلًا الكتابة إلى الملف الذي توقعت، أو أنه أنشأ ملفًا مؤقتًا في موقع مختلف، أو أن محاولة فتح مورد إضافي هي التي رُفضت.

خلنا نفترض أن التقرير يقرأ طبيعيًا، لكن خطوة إنشاء ملف مؤقت في مجلد آخر رفضت. هنا الملاحظة الدقيقة ليست «ملف التقرير لا يقبل القراءة» ولا «كل حقوق المستخدم غلط». هي اختلاف بين متطلبات سير الحفظ والإعداد الحالي للمورد الثاني. راجع هل الموقع الصحيح للتطبيق هو ذلك المجلد، وهل وظيفته تحتاجه فعلًا.

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

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

ما الذي تحتفظ به، وما الذي لا تنشره؟

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

في نسخة التقرير، اختر الأحداث التي تثبت الملاحظة مع قدر كافٍ من السياق: الوقت والعملية وPID والمسار والطلب والنتيجة. لا تقص النتيجة وحدها وتخفي الطلب الذي رُفض. وفي الوقت نفسه، أخفِ القيم الحساسة غير اللازمة مع الاحتفاظ بالأصل للمراجعة في نطاقه الصحيح.

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

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

لو سألك مسؤول التطبيق عن النتيجة، أعطه سؤالًا محددًا: «هل خطوة الحفظ هذه يفترض أن تنشئ موردًا في هذا الموقع تحت هذه الهوية؟». هذا أسهل للعمل من إرسال مئة ألف حدث وطلب «شوف وش المشكلة». مهارتك هي اختيار الدليل الذي يشرح السلوك ويحترم خصوصية ما لا يتعلق به.

اختبارك انتهى لما قدرت تشرح الحدث وحدوده

الملاحظة المهنية تصف العلاقة بين تجربة المستخدم والحدث الذي دعمه الدليل. مثال: «أثناء محاولة الحفظ المحددة، حاولت العملية إنشاء مورد مؤقت في الموقع المعين ورفض الطلب. وافق مالك التطبيق أن هذه الخطوة مطلوبة في سير العمل، ويوصى بمراجعة الموقع والحقوق المناسبة دون توسيعها عن الحاجة». وإذا العلاقة لم تثبت، اكتب أن السبب ما زال قيد المراجعة.

لا تستخدم عبارة «ثغرة في النظام» لكل ACCESS DENIED، ولا «DLL Hijacking» لكل NAME NOT FOUND، ولا «كتابة ناجحة» لكل CreateFile. أسماء العمليات والنتائج بداية لفهم حدث، والأثر الأمني يحتاج سياقًا وأدلة أخرى. هذا الفرق يفيدك في اختبار مصرح وفي تشخيص تطبيقات عادية بنفس القدر.

للقراءة المكملة في المجتمع، شرح Process Explorer للحالة الحالية، وAccessChk لحقوق الموارد:
https://courses.cyberpts.com/community/81/shrh-process-explorer-llmkhtbr-aqra-alamlyh-wmsarha-wmlfatha-qbl-ma-thkm-alyha
https://courses.cyberpts.com/community/80/shrh-accesschk-kyf-tqra-slahyat-wyndwz-wtfrq-byn-mlf-qabl-llktabh-wthghrh-mthbth

المراجع الأساسية: صفحة Procmon الرسمية، وتوثيق CreateFileW، وFile security and access rights:
https://learn.microsoft.com/en-us/sysinternals/downloads/procmon
https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilew
https://learn.microsoft.com/en-us/windows/win32/fileio/file-security-and-access-rights

إذا احتفظت بسؤال واضح وفترة قصيرة وسياق كل حدث، يصبح الأثر الطويل قابلًا للفهم. مو المطلوب أن تحفظ كل Operation، المطلوب تعرف أي حدث يجاوب السؤال وأي نتيجة لا تسمح لك تستنتج أكثر مما قسته.