मल्टीप्लेयर धोखा को रोकें


10

मैं एक छोटा इंडी-स्टाइल मल्टीप्लेयर गेम विकसित कर रहा हूं। जबकि मैं लोगों को एकल-खिलाड़ी में धोखा देने की अनुमति देना चाहता हूं, लेकिन यह स्पष्ट रूप से बहु-खिलाड़ी में स्वीकार्य नहीं है। क्या किसी को खेल के कुछ हिस्सों को संशोधित करने के लिए चीट-इंजन जैसी किसी चीज का उपयोग करने से औसत जो को रोकने में मदद करने का कोई तरीका पता है? मैं वर्तमान में हर कुछ सेकंड के सत्यापन के लिए गेम सर्वर पर गेम का उपयोग करने वाली फ़ाइल (XML के रूप में संग्रहीत) के लिए प्रत्येक सेटिंग के एमडी 5 हैश अपलोड करने की योजना बना रहा हूं, लेकिन मेमोरी-एडिटर जैसी चीजों को रोकने के लिए मैं कुछ भी कर सकता हूं। ?


2
मैं इस लेख, बिल्डिंग मल्टीप्लेयर गेम्स - सुरक्षा को कुछ मल्टीप्लेयर एपीआई के लिए लिखा गया हूं , लेकिन विचार अच्छे हैं और अभी भी लागू होते हैं
साइरेल

जवाबों:


8

यदि आप स्थानीय रूप से संशोधित कोड के बारे में चिंतित हैं, तो आप यह कैसे सुनिश्चित कर सकते हैं कि किसी ने एमडी 5 हैश की स्थिर सूची भेजने के लिए आपके अधिसूचना कोड को संशोधित नहीं किया है, वही जिनकी आप उम्मीद करते हैं? वास्तव में, आपको ऐसा करने के लिए कोड संशोधन की भी आवश्यकता नहीं है, आपको बस एक काफी बुनियादी प्रॉक्सी की आवश्यकता है (कोई एसएसएल नहीं, लेकिन यहां तक ​​कि थोड़ा और प्रयास के साथ नकली किया जा सकता है)।

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

तो सवाल यह है कि 'औसत जो' कितना औसत है? आपने पहले ही कोड संपादन और मेमोरी संपादकों का उल्लेख किया है। यह उस चीज से ऊपर है जिसे मैं व्यक्तिगत रूप से औसत स्तर पर विचार करूंगा, और यदि आप उस स्तर के बारे में चिंतित होना चाहते हैं तो एक अलग विश्वसनीय सर्वर जो सभी भारी उठाने की आवश्यकता है और ग्राहक अनिवार्य रूप से सिर्फ डिस्प्ले और इनपुट डिवाइस होने का दावा करेगा।


2
@ user185812: आमतौर पर एक स्वीकृत उत्तर को चिह्नित करने से कुछ घंटे पहले इंतजार करना एक अच्छा विचार है। हालांकि व्यक्तिगत रूप से मुझे लगता है कि मेरा उत्तर बहुत शानदार है (मैं पक्षपाती हूं), अन्य की संभावना अधिक इनपुट होगी, हालांकि एक स्वीकृत जवाब देखकर दूसरों को जवाब देने के लिए अक्सर एक बाधा होती है।
मैथ्यू शारले

@MatthewScharley - कोई चिंता नहीं। ;)
मार्टिन सोजका

11

ग्राहक दुश्मन के हाथ में है। ( ऑनलाइन विश्व डिजाइन के कानून )

वास्तव में, सबसे अधिक धोखा देने का एकमात्र तरीका ग्राहक को "पतला ग्राहक" होना है, वह यह है: केवल एक इनपुट और आउटपुट डिवाइस के रूप में कार्य करने के लिए, और इसे ठीक से ज़रूरत से ज़्यादा जानकारी देने के लिए कभी नहीं।

यह स्वचालन को नहीं रोकेगा और यह निष्क्रिय जानकारी एकत्र करने और विश्लेषण को नहीं रोकेगा, लेकिन आप अपने गेम को ऐसे डिजाइन कर सकते हैं कि इन पर महत्वपूर्ण प्रभाव न पड़े।

