और फिर, डायमंड डैश

जैसे ही मैंने हाल ही के लेख में Google+ पर डायमंड डैश के लिए एक बॉट लिखने के बारे में पढ़ा, जो लगभग 2 मिलियन अंकों तक पहुंच गया, मेरे हाथ तुरंत एक समान बॉट लिखने के लिए कंघी करते हैं जो इस लक्ष्य को प्राप्त करेगा - और, कई दिनों के प्रयोगों के बाद, परिणाम वास्तव में हासिल किया गया है ।

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

सिद्धांत

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

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

• ग्राहक में वायर्ड कुंजी के साथ प्रेषित सूचना पर हस्ताक्षर करना,
• सर्वर से प्राप्त एक कुंजी के साथ प्रेषित सूचना पर हस्ताक्षर करना,
• वर्तमान समय के साथ संचरित सूचना पर हस्ताक्षर करना (एक अलग क्षेत्र में संचरित),
• प्रेषित जानकारी को एन्क्रिप्ट करना,
• एन्क्रिप्शन कोड, हस्ताक्षर एल्गोरिथ्म और फ्लैश की गई कुंजी के मूल्य को जानने से रोकने के लिए क्लाइंट कोड को बाधित करना।

आइए देखें कि गेम के डेवलपर्स द्वारा इनमें से कौन सी तकनीक का उपयोग किया गया था।

ऑपरेशन इंटरसेप्शन

हमने कुछ प्रकार के वेब ट्रैफ़िक स्निफ़र लगाए - उदाहरण के लिए, फिडलर । यह केवल HTTP (और फिर भी हमेशा नहीं) को रोक सकता है, लेकिन यहां यह हमारे लिए पर्याप्त है। स्निफर लॉन्च करें, गेम के साथ पेज खोलें, और एक गेम खेलें। हम फिडलर लौटते हैं, देखो।



हाँ, खिलौना सर्वर से अनुरोध (ddg.wooga.com) विरल हैं - सब कुछ उम्मीद के मुताबिक है। आप स्पष्ट रूप से खेल की शुरुआत ( / खेल / use_life / - जीवन के दिल का उपयोग करें जो प्रत्येक खेल पर खर्च होता है) और उसके अंत ( / खेल / eor / - दौर के अंत) का उपयोग कर सकते हैं, और बीच में कुछ भी नहीं।

खेल के अंत में दो अनुरोध हैं - एक ddg.wooga.com/game/eor पर , दूसरा ddg.t.wooga.com/w/eor के लिए । हम पहले विच्छेद करना शुरू करते हैं।

प्रश्न:

