PHDays III CTF: इनसाइड लुक (भाग 1)

23 और 24 मई, 2013 को व्यावहारिक सूचना सुरक्षा पॉजिटिव हैक डेज़ III पर वार्षिक अंतरराष्ट्रीय मंच के हिस्से के रूप में, कैप्चर द फ्लैग सिद्धांत पर आधारित सबसे बड़ी प्रतियोगिताओं में से एक का आयोजन किया गया था - PHDays III CTF। इस वर्ष, प्रतियोगिता के आयोजन पर बहुत प्रयास किया गया था, और परिणाम ने किसी भी प्रतिभागी को उदासीन नहीं छोड़ा। इस घटना के बाद, हमने इस बारे में बात करने का फैसला किया कि प्रतियोगिता की तैयारी कैसे हुई और पर्दे के पीछे से एक दृश्य प्रस्तुत करना।

CTF टीम प्ले के समान प्रारूप में सूचना सुरक्षा प्रदान करने की एक प्रतियोगिता है। प्रत्येक टीम को पूर्वस्थापित कमजोर सेवाओं के साथ अपने स्वयं के नेटवर्क के बुनियादी ढांचे के साथ प्रदान किया जाता है। टीमों को सेवाओं का अध्ययन करना चाहिए, उनमें कमजोरियों की तलाश करनी चाहिए और उनका उपयोग करते हुए अपने प्रतिद्वंद्वियों की सेवाओं पर हमला करना चाहिए। साथ ही, उन्हें प्रतिद्वंद्वी हमलों से खुद को बचाने के लिए काम करने की स्थिति में अपनी सेवाओं को बनाए रखने और उनमें त्रुटियों को ठीक करने की आवश्यकता होती है।

दुश्मन सेवा पर एक सफल हमला करते समय, टीम को कुछ गुप्त डेटा प्राप्त होता है जिसे "ध्वज" कहा जाता है। झंडा एक सफल हमले का सबूत है। इसके अलावा, सेवाओं के अलावा, टीमों को पूर्व-तैयार कार्यों का एक सेट दिया जाता है जो अतिरिक्त झंडे ला सकता है।

तैयारी शुरू

सीटीएफ प्रतियोगिताओं में भाग लेने और आयोजित करने में व्यापक अनुभव होने के बाद, हम यह समझ गए कि प्रतियोगिता के लिए मुख्य कार्य कार्य हैं। हालांकि, एक अच्छे "रैपर" के बिना - एक किंवदंती, एक खेल की दुनिया, आकर्षक नियम और दृश्य घटक जो खिलाड़ियों और दर्शकों दोनों के लिए विसर्जन प्रदान करते हैं, प्रतियोगिता गणित ओलंपियाड की तुलना में थोड़ी अधिक दिलचस्प होगी।

सबसे पहले, यह किंवदंती और नियमों को काम करने का निर्णय लिया गया था, और फिर उन्हें कार्यों को स्वयं बनाने के लिए एक शुरुआती बिंदु के रूप में उपयोग किया गया था। हौसले से पके हुए खेल घटकों को एक साथ जोड़ने के प्रयास में, हमने गेम बनाने की प्रक्रिया के बारे में और जानने का फैसला किया।

एक किंवदंती की अवधारणा को विकसित करने के बाद, खेल यांत्रिकी के माध्यम से आया। सबसे पहले, हमने प्रतियोगिता के प्रारूप पर फैसला किया: यह सामान्य कार्यों (जार्जेट सीटीएफ), सेवाओं (क्लासिक सीटीएफ) और नवाचार के साथ मिश्रित CTF माना जाता था - हल करने के लिए सीमित समय के साथ कार्य और अंकों की लगातार बढ़ती कीमत, जिसे हमने "बॉस कार्य" कहा। । यह प्रारूप, जैसा कि यह हमें लगता है, हमें प्रतिभागियों के कौशल का व्यापक रूप से मूल्यांकन करने की अनुमति देता है और खेल में गतिशीलता लाता है।

इसके बाद, यह समझना आवश्यक था कि खिलाड़ी कार्यों के साथ क्या कर सकते हैं और इसके लिए क्या प्राप्त करना है। खेल का सार, खिलाड़ियों की गतिविधि और भागीदारी जैसे शब्द सामने आए। बोर्ड पर संस्थाओं को आकर्षित करने और उन पर कार्रवाई को परिभाषित करने से, हम अंततः नियमों को ठीक करने में सक्षम थे। यह केवल खेल के संतुलन को निर्धारित करने के लिए बनी हुई है - खिलाड़ियों के कार्यों और आंतरिक खेल संसाधनों के लिए अंकों का वितरण।