यह सर्वर द्वारा भरोसा किए गए विकृत संदेशों के माध्यम से लोगों को एक-दूसरे को हैक करने से नहीं रोकेगा - आपके क्लाइंट को सर्वर से संदेशों के खिलाफ गार्ड करने की आवश्यकता है जैसे कि आप अपनी वेब साइटों को SQL इंजेक्शन हमलों से बचाएंगे।

चूंकि आप एकल-खिलाड़ी गेम के लिए एक ही क्लाइंट का उपयोग करना चाहते हैं, इसलिए एक समाधान एक स्थानीय सर्वर को एक अलग प्रक्रिया / थ्रेड में चलाने और आंतरिक रूप से क्लाइंट / सर्वर सेटिंग के रूप में व्यवहार करना होगा। "धोखा" तब सर्वर की तरफ काम करेगा। Minecraft कुछ ऐसा ही करता है, हालांकि यह गेम इंजन को उसके इंटरफ़ेस से इस तरह विभाजित करने वाला पहला गेम नहीं है।

सुझाया गया पढ़ना:


2

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

अब धोखा देने के अन्य तरीके भी हैं, लेकिन वे सभी इस बारे में हैं कि आपका गेम कैसे बनाया गया है।

सबसे आसान हैक से बचाने के लिए, जो नेटवर्क संदेशों को फीका कर रहा है, सर्वर को अपनी पवित्रता के लिए उन पैकेज की जांच करनी चाहिए। "उस आदमी ने सिर्फ 5 स्क्रीन जंप किए। यह असंभव है, इनकार पैकेज।" (ध्यान दें कि आप पूरी तरह से सिंक्रनाइज़ किए गए रूट पर भी जा सकते हैं-इसका मतलब है कि सब कुछ सिंक्रनाइज़ है और केवल "क्या बटन खिलाड़ी को दबाते हैं।" - इस तरह के संदेश भेजते हैं- जो फेकिंग नेटवर्क संदेशों को डिजाइन द्वारा बेकार कर देता है।)

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


मैं दृश्यता हैक पर असहमत हूं। जब तक उनके चरित्र के बारे में पता नहीं होगा, तब तक ग्राहक को जानकारी न देकर इन्हें रोका नहीं जा सकता है? मुझे गलत मत समझो, यह अच्छा डिज़ाइन नहीं हो सकता है। लेकिन रोकना असंभव होने से अलग है।
xuincherguixe

@xuincherguixe मुझे लगता है कि कुछ परिस्थितियों में यह असंभव है। उदाहरण के लिए दोनों क्लाइंट एक ही आईपी और एक ही पोर्ट के नीचे खेल रहे हैं। ऐसे मामले में यह केवल एक ग्राहक की भलाई है जो उसे दूसरे के लिए डेटा पढ़ने से रोकता है।
वोडज़ु

1

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

उदाहरण के लिए, मेरे पास 245 गोल्ड है ... चीट इंजन के साथ मैं 245 के लिए एक खोज करता हूं और कई मेमोरी लोकेशन ढूंढता हूं। फिर मैं कुछ और खेलता हूं और अपने सोने को 314 तक लाता हूं, फिर मैं 314 मूल्य के लिए पिछले खोज आउटपुट को खोजता हूं और आसानी से मेमोरी स्थान ढूंढता हूं जहां सोने को संग्रहीत किया जाता है।

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

तो अब सवाल यह है: आप वास्तव में इस तरह से एक मूल्य कैसे संग्रहीत करते हैं जो इसे प्रकट नहीं करता है? यह थोड़ा मुश्किल और बदसूरत हो जाता है और मुझे यकीन है कि कई तरीके हो सकते हैं। मुझे क्या करना पसंद है एक बूलियन सरणी (या बाइट सरणी) स्टोर करना। सरणी की लंबाई कुछ भी हो सकती है, लेकिन मान लें कि यह 13. है। फिर आपके पास एक काउंटर है जो यह दर्शाता है कि 13 वास्तविक मूल्य में कितनी बार जाता है। इसलिए यदि हम 245 का प्रतिनिधित्व करना चाहते हैं, तो काउंटर का मूल्य 18 होगा। अब सरणी में 245/13 के शेष भाग के लिए सभी बूलियनों को सेट करना होगा ... मूल रूप से मापांक। इस मामले में यह 11 है, इसलिए सरणी में पहले 11 बूलियनों को सही पर सेट किया जाएगा, बाकी झूठे को सेट किया जाएगा। आपके द्वारा किए जाने वाले सभी मूल्य को पुनः प्राप्त करने के लिए, सरणी की लंबाई से काउंटर को गुणा करें, फिर प्रत्येक बूलियन सेट के लिए 1 को सच में जोड़ें (पहले गलत पर रोकते हुए)। अब 245 की संख्या को कभी भी कहीं भी संग्रहीत नहीं किया जाएगा और उस स्मृति स्थान को खोजना मुश्किल होगा जो सोने की राशि को बदलने के लिए हेरफेर करने की आवश्यकता होगी। जब आप इस ऑब्जेक्ट को बनाते हैं, तो आप सरणी की लंबाई अलग-अलग आकारों में सेट करना चाहते हैं (हो सकता है कि कुछ उचित सीमा के बीच संख्या को अनियमित रूप से उठाएं)।

संपादित करें: यह मल्टीप्लेयर और एकल खिलाड़ी के लिए उपयोगी है। ऐसा धोखा है जो मल्टीप्लेयर में भी किया जा सकता है, जहां पैकेट में मूल्यों में परिवर्तन हो सकता है। इसे रोकने के लिए विभिन्न तकनीकों की आवश्यकता होगी, जैसे प्रत्येक पैकेट पर हस्ताक्षर करना।


1
आमतौर पर, धोखाधड़ी को रोकने के लिए, मल्टीप्लेयर गेम सर्वर पर सब कुछ की गणना करते हैं, इसलिए क्लाइंट पर एक मूल्य को संशोधित करते हैं, या सर्वर को भेजे गए पैकेट में, वास्तविक गेम में कोई चीज़ नहीं बदलते हैं। लेकिन फिर भी, बाकी का जवाब दिलचस्प है।
Vaillancourt

@AlexandreVaillancourt अच्छी बात है। मैं सर्वर के सीपीयू को चिन्हित करने वाले हस्ताक्षरों से टकराकर चिंतित हूँ। मैं केवल दो खिलाड़ियों के बीच पैकेट पास करके सर्वर को तेज रखना चाहता हूं, लेकिन मैं अब इस पर ध्यान दूंगा कि आपने इसे इंगित किया है।
जोस मार्टिनेज

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

1
उससे बचने के लिए, आप सर्वर को नए जीवन को अपडेट करने देते हैं, फिर ग्राहक को नया जीवन भेजते हैं। सब कुछ सर्वर पर गणना की जाती है, और क्लाइंट को सभी महत्वपूर्ण चीजों के लिए बस "डंबल टर्मिनल" होने दें: क्लाइंट खिलाड़ी से इनपुट कैप्चर करने के लिए जिम्मेदार होगा ("समय पर एक्स, वाई पर क्लिक किया जाता है", "हिट" बटन समय पर T "), उन्हें सर्वर पर भेज रहा है, और सर्वर से नया राज्य प्राप्त कर रहा है (" खिलाड़ी अब स्थिति X, Y पर है "," खिलाड़ी के पास जीवन ZZZ है ") और खिलाड़ी को प्रदर्शित करता है।
Vaillancourt

1
इसके साथ, चीटर (बीच में आदमी) उन सभी को गड़बड़ कर सकता है जो पैकेट के साथ चाहते हैं, यह सर्वर पर गेम की स्थिति को नहीं बदलेगा क्योंकि सर्वर यह सुनिश्चित करेगा कि इनपुट वैध है ("हम्म क्लाइंट ने क्लिक किया है" पिछले 0.03 सेकंड के भीतर पांच अलग-अलग स्थानों पर, यह सामान्य नहीं है, आइए इन क्लिक्स को अस्वीकार करें "), और सभी सिमुलेशन को स्वयं चलाएं ।
Vaillancourt
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.