POST ddg.wooga.com/game/eor/?timestamp=1314395650744&signature=V5rwMEQJS_2diWc...ulj2VBs%3D&session=1100447b5bb0d08c12 HTTP/1.1
Host: ddg.wooga.com
Connection: keep-alive
Content-Length: 99
Origin: 8kubpeu8314p2efdd7ljdo-a-oz-opensocial.googleusercontent.com
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.215 Safari/535.1
content-type: application/json
Accept: */*
Accept-Encoding: gzip,deflate,sdch
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.3
Cookie: _dd_rails_session=BAh7BkkiD3Nlc3Npb25faWQGOgZFRiIljA4NmUzZDZiNjk5MGYxZDQzNWQ%3D--3e580eae77a1037b347dae6229bb6d

{"user_id":"104465643407894900734","level":21,"sound":1,"score":144768,"xp":130,"gems_removed":348}

उत्तर है:

HTTP/1.1 200 OK
Server: nginx
Date: Fri, 26 Aug 2011 21:54:12 GMT
Content-Type: text/html; charset=utf-8
Connection: close
Vary: Accept-Encoding
Status: 200 OK
Cache-Control: no-cache
X-UA-Compatible: IE=Edge,chrome=1
Set-Cookie: _dd_rails_session=BAh7BkkiD3GOgZFR...wNDUxNTc%3D--b85c8953db82adcb0; path=/; HttpOnly
X-Runtime: 0.009475
Content-Length: 120

{"timestamp":"1314395652","user_id":"104465643407894900734","signature":"PAfgcneDa83-fR5_-CzJWpQ="}

(इसके बाद, कुछ पंक्तियों को केवल हाइफ़नेशन के बिना फिट करने के लिए छोटा किया जाता है)

सरल और स्पष्ट JSON, किसी भी तरह से एन्क्रिप्टेड नहीं। सच है, पते में टाइमस्टैम्प , हस्ताक्षर और सत्र शामिल हैं - इसलिए, किसी प्रकार का हस्ताक्षर है। जवाब, वास्तव में, विशेष रूप से सार्थक नहीं है - सर्वर, अपने हिस्से के लिए, हस्ताक्षर डेटा भी खर्च करता है।

सक्रिय क्रिया

ठीक है, हम मूर्खतापूर्ण प्रयास कर रहे हैं: खेल शुरू किए बिना, हम पूरी तरह से समान अनुरोध भेजेंगे, केवल 99999999 के साथ स्कोर फ़ील्ड का मूल्य बदल देंगे। सौभाग्य से, फिडलर के पास इसके लिए एक उपयुक्त उपकरण है - अनुरोध बिल्डर।

अजीब तरह से पर्याप्त है, जवाब में हमें एक ही टाइमस्टैम्प और हस्ताक्षर को छोड़कर, ठीक 200 समान मिलते हैं। सर्वर की लापरवाह प्रतिक्रिया से हम हैरान हैं, हम गेम के साथ पेज को अपडेट करने की कोशिश कर रहे हैं। अद्यतन होने के बाद, हम और भी हैरान हैं: खेल ने हमें विश्वास किया, लेकिन 99 मिलियन के बजाय यह 16,777,215 गिना गया। ऐसा लगता है कि यह "सीलिंग" है - डेटाबेस में यह सबसे अधिक संभावना है कि यह UNSIGNIGN MEDIUMINT (तीन-बाइट पूर्णांक) जैसी किसी चीज के रूप में संग्रहीत है, जिसमें वास्तव में यही है। अधिकतम मूल्य।

इस पर रोक लगाना संभव है, लेकिन आवेदन की "सुरक्षा" के संदर्भ में इस तरह की शिथिलता के बाद, एक अनजाने में चमत्कार होता है - क्या कोई बड़ा छेद है?

आगे बढ़ते हैं

जैसा कि हम देख सकते हैं, सर्वर के अनुरोध में हमारा user_id पास है - Google+ पर हमारे पृष्ठ का पहचानकर्ता। और हस्ताक्षर, जाहिरा तौर पर, सटीक रूप से आवश्यक है ताकि तीसरे पक्ष के सर्वर को समझ सके कि क्या यह user_id वास्तव में हमारा है। हम्म, क्या वह वास्तव में यह समझता है? या शायद वह इतना भोला है कि वह उसे किसी और की ओर से भी "जीतने" की अनुमति देगा?

हम दोस्तों में से एक के पेज पर चढ़ते हैं, पते से उसकी आईडी खींचते हैं, एक ही अनुरोध में सब कुछ बंद कर देते हैं (ठीक करने के लिए टाइमस्टैम्प भी स्कोर करते हैं)। हाँ, यहाँ सब कुछ ठीक लग रहा है: 400 बुरा अनुरोध ... हालाँकि नहीं, एक मिनट रुकिए:

HTTP/1.1 400 Bad Request
Server: nginx
Date: Fri, 26 Aug 2011 22:07:06 GMT
Content-Type: text/html; charset=utf-8
Connection: close
Status: 400 Bad Request
Cache-Control: no-cache
X-UA-Compatible: IE=Edge,chrome=1
Set-Cookie: _dd_rails_session=BAh7BkkiZ...Tk5NmFkOTA%3D--b96793945142dd62b0e5ea9a; path=/; HttpOnly
X-Runtime: 0.002774
Content-Length: 124

Signature mismatch! Got: V5rwMEQJS_2diQ8sdZMXBs= computed: gcLO6NdBJtwBtOwrWIpwL9LliuA=

संगणित! वास्तव में, स्थिति लगभग निम्नलिखित है: हम किसी और के खाते में प्रवेश करने की कोशिश कर रहे हैं; पासवर्ड जाने बिना, जो भी दर्ज करें; जवाब में, हमें न केवल एक त्रुटि संदेश मिलता है, बल्कि सही पासवर्ड भी। ठीक।

प्रतिक्रिया से हस्ताक्षर को अनिवार्य रूप से कॉपी करें, इसे अनुरोध में स्थानापन्न करें, इसे भेजें। आपने शायद पहले ही अनुमान लगा लिया था कि प्रतिक्रिया में एक पूरी तरह से अनुकूल 200 ओके आता है। और अपेक्षित परिणाम:


(ऊपर मेरा खाता है, नीचे "प्रयोगात्मक" मित्र है)

निष्कर्ष या यह सब "नकली" धोखा क्यों है

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

आपका ध्यान के लिए धन्यवाद - और मुझे आशा है कि मेरा लेख मुख्य रूप से धोखा देने के लिए नहीं बल्कि इसके खिलाफ बचाव विकसित करने के लिए उपयोगी है :)