हमने विभिन्न प्रकार के कार्यों - सेवाओं और कार्यों को प्राथमिकता देकर शुरू किया। हमें तय करना था कि हमारे लिए विजेता कौन है - वह टीम जिसने सभी समस्याओं का समाधान किया है, या जिस टीम ने सभी सेवाओं का पूरी तरह से विश्लेषण किया है, उनके लिए कारनामे लिखे और उनकी सेवाओं में निश्चित कमजोरियां लिखीं। हमें कार्यों या सेवाओं के किसी भी आंशिक समाधान की आपस में तुलना करने की भी आवश्यकता है। रैंकिंग ने हमें असाइनमेंट स्कोर की एक संतुलित प्रणाली बनाने की अनुमति दी, जिसने पूरे सीटीएफ को हल करने के दौरान टीमों को रणनीति चुनने की स्वतंत्रता दी।

CTF के विकास में एक महत्वपूर्ण बिंदु यह था कि पॉजिटिव हैक डेज़ फोरम, जिसके भीतर प्रतियोगिता आयोजित की जानी थी, हैकर्स की लड़ाई तक ही सीमित नहीं है, जिसका अर्थ है कि हमारे पास ऐसे लोगों की एक बड़ी संख्या है जो इस खेल में हो रहे हैं, प्रशंसकों का उल्लेख नहीं करना। आदेशों।

किसी को भी एक तरफ नहीं छोड़ने के लिए, हमें एक ऐसी प्रणाली की आवश्यकता थी जो नेत्रहीन खेल के पाठ्यक्रम को प्रतिबिंबित करे, और यहां तक ​​कि यह महसूस किया कि जिस दुनिया में हमने आविष्कार किया था। वास्तव में, इस प्रणाली को दर्शक को वास्तविक समय में खेल की घटनाओं की कल्पना करनी चाहिए। और चूंकि यह एक खेल है, सिस्टम को एक खेल की तरह दिखना चाहिए: दुनिया की रंगीन तस्वीरें, स्टाइलिश नायक, सुंदर विशेष प्रभाव और असमान (जहां तक ​​संभव हो) घटनाएं। एक म्यूजियम ने हम सभी का दौरा किया: हम चाहते हैं कि गेम एक हीरोज की तरह ही प्रभावित हो सकता है और शायद हीरोज ऑफ माइट और मैजिक भी। और यह आदर्श होगा यदि हम इसे विभिन्न मोबाइल प्लेटफार्मों पर लॉन्च कर सकते हैं!

अद्वितीय गेम डिज़ाइन और CTF नियमों को विकसित करने में उनकी बड़ी मदद के लिए मैक्सिम कोरोलसेव ( gametrek.ru ) का विशेष धन्यवाद।

नियम और खेल यांत्रिकी

किंवदंती के अलावा, बुद्धिशीलता के पहले हफ्तों में, मूल खेल यांत्रिकी और खेल के नियम दिखाई दिए, जो कार्य को सुलझाने की प्रक्रिया में थोड़ी सी रणनीति जोड़ते हैं। हमने यांत्रिकी को विकसित करने की कोशिश की ताकि खिलाड़ियों को खेल के संचालन के लिए हमेशा कई रणनीतियों का विकल्प मिले, जिनमें से प्रत्येक उन्हें जीत की ओर ले जा सके।
खेल सेट में शामिल हैं:

• 10 टीमें :),
• 5 टीम सेवाओं (खानों),
• 3 सामान्य सेवाएं (ड्रॉ माइंस),
• 25 कार्य
• 4 बॉस (खलनायक)।

खेल का उद्देश्य: जितना संभव हो उतना सोना हासिल करें। सबसे "अमीर" टीम जीतती है।


खेल यांत्रिकी का योजनाबद्ध प्रतिनिधित्व (विकल्प 1)

खेल का सार:

1. राउंड - खेलने के समय का पांच मिनट का अंतराल। प्रत्येक दौर के अंत में, खेल की घटनाएं घटित होती हैं, साथ ही सेवाओं में झंडे भी अपडेट किए जाते हैं।
2. एक ध्वज कुछ गुप्त जानकारी है जो सेवाओं, कार्यों या मालिकों में पाई जा सकती है।
3. सोना डी। आई। मेंडेलीव के रासायनिक तत्वों की आवधिक प्रणाली के छठे काल के पहले समूह के उपसमूह का एक तत्व है जिसमें परमाणु संख्या 79 है। इसके अलावा, खेल के प्रकार जो रैंकिंग में टीम की स्थिति निर्धारित करते हैं।
4. संसाधन - टीम सेवाओं पर कार्रवाई के प्रदर्शन से प्राप्त एक प्रकार का गेम पॉइंट। प्रत्येक सेवा अपने तरह के संसाधन लाती है।

संसाधनों के प्रकार (बढ़ती लागत के क्रम में):

• पेड़,
• कोयला,
• लोहा,
• तेल,
• क्रिस्टल।

संसाधन क्रियाएँ:

• सोने के लिए संसाधनों की खरीद / बिक्री (संसाधनों को सोने के लिए खरीदा / बेचा जा सकता है, और संसाधनों की खरीद की लागत बिक्री की लागत से अधिक है);
• कार्यों की खरीद (कार्यों पर कार्रवाई देखें);
• एक स्वस्थ राज्य में अपनी सेवा बनाए रखने के लिए एक संसाधन प्राप्त करना (टीम सेवाओं पर कार्रवाई देखें);
• प्रतियोगियों की सेवाओं पर हमले के लिए एक संसाधन प्राप्त करना (टीम सेवाओं पर कार्रवाई देखें)।

1. सेवा - प्रति चक्कर एक बार अपडेट किए गए ध्वज के साथ एक संवेदनशील अनुप्रयोग, जो टीमों में से एक से संबंधित है।
टीम सेवाओं पर कार्रवाई:

• स्वस्थ अवस्था में इसकी सेवा को बनाए रखना। यदि सेवा स्वस्थ अवस्था में है, तो प्रत्येक दौर में इसके मालिक के लिए एक निश्चित मात्रा में संसाधन का उत्पादन होता है।
• प्रतिद्वंद्वी सेवाओं पर हमले। एक टीम अपनी सेवाओं में कमजोरियों का फायदा उठाकर प्रतिद्वंद्वियों की सेवाओं पर हमला कर सकती है। इसके अलावा, एक सफल हमले के लिए, हमला करने वाली टीम एक दौर के लिए पीड़ित टीम के संसाधन का हिस्सा होती है। इस प्रकार, जितने अधिक विरोधी एक टीम पर हमला करते हैं, उतने अधिक संसाधन प्राप्त करते हैं।
• उनकी सेवा का संरक्षण (पैचिंग)। अधिक विरोधी सफलतापूर्वक किसी टीम की सेवा पर हमला करते हैं, कम संसाधन जो इसे राउंड के अंत में प्राप्त होगा, इसलिए इसे कमजोरियों को बंद करके अपनी खानों की रक्षा करने की आवश्यकता है।

सेवाओं के लिए टीमों को प्राप्त होने वाले अंकों की गणना निम्नलिखित सूत्रों का उपयोग करके की जाती है:

• यदि कोई टीम किसी और के झंडे को चुरा लेती है, तो उसे 0.4 * C / N प्राप्त होता है, जहाँ C प्रति चक्कर में सेवा द्वारा लाए गए संसाधनों की कुल संख्या है, और N , उन टीमों की संख्या है, जिन्होंने सेवा के स्वामी टीम सहित इस ध्वज को पारित किया है, यदि सेवा को संचालन के रूप में मान्यता प्राप्त है।
• यदि टीम सेवा का मालिक है और यह पूरे दौर के लिए काम करने की स्थिति में है, तो टीम को चोरी के पूरे शेष संसाधन शून्य से प्राप्त होते हैं।

2. साझा सेवा प्रति दौर एक बार अपडेट किए गए झंडे के साथ एक कमजोर अनुप्रयोग है जो किसी भी टीम से संबंधित नहीं है।

साझा सेवाओं पर कार्रवाई:

• साझा सेवाओं पर हमले। एक टीम अपनी सेवाओं में कमजोरियों का फायदा उठाकर आम सेवाओं पर हमला कर सकती है। इसके अलावा, एक सफल हमले के लिए, हमलावर टीम को निश्चित मात्रा में सोना मिलता है।

3. कार्य - यह एक ध्वज के साथ एक पूर्व-तैयार कार्य है, जिसे हल करने के लिए कुछ कौशल की आवश्यकता होती है।

कार्यों पर कार्रवाई:

• उद्घाटन (खरीद) कार्य। प्रारंभ में, सभी कार्य टीमों के लिए बंद हैं। इनाम और कौशल को हल करने के लिए आवश्यक कार्य पर जानकारी उपलब्ध है। किसी कार्य को हल करने की शुरुआत करने के लिए, एक टीम को उस पर निश्चित मात्रा में संसाधन खर्च करके एक कार्य खरीदना चाहिए।
• समाधान कार्य है। यदि टीम ने कार्य को हल कर लिया है, तो वह कार्य की जटिलता के आधार पर एक निश्चित मात्रा में सोना प्राप्त करता है। साथ ही, कार्य को हल करने के लिए आवश्यक कौशल के मूल्यों को टीम के संबंधित कौशल में जोड़ा जाता है।

4. बॉस एक ध्वज के साथ एक पूर्व-तैयार कार्य है, जिसमें एक सीमित जीवनकाल (3 घंटे), चर पारिश्रमिक और इसे हल करने के लिए कुछ कौशल की आवश्यकता होती है।

सभी टीमों के प्रत्येक राउंड में एक निश्चित मात्रा में सोना (टैक्स) इकट्ठा किया जाता है, जिसे गुल्लक में बॉस को डाल दिया जाता है।

मालिकों पर कार्रवाई:

• बॉस का फैसला। यदि टीम ने बॉस पर फैसला किया है, तो बॉस का शेष जीवन समय 30 मिनट तक कम हो जाता है, और कर लगाया जाना बंद हो जाता है। आवंटित समय में बॉस का फैसला करने वाली सभी टीमों ने अपने गुल्लक को समान रूप से विभाजित किया और इसे हल करने के लिए आवश्यक कौशल के लिए एक प्लस प्राप्त किया।

5. कौशल (कौशल) - खेल के प्रकार जो बताते हैं:

• किसी विशिष्ट कार्य को हल करने के लिए खिलाड़ियों से क्या कौशल चाहिए;
• टीम के खिलाड़ियों के पास कौन से कौशल हैं जो वे हल करते हैं।

कौशल के प्रकार:

• वेब - वेब के साथ काम करने का कौशल;
• रिवर्स - रिवर्स विश्लेषण का कौशल;
• Pwn - कमजोरियों का कौशल शोषण;
• फोरेंसिक - फोरेंसिक परीक्षाओं का ज्ञान;
• Ucucuga - गैर-मानक / गैर-स्पष्ट कार्यों को हल करने का कौशल;
• क्रिप्टो - क्रिप्टोग्राफी का ज्ञान;
• नेटवर्क - नेटवर्क के बुनियादी ढांचे और प्रोटोकॉल का ज्ञान;
• विविध - विभिन्न प्रकार के कौशल जो पिछले प्रकारों से संबंधित नहीं हैं।

कौशल पर कार्रवाई:

• कार्य को हल करने के लिए कौशल प्राप्त करना (कार्य पर कार्रवाई देखें);
• बॉस निर्णय के लिए कौशल प्राप्त करना (बॉस पर कार्रवाई देखें)।

6. उपलब्धि (इनाम) - कुछ आवश्यकताओं को पूरा करने के लिए एक टीम को जारी किया गया इनाम। कुल मिलाकर, खेल में आप 42 प्रकार के पुरस्कार प्राप्त कर सकते हैं।


खेल यांत्रिकी का योजनाबद्ध प्रतिनिधित्व (विकल्प 2)

नेटवर्क का बुनियादी ढांचा

जब खेल के नियम तैयार थे और हर किसी को पहले से ही इस बात का अंदाजा था कि प्रतियोगिता कैसे होगी और तकनीकी दृष्टिकोण से इसकी क्या जरूरत है, नेटवर्क इन्फ्रास्ट्रक्चर का डिजाइन शुरू हुआ।

डिज़ाइन

शैली के सभी कैनन के अनुसार, नियमों, गेम मैकेनिक्स और सामान्य ज्ञान के आधार पर आवश्यकताओं के विनिर्देशन के साथ डिजाइनिंग शुरू हुई, और उसके बाद ही सीधे नेटवर्क के डिजाइन के लिए आगे बढ़ना संभव था।

प्रत्येक टीम का अपना सबनेट होना चाहिए, और एक सबनेट से दूसरे के अनुरोध को एनएटी के पीछे छिपाया जाना चाहिए, ताकि खिलाड़ी आईपी पते के आधार पर जूरी सिस्टम के अनुरोधों से विरोधियों के हमलों को अलग न कर सकें।

