पायरेसी से बचाव का कारगर तरीका

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

आसान पैसे की तलाश में

शुरू करने के लिए, विचार करें कि Apple ने आपकी और हमारी सुरक्षा के लिए क्या कदम उठाए हैं। इस DRM को फेयरप्ले कहा जाता है और इसकी क्षमता में निष्पादन योग्य फ़ाइल का पूर्ण एन्क्रिप्शन शामिल है, जो कि ऐप्पल द्वारा कल्पना की गई है, रिवर्स इंजीनियरिंग और अनधिकृत नकल को रोकना चाहिए। सामान्य तौर पर, सिस्टम अपने कार्यों से मुकाबला करता है, लेकिन केवल उस क्षण तक जब हमारा आवेदन iDevice को मिलता है। तथ्य यह है कि प्रोसेसर को पता नहीं है कि एन्क्रिप्टेड निर्देशों को कैसे निष्पादित किया जाए, इसलिए ऑपरेटिंग सिस्टम, फ़ाइल को मेमोरी में लोड करने और उसके निष्पादन से तुरंत पहले, इसे पूरी तरह से डिक्रिप्ट करता है। यह यह सुविधा है जो सभी पटाखा सॉफ्टवेयर का फायदा उठाती है। स्मृति में पूरी तरह से डिक्रिप्ट होने और निष्पादन के लिए तैयार होने के लिए आवेदन की प्रतीक्षा में, पटाखा उपयोगिता एक फ़ाइल में अपनी छवि को डंप कर देगी।

स्पष्टता के लिए, मैं दिखाऊंगा कि यह gdb के साथ कैसे किया जा सकता है:

break main #       command 1 #     ,      output.bin dump memory output.bin 0x2000 cryptsize # cryptsize   otool -l   LC_ENCRYPTION_INFO kill quit end start 

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

स्वाभाविक रूप से, मामलों की यह स्थिति विकास समुदाय को उदासीन नहीं छोड़ सकती है। आप एक दर्जन फैसलों के साथ आसानी से Google कर सकते हैं जो स्कूली बच्चों के साथ सामना करने में मदद करेंगे, लेकिन एक नौसिखिए पटाखा के खिलाफ पूरी तरह से असहाय हैं। क्यों? आइए एक नज़र डालें। चेकों का मुख्य विचार एप्लिकेशन बंडल में परिवर्तनों को ट्रैक करना है। उदाहरण के लिए, निष्पादन योग्य फ़ाइल और Info.plist के निर्माण का अलग-अलग समय, या Info.plist का आकार संदर्भ से भिन्न होता है, या _CodeSignature निर्देशिका अनुपलब्ध है। जैसे कि ios ऐप, इन सभी चेकों को ObjC में फ्रेमवर्क का उपयोग करके लिखा गया है।

टेक्स्ट एडिटर में अपने एप्लिकेशन की निष्पादन योग्य फ़ाइल को खोलने का प्रयास करें, और कंसोल उपयोगिता स्ट्रिंग्स के माध्यम से भी बेहतर। आप देखते हैं? आप जो भी उपयोग करते हैं वह एक नज़र में है। यह बाइनरी को आईडीए में लोड करने और यह देखने के लिए पर्याप्त है कि कोड में कौन और कहां इन सभी NSBundle, NSDate और NSFileSize का उपयोग करता है। “दुर्जेय” क्रैक डिटेक्टेड चेतावनियों का उपयोग कहां किया जाता है, आदि। चेक की खोज करने के बाद, पटाखा के लिए 1-2 बाइट्स बदलना मुश्किल नहीं होगा, ताकि चेक हमेशा एक सुविधाजनक मूल्य लौटाए।

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

 #import <mach-o/dyld.h> #define LC_ENCRYPTION_INFO 0x21 struct encryption_info_command { uint32_t cmd; uint32_t cmdsize; uint32_t cryptoff; uint32_t cryptsize; uint32_t cryptid; }; static BOOL is_encrypted () { //         dladdr(main, &dlinfo),   iphone  , //  ,       dl- struct mach_header *header = 0x1000; struct load_command *cmd = (struct load_command *) (header+1); for (uint32_t i = 0; cmd != NULL && i < header->ncmds; i++) { /* Encryption info segment */ if (cmd->cmd == LC_ENCRYPTION_INFO) { struct encryption_info_command *crypt_cmd = (struct encryption_info_command *) cmd; /* Check if binary encryption is enabled */ if (crypt_cmd->cryptid < 1) { /* Disabled, probably pirated */ return NO; } /* Probably not pirated? */ return YES; } cmd = (struct load_command *) ((uint8_t *) cmd + cmd->cmdsize); } /* Encryption info not found */ return NO; } 

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

इस बिंदु पर, जनता में सभी अच्छे विचार समाप्त होते हैं, फिर केवल निजीकरण

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

 ptrace(PT_DENY_ATTACH, 0, 0, 0); 

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

 break ptrace #    ptrace commands 1 return #     ,      continue end run 

कैसे हो सकता है? फैंसी आपी को मना करें और अपने हाथों से एक सिस्टम कॉल करें!
अनुयायी C याद कर सकते हैं:

 #include <sys/syscall.h> syscall(SYS_ptrace, PT_DENY_ATTACH, 0, 0, 0); 

लेकिन, सबसे पहले, syscall एक ऐसा फंक्शन है, जिसके साथ आप ptrace के साथ भी ऐसा ही कर सकते हैं, और दूसरी बात, यह निजी एपीआई का हिस्सा है और सेंसर इसके इस्तेमाल के लिए प्रोग्राम को मिस नहीं कर सकते।
इसलिए, हमें बिचौलियों के बिना, सीधे असेंबलर में एक सिस्टम कॉल करना होगा, क्योंकि यह बिल्कुल डरावना नहीं है:

 asm { mov r0, #31 // PT_DENY_ATTACH mov r1, #0 mov r2, #0 mov r3, #0 mov ip, #26 // SYS_ptrace svc #0x80 //    } 

लेकिन इन निर्देशों को खोजना और उन्हें बेअसर करना अधिक कठिन होगा, खासकर अगर 5-10 ऐसे कॉल हों और वे पूरे प्रोग्राम कोड में बिखरे हुए हों।

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

 otool -l myPrecious.app/binary ... Section sectname __text segname __TEXT addr 0x00002000 size 0x00096980 offset 4096 align 2^2 (4) reloff 0 nreloc 0 flags 0x80000400 reserved1 0 reserved2 0 ... 

जिस कोड में हम रुचि रखते हैं वह 0x2000 के पते से शुरू होता है जिसे हम पहले से जानते हैं, और लंबाई क्रमशः 0x96980 है।
इस जाँच का खाका इस प्रकार हो सकता है:

 __attribute__((always_inline)) void my_secret_checksum() { u_char *buf = 0x2000; u_int res; for (int i = 0; i < 0x96980; i++) { res += buf[i] ..... //    crc/adler   } if (res != ...) { // Achtung! Partizanen! } } 

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

अंतभाषण

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

साहित्य

पैचिंग Iphone एप्लीकेशन पर जीवन उदाहरण के साथ एक अच्छा ट्यूटोरियल यहां पाया जा सकता है ।