- بواسطة x32x01 ||
لو بتتعلم Cyber Security، غالبًا عديت بالموقف ده: تقرأ عن Vulnerability، تشوف فيديو عنها، تفهم الـConcept كويس جدًا، لكن أول ما تدخل Lab أو CTF وتقول "يلا أجرب"، تلاقي نفسك مش عارف تبدأ منين.
المشكلة هنا مش بالضرورة في فهمك.
اللي ناقص غالبًا هو التحويل من المعرفة النظرية للتطبيق العملي: تعرف تبص على الـRequest، تحدد إيه اللي يستحق الاختبار، تجرب، تقرأ الـResponse، وتربط النتيجة بالخطوة اللي بعدها.
وده تحديدًا هو الهدف من مشروع SilentN0va Offensive Security: تقديم محتوى عربي عملي يساعدك تنتقل من "أنا فاهم الثغرة" إلى "أنا قادر أكتشفها وأختبرها بنفسي" داخل بيئات تدريبية آمنة.
وده مهم طبعًا، لكن فيه مرحلة تانية أصعب شوية.
تفتح Burp Suite، تشوف الـRequests والـParameters قدامك، وتبقى فاهم نظريًا إن فيه Vulnerability ممكن تكون موجودة، لكن السؤال الحقيقي يفضل:
"أعمل إيه دلوقتي؟"
تجرب إيه؟
تبص على إيه في الـResponse؟
إزاي تعرف إن الـInput ده يستحق الاختبار؟
ولو أول محاولة فشلت، تجرب إيه بعدها؟
الفجوة دي بين المعرفة النظرية والتطبيق العملي هي واحدة من أهم المشاكل اللي بيحاول المشروع يعالجها.
الفكرة مش إنك تحفظ تعريفات Vulnerabilities، لكن إنك تتعلم طريقة التفكير اللي توصلك للثغرة.
🧠 بدل ما يكون عندك معلومة عن الثغرة فقط، يبقى عندك منهج تفكير تقدر تستخدمه لما تقابل Application جديدة.
كل Playlist بتحاول تاخدك في رحلة تبدأ من الأساسيات المطلوبة لفهم الـVulnerability، وبعدها تنتقل للتطبيق العملي خطوة بخطوة داخل بيئة تدريبية.
الفكرة الأساسية هي إنك تتعلم:
"الثغرة موجودة هنا، استخدم الـPayload ده."
أنت اللي المفروض تستكشف وتختبر وتربط المعلومات ببعض.
الـApplication ممكن تكون شغالة بشكل سليم جدًا من الناحية التقنية، ومفيش SQL Injection أو XSS واضح، لكن المشكلة تكون في منطق العمل نفسه.
مثلًا، ممكن Application تسمح للمستخدم إنه:
وده محتاج منك تفكير مختلف.
بدل ما تبص للـApplication كأنها مجرد مجموعة Requests، حاول تفهم:
إيه القواعد اللي الـApplication المفروض تمشي عليها؟
وبعد كده اسأل نفسك:
هل أقدر أوصل لحالة المفروض إنها مستحيلة؟
🎯 الـPlaylist دي بتركز على بناء طريقة التفكير دي، وفهم الـBusiness Logic، واختبار السيناريوهات داخل بيئات تدريبية.
🔗 رابط الـPlaylist:
PortSwigger Business Logic Labs | Full Course & Solutions
فكرة الـToken نفسها بسيطة نسبيًا، وغالبًا بتتكون من:
هل الـApplication بتتحقق من الـToken بالطريقة الصحيحة؟
هنا ممكن تظهر مجموعة مختلفة من المشاكل، مثل:
لازم تفهم:
إيه اللي بيتم توقيعه؟ وإزاي السيرفر بيتحقق منه؟ وإيه الافتراضات اللي بيعتمد عليها؟
🔐 الـPlaylist بتبدأ من فهم تركيب الـJWT، وبعدها تنتقل إلى اختبار نقاط الضعف المختلفة عمليًا داخل بيئات تدريبية.
🔗 رابط الـPlaylist:
JWT Vulnerabilities Masterclass | شرح وحل جميع لابات JWT في PortSwigger Web Security Academy
الفكرة ببساطة إن التطبيق يكون عنده مسار أو اسم ملف جاي من المستخدم، وبعدها يستخدم القيمة دي للوصول إلى ملف.
لو مفيش تحكم مناسب، ممكن يحاول المستخدم يخرج من الـDirectory المفروض يكون محصور فيه، وبالتالي يوصل إلى ملفات خارج النطاق المسموح.
وده ممكن يؤدي إلى كشف ملفات إعدادات أو بيانات حساسة حسب صلاحيات التطبيق والبيئة الموجودة.
🧩 المهم في Path Traversal مش مجرد معرفة الفكرة، لكن فهم:
Path traversal vulnerabilities | portswigger
لكن أحيانًا المعلومة الصغيرة بتكون جزء من صورة أكبر.
مثلًا، Error Message ممكن تكشف:
المعلومة وحدها مش معناها إنك حصلت على اختراق، لكن ممكن تساعدك تفهم الـApplication بشكل أفضل وتحدد إيه اللي يستحق الاختبار بعد كده.
🔎 عشان كده الـPlaylist بتركز على البحث المنهجي عن المعلومات، والأهم من كده: إزاي تربط المعلومة اللي لقيتها بالخطوة التالية في الاختبار.
🔗 رابط الـPlaylist:
Information Disclosure | PortSwigger Academy
ممكن تلاقي مثلًا Application بتعمل وظيفة محتاجة تنفيذ أمر على السيرفر، زي أدوات معينة للتعامل مع الملفات أو الشبكات.
لو الـInput وصل لعملية تنفيذ الأمر بدون فصل آمن بين البيانات والأمر نفسه، ممكن يظهر Injection.
⚠️ هنا المشكلة مش في وجود Command Execution كوظيفة فقط، لكن في إدخال بيانات المستخدم في سياق أمر بطريقة تسمح بتغيير السلوك المقصود.
في الـPlaylist بتتعلم الفكرة من الأساس:
OS Command Injection | PortSwigger Walkthrough
هل المستخدم مسموح له فعلًا يعمل العملية دي أو يشوف البيانات دي؟
المشكلة ممكن تظهر بأشكال مختلفة.
مثلًا، ممكن Application تعتمد على قيمة ID للوصول إلى Resource، لكن الـBackend لا يتحقق بشكل صحيح من إن المستخدم الحالي يملك صلاحية الوصول إلى الـResource ده.
وده ممكن يؤدي إلى حالات معروفة مثل IDOR.
وفي سيناريوهات تانية، ممكن تلاقي:
الـPlaylist بتدخل في أنواع مختلفة من مشاكل الـAccess Control، من الحالات البسيطة لحد السيناريوهات اللي محتاجة فهم أكبر للـApplication Workflow.
🔗 رابط الـPlaylist:
PortSwigger Broken Access Control Labs
ممكن تكون فاهم الـVulnerability، لكن لو الأدوات مش متجهزة، هتلاقي نفسك رجعت لنفس المشكلة:
"أنا فاهم، بس أبدأ منين؟"
عشان كده المشروع بيضم محتوى خاص بتجهيز بيئة العمل نفسها.
🔗 الفيديو:
الفيديو بيشرح إعداد الـProxy وربط Burp Suite بمتصفح Firefox من خلال تثبيت الـCertificate، بحيث تقدر تشوف الـRequests والـResponses وتبدأ تختبر الـApplication داخل بيئة تدريبية.
🔗 الفيديو:
مش الهدف إنك تحفظ تعريف Business Logic Flaw أو JWT أو Path Traversal وتقدر تشرحه لو حد سألك.
الهدف الحقيقي هو إنك تفهم:
ليه الـVulnerability بتحصل من الأساس؟
ولما تدخل على Application جديدة، تعرف تسأل الأسئلة الصح.
إيه الـInput اللي يستحق الاختبار؟
إيه الـWorkflow اللي ممكن يكون فيه مشكلة؟
هل الـBackend بيتحقق من الصلاحيات؟
إيه المعلومات اللي الـApplication بتكشفها؟
إيه اللي حصل بعد تغيير الـRequest؟
وإيه الخطوة المنطقية اللي المفروض أجربها بعد كده؟
💡 مع الوقت، الطريقة دي في التفكير بتفرق جدًا بين شخص حافظ مجموعة Vulnerabilities وشخص بدأ فعلًا يكتسب خبرة في اختبار التطبيقات.
ومعظم الوقت مش هيقولك: "استخدم الـPayload ده هنا."
أنت المفروض تلاحظ السلوك، تعمل Hypothesis، تختبرها، تشوف النتيجة، وتعدل فكرتك بناءً على اللي حصل.
وده سبب مهم يخلي التدريب العملي مفيد.
لما تجرب Vulnerability بنفسك داخل بيئة آمنة، بتبدأ تكون عندك خبرة عملية تساعدك تفهمها لما تقابل Pattern مشابه بعد كده.
🧠 الهدف هو الانتقال من:
أعرف الثغرة ⬅️ أقدر أشرح الثغرة ⬅️ أقدر أكتشف الثغرة بنفسي.
الفكرة إن المحتوى يتوسع مع الوقت ليشمل Vulnerabilities إضافية، Playlists جديدة، Labs أكثر، وCheatsheets تكون مرجع سريع أثناء المذاكرة والتطبيق.
يعني المحتوى الموجود حاليًا هو بداية المشروع، وليس الشكل النهائي له.
بعد كده تقدر ترجع للـPlaylists وتبدأ بالموضوع الأقرب لمستواك واهتماماتك.
وكمان تقدر تدخل على الـGitHub Repository وتعمل ⭐ Star للمشروع.
الخطوة بسيطة، لكنها بتساعد في زيادة وصول المشروع للناس المهتمة بالمحتوى العربي المجاني في مجال Offensive Security.
🔗 GitHub Repository:
SilentN0va Offensive Security
المشكلة غالبًا إنك محتاج تربط اللي بتتعلمه باللي بتعمله بإيدك.
SilentN0va Offensive Security بيحاول يعالج الجزء ده من خلال محتوى عربي عملي يربط بين فهم الـConcept، تجهيز الأدوات، اختبار الـApplication، وتحليل النتيجة داخل بيئات تدريبية.
ولو أنت حاليًا في مرحلة:
"أنا فاهم الـTheory، بس أول ما أدخل Lab مش عارف أبدأ منين"
فده بالضبط النوع من الفجوة اللي المشروع بيحاول يساعدك تتخطاها.
المشكلة هنا مش بالضرورة في فهمك.
اللي ناقص غالبًا هو التحويل من المعرفة النظرية للتطبيق العملي: تعرف تبص على الـRequest، تحدد إيه اللي يستحق الاختبار، تجرب، تقرأ الـResponse، وتربط النتيجة بالخطوة اللي بعدها.
وده تحديدًا هو الهدف من مشروع SilentN0va Offensive Security: تقديم محتوى عربي عملي يساعدك تنتقل من "أنا فاهم الثغرة" إلى "أنا قادر أكتشفها وأختبرها بنفسي" داخل بيئات تدريبية آمنة.
إيه المشكلة اللي بيحاول SilentN0va يحلها؟
أغلب الناس وهي بتبدأ في Cyber Security بتقضي وقت كبير في قراءة الـTheory.وده مهم طبعًا، لكن فيه مرحلة تانية أصعب شوية.
تفتح Burp Suite، تشوف الـRequests والـParameters قدامك، وتبقى فاهم نظريًا إن فيه Vulnerability ممكن تكون موجودة، لكن السؤال الحقيقي يفضل:
"أعمل إيه دلوقتي؟"
تجرب إيه؟
تبص على إيه في الـResponse؟
إزاي تعرف إن الـInput ده يستحق الاختبار؟
ولو أول محاولة فشلت، تجرب إيه بعدها؟
الفجوة دي بين المعرفة النظرية والتطبيق العملي هي واحدة من أهم المشاكل اللي بيحاول المشروع يعالجها.
الفكرة مش إنك تحفظ تعريفات Vulnerabilities، لكن إنك تتعلم طريقة التفكير اللي توصلك للثغرة.
🧠 بدل ما يكون عندك معلومة عن الثغرة فقط، يبقى عندك منهج تفكير تقدر تستخدمه لما تقابل Application جديدة.
المحتوى مبني على التطبيق العملي
المشروع بيقدم المحتوى بالعربي، وهدفه مش مجرد ترجمة محتوى أجنبي أو تجميع مجموعة Links في مكان واحد.كل Playlist بتحاول تاخدك في رحلة تبدأ من الأساسيات المطلوبة لفهم الـVulnerability، وبعدها تنتقل للتطبيق العملي خطوة بخطوة داخل بيئة تدريبية.
الفكرة الأساسية هي إنك تتعلم:
- إيه اللي بتدور عليه؟
- ليه الـVulnerability بتحصل؟
- إزاي تختبر الـApplication؟
- إزاي تقرأ النتيجة؟
- إزاي تعرف الخطوة التالية؟
- وإزاي تعتمد على نفسك بدل ما تكون مستني حد يقولك مكان الثغرة؟
"الثغرة موجودة هنا، استخدم الـPayload ده."
أنت اللي المفروض تستكشف وتختبر وتربط المعلومات ببعض.
1. Business Logic Flaws
Business Logic Flaws مختلفة عن كثير من الثغرات التقنية التقليدية.الـApplication ممكن تكون شغالة بشكل سليم جدًا من الناحية التقنية، ومفيش SQL Injection أو XSS واضح، لكن المشكلة تكون في منطق العمل نفسه.
مثلًا، ممكن Application تسمح للمستخدم إنه:
- يضيف كمية غير منطقية من منتج.
- يتجاوز خطوة مفروضة في عملية معينة.
- يستخدم Discount بطريقة غير متوقعة.
- يعدل ترتيب خطوات Workflow بطريقة تكسر القاعدة المفروضة.
وده محتاج منك تفكير مختلف.
بدل ما تبص للـApplication كأنها مجرد مجموعة Requests، حاول تفهم:
إيه القواعد اللي الـApplication المفروض تمشي عليها؟
وبعد كده اسأل نفسك:
هل أقدر أوصل لحالة المفروض إنها مستحيلة؟
🎯 الـPlaylist دي بتركز على بناء طريقة التفكير دي، وفهم الـBusiness Logic، واختبار السيناريوهات داخل بيئات تدريبية.
🔗 رابط الـPlaylist:
PortSwigger Business Logic Labs | Full Course & Solutions
2. JWT Authentication
الـJSON Web Tokens أو JWT مستخدمة بشكل واسع في تطبيقات الويب والـAPIs الحديثة.فكرة الـToken نفسها بسيطة نسبيًا، وغالبًا بتتكون من:
- Header
- Payload
- Signature
هل الـApplication بتتحقق من الـToken بالطريقة الصحيحة؟
هنا ممكن تظهر مجموعة مختلفة من المشاكل، مثل:
- ضعف في التحقق من الـSignature.
- Secrets ضعيفة يمكن تخمينها أو اختبارها في بيئة تدريبية.
- مشاكل مرتبطة باختيار الـAlgorithm.
- Key Confusion في بعض السيناريوهات.
- أخطاء في طريقة تعامل الـApplication مع بيانات الـToken.
لازم تفهم:
إيه اللي بيتم توقيعه؟ وإزاي السيرفر بيتحقق منه؟ وإيه الافتراضات اللي بيعتمد عليها؟
🔐 الـPlaylist بتبدأ من فهم تركيب الـJWT، وبعدها تنتقل إلى اختبار نقاط الضعف المختلفة عمليًا داخل بيئات تدريبية.
🔗 رابط الـPlaylist:
JWT Vulnerabilities Masterclass | شرح وحل جميع لابات JWT في PortSwigger Web Security Academy
3. Path Traversal
Path Traversal من الثغرات القديمة، لكنها لسه ممكن تظهر في تطبيقات حديثة لما الـApplication تتعامل مع أسماء الملفات أو مساراتها بدون Validation مناسب.الفكرة ببساطة إن التطبيق يكون عنده مسار أو اسم ملف جاي من المستخدم، وبعدها يستخدم القيمة دي للوصول إلى ملف.
لو مفيش تحكم مناسب، ممكن يحاول المستخدم يخرج من الـDirectory المفروض يكون محصور فيه، وبالتالي يوصل إلى ملفات خارج النطاق المسموح.
وده ممكن يؤدي إلى كشف ملفات إعدادات أو بيانات حساسة حسب صلاحيات التطبيق والبيئة الموجودة.
🧩 المهم في Path Traversal مش مجرد معرفة الفكرة، لكن فهم:
- إزاي الـInput بيوصل لعملية قراءة الملف.
- إيه الـValidation الموجودة.
- هل فيه Normalization للـPath؟
- هل الحماية بتتعامل مع الحالات غير المتوقعة؟
- إيه النتيجة اللي ظهرت في الـResponse؟
Path traversal vulnerabilities | portswigger
4. Information Disclosure
كتير من المبتدئين بيستهينوا بـInformation Disclosure لأن المعلومة اللي ظهرت ممكن تبدو بسيطة.لكن أحيانًا المعلومة الصغيرة بتكون جزء من صورة أكبر.
مثلًا، Error Message ممكن تكشف:
- نوع الـDatabase.
- إصدار Server أو Framework.
- مسار داخلي على النظام.
- اسم ملف أو Endpoint.
- تفاصيل عن طريقة تنفيذ Request معين.
المعلومة وحدها مش معناها إنك حصلت على اختراق، لكن ممكن تساعدك تفهم الـApplication بشكل أفضل وتحدد إيه اللي يستحق الاختبار بعد كده.
🔎 عشان كده الـPlaylist بتركز على البحث المنهجي عن المعلومات، والأهم من كده: إزاي تربط المعلومة اللي لقيتها بالخطوة التالية في الاختبار.
🔗 رابط الـPlaylist:
Information Disclosure | PortSwigger Academy
5. OS Command Injection
OS Command Injection من الثغرات اللي ممكن تكون خطيرة جدًا، لأنها بتحصل لما Application تستخدم User Input بطريقة غير آمنة داخل أمر يتم تنفيذه على نظام التشغيل.ممكن تلاقي مثلًا Application بتعمل وظيفة محتاجة تنفيذ أمر على السيرفر، زي أدوات معينة للتعامل مع الملفات أو الشبكات.
لو الـInput وصل لعملية تنفيذ الأمر بدون فصل آمن بين البيانات والأمر نفسه، ممكن يظهر Injection.
⚠️ هنا المشكلة مش في وجود Command Execution كوظيفة فقط، لكن في إدخال بيانات المستخدم في سياق أمر بطريقة تسمح بتغيير السلوك المقصود.
في الـPlaylist بتتعلم الفكرة من الأساس:
- إزاي الـUser Input ممكن يوصل لتنفيذ Command.
- إزاي تكتشف نقطة الإدخال.
- إزاي تفرق بين Input عادي وInput بيتفسر كجزء من Command.
- إزاي تختبر الحالة داخل بيئة تدريبية.
- وإزاي تفهم تأثير الـFiltering بدل الاعتماد على تجربة عشوائية.
OS Command Injection | PortSwigger Walkthrough
6. Broken Access Control
Broken Access Control من أهم موضوعات Web Security، لأنها مرتبطة بشكل مباشر بسؤال أساسي:هل المستخدم مسموح له فعلًا يعمل العملية دي أو يشوف البيانات دي؟
المشكلة ممكن تظهر بأشكال مختلفة.
مثلًا، ممكن Application تعتمد على قيمة ID للوصول إلى Resource، لكن الـBackend لا يتحقق بشكل صحيح من إن المستخدم الحالي يملك صلاحية الوصول إلى الـResource ده.
وده ممكن يؤدي إلى حالات معروفة مثل IDOR.
وفي سيناريوهات تانية، ممكن تلاقي:
- صفحة إدارية غير محمية بشكل صحيح.
- Endpoint متاح لمستخدم لا يملك الصلاحية.
- اختلاف بين الصلاحيات اللي الـUI بتعرضها والصلاحيات الفعلية على الـBackend.
- إمكانية تنفيذ Action المفروض تكون مقيدة على Role معين.
الـPlaylist بتدخل في أنواع مختلفة من مشاكل الـAccess Control، من الحالات البسيطة لحد السيناريوهات اللي محتاجة فهم أكبر للـApplication Workflow.
🔗 رابط الـPlaylist:
PortSwigger Broken Access Control Labs
تجهيز بيئة العمل: Kali Linux وBurp Suite
مفيش تطبيق عملي حقيقي من غير بيئة تقدر تتدرب عليها.ممكن تكون فاهم الـVulnerability، لكن لو الأدوات مش متجهزة، هتلاقي نفسك رجعت لنفس المشكلة:
"أنا فاهم، بس أبدأ منين؟"
عشان كده المشروع بيضم محتوى خاص بتجهيز بيئة العمل نفسها.
تجهيز Kali Linux 2026 على VirtualBox
الفيديو بيشرح تجهيز Kali Linux 2026 على VirtualBox من البداية، بداية من تنزيل النظام، مرورًا بإعداد الـVirtual Machine، لحد ما يبقى عندك Environment جاهزة للاستخدام.🔗 الفيديو:
إعداد Burp Suite Pro وFirefox
Burp Suite من الأدوات الأساسية في اختبار Web Applications.الفيديو بيشرح إعداد الـProxy وربط Burp Suite بمتصفح Firefox من خلال تثبيت الـCertificate، بحيث تقدر تشوف الـRequests والـResponses وتبدأ تختبر الـApplication داخل بيئة تدريبية.
🔗 الفيديو:
إيه الهدف الحقيقي من المشروع؟ 🎯
الهدف مش إنك "تعرف" الثغرة وخلاص.مش الهدف إنك تحفظ تعريف Business Logic Flaw أو JWT أو Path Traversal وتقدر تشرحه لو حد سألك.
الهدف الحقيقي هو إنك تفهم:
ليه الـVulnerability بتحصل من الأساس؟
ولما تدخل على Application جديدة، تعرف تسأل الأسئلة الصح.
إيه الـInput اللي يستحق الاختبار؟
إيه الـWorkflow اللي ممكن يكون فيه مشكلة؟
هل الـBackend بيتحقق من الصلاحيات؟
إيه المعلومات اللي الـApplication بتكشفها؟
إيه اللي حصل بعد تغيير الـRequest؟
وإيه الخطوة المنطقية اللي المفروض أجربها بعد كده؟
💡 مع الوقت، الطريقة دي في التفكير بتفرق جدًا بين شخص حافظ مجموعة Vulnerabilities وشخص بدأ فعلًا يكتسب خبرة في اختبار التطبيقات.
التطبيق قبل مواجهة الواقع
لما تدخل Lab أو CTF، محدش هيحدد لك مكان الثغرة.ومعظم الوقت مش هيقولك: "استخدم الـPayload ده هنا."
أنت المفروض تلاحظ السلوك، تعمل Hypothesis، تختبرها، تشوف النتيجة، وتعدل فكرتك بناءً على اللي حصل.
وده سبب مهم يخلي التدريب العملي مفيد.
لما تجرب Vulnerability بنفسك داخل بيئة آمنة، بتبدأ تكون عندك خبرة عملية تساعدك تفهمها لما تقابل Pattern مشابه بعد كده.
🧠 الهدف هو الانتقال من:
أعرف الثغرة ⬅️ أقدر أشرح الثغرة ⬅️ أقدر أكتشف الثغرة بنفسي.
المشروع لسه في البداية 🚀
SilentN0va Offensive Security لسه بيتبني، والـSix Playlists الموجودة حاليًا مش هي نهاية المشروع.الفكرة إن المحتوى يتوسع مع الوقت ليشمل Vulnerabilities إضافية، Playlists جديدة، Labs أكثر، وCheatsheets تكون مرجع سريع أثناء المذاكرة والتطبيق.
يعني المحتوى الموجود حاليًا هو بداية المشروع، وليس الشكل النهائي له.
لو فاتك الجزء الأول
لو دي أول مرة تسمع عن SilentN0va، فممكن تبدأ بالجزء الأول من السلسلة عشان تاخد الصورة الكاملة عن المشروع، سبب إنشائه، والفكرة اللي مبني عليها.بعد كده تقدر ترجع للـPlaylists وتبدأ بالموضوع الأقرب لمستواك واهتماماتك.
إزاي تقدر تساعد المشروع؟ ❤️
لو شايف إن المحتوى ممكن يفيد شخص بيتعلم Cyber Security وواقف في نفس المرحلة، مشاركة المقال ممكن تساعده يوصل للمشروع.وكمان تقدر تدخل على الـGitHub Repository وتعمل ⭐ Star للمشروع.
الخطوة بسيطة، لكنها بتساعد في زيادة وصول المشروع للناس المهتمة بالمحتوى العربي المجاني في مجال Offensive Security.
🔗 GitHub Repository:
SilentN0va Offensive Security
الخلاصة
أكبر مشكلة في تعلم Cyber Security مش إنك مش قادر تحفظ Vulnerabilities أكثر.المشكلة غالبًا إنك محتاج تربط اللي بتتعلمه باللي بتعمله بإيدك.
SilentN0va Offensive Security بيحاول يعالج الجزء ده من خلال محتوى عربي عملي يربط بين فهم الـConcept، تجهيز الأدوات، اختبار الـApplication، وتحليل النتيجة داخل بيئات تدريبية.
ولو أنت حاليًا في مرحلة:
"أنا فاهم الـTheory، بس أول ما أدخل Lab مش عارف أبدأ منين"
فده بالضبط النوع من الفجوة اللي المشروع بيحاول يساعدك تتخطاها.
الأسئلة الشائعة
-------------هل SilentN0va مناسب للمبتدئين؟
مناسب للشخص اللي عنده أساسيات في Cyber Security وعايز ينقل معرفته من الجانب النظري للتطبيق العملي. ومن الأفضل إنك تبني الأساسيات المطلوبة لكل موضوع قبل الدخول في تفاصيل الـVulnerability.هل المحتوى مجرد ترجمة لمحتوى أجنبي؟
لا، فكرة المشروع هي تقديم محتوى عربي يركز على الفهم والتطبيق العملي، وليس مجرد ترجمة أو تجميع لمحتوى موجود في أماكن أخرى.هل التدريب يتم على أنظمة حقيقية؟
الهدف من المحتوى التدرب داخل Labs وCTFs وبيئات مخصصة للتعلم بشكل آمن. الاختبارات الأمنية يجب أن تتم فقط على الأنظمة التي تملك تصريحًا لاختبارها.إيه الأدوات الأساسية الموجودة في المحتوى؟
من الأدوات التي يتم تجهيزها واستخدامها Burp Suite وKali Linux، بالإضافة إلى الأدوات والبيئات المطلوبة حسب موضوع كل Playlist.هل المشروع هيضيف محتوى جديد؟
نعم، المشروع ما زال في مرحلة البناء، والخطة تتضمن إضافة Vulnerabilities وPlaylists وLabs وCheatsheets جديدة مع استمرار تطوير المحتوى. التعديل الأخير: