شرح SQLRecon: الفرق بين info وwhoami وdebug، وكيف تقرأ نتائج SQL في لاب الدومين؟

تلقى SQLRecon في شرح لاب، وتلاحظ أن عنده info بأكثر من سياق، وwhoami، وdebug، وقائمة طويلة من الوحدات. لو شغلت الأسماء بدون فهم، ممكن تقارن خرج اكتشاف خدمة بخرج جلسة مصادقة وتظن أنها نتائج متناقضة. البداية الأفضل أن تعرف ما يسأله كل وضع وأي سياق يستخدمه.
SQLRecon مشروع أدوات لـMicrosoft SQL Server، ويدعم وظائف تتجاوز القراءة. هنا بنحصر أمثلتنا في مراجعة معلومات وسياق على خادم تدريب واحد تملكه. ما ننفذ عمليات تغيير أو تشغيل أوامر على النظام، ولا ننتقل لخوادم مرتبطة خارج النطاق. المقال يكمل أساس Login وDatabase User الذي شرحناه بالمجتمع، ويركز على تفسير مخرجات الأداة واختيار الخطوة التالية.

لا تبدأ من قائمة الوحدات؛ ابدأ من سؤال الجلسة

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

info في Enumeration يختلف عن info في SQL Modules

يقسم المشروع وظائف Enumeration التي تمرر عبر /e أو /enum، ووحدات SQL التي تمرر عبر /m أو /module. تذكر وثائق Enumeration أن info يمكنها عرض معلومات عن الخدمة، بينما توجد وحدة Info ضمن وحدات SQL ذات سياق اتصال. تشابه الاسم لا يجعل السؤال أو طريق الحصول على البيانات مطابقًا.
مثال محدود لخادم لاب تملكه:
SQLRecon.exe /e:info /h:sql01.lab.test
هذا المثال ليس تسجيل دخول بحساب SQL، ولا اختبار قراءة جداول. إذا ظهرت معلومات Instance أو منفذ، سجل مصدرها ووظيفة الأمر. وإذا لم تظهر نتيجة، لا تستنتج أن كل خدمة SQL على الجهاز غير موجودة أو أن كل طرق الاتصال إليها ستفشل.
يساعد SQL Server Browser بعض العملاء على معرفة Instances ووجهاتها، ويستعمل UDP 1434 في السياق الذي توثقه Microsoft. هذا طريق اكتشاف يختلف عن اتصال العميل بالمحرك نفسه. خدمة اكتشاف لا تستجيب في محاولة ما، بينما اتصال مباشر بوجهة معروفة قد يكون ممكنًا وفق الإعداد.
الخطوة المنطقية هي مراجعة تصميم اللاب ووجهة الخدمة المقصودة. لا تشغل مسحًا واسعًا لأن أمر المعلومات ما رجع شيئًا. إذا تعرف Instance ومنفذها من إعداد خادمك، يمكنك اختبار السؤال المناسب لذلك الاتصال المصرح. ما تريد إثبات أن الأداة تعطي خرجًا بأي طريقة؛ تريد تعرف أي معلومة متاحة من أي مصدر.

WinToken: من ينفذ العملية فعلًا؟

WinToken في SQLRecon يستخدم سياق المستخدم الحالي للمصادقة كما يصف المشروع. هذه معلومة أساسية للتفسير: اسم الحساب الذي كنت تقصد استخدامه في ذهنك ما يغير سياق العملية. راجع الجهاز والجلسة والهوية التي تشغل منها البرنامج، ثم احتفظ بهذا الوصف بجانب الناتج.
في لابك، افتح جلسة مصرحًا بها للحساب التدريبي المقصود، ولا تخلط قراءتها مع جلسة أخرى تحمل هوية إدارية. إذا قارنت النتيجتين، سجل اختلاف الحساب بوضوح. لا تستنتج أن إعداد SQL تغير لأن مخرجات الصلاحيات اختلفت بعد أن غيرت مصدر التنفيذ دون ملاحظة.
مثال مراجعة الهوية على خادم التدريب:
SQLRecon.exe /a:WinToken /h:sql01.lab.test /m:whoami
ارجع لمساعدة نسختك ومتطلبات الاتصال. الأمر هنا لا يحتاج تضمين كلمة مرور في سطر منشور، لكن ذلك لا يجعل جمع النتائج بلا حدود. استخدمه على الوجهة المصرح بها، واحفظ الناتج في سياق اللاب المناسب.
إذا فشل الاتصال، اقرأ المرحلة والرسالة بدل تبديل مزود المصادقة تلقائيًا. قد يكون الاسم أو الوجهة أو متطلب اتصال سببًا يحتاج مراجعة. نجاح نوع مختلف من المصادقة لاحقًا ما يثبت وحده أن النوع الأول معطوب؛ قد تكون التجربتان مختلفتين في أكثر من عنصر. حافظ على وصف كل محاولة حتى يكون التشخيص قابلًا للفهم.

whoami هنا مو أمر ويندوز الذي يحكي كل شيء