कमांड सबनेट के अलावा, इंटरैक्टिव कार्यों और साझा सेवाओं की मेजबानी के लिए एक अलग सेगमेंट होना चाहिए। इसके अलावा, यह आवश्यक है कि सेवा सबनेट के बारे में जानकारी प्राप्त कर सकती है जिसमें से टीम की पहचान करने के लिए अनुरोध भेजा गया था।

डिफ़ॉल्ट रूप से, सभी कार्यों के लिए खिलाड़ियों की पहुंच सीमित होनी चाहिए, लेकिन टीम द्वारा एक निश्चित कार्य खरीदने के तुरंत बाद, पूरे सबनेट तक पहुंच होनी चाहिए।

गेमिंग इन्फ्रास्ट्रक्चर में ज्यूरी सेगमेंट भी शामिल होना चाहिए। इसमें ज्यूरी सिस्टम, एक यूजर इंटरफेस वाला एक वेब सर्वर, विजुअलाइज़र का सर्वर हिस्सा, साथ ही साथ कंप्यूटर हैं जिनसे पूरी गेम प्रक्रिया को कॉन्फ़िगर और मॉनिटर किया जाता है। इस सबनेट से, सभी कार्यों, सेवाओं और कमांड तक पहुंच खुली होनी चाहिए। और, ज़ाहिर है, सभी सबनेट के लिए इंटरनेट तक मुफ्त पहुंच होनी चाहिए।

कार्यान्वयन

सिस्को उत्प्रेरक 3750X 24 स्विच सर्वर रूम में स्थित नेटवर्क कोर के रूप में चुना गया था। सिस्को एएसए 5510 फ़ायरवॉल इससे जुड़ा हुआ था, जो सीटीएफ नेटवर्क (टीमों, कार्यों, सेवाओं, चोटों) के सभी खंडों के लिए डिफ़ॉल्ट गेटवे के रूप में भी काम करता था। उन्होंने नेटवर्क पर सभी कंप्यूटरों के लिए आईपी पते (डीएचसीपी) वितरित किए, आईपी पते का अनुवाद (एनएटी) प्रदान किया, कार्यों के लिए सीमांकित पहुंच, और इंटरनेट का उपयोग प्रदान किया।

सिस्को उत्प्रेरक 3750G 24 स्विच नेटवर्क कोर से जुड़ा था, जिसमें दस टीमों के डी-लिंक डेस -1008 ई स्विच और एक जूरी जुड़े हुए थे, जिनमें से प्रत्येक अपने स्वयं के खंड (वीएलएएन) से संबंधित थे।

इसके अलावा, इंटरेक्टिव कार्यों, सामान्य सेवाओं और जूरी सिस्टम के लिए दो शक्तिशाली सर्वर मुख्य राउटर से जुड़े थे:

1.2 प्रोसेसर, 4 कोर, 64 जीबी रैम, 1 टीबी एचडीडी।
दो आभासी मशीनों के साथ VMware ESXi को इस पर उठाया गया था। Ubuntu 13.04 के पहले सर्वर संस्करण ने जूरी सेवाओं के एक सेट के साथ काम किया:

• जूरी प्रणाली
• उपयोगकर्ता इंटरफ़ेस
• सेवाओं के कामकाज के लिए आवश्यक सब कुछ।

दूसरे ने विंडोज 7 चलाने वाली विज़ुअलाइज़र सेवा चलाई।

2.2 प्रोसेसर, 6 कोर, 128 जीबी रैम, 1 टीबी एचडीडी।
VMware ESXi भी इस पर चला, 36 आभासी मशीनों चल रहा है:

• इंटरैक्टिव कार्यों के लिए 20
• सामान्य सेवाओं के लिए 3,
• 13 मालिकों के तहत।

गेम नेटवर्क आरेख

सामान्य परियोजना वास्तुकला

एक बार जब किंवदंती और नियम तैयार हो गए, तो सिस्टम की समग्र वास्तुकला को डिजाइन करना शुरू करना आवश्यक था। इसके बाद डिवाइस प्लेटफॉर्म को संपूर्ण, साथ ही प्रत्येक व्यक्तिगत घटक के रूप में वर्णित किया जाएगा।


परियोजना की समग्र वास्तुकला का योजनाबद्ध प्रतिनिधित्व

मुख्य तत्व जूरी सिस्टम है , एक सिस्टम जो सभी गेम लॉजिक को प्रोसेस करता है। उनके कार्यों में खेल की घटनाओं और स्कोरिंग टीमों का प्रसंस्करण शामिल है। अन्य सभी भाग स्वतंत्र उपतंत्र के बजाय बाहरी इंटरफेस हैं।

