हमारे (मल्टीप्लेयर) गेम में धोखाधड़ी को कैसे रोकें?

Question

यदि आप एक गेम लिख रहे हैं तो आपको धोखेबाज़ों और धोखाधड़ी से रोकने के बारे में सोचना चाहिए।

मुझे लगता है कि केवल mmo मल्टीप्लेयर गेम नहीं बल्कि सिंगलप्लेयर या "होम-ब्रूड" पी 2 पी एमपी गेम्स भी नहीं हैं।

जब गेम पूरी तरह से सर्वर-क्लाइंट आर्किटेक्चर पर आधारित होता है, तो नौकरी लगभग पूरी तरह से होती है, मुझे लगता है कि दीवार हैक्स या कुछ और भी है।

मैंने अपना खुद का पी 2 पी गेम बनाया और कुछ समय बाद धोखेबाज दिखाई दिए। वे केवल स्क्रिप्टकिडीज़ थे जिन्होंने धोखा इंजन का इस्तेमाल किया और स्पीडहेक्स और मेमोरी हैक की कोशिश की।

अधिकांश speedhacks हुक gettickcount। मैंने निम्नलिखित सरल चाल से स्पीडहेकर को हल किया। मैं सिर्फ time()-GetTickCount() मान को ट्रैक कर रहा हूं और यदि अंतर में परिवर्तन होता है तो धोखाधड़ी होती है।

मेमोरी भ्रष्टाचार को कहीं भी एक हैश की प्रतिलिपि रखते हुए हल किया जा सकता है और इसे हमेशा चल रहा है और हमेशा यादृच्छिक मूल्य से इसे फिर से चलाया जा सकता है। विसंगति का कारण दुर्घटनाग्रस्त हो जाता है।

बिल्कुल Cheat इंजन सुलझा लिए, बस की जाँच करें:

if (OpenFileMapping(FILE_MAP_READ,false,'CEHYPERSCANSETTINGS')!=0) 
{ 
    // Cheat Engine runs. 
} 

(एक दोस्त ने मुझे बताया कि यह, मैं इसे अभी तक परीक्षण नहीं किया।)

ये चाल सबसे धोखेबाज हल। लेकिन निश्चित रूप से अधिक धोखाधड़ी तकनीक है। मैंने इस विकी को और अधिक धोखाधड़ी तकनीक और उनसे बचने के तरीके पर चर्चा करने के लिए खोला।

Answer 1

मुझे नहीं लगता कि आपको सिंगल प्लेयर गेम पर धोखा देने से रोकने के लिए कुछ भी करना चाहिए। आपके उपयोगकर्ताओं ने गेम खरीदा, वे धोखा देने में सक्षम होना चाहिए, जब तक कि वे दूसरों के खिलाफ नहीं खेल रहे हैं।

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

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

2) अन्य सभी प्रक्रियाओं को खोलें, और उनके WriteProcessMemory फ़ंक्शंस को हुक करें ताकि वे आपके गेम की प्रक्रिया में स्मृति को नहीं लिख सकें। सही हो गया यह एक कदम सभी धोखाधड़ी और धोखा इंजन के 90% को अवरुद्ध करेगा।

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

4) अपने गेम की अपनी प्रक्रिया में वर्चुअलप्रोटेक्टएक्स/वर्चुअलएलोकएक्स/आदि कार्यों में हुक करें और निगरानी करें कि कौन से मॉड्यूल सुरक्षा स्तर बदल रहे हैं या नई मेमोरी हिस्से आवंटित कर रहे हैं। जब आपका गेम बहुत सारे आवंटन करता है तो इसे बहुत सीपीयू गहन होने से रोकने के लिए आपको इसके साथ चालाक होना चाहिए, लेकिन यह किया जा सकता है।

5) लोड लाइब्रेरी कार्यों में हुक करें और डीएलएल इंजेक्शन को रोकने के लिए गतिशील रूप से लोड किए जा रहे किसी भी डीएलएल की निगरानी करें।

6) अपने गेम कनेक्शन पर कुछ हल्के पॉलीमोर्फिक एन्कोडिंग का उपयोग करें।

7) डीबगर्स को अपनी प्रक्रियाओं से जोड़ने से रोकने के लिए कुछ एंटी-डिबगिंग तकनीकों का उपयोग करें। Google एंटी-डिबगिंग और आपको बहुत सारी चीज़ें मिलनी चाहिए।

8) अपने गेम के उपयोगी डिस्सेप्लर को रोकने के लिए एक कस्टम मालिकाना पीई पैकर का उपयोग करें।

9) पारदर्शिता और अल्फा मिश्रण से निपटने वाले आपके ओपनजीएल या डायरेक्ट 3 डी कार्यों और विधियों में हुक करें।

10) यदि शेडर्स का उपयोग करते हैं, तो अपने शेडर्स और शेडर निरंतर मूल्यों की जांच करें।

11) खिलाड़ी पात्रों पर अतिरिक्त प्रलोभन खींचने की तकनीक का उपयोग उनको रोकने के लिए करें जब उन्हें दृष्टि की रेखा अन्य ज्यामिति द्वारा अवरुद्ध कर दी जाती है। यह आपके प्रदर्शन के साथ भी मदद कर सकता है या नहीं, लेकिन यह कई wallhacks को रोक देगा।

Answer 2

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

Answer 3

जब गेम पूरी तरह से सर्वर-क्लाइंट आर्किटेक्चर पर आधारित होता है, तो नौकरी लगभग पूरी तरह से होती है, मुझे लगता है, लेकिन दीवार हैक या कुछ और भी है।

आप लॉजिक्स के सबसे सर्वर साइड पर चलने के लिए, कम से कम, के रूप में वास्तविक संभव प्रत्येक खेल खेलने के चरण के दौरान कम से कम राज्य साझा करने का प्रयास दूसरे शब्दों में नहीं ले जा सकते हैं: में प्रत्येक खिलाड़ी के सक्रिय खेल मोड रखना खाता और केवल उस जानकारी को साझा करें जो उस समय वास्तव में प्रासंगिक है।

यह न केवल धोखा देने की संभावना को कम करेगा, बल्कि आपके प्रोटोकॉल के कारण यातायात को भी कम करेगा, यानी यह दक्षता में सुधार करेगा।

यह एक ऐसी तकनीक है जो बड़े पैमाने पर 3 डी दृश्यों को प्रस्तुत करते समय दक्षता में सुधार के लिए गेमिंग/सिमुलेशन उद्योग में लंबे समय से ज्ञात और लागू होती है।

वहां, "फस्टम कूलिंग" का उपयोग यह निर्धारित करने के लिए किया जाता है कि दृश्य के कौन से हिस्से वास्तव में दिखाई दे रहे हैं, ताकि केवल प्रासंगिक भागों को प्रस्तुत किया जा सके।

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

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

दूसरे शब्दों में, आपके द्वारा समर्थित अद्यतन पैकेट को कम से कम जोड़े जाने का प्रयास करें, ताकि उनके पास पारस्परिक निर्भरताएं एक दूसरे पर न हों, और इसे स्वतंत्र रूप से प्रचारित/सब्सक्राइब किया जा सके।

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