تعرض وثائق SQLRecon مثال whoami مع هوية الاتصال والمستخدم المرتبط ونطاقات صلاحيات وأدوار. هذا خرج يخص سياق SQL المقصود، وليس بديلًا عن وصف هوية العملية على ويندوز أو كل حقوقها. لا تحمل تشابه اسم الوحدة مع أمر نظام معروف معنى ما تقصده الوثائق.
لو ظهر اسم Login ثم مستخدم مختلف داخل قاعدة، ارجع إلى الفرق بين Login وDatabase User. اختلاف الاسم وحده ما يثبت انتحالًا أو خطأ. تحتاج تعرف القاعدة والسياق ودلالة كل قسم في المخرجات. في المثال التعليمي، اكتب تفسيرًا لكل عنوان قبل البحث عن أعلى دور في القائمة.
افصل أيضًا رؤية اسم قاعدة عن قراءة بياناتها. قد يعرض المصدر معلومات عن قواعد أو وصول معين، لكن ادعاء قراءة جدول يحتاج طلبًا مصرحًا محددًا ودليلًا خاصًا به. لا تنفذ استخراجًا واسعًا كي تحول المعلومة إلى صورة أقوى. اختبار مورد تدريبي صغير يكفي للسؤال التعليمي المناسب.
إذا النتيجة تحتوي عضوية دور، راجع الدور والنطاق والمتطلب التشغيلي قبل تقييمها. الدور قد يكون مطلوبًا لحساب خدمة في سيناريو معين، أو أوسع مما يحتاجه حساب آخر. الاسم لا يقرر ذلك نيابة عنك. المخرج الفني يصف الحالة، ومعرفة دور الحساب تساعدك تقارنها بما يفترض أن يكون عليه الوصول.

Debug لا يعني أن البرنامج كله يعمل دون اتصال

توثق الأداة أن /debug يعرض استعلامات الوحدة دون تنفيذها على الخادم، بينما /verbose يعرضها مع التنفيذ. لكن مثال Debug الرسمي يعرض أيضًا معلومات اتصال وState: Open. لذلك لا تصفه كضمان أن الأداة لن تتصل بالخادم أو لن تجري مصادقة؛ الفرق الموثق هنا يتعلق بتنفيذ الاستعلامات المعروضة.
هذه نقطة دقيقة تفيدك عند التخطيط. لو تريد مراجعة استعلام قبل تنفيذه، Debug أداة مناسبة ضمن نطاق مصرح. أما لو مطلوب تحليل بلا اتصال نهائيًا، فلا تستنتج أن الخيار يحقق ذلك من الاسم. راجع سلوك نسختك ومصدرها، واستخدم مادة توثيق مناسبة بدل تشغيله على وجهة غير مصرح بها.
مثال في لابك لعرض استعلامات وحدة Users وفق التوثيق:
SQLRecon.exe /a:WinToken /h:sql01.lab.test /m:users /debug
اقرأ الناتج لتعرف ما تسأل عنه الوحدة وما تستثنيه. لا تعتبر عرض النص دليلًا أن الاستعلام نجح أو أن النتائج متاحة لحسابك، لأنه ليس تجربة تنفيذ لهذه الاستعلامات.
بعد القراءة، اكتب توقعًا عن المعلومات التي يمكن أن تنتج، ثم قرر هل السؤال مناسب لهدف الجلسة. لا تزل Debug تلقائيًا فقط كي ترى المزيد. المراجعة قبل التنفيذ مفيدة إذا كانت تنتج قرارًا واضحًا. ولو احتجت تنفيذ قراءة مصرح بها، سجل ذلك كمحاولة مستقلة حتى لا تختلط بيانات عرض الاستعلام بنتائج التشغيل الفعلية.

اقرأ الاستعلام نفسه: المرشح جزء من معنى النتيجة

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

خطأ اتصال، رفض صلاحية، وقائمة صغيرة: فرّق بينها

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

خطة جلسة قصيرة لكن نتيجتها عميقة

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

وش تكتب في ملاحظاتك بعد SQLRecon؟

اكتب اسم المصدر والنسخة والوجهة والحساب ونوع الوظيفة والوقت، ثم احتفظ بجزء النتائج الذي يجيب عن سؤال الجلسة. لا تنشر كلمات مرور أو سلاسل اتصال تحتوي أسرارًا في مجتمع عام. وأي مثال تستخدمه في المقالات اجعله تدريبًا صريحًا ببيانات مصطنعة، لا قصة اكتشاف عميل لم تحدث.
عند قراءة نتيجة Whoami، سم نطاق SQL الذي تتحدث عنه. وعند قراءة Info، سم طريقة الحصول على المعلومة. وعند قراءة Debug، اذكر أنه عرض استعلامات دون تنفيذها وفق الوظيفة الموثقة، ولا تساوه بتحليل بلا اتصال. هذه الفروق الثلاثة تختصر أهم ما تحتاجه لتجنب تفسير مضلل.
ارجع للمصدر الرسمي عند أي اختلاف في نسخة أو خيار. الوثائق والمصدر أدوات تعلم أيضًا، وليست روابط تحطها آخر المقال فقط. إذا كنت ما تعرف ماذا تستبعد وحدة أو ماذا تنفذ، افحص ذلك قبل الاستنتاج. هذه العادة تبقى مفيدة حتى بعد أن تحفظ الأوامر، لأنها تحميك من نقل افتراض قديم إلى سلوك تغير.
المراجع:
https://github.com/skahwah/SQLRecon
https://github.com/skahwah/SQLRecon/wiki/1.-Enumeration
https://github.com/skahwah/SQLRecon/wiki/2.-Authentication
https://github.com/skahwah/SQLRecon/wiki/3.-Standard-Modules
https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/sql-server-browser-service-database-engine-and-ssas
إذا انتهت الجلسة وأنت تعرف ما الذي سأله كل أمر، فالأداة أدت غرضها التعليمي. أما إذا بقيت النتيجة مجرد أسماء وصفات، ارجع لسؤال أصغر. SQLRecon يكون مفيدًا لما تستخدم وحداته لقياس شيء محدد وتقرأه في سياقه، لا لما تشغل أكبر قائمة وتترك الخرج يقرر القصة نيابة عنك.