ध्वज स्वीकर्ता इंटरफ़ेस - ध्वज स्वीकार इंटरफ़ेस। यह जूरी सिस्टम का एक सबसिस्टम है; आम सेवाओं और विरोधियों की सेवाओं से चुराए गए झंडे को पारित करने के लिए टीमों की क्षमता प्रदर्शित करने के लिए इस आरेख पर प्रस्तुत किया गया है।

MongoDB एक गेम स्टेट डेटाबेस है। खेल की सभी वर्तमान स्थिति संग्रहीत और अद्यतन की गई है: टीमों द्वारा बनाए गए अंक, कार्य की स्थिति (प्रत्येक टीम के लिए खुला या बंद), कार्यों और मालिकों का पूर्ण विवरण, खेल की अवधि, आदि।

उपयोगकर्ता इंटरफ़ेस (UI) - वेब एप्लिकेशन के रूप में कार्यान्वित आदेशों के लिए एक उपयोगकर्ता इंटरफ़ेस। खेल के नियमों के अनुसार, टीमें कार्य खोल सकती हैं, संसाधन खरीद / बेच सकती हैं, कार्यों को हल कर सकती हैं, वर्तमान रेटिंग के बारे में जानकारी प्राप्त कर सकती हैं, आदि यूआई इस कार्यक्षमता के लिए जिम्मेदार है। प्रदर्शन के लिए प्रारंभिक डेटा के रूप में, हम MongoDB से डेटा लेते हैं। उपयोगकर्ताओं से प्रसंस्करण अनुरोध RPC के माध्यम से कार्यान्वित किए जाते हैं, जो AMQP पर बदले में बनाए जाते हैं।

विज़ुअलाइज़र एक गेम विज़ुअलाइज़ेशन सिस्टम है जो गेम इवेंट्स को जमा और प्रदर्शित करता है। चूंकि सभी जानकारी को घटनाओं के माध्यम से प्रेषित नहीं किया जा सकता है, सिस्टम MongoDB में सिस्टम की स्थिति से कुछ डेटा लेता है।

नेटवर्क एक्सेस इंटरफेस - टास्क एक्सेस कंट्रोल इंटरफेस। खेल की शुरुआत में, सभी कार्य टीमों के लिए उपलब्ध नहीं हैं। जैसे ही टीम एक कार्य खोलती है, उसे इस इंटरफ़ेस का उपयोग करके इसे खोला जाता है।

जूरी प्रणाली

जैसा कि ऊपर वर्णित है, जूरी सिस्टम गेम लॉजिक के प्रतिपादन के लिए जिम्मेदार है। इसे डिजाइन करते समय, हमने निम्नलिखित लक्ष्यों को प्राप्त करने की कोशिश की:

1. खेल के नियमों का सही क्रियान्वयन । आप किसी भी प्रतिभागी को कोई धोखा नहीं दे सकते। हमारे लिए सबसे महत्वपूर्ण चीज खेल के नियमों का पालन करना था।
2. काम की स्थिरता। खेल के दौरान, प्रतिभागियों को जूरी सिस्टम के साथ काम करने में कठिनाई नहीं होनी चाहिए। अचानक गिरने से पूरे खेल का असंतुलन हो सकता है: संभावना असमान होगी और प्रतियोगिता उद्देश्यपूर्ण नहीं होगी। इस कारण से, स्थिर संचालन को प्राप्त करने के लिए, हमने परीक्षण पर बहुत प्रयास किया।
   
   सुरक्षा कारणों से, हमने जूरी सिस्टम के गिरने के बाद खेल की स्थिति को बहाल करने के लिए एक विशेष प्रणाली बनाई।
3. काम की गति। सीटीएफ गेम खेलने के अनुभव से, हम जानते थे कि सिस्टम से प्रतिक्रिया में देरी एक टीम के लिए घातक हो सकती है, खासकर अगर अंतिम समय में कार्य हल किया गया था। सिस्टम जितनी तेजी से उपयोगकर्ता से अनुरोध संसाधित करता है, उतनी ही तेजी से टीम अगला कार्य शुरू कर सकती है।
4. सुरक्षा। नियमों के सही पालन के साथ, एक महत्वपूर्ण पहलू पूरे सिस्टम की सुरक्षा भी था। साधारण प्रोग्रामर ने खेल में भाग नहीं लिया, लेकिन असली हैकर्स। अवैध बिंदुओं या अनधिकृत पहुंच की अनुमति देना असंभव था :)

लक्ष्य इंगित किए गए हैं, अब आप जूरी सिस्टम के कार्यों को चित्रित कर सकते हैं:
1. दौरों को संभालना

• नियमों के अनुसार, प्रत्येक दौर में नई टीमों के झंडे टीमों की सेवाओं से भरे होने चाहिए, और दौर के अंत में, टीमों से प्राप्त सभी झंडों के लिए संसाधनों को जोड़ा जाना चाहिए। वर्तमान दौर के झंडे हटा दिए गए हैं।
• यदि कोई सक्रिय बॉस है, तो राउंड के अंत में, टीम से "निकासी" करों।

2. उपयोगकर्ता अनुरोध प्रसंस्करण

• संसाधनों की खरीद / बिक्री का कार्यान्वयन।
• कार्य खोलने / सुलझाने का काम।
• प्रसंस्करण समाधान।

3. टीमों से सेवाओं से झंडे का रिसेप्शन

• इस कार्य में मौजूदा दौर के लिए ध्वज की वैधता की जाँच करना और उस टीम को शामिल किया गया है जिसने ध्वज को पारित किया है (आप अपने झंडे को पास नहीं कर सकते हैं)। यदि झंडा चेक से गुजरता है, तो राउंड के अंत में इसके लिए संसाधन प्राप्त करने के लिए राहगीर को एक विशेष सूची में रखा जाता है।
• एक ही टीम द्वारा एक ही झंडे को पारित किया जा सकता है।

4. मालिकों के तर्क को संसाधित करना

• मालिकों को समय पर उपेक्षित और मार दिया जाना चाहिए। बॉस की हत्या का समय गतिशील है। पहली टीम के निर्णय के बाद, बॉस को 30 मिनट तक रहना होगा। यह याद रखने योग्य है कि बॉस के पास अधिकतम 3 घंटे का जीवनकाल है।

5. उपलब्धियों के साथ टीम को पुरस्कृत करना

• हम 42 अलग-अलग उपलब्धियों के साथ आए, जिनके साथ टीमों को चिह्नित किया जा सकता है। वे सभी विभिन्न प्रकार के कार्यों के प्रतिभागियों द्वारा अनुक्रमिक निष्पादन पर आधारित हैं, इसलिए वे एक तरह से टीमों की रणनीति की विशेषता रखते हैं। इस तर्क को लागू करने के लिए, सभी डेटाबेस प्रश्नों में से अधिकांश लिया, लेकिन कम से कम यह मजेदार है :)

जूरी सिस्टम आर्किटेक्चर

बाहरी घटकों के साथ काम करने के लिए इंटरफेस:

• MongoDB - MongoDB के साथ काम करने के लिए एक इंटरफ़ेस। प्रारंभ में, यह MongoDB में एक चालू खाते को बचाने के लिए योजना बनाई गई थी, ताकि यूआई जल्दी से टीमों की रेटिंग पर प्रासंगिक डेटा प्राप्त कर सके। इस लक्ष्य के आधार पर, MongoDB को चुना गया क्योंकि यह तेजी से पढ़ने की सुविधा प्रदान करता है। खेल के पूरे समय के लिए डेटाबेस में लिखना काफी दुर्लभ है और बाहरी घटनाओं (टीमों द्वारा ध्वज का वितरण, कार्य) या दौर के अंत में (अगले की शुरुआत) के साथ मेल खाने के लिए समयबद्ध है।
• AMQP इंटरफ़ेस - AMQP के साथ काम करने के लिए एक इंटरफ़ेस। AMQP को मैसेजिंग प्रोटोकॉल के रूप में चुना गया था। इस इंटरफ़ेस के आधार पर, RPC को UI और इवेंट मैनेजर द्वारा विज़ुअलाइज़र और UI के कुछ हिस्सों के लिए लागू किया गया था।

खेल का सार:

• टीमें - आदेशों के विवरण के लिए एक अमूर्त,
• सेवाएं - सेवाओं का विवरण,
• मालिकों - मालिकों का वर्णन,
• संसाधन - संसाधनों का वर्णन,
• कार्य - कार्यों का वर्णन।

खेल संस्थाओं पर तर्क का प्रसंस्करण "खेल प्रबंधकों" द्वारा किया जाता है। मैं उनकी कुछ कार्यान्वयन सुविधाओं पर ध्यान देना चाहूंगा।

• ध्वज स्वीकर्ता एक ऐसी टीम है जो टीमों से सेवाओं के झंडे प्राप्त करने के लिए पूरी तरह से जिम्मेदार है। TCP-Server , . ( 10), : , — «» .
• Boss Manager — . , , . .
• Event Manager — , . , . , , . .
• Service Checker Manager — , . , .

सेवाओं की सेवाक्षमता की जांच करने के लिए, CTF आयोजक विशेष कार्यक्रमों, चेकर्स को पूर्व-लिखते हैं। सेवाएं आमतौर पर पूरी तरह से अमूर्त होती हैं और प्रतिस्पर्धा से प्रतिस्पर्धा में भिन्न होती हैं, इसलिए, चेकर्स के साथ काम करने के लिए एक सार्वभौमिक इंटरफ़ेस होना चाहिए। निम्न कमांड लाइन मापदंडों के साथ चेकर्स को अलग-अलग प्रक्रियाओं में लॉन्च किया जाता है: {GET या PUT} कमांड , जो यह निर्धारित करता है कि क्या कार्रवाई की जाए - सेवा पर एक ध्वज लगाएं या उसकी उपस्थिति की जांच करें, उस सर्वर का आईपी पता जिस पर ध्वज के साथ सेवा की जाँच की जाती है, ध्वज। पूरा होने पर, परीक्षक को पूर्ण स्थिति वापस करनी होगी:

• 0 - सेवा ठीक से काम कर रही है;
• 1 - सेवा चल रही है, लेकिन प्रोटोकॉल नहीं चल रहा है (झंडा गायब है);
• 2 - सेवा काम नहीं कर रही है (कनेक्शन ने इनकार कर दिया)।

चूँकि चेकर्स के लिए 2 क्रियाएं - GET और PUT - को एक राउंड में किया जाना चाहिए, उन्हें सभी टीमों के लिए प्रति राउंड 2 बार लॉन्च किया जाता है: PUT - राउंड के पहले क्वार्टर में एक चौथाई के भीतर रैंडम देरी के साथ, GET - राउंड के तीसरे क्वार्टर में रैंडम डिले के साथ। PUT कमांड के निष्पादन के लिए चेकर्स की शुरुआत के समय, उन सभी चेकर्स को पूरा करना जिनके पास उस समय तक काम करने का समय नहीं था, भी प्रदर्शन किया गया था। इस स्थिति में सेवा की स्थिति एक चेकर ऑपरेशन त्रुटि प्रदर्शित करेगी।

वास्तुकला में, सभी सेवाओं और सभी टीमों पर तुरंत चेकर्स लॉन्च किए जाते हैं, इसलिए सेवाओं की जांच करना पूरे सिस्टम का सबसे संसाधन-गहन कार्य है। इसलिए, लेखन चेकर्स पर विशेष ध्यान दिया जाना चाहिए - उन्हें जितनी जल्दी हो सके बाहर काम करना चाहिए और यथासंभव कम संसाधनों का उपयोग करना चाहिए। सामान्य तौर पर, प्रोग्रामिंग के दृष्टिकोण से, सब कुछ हमेशा की तरह है :)

शेष घटक विशेष रुचि के नहीं हैं। केवल एक चीज जो मैं नोट करना चाहूंगा वह है कि गिरावट के बाद खेल को बहाल करना। इस कार्यक्षमता को लागू करने के लिए, कई गेम चर को एक बाहरी डेटाबेस में सहेजना पड़ता था। चूंकि अधिकांश डेटा पहले से ही MongoDB में संग्रहीत थे, इसलिए शेष को बचाने और डेटाबेस से उन्हें पुनर्स्थापित करने के लिए कार्यक्षमता जोड़ने का निर्णय लिया गया था।

अंत में, जूरी सिस्टम के कार्यान्वयन के बारे में कुछ शब्द ध्यान देने योग्य हैं। पूरी प्रणाली C ++ में लिखी गई थी, क्योंकि यह सिस्टम डेवलपमेंट टीम के बीच सबसे लोकप्रिय भाषा थी। इसके अलावा, लेखक दृढ़ता से आश्वस्त है कि पायथन में लिखा गया समान कोड अधिक धीमी गति से काम करेगा। एक विकास ढांचे के रूप में, Qt को परियोजना के लिए समर्पित डेवलपर्स के लिए सबसे सुविधाजनक चुना गया था।

विस्तार

लेखक: slim_d0g blackzert muodov ki11obyte Asperka

PS गेमप्ले के विश्लेषण के साथ एक दिलचस्प लेख PHDays वेबसाइट पर प्रकाशित किया